An order cycle has been tagged for specific customers for a shopfront that uses registered only access.
Most shoppers will only have one order cycle that they can choose from, however these shoppers still have to click the order cycle selection box and choose the only available order cycle.
Affected users / customers
Shopfront users for shops with registered users - i.e. Locavore
Problem impact
Users may think that there is no order cycle available for them - a particular issue for new users
I agree with @sauloperez@SineadOFNUK it should directly open the only shop available, for me it is a bug as well. So please fill in a bug, add it to bug backlog how prioritary you think it is compared to other bugs… (don’t be afraid, we will try to push more bugs in the pipe when Spree upgrade is done… they are accumulating…)
@sauloperez@MyriamBoure I am unfamiliar with tagged customers and order cycles, but I wonder if this is actually part of a bigger UX discussion (which I am yet to wishlist) about behaviour of the oc dropdown? My understanding is that the current default is to ALWAYS force the customer to choose so that you know that they have seen the date that they are getting their order. If it defaults then there is a risk of ‘no cognition’ - a frequent problem with systems like this
I get what you say @Kirsten but I think the situation described by @SineadOFNUK is not designed that way, today already if you have only one OC it is directly displayed, you are not asked to choose. The “bug” is that you are asked to choose in this specific situation even if there is only one OC because you are a tagged customer and even if the shop has mutliple OC opened you can only access one. So it’s kind of a UX bug, it was designed to not display the selector if only one OC is available.
The redesign proposed by Yuko IMO doesn’t solve that. IMO I would open that as a bug in GH as the system has been designed to not display the selector if one OC so if it does, it’s a bug. And the same bug will continue with the new design of the selector. So we need to fix that bug for the new design proposed by Yuko to work properly for tagged customers
@Rachel do you agree ? If yes let’s open a bug and close that wishlist item.
Does it make sense @Kirsten ? Also I thought this redesign was part of Mobile Ready feature, isn’t it ? For me it has already been prioritized. If not then yes we need to prioritize so to be able to vote in it.
Yes this is also how I understand Sinead’s post @MyriamBoure However whether it is a bug or a feature I don’t know. Was this case of tagged customers for private shopfront ever tested with this rule? Maybe it’s something that was forgotten during production phase. In that case it’s not a bug…
Hum… I understand your point @Rachel but as our process were not so precise and we don’t know, I would propose to treat it as a bug, as it should have been tested. Also it’s not about tagged customer for private shopfront, but for any tagged customer that in the tag rule has access to only one OC even if two are open. It appears as a bug for user so the user see it as a bug…
OK, but this is not the definition of a bug It seemed at first that this was more a case that has been forgotten. Btw even if testing brought it up, to me it’s should still be a new feature.
Anyway if everybody is fine with it being a bug, I will follow
It’s a good use case to help us learn as a team !
For me a bug is “the system is supposed to work that way, and it doesn’t”. It if was badly designed but work as expected, this is not a bug.
How is the system supposed to work ?
For a given customer:
If there is only one OC, the user is not asked to choose, the active OC directly displays. The selector dropdown is still visible though, but with nothing to choose from. So @Kirsten I disagree with your interpretation of how the system is supposed to work as it already doesn’t ask to choose if only one OC
If there is more than one OC, the user is asked to choose before the content of the shop displays.
As I don’t know the case of tagged customer were included and we have not way to really know it, I would say that:
displaying automatically the content of the shop if a tagged customer has access to only one OC is the way the feature was designed to work, so maybe we forgot to test that case, but it is a bug if we refer to how the feature is supposed to work
not proposing a dropdown with choosing option is there is only one option is bad design but not a bug, so it’s a new feature type “UX improvement to reduce confusion for OC selection”
if we forget a test case and release a feature that is nos working as expected because of that, it should be bug no ? Or we can decide afterwards to rescope the feature that was released… and then decide to treat as a new feature the thing that is not working yet. I guess it’s a case based decision @Rachel ?
Would be good to have @danielle opinion on this so we right down some rule for such case and know how to treat them ?
Well, for me this should not be case based :). A bug for me is : we have designed / incepted something like “this”, and when testing / using it is doing “that”. I had the same state of mind as you at first Myriam. Especially because when using it you feel it like a bug.
But when doing retrospective with devs, they told me their side of the story : it’s like when someone ask you to do a job, but your work gets “rejected” by something that was unknown to you when you were doing it. So this is unfair.
So if we have forgotten a use case, we should IMO always add a new feature and not a new bug. This will force us to write better feature in the first place. Also some test case could really take much time, so I would feel better to re-prioritize them rather than seeing them strait in github again. Indeed, you t-shirt estimate the work based on test cases. So if you miss one this means that more work is necessary. In some cases this could lead to something becoming larger than expected.
I would also add that it would help us to have a better view of our product. So if we say “we have lot of bugs” it would be for “real” bugs and not stuff we forgot.
I don’t think it’s rejecting what the devs has done, but I get what you say and happy to try to follow that process. I put it as ready to vote for then.
It seemed at first that this was more a case that has been forgotten. Btw even if testing brought it up, to me it’s should still be a new feature.