Future of Padloper - New Project Lead Announcement

[HMCB]

@kongondo you should consider crowdfunding this. Kickstarter or whatever. The community needs an official or reputable shopping solution and what you’re doing is so much work without a guarantee that it will pay off for you.

[szabesz]

Happy and productive new year! ?

I opt for this one:

5 hours ago, kongondo said:

• 2-column layout with vertical sidebar menu on the left and main content on the right (maybe with an option to collapse the sidebar)

Please do not try to take on too much work before the initial release regarding the GUI. I think one layout is just enough to start with. Besides, if we have two layouts then it will make creating docs an tutorials more complex as we need to account for both. Configurable layout is less desirable than and easy to use one right from the beginning.

I would not like to see an app like behaviour as that implies mobile only experience which can never be as productive as a well tailored desktop GUI. Sure, it should be usable on mobiles without any irritating issues but that is of second concern to me.

 

Edited January 13, 2019 by szabesz
typo fix

[cb2004]

20 hours ago, HMCB said:

@kongondo you should consider crowdfunding this. Kickstarter or whatever. The community needs an official or reputable shopping solution and what you’re doing is so much work without a guarantee that it will pay off for you.

Interesting concept, you could offer a license for the people that did fund you and it will give you some enthusiasm, but may of course hold you to deadlines, ha ha. Putting my cards on the table, I am not sure if I would ever use Padloper, I would love to but the need hasn't come up yet. The only thing I like about WordPress is the speed you can get WooCommerce to market. However I probably would Kickstart it as I know it would make a great addition to PW. There may be many like me, so if you offer up the license to people who do fund, you are not missing out on anything, only they are if they don't use the license.

Great thinking HMCB.

[alexm]

On 12/18/2018 at 10:00 PM, porl said:

Thanks for the quick response! If I was to use Padloper for the payment side, would it be difficult to, say, add to a template the option to "automatically charge me each month" and then use some other module (cron like for instance) to use Padloper's api to charge again on the schedule?

I feel that if that is simple enough to hook into and I could also get simple information (last time this member paid for the month membership etc.) then it might make a good solution. Otherwise you might be right to suggest looking at other "membership modules".

 

On 12/19/2018 at 1:02 PM, kongondo said:

Maybe by setting up recurring payments, say in PayPal, it might work? I've not tried it so just guessing here. This would mean automatically triggering a PayPal payment request, again, something I've not tried before.

 

GoCardless is perfect for membership type payments. Direct Debit mandates are created and then once a customer has set up a mandate with you you can subscribe them to a package and set recurring payments and the interval between payments in years or months and how many payments should be taken. e.g. you can have a package that takes a payment monthly and you can set it to recur 10 times or it could be a yearly membership. GoCardless have various webhooks which can send info back to your application via a callback URL. @porl You could definitely get something like this set up. The API documentation is pretty damn good. You could then suspend a membership automatically if for instance a payment fails or the member cancels their direct debit.

[alexm]

@kongondo Are you still working to a March/April timeframe for the first release? I've got a project that I'm doing in phases and if it's a matter of a couple months I may well hold off on installing the existing version I have to save switching things out later.

@HMCB Cool idea.

[kongondo]

3 hours ago, alexmercenary said:

Are you still working to a March/April timeframe for the first release? I

A couple of things have derailed me some, so I cannot promise this. Beta testing will also take a bit of time, sorry.

[alexm]

4 minutes ago, kongondo said:

A couple of things have derailed me some, so I cannot promise this. Beta testing will also take a bit of time, sorry.

No worries at all! Completely understand. Let me know if you want me to give this a trial run at any point when it's in Beta. Would pay the going rate up front also.

Best of luck with it mate! Looking forward to putting it to good use! ?

[Jozsef]

6 minutes ago, kongondo said:

A couple of things have derailed me some, so I cannot promise this. Beta testing will also take a bit of time, sorry.

Count me in too. ? I'm also waiting for this for a project where the website is done and I have to add the shop in later. No point to go with the old version. Let me know if you need any testing done, happy to help and pay the price.

[MateThemes]

On 1/13/2019 at 3:03 PM, kongondo said:

Shop Dashboard/Backend GUI

Hello good people. It's GUI Time! 

It's time to start thinking about the backend GUI (your Padloper shop Admin/Dashboard). I'd like to hear your thoughts regarding the layout. What is your general preference? What would your clients prefer? The options are:

1. 1-column layout with horizontal dropdown menu (orders, products, reports, etc)
2. 2-column layout with vertical sidebar menu on the left and main content on the right (maybe with an option to collapse the sidebar)
3. Shop resembling an app (meaning will look different from rest of ProcessWire admin).

Another variation could be a full-width screen. This would also look different from the rest of the ProcessWire admin.

I am leaning toward #2. Alternatively, we could make this configurable and offer two choices; either #1 or #2. 

Thoughts?

Thanks.

Hello!!!

It is good to hear that you are that far with your shop module. I am waiting for it!!! :-0)

I think the second option would be the best. Because it is easy to work with especially on Desktop.

I am looking forward for your great module!!!

Have a good day!

Gerald

[Jozsef]

On 1/13/2019 at 2:03 PM, kongondo said:

2-column layout with vertical sidebar menu on the left and main content on the right (maybe with an option to collapse the sidebar)

I put my vote on this one too. Conventions play a big role in usability and people still use computers or large enough tablets to get work done (e.g. managing a shop).

[alexm]

7 hours ago, MateThemes said:

2-column layout with vertical sidebar menu on the left and main content on the right (maybe with an option to collapse the sidebar)

I'd have to back this also. My logic being that it's a familiar set up for users of other e-commerce solutions such as Magento (who now use a sidebar in v2), prestashop, shopify etc. Also if they've all adopted the sidebar perhaps this is from some UX studies? Seems likely.

[Kiwi Chris]

On 1/14/2019 at 3:03 AM, kongondo said:

Shop Dashboard/Backend GUI

Hello good people. It's GUI Time! 

It's time to start thinking about the backend GUI (your Padloper shop Admin/Dashboard). I'd like to hear your thoughts regarding the layout. What is your general preference? What would your clients prefer? The options are:

1. 1-column layout with horizontal dropdown menu (orders, products, reports, etc)
2. 2-column layout with vertical sidebar menu on the left and main content on the right (maybe with an option to collapse the sidebar)
3. Shop resembling an app (meaning will look different from rest of ProcessWire admin).

Another variation could be a full-width screen. This would also look different from the rest of the ProcessWire admin.

I am leaning toward #2. Alternatively, we could make this configurable and offer two choices; either #1 or #2. 

Thoughts?

Thanks.

Conditionally 2, provided the collapsible option is available. One of the things I like about Processwire is that it plays nice with mobile screens. Some other CMSs are clearly designed for desktops or large tablets only, but Processwire will work even on a smartphone. I can't say how often I'd actually use it on a phone, but it would be nice to have the option.

I actually can think of a case where having the backend mobile friendly would be handy. I was at a market last year, and someone didn't have any cash, but did have a credit card. Of course the front end of my site is mobile friendly anyway, but it could be handy to have the backend mobile friendly too.

[MateThemes]

Hello everybody!

Are there any News for Padloper 2 now?

Thank you!

[kongondo]

On 2/21/2019 at 3:46 AM, MateThemes said:

Are there any News for Padloper 2 now?

We're still working on it :-). I'll write a progress report (post) next week.

[gornycreative]

Looking forward to seeing this project in beta!

[kongondo]

13 minutes ago, gornycreative said:

Looking forward to seeing this project in beta!

I'm looking forward to seeing it in alpha! ?. Most of it (especially the backend) is already planned (going through several iterations) and all that is remaining is the relevant code. 

[kongondo]

News Update - 6 March 2019

Hi all. How time flies! It's been a while since I gave you an update on progress.

Taxes

Most of the current work has focused on Taxes. Although the last mini update talked about the GUI, the main work has gone into taxes. I went back and forth on this one but I think I've finally arrived at something I am satisfied with. Looking at other systems, I liked both the approaches of Shopify and Woocommerce, but especially the former. The approach we'll take will marry the best of both worlds. In a nutshell, taxes will involve/feature the following:

• You will first need to set up countries that you will be shipping to (this is done when setting up shipping zones).
• An overview of the shops tax settings.
• Tax Overrides: Use this feature to override the base tax rates and taxes on shipping per country and/or country state/province. You can create a product category (aka collection) to which a specific tax override will apply.
• Tax Exemptions: At each product level, you will be able to specify whether a product should be charged tax or not. However, you will also be able to exempt some customers from paying taxes on purchases. Currently, email addresses will be used to identify such customers.
• Option to choose if taxes should be charged on shipping rates or not.
• In cases where more than one tax can be applied, choose whether taxes are compounded (e.g. a country + province tax) or one used instead of the other.
• Specify whether digital products should be charged tax (e.g. EU VAT) or not.
• Evidence of buyers location for EU VAT.
• Specify if taxes are calculated based on origin (where you are shipping from/your shop location) or destination (where you are shipping to)[default].
• Specify if stated/displayed prices include taxes already or not.
• Print out tax reports (how much tax you've charged over a given period).

Taxes in the United States are a bit tricky to determine. We'll do our best to accommodate the needs of Padloper users in this country.

Please note that although Padloper 2 will ship with base rate taxes for most/many territories of the world, including their states/provinces where applicable, and whilst we'll endeavour to regularly update tax rates, the responsibility to ensure that a shop/business is charging and remitting the correct taxes lies solely with the shop owner. Shop owners can use overrides to update their taxes in cases where Padloper 2 base tax rates are not up to date. We will not accept any responsibility for any wrongful tax deductions due to incorrect base rates and/or overrides. 

GUI

i was hoping to have something for you to look at by now but I needed to sort out tax related logic first. I wanted the logic to guide the GUI design and not the other way around. So, you'll have to take a rain check on this one.

Files

We had a bit of a think on how to handle files (downloadable/digital products, site-wise assets, etc). No final decision has been made but the goal is to be as versatile as possible.

Notifications

We've started drafting plans on how this will work. More on this later but this will involve email notification to yourself, customers and shop staff regarding their orders. Some notifications will be (semi-) automated, e.g. sending order confirmation, order status change, etc.

That's it for now. By next update, I'm hoping to have something for you to look at, however crude :-).

 

Thanks!

[alexm]

@kongondo Awesome! Taxes are a ball ache. No mean feat, so can totally appreciate everything you're saying. Looking forward to hearing more. ?

[kongondo]

Hello all,

Multilingual

Quick question(s). I am working on the GuI and refactoring Product code that I posted about a couple of 'updates' earlier. I want Padloper 2 to be multilingual ready from day one. I am not talking about translatable strings but fields whose input may need to be multilingual, for instance Product names, descriptions, etc. I've gone back and forth about product categories, tags and options and their values (e.g. Colour => red, blue, yellow; Size => Small, Medium, Large) but I think these too should be multilingual ready.  For instance, you French site can list or users can search for "Rouge", "Maison" etc or you might want to display petit/rouge for the French version of the site and small/red for the English one. Given this, the recommended way to go in ProcessWire are multilingual text fields. This invariably means that most things are 'pages'. On the other hand, for some functionality, if I didn't need the field to be multilingual, I could even make a custom DB table as opposed to a field, if I thought it had some advantages over creating a custom Fieldtype. 

I just wanted to pick your brains about this issue. Is there anything that you think I should consider? Anything you think I might have overlooked? My current position is to go with ProcessWire pages and multilingual text fields for product properties that can be translated and will need to be displayed in the frontend. These include titles, description, types (e.g. trousers/pantalon), tags (red/rouge), categories (summer/été), etc. I'd love to hear your thoughtss.

Thanks.

[Marco Ro]

Hi Kongondo, at moment for us the Multilingual Text Fields and the Type Options Fields works well. Maybe I wrong but perhaps the multilingual system should be something  that is about the website. But sure the new Padloper must be ready to accept the multilingual version. 

Thank you and good work!

[kongondo]

1 hour ago, MarcoPLY said:

multilingual system should be something  that is about the website

You are right. I am not referring to the website. However, you might need certain aspects of your products to be multilingual, for instance, their categories/collections, descriptions, etc. Padloper needs to make sure that the developer/shop owner has inputs corresponding to the languages they have installed for entering information. In my example above, if you had a product "Trousers" and your shop is in Canada, you probably have an English and a French version of the site. Padloper needs to give you inputs for both when you are creating product categories, tags, or inputting product titles, descriptions, etc. 

Maybe you are thinking about old Padloper ? :-). 

1 hour ago, MarcoPLY said:

But sure the new Padloper must be ready to accept the multilingual version. 

Exactly.

[szabesz]

Hello,

I support this:

18 hours ago, kongondo said:

My current position is to go with ProcessWire pages and multilingual text fields for product properties that can be translated and will need to be displayed in the frontend. These include titles, description, types (e.g. trousers/pantalon), tags (red/rouge), categories (summer/été), etc.

In other words I think supporting multilingual stores is a must and doing it the PW way is the easiest to use by those who will build stores based on Padloper 2. Regarding performance, custom db tables might have an advantage but – I guess – most Padloper 2 sites will never reach the point when it matters.

[Jozsef]

I agree, Padloper should work the Processwire way, that's the whole point of it. Using multi-language fields and page objects for products is the way to go.
I guess most of us who builds a PW store will expect it that way.

[nfil]

Looking forward to the alpha version of Padloper

[kongondo]

News Update - 3 May 2019 - Part One

The little speckled fella has been very busy on the trail. Despite being the smallest of its kind, she has lofty dreams. 

We've been working on the API and the Products GUI. In the next post, I'll tell you more about the API.

Products Features and GUI

Though there are a few issues still pending (aren't there always? sigh), I am relatively pleased with the results. Of course, during beta testing we'll received and incorporate feedback as best as we can. Only UI-Kit theme will be officially supported. 

• Multilingual fields if site is multilingual
• Ajax powered inputs for fast and convenient editing
• Four types of products
  • Physical product requiring shipping
  • Physical product not requiring shipping (for collection)
  • Digital product
  • Service/Event (etc) products - e.g. Swimming lessons, Consultancy services, Hotel booking, etc
• Product Classification (ajax powered) by:
  • Type: e.g. Belt, trousers, etc
  • Brand: Puma, Sanyo, whatever (editors can type in or import brand names + planning to support logos)
  • Categories (aka Collections): Multiple categories, e.g. Men, Girls, Hospitality
  • Tags: Multiple tags can be entered, e.g. sale, amazing, etc
• Product Variants (consists of an Option (e.g. Colour) and an Option Value (e.g. Red)
  • Add zero or n variants as you wish
  • Live preview as you build variants
  • Each created product variant can be enabled/disabled. Devs can then decide to either show that variant as unavailable or not show them at all. That's up to you :-).
• Apart from classifications, shipping class, inventory policy, weight and dimensions units, title and description (and this latter one may change), almost all product properties will vary by variant if variants are used
• Product properties include:
  • Images
  • Colour (more on this below)
  • Downloads (centralised and reusable)
  • Price and Compare Price (aka former price)
  • Inventory policy (whether to track or not)
  • Charge taxes
  • SKU (stock keeping unit)
  • Inventory (quantity)
  • Allow back orders (aka overselling) - @note: this can be set per variant. This is useful if one variant can be restocked faster than others
  • Weight
  • Length
  • Width
  • Height
  • Weight Unit (mg, g, kg, oz, lb, t)
  • Dimensions Unit (mm, cm, m, in, ft )
  • Shipping Class - can be used for product-based shipping if needed (e.g. bulky goods, light, fragile, small items, perishable, etc)
  • Images (more on this below)
  • Downloads (more on this below)
• Images 
  • Multiple images can be added to both a product and its variants (in case its has some). 
  • Images add to the product itself can be used with all variants
  • Images added to a variant are tracked/tagged as belonging to only that variant
  • In some cases, it may not make much sense to add different images for similar variants. For instance, a small red hat and a large red hat could probably share the same images. Although we do not currently support specifying an already uploaded image as belonging to a group of variants, this may change in the future
• Colour
  • Similar to images, can be set at both product and its variants level
  • Colour saved in RGBA format
• Downloads
  • Also similar to images, can be populated for both both product and/or its variants
  • Multiple files can be added to a product
  • A file designated for 'whole' product will be available to download irrespective which variant of the product was purchased
  • Conversely, a file or files saved for a variant will only be available to the buyer if they buy that variant of the product
  • The above is useful if you want buyers to be able to download different files of the same product. For instance, recently someone needed to sell two versions of a font as part of one product. This is a solution for such cases.

 

TODO List

Lots!  e.g. default settings for some properties, e.g. weight unit, shop currency, etc.

For the frontend, we are creating a rich language-aware API that you can use to build your shop however you want. There will be no rendering of markup (but see first post in this thread about a separate fully functional frontend shop). In the next post, we talk a bit about the API. Before that, here are some screenshots and a video demo (if you can spare some 20 minutes away from watching, er..., cat videos? ?)

Screenshots

 

Video Demo

 

Thanks ? 

Edited May 3, 2019 by kongondo