Harmonise button width in mobile device

[ElodieOS]

Hi everyone!

I have noticed that the treatment of the buttons isn't always the same. Sometimes the buttons are full width and sometimes not. Can we add a rule that makes them full-width all the time on a mobile screen to keep consistency?

Pages concerned:

• Cart page
• Contact page
• Home page
• Review modal
• My account - Information
• My account - Order details
• My account - Add new address

[SharakPL]

All good except the Add to cart button. Remember this text will be longer in different languages and with 2 items per row this button will have 2 lines or even 3 for very small screens. So either stick to the icon only on mobile (to fix the quantity input group maybe it would be better to pair the button with the price on the same line and let quantity span full width) or we should consider displaying 1 item per row on less than 350px screen width.

[ElodieOS]

Hello @SharakPL! Thank you for your feedback. It's a really good point. Unfortunately, I think we can't pair the button with price on the same line because sometimes you have a reduced price.

I'm going to do some research to find the best solution.

[SharakPL]

I realise that. Reduced price, unit price, tax label - it all could wrap to separate lines. Quantity input group not so much.

[Hlavtox]

@SharakPL I think the pricing is completely different information. I like @ElodieOS proposal on this one.

We could make the button textual with "Add to cart", it could make it more consistent with producuts having "See details" - those that must be opened to fill customizations etc.

We could also use an input group maybe, or use a standard number imput maybe? It could save us some hassle with the +- buttons. WDYT?

[ElodieOS]

Yes, it's a really good point @Hlavtox for the consistency with "See details". In this case, maybe we can go with this design

The button is a little bit empty, but we keep the consistent with "See details" and a sufficient surface to have a comfortable click in mobile.

Another possibility is to change the counter field like propose @Hlavtox by a dropdown. It's less obvious but it can work too.

Wdyt?

[SharakPL]

Most of the time customers want just 1 item so how about leaving just a button with icon and text and if this product is already in the cart then switch the button with the select list.

https://github.com/PrestaShop/hummingbird/assets/5007456/cb4e5e85-6b6e-4083-b48d-80ce5e1c0017

[dennispw]

I strongly advice against using a select element for the quantity. What if a user wants 25 of something? Some shops might sell in batches of 100s? Where should we draw the line?

Let's say you have 12 products per page in a category. Each product have a select with 25 option for each quantity selection. That means that only for quantity selection we have 300 extra DOM nodes.

A select also requires more clicks to have the same effect as simple +/- buttons. Open (1), select (2) and depending on the device/OS/browser a "done" click (3). Adding to cart could be the 3rd (or 4th) click.

While I understand and like the approach @sh proposed, I don't think it's worth the complexity it adds.

I vote for this one - just tighten up the spacing a bit.

[SharakPL]

I strongly advice against using a select element for the quantity. What if a user wants 25 of something?

It's still better to use 2 clicks to select 25 from the list than hit + 25 times or even type 25. Besides adding to the cart from the product list is suppoesd to be just a quick way of buying simple products. If someone wants to configure their product (eg. pick a size, color, quantity, etc.) then it should be done from the product page.

[ElodieOS]

Thanks for your feedback @SharakPL @dennispw, it's a real pleasure to talk about this subject.

From your point of view @SharakPL, a lot of stores put the counter on the product page, but I think it would be preferable to leave it up to the merchant to choose whether to hide or display this functionality in the front office so as not to cause a regression. Perhaps create a new feature in the back office?

As for your proposal @dennispw on reflection, I think you're right: the counter is preferable. There are a lot of different types of stores and products and we can't accurately predict what users' needs are. I think that leaving the +/- and the possibility of typing in the number is the best solution for adapting to a large number of situations.

Wdyt?

[dennispw]

I strongly advice against using a select element for the quantity. What if a user wants 25 of something?

It's still better to use 2 clicks to select 25 from the list than hit + 25 times or even type 25.

But still, is it worth it to bloat the DOM tree with 300 extra elements which decrease effieciency, performance and load times?

Like you said, if the user want a higher quantity they can either go to the product page and/or the cart page. Personally, in this case I would remove the quantity input from the lists all together.

[SharakPL]

@dennispw that's why I prefer showing only a button at first to add a single item to the cart and then switch it with a form to quickly change the quantity. I've been using it for quite some time and I must say it's very useful this way.

[ElodieOS]

Merchants can choose. We could add a toggle (or other) in the back office to display or hide the counter in the product list.

Wdyt @Zoefinders?

[ElodieOS]

The display problem is solved, I'll refer you to this issue https://github.com/PrestaShop/PrestaShop/discussions/33284 for the new feature we've been talking about