Item count does not update when SpreadShop cart is updated

[jtlapp]

The shopping cart's item count does not update when changes are made from within the SpreadShop cart proper, although it becomes accurate when you click to view the plugin cart. The count only updates when new items are added to the shopping cart from outside the SpreadShop shopping cart. The plugin can report the wrong number or a number that disagrees with the number shown for the SpreadShop cart. This is sure to cause users heartache. (My upgradeable-core pull request addresses this issue by making it an option to remove the real-time count entirely.)

[RobertSpread]

Within the basket there a re a couple of elements triggering a change of quantity. I will add a listener to these items. From my perspective this is not a big issue as I would, per default, hide the spreadshop cart when the custom cart is in place. Everything else leads to redundanct and confusion. No customer should need to ask himself why there a re 2 carts.

[jtlapp]

Oh, good point about not ever wanting to see two carts or two counts at once!

I think making further dependencies on the current SpreadShop UI implementation is really fragile. Instead, I'm now thinking that we need special support from the SpreadShop cart. There should be a way to subscribe to notices that the cart has changed. When we get the notice, we just recompute the item count from scratch. SpreadShop will probably also want to subscribe to this function, because our plugin might also change the shopping cart. And providing such a special function would free SpreadShirt from ever worrying about breaking our stuff, or us worrying that they'd break our stuff -- because that one subscription function exists only for third party plugins such as ours.

[jtlapp]

Oh, maybe I didn't fully understand your original point. It seems that if the plugin cart does not appear whenever the SpreadShop cart appears, there is actually no need to ever dynamically update the plugin cart.

This does force site developers to make sure the plugin cart is hidden at the right times. I think I could manage it on my site by only showing the cart on pages that do not show the store. The only odd thing about that is that the site user can't make a habit of always looking at the top of the page to find the shopping cart -- it won't be there if it's embedded lower on the page.

[jtlapp]

I'm now thinking that we need to be able to move the cart out of the SpreadShop store for the entire site, so the user always thinks to go to the same place (presumably the page header) to see the shopping cart. In this case, we'd need a fully-capable cart that receives SpreadShop cart update notices.

But this cart would only need to receive the addItem notice, because we would not be allowing the user to open the SpreadShop cart to do other cart edits.

[RobertSpread]

Well, this plugin has the intention to work on any site to give the customer just on cart everywhere.. This is also why I will remove the config from the html side again and force the spreadshop cart to be hidden when this plugin is used. You are absolutely right with the dependencies on the shop. I consider it as an API that might or might not change. But since I am sitting next to the developers of the shop, we will know quite fast if there is anything to adjust. In the long term, being independent is definetely the goal.

[RobertSpread]

I will close this ticket for now but am open for discussions on this (just want to keep the backlog clean ;)) The spreadshop cart is now always hidden (via js and css) and therefore will not cause any "why is there a second basket" confusion. With this the interaction between spreadshop cart and SpreadCart is also less relevant.

[jtlapp]

This might be a good solution, but there are two things to remember:

(1) When you create a store, the user expects to be able to get to the shopping cart on any page via the menubar at the top of the page. This solution seems to have the cart sometimes in the menubar and sometimes not. While the cart may be visible elsewhere on the page, not having one place to always look for the cart produces a detrimental user experience.

(2) My solution included a configuration variable (showBasketIcon) that eliminates the update problem because it doesn't show the item count. This solution allows the cart to be always available in the menubar, even when a more capable cart is shown in SpreadShop. The more capable cart should be shown when available so the user can edit the cart. So always having the SpreadShop cart hidden when the plugin cart is available breaks my reason for this configuration variable.

There is one other minor thing to consider. Developers of small web sites don't normally think of conditionally including CSS. The CSS is usually included in the template for the whole site and never thought about again. This just adds an unexpected, but minor complication. It is possible to make the spreadcart plugin includable within this template and to only show the plugin when the named element is provided. We haven't implemented that, though. We could make this require a bit less thinking on the site developer's part.

I've had another thought. What about moving the spreadshop cart to the menubar, instead of using our plugin? Every page of the site would include the store, but some pages would only show the spreadshop cart from the store and hide everything else. Probably complicated to implement, though.

[jtlapp]

Also, did you forget to check in the file with the configuration variables? I don't see how people even learn what they are at the moment.

[jtlapp]

Actually, I don't understand why the configuration variables were removed from index.html. index.html is a demo file. Developers understand that they only conditionally include the SpreadShop configuration where needed, and they'll understand that they only conditionally include the plugin configuration where needed.

[RobertSpread]

Upps, file for configuration was missing. Now it is added. Maybe I have been lost in translation. Let me try to address the points you made (btw. I really appreciate our conversation here):

1.The goal of this plugin is, to give semi tech savy people an option to have the basket everywhere on his page. Even if there is no shop you want to have a basket. This is why it reads from the localStorage. To prevent the basket showing up several times or on different places I now force the spreadshop basket to be hidden to prevent confusion

2.I would prefer to always having just one cart. Otherwise people might be confused why cart a looks different and has other options compared to cart b. Also the increase of the item quantity in the cart is a rare case so it is not that big of a problem to not have this option. To display a consistent cart at one position with the same featuresDeletion is, I hope, more imporatnt. You are right, this makes the configuration you added obsolete but I believe that this is no big issue.

The reason why I initially implemented the plugin is, that hiding everything but the cart creates a huge overhead. We would always load all data and need to wait for the entire shop to be loaded. This will have a huge impact on the overall page performance in case of an unchaced shop.

let me know what you think!

[RobertSpread]

Sorry, just read your latest comment now. I removed the config from the demo HTML so that the plugin can be used everywhere. If we assume that you have domain.tld/shop and domain.tld/home, then you want to have the same cart on both pages. Instead of defining the config on both pages you should just need to define it in one place, the config file. This reduced the complexity. I have WP in mind where you hook the needed files into the header section and then you will have it automatically everywhere. If you configure everything on page level the effort to get it running would be quite high.

[jtlapp]

Regarding your (1), yes, I understand that you want to prevent confusion. That is, confusion about the count of items in the cart.

Regarding (2), the new plugin cart is not something I would use. My objective it to make the user experience as good as possible. Users must have the ability to edit the cart. For the sake of helping the user order more than one item of a kind without inclining them to repeatedly select that item and its color and size, they need access to a cart that allows for changing quantities. If we don't provide that, we still need the SpreadShop cart.

My showBasketIcon configuration variable solves all of these problems because it allows me to hide the item count and eliminate any potential conflicts. It is another way to solve the discrepancy problem, and it is so far still my preferred way.

[jtlapp]

But the SpreadShop cart is giving me some trouble showing dialog boxes in places where they cannot be seen, requiring a reloading of the whole page to recover. Might be best for us to implement a fully functional shopping cart so we can reasonably forever hide the SpreadShop one.

[RobertSpread]

Hey jtlapp,

Thank you for the input! We have to make a call on priorities here. The question is what is more important. The functionality or the consistency. I want to go, based on the data I have, for consistency. Why is that? If we go for consistency, we would always hide the spreadshop own cart. This allows the shop partner to have one cart on all pages, on the same position, with the same functionality everywhere. And we would also automatically solve the issue with the update of the quantity counter. On the other hand we would lose the functionality to increase the qunatity of the basket items in the basket. But, is this functionality important? From a user flow and from the statistics I have, the answer should be No. It is an extremely rare case that people add more than 1 item of the same size and article and color to the cart. This happens for group orders sometimes. It happens, but not often. If customers want to do that, they hit the add to basket button several times as they have the need to add more items when on the product detail page. Since they also do not know, that this option exists in the basket when they already do know that they need more that 1 item, they will go this path.

If we go for functionality, we have the issue that there are 2 basket representations. These representations have a different layout, functionality and positioning. Based on the fundamentals from Steven Krug (don't make me think) this is not ideal. When people see two carts, they assume it is there for a reason. I ultimatively want to avoid this congnitive load.

Based on this, I prefer the current proposal.

[jtlapp]

I agree. We should only have one cart. But it should be fully functional.

I haven't yet looked into why you're delegating deletion to a PHP server, but requiring delegation to a server might render the plugin unusable to some users. Dunno. It might be helpful to provide a read-only version of the cart, which would have to complement a fully-functional cart.

I'll look into writing a node.js proxy. I'm not running PHP.

[RobertSpread]

I agree, the full functionality should be something we aim for. The reason to go with the proxy.php is, that I have some cross origin issues going with JS. Whilst I will check tonight if there are some CORS options I missed so far. The reason why it is currently php is, that 25% of the web is running on wordpress (http://venturebeat.com/2015/11/08/wordpress-now-powers-25-of-the-web/) and I wanted to support the majority first. But as you pointed out, there are quite some alternatives we can go for!

Again, thank you for the input and effort. I am enjoying this quite a lot!

[jtlapp]

Sure! Thanks for jump-starting this whole process. It's more complicated than I imagined it would be. There's a comment on one of the support sites saying that any programmer should be able to use the API to provide a universal cart, so it's not necessary for SpreadShirt to provide one. I think the complexity proves otherwise. But if we get the job done, maybe SpreadShirt won't have to. Oh wait -- you are a SpreadShirt employee -- so maybe this is the intended way to provide the solution! Haha!

Oh yeah. If you're going to provide any server-side solution, have to do PHP first. You should be able to port over anything I write. But I want to confirm the cross-site issue first. Thanks for the heads up!

[RobertSpread]

Well, I am the product owner of the entire shop project. So I can assure you that this is not the way to crowdsource this topic. It is a tough call to make for me here. We do know how many users integrate in external websites, we do know how many people have iusses but we also know that there are higher priorities. This is why I build this in my spare time between work and playing with my child to give everyone a option. And yes, our API is complicated. But we try to solve this issue in an other project.

[jtlapp]

Hey, you're a pretty good inside contact. Haha! Wow, I'm impressed that you would take on an outside job of helping the few of us trying to do multi-page integrated sites. Thank you sooo much!