Just dumping my latest thinking around Order Cycles for comment. Please try and poke holes in it, I am starting to go around in circles and can’t think objectively anymore.
The primary drivers for the proposed change are:
“Order Cycles” are a difficult thing to understand, they can be very complex, and in their current form it is difficult to hide complexity from new users
The complexity also means that we have A LOT of logic to run through to determine who is allowed to add/remove change things, resulting in very poor performance in complex multi-hub OCs with 500+ products. See G#838
Order cycles don’t currently have any way of repeating autonomously, so this must be done manually by the user, which is totally unnecessary.
We need a way of grouping Order Cycles together in order to implement Standing Orders.
The structure of Orders Cycles is overly prescriptive. For example: in order to share an incoming product list, shops must also share OC open and close dates and vice versa.
What I am about to propose might seem like a fairly massive divergence from our current conception of Order Cycles, but it is one that I think should be capable of retaining most if not all of the current feature set in a much more manageable way, so bear with me.
Proposal
New way of defining the “Cycle”: I am calling it the “Schedule”. Schedules:
have a set a frequency, ie. weekly, fortnightly, monthly, or “always open” (see bottom of my comment below
have a start and end date
contain logic to set OC open/close dates, relative the the frequency (eg. “[Monday] @ [5:00pm]” for weekly, or “[Second][Wednesday] @ [2:00am]” for monthly)
can be used by multiple “Shop Configurations” (or maybe not, see comments below)
can be created and edited inside of the new/edit interface for “Shop Configurations”, so despite being a separate model, it should be relatively intuitive to set up a Schedule and understand its importance.
“Shop Configurations” store all of the information about how and when a shop for a given enterprise is visible, They:
define a group or series of order cycles (the user does not need to look at these or even know that they exist - see point 3)
have a Schedule
contain logic to determine a pickup time for an OC relative to the opening or closing times defined by Schedule.
define a naming convention, so that each OC can be named automatically based on a user-defined naming template - (which will have a sensible default defined, so new users will not need to use this)
have a list of products (as defined by an Inventory List) which is used to populate OCs - (which will default to the shop’s default Inventory, so does not need to be understood by new users)
store information about which Fees to apply and how (per supplier, per product tag, or universal) - (none by default)
can be Tagged (none by default)
All information defined by a Shop Configuration is inherited by its child OCs, but can be overridden by an OC when necessary, in a similar way to variant overrides. So OCs simply become a way to deviate from the patterns defined by the Shop Configuration/Schedule. This means that complex functionality and fine-grained control is available to power users, but is completely hidden for new users with simple requirements. (eg. the only reason that I can think of that Baw Baw Food Hub would ever need to override a Shop Configuration/Schedule is in the event that we pack on a Wednesday rather than a Tuesday if the Tuesday is a public holiday - maybe once or twice a year)
Shop Configurations/OCs pertain to a single enterprise only, ie. the shop that will be selling products. This massively reduces the complexity of the interface.
There will therefore be no more incoming and outgoing exchanges. By default, products for the shopfront will be specified by the Inventory List defined by the parent Shop Configuration, unless overridden by a different list on an OC by OC basis.
Prerequisites
Inventory Lists
Dependents
Standing Orders
Discussion
Realistically, the change described is so massive that this will probably need to be built as a feature that exists concurrent to the existing Order Cycles UI, rather than as a drop in replacement. This will allow users to migrate across to the new model/interface in their own way, rather than having to try and write what seems to me like an impossible data migration. Once all users have migrated across we can hide the old Order Cycle UI, effectively making it obsolete.
During the transition, we could make it so that users who have never used the old Order Cycles interface would not be able to access the old interface, thus removing a confusing choice between Order Cycles and Shop Configurations.
The feature that will allow all of this to happen is Inventory Lists, which will provide a way of mapping out the set of products that should be included in an order cycle. Hopefully this will mean that once a Shop Configuration is set up, users should not need to look at it on a recurring basis ever again.
We could build a simple version of this feature without necessarily having to do anything about Inventory Lists, but that would mean that a shop could only ever have one configuration (in terms of the products they sold). ie. their inventory (each shop only has one at the moment). Still, perhaps this is a good first step?
If anyone can think of a better noun than “Shop Configuration” please let me know.
@oeoeaio
Sir, you are a genius
This sounds great! The really clever bits will be the UX design so that the complex features are still intuitive but most users don’t get wrapped up in them.
Can you expand a bit on this? Are they really going to be so reusable?
define a group or series of order cycles
All information defined by a Shop Configuration is inherited by its child OCs
There is a bit of a mix here of Schedule, OC, ShopConfiguration. Not sure how a Config could define a series of OCs and be a parent to them?
Might ShopProfile work as a name? Just a thought.
If considering this level of refactoring, what about considering how an Enterprise could have an Inventory for sale without tieing it to any cycle at all? To enable producers to simply have shop fronts where they sell all the time.
I guess it is up to us to decide. I think it introduces unnecessary complexity. The reason I included the shared element is really just to replicate existing functionality. Buying groups in Aus have tended to use a single order cycle with shared Opening and Closing times, but I don’t have a good feel for how vital this is, or whether it was simply a decision forced by the desire to share incoming product lists and fees. I guess the question is: are there any instances where multiple shops really need to have Order Cycles that are in sync with each other? The model I am proposing should allow deviations from the pattern of open and closing times defined by the Schedule to be synced across multiple shops, by altering the schedule itself, though I am yet to think this all the way through. So, basically: I am certainly not wedded to the idea of shared Schedules, in fact I would personally like to avoid sharing if possible.
Yes, I agree. I’ve only really come up with this current format in the past day or two, so it’s still a bit fresh. If we don’t need to share Schedules they can become a part of Shop Configuration rather than a separate model, so that may simplify things a bit. In terms of Configs ‘defining’ and being ‘parent’ to OCs, ‘defining’ is probably the wrong word. Configs would have_many OCs, which would be automatically created upon initialisation of the Config. I am thinking that once a Shop Config is defined its end date could be extended, thus allowing more OCs to be generated, but the start date should probably remain fixed?
My only issue with this is that we already use the term shop_profile to describe Enterprises that are in the system as a shop/hub, but which to not have a subscription for an actual OFN shopfront. ie. they are essential a placeholder for a name, and a point on a map. Also, terms like Configuration or Layout, Setup seem to describe what we want better, ie. a collection of settings which determine how your shop functions. I don’t know - I’ll keep thinking about it.
Yes, I have thought about this. What about the idea of allowing a Shop Config to define a special type of schedule that is “Always Open”, which could be open and closed manually using a big red button on the Shop Config that says “Open Now” or “Close Now” depending on the current state. There could even be a default ShopConfig set up for all new shops that makes products from the shop’s default inventory available using this type of Schedule. This would mean that as soon as new users have set up products, shipping and payment methods, they could head to the ShopConfig page, hit the “Open Now” button on the default Config that is waiting for them and their shop would go live. What do yo think?
Even if yes, is it worth the complexity of sharing objects? Why can’t they just define the same thing? With the other changes, the overall definition becomes easier anyway.
Is it possible one Config might have more than one Schedule?
My preference would be no. Partly because I can’t immediately grasp how that would work (in either the UI or in the model), which is starting to be a red flag for me. Mostly because the model is simpler with one schedule per config, and I suppose I would like to think that the point of all of this refactoring is to end up in a situation where it takes such a tiny amount of time to set up a new ShopConfig that it removes the need to build any time-saving cleverness (read complexity) into the model. What do you think?
Yep, I think so. That is a job for me for tomorrow. If you have any ideas for UI I’m all ears.
Just another thought I’m having: if we are going to map ShopConfigs and Schedules one-one, how do you feel about just calling the ShopConfig the Schedule and mashing everything into the same model. There is not really any value in keeping the two components separate. Is Schedule an intuitive name for the model we are designing here? It has_one enterprise, a frequency, an open/close pattern, a pickup time pattern, a name pattern, has_one inventory, fee rules, tags, has_many OCs, has_many StandingOrders. Is the time-component important enough in all of that to call the whole thing a Schedule? I suppose it is a little weird to call it a Schedule when the frequency is set to “always open”… I just really don’t like ShopConfig as a name.
Yeah, it is kind of overloaded, but the timing component is certainly the most central element of the model, and the element that users are going to think of and engage with first when they go to set one up. A lot of the other elements are hidden or only engaged with by power users.
If I say “the next step is to set up a schedule for my shop”, it is certainly not going to throw me off if I need to also select a list of products that will be available during the open times that I select, and for basic users, that should be all that they need to do.
The word “Profile” for a shop doesn’t describe a use to me, maybe it does to you. A “Schedule” for a shop immediately tells me that it is a way of setting up timing around my shop, and when I am presented with additional options, at least I have a bit of context within which to make decisions.
