Tagging ShippingMethods to OrderCycles

Tags: #<Tag:0x00007f2199317088>

Very often we get asked if it is possible to limit the display of specific shipping methods to specific order cycles. This then allows an appropriate “Pick Up from The Bakery” to be shown when selecting order tag “Ready for Tuesday at the Bakery”.

Currently the work around is to tag customers to both of these things. But this means that you have to have a private shopfront and force customers to log in before they can buy from you, so that you know the customer is ONLY able to buy from their appropriate pick up point. Using these features prevents spontaneous sales, which impacts our users. And it doesn’t reduce the communicative burden of making sure the OCs and Shipping methods state their relative availability. Or administrative burden of ensuring that new customers are correctly set up. Or spontaneity of customers to be able to choose a new point from week to week.

Customer can select from a range of Order Cycles when making an order, specified as ‘Ready For’. Once they’ve selected the order cycle they want they go to checkout and only have the appropriate delivery methods available.

Real World Examples:

  1. Hub can have a different order cycle and delivery for different towns: Ready in Coleford on Tuesday, Lydney on Friday.
  2. Hub can offer Home Delivery on Wednesdays but not on Saturday.
  3. Farm can offer Tuesday delivery from the Bakery, Wednesday from the Farm, Saturday from the Market.

Although a little clunky, the interface for this already exists. In the same way that you can tag an ordercycle to a customer set, you could tag the order cycle to a shipping_method. And you can tag a shipping method already in edit shipping method. All we need is for these to link together.

I guess the most logical way for the user is if we use the existing Tag Rules tabs in the Edit Enterprise section.

Something like:

Exchange and delivery method both implement act-as-taggable. So the task here is to set up the ability for the enterprise to create rules between them.

@oeoeaio In your mind could this just slide into the existing tagging models?
Can you see any complications of doing this?

Also ping @Kirsten @maikel @danielle @MyriamBoure

That would be a great feature. A lot of businesses use something like that. I’m just wondering if tagging is the right model. It looks like you want to associate order cycles with shipping methods. But does that association need a name (tag)?

I’m just bringing this up, because the data model could be simpler and more explicit if we introduce a new relation instead of using tags.

Hi @maikel
Totally agree that the tagging feature is actually a bit of an overkill for this relationship. However I did think about this and there are a few reasons I think it might be a good move anyway:

  1. Uses functionality that already exists. This would possibly mean faster development, and potentially easy for the user to understand.
  2. Allows tags to be reused. I can imagine this being really useful. For example you have a ‘Saturday Market’ tag and you can tag specific delivery, payment methods and customers all using the same tag.

Very happy to re-explore this with just a new relation. As you say @maikel it would be more explicit and simpler in this case.

@oeoeaio @Kirsten @sstead @mags @danielle @NickWeir @MyriamBoure what do you think on this one?

I think that this relates to conversations around Inventory 2.0 (believe it or not), because we are imagining a stripped down Order Cycle interface that basically just sets a timeframe and links a whole lot of things together for that timeframe. The key thing here is using Inventory Lists (exclusively?) to manage product and variant availability. We had talked about selecting which payment and shipping methods available to which shops at an OC level as part of this change. But not sure when it will happen.

I guess my point here is that if we are (eventually) heading in that direction, it would probably be better to skip the tagging thing and just enable selecting shipping methods at the OC . . any thoughts @oeoeaio @sstead

@lin_d_hop I agree that this functionality would be very valuable!

For the majority of our users (people running simple shops, and not using the tagging tool) tagging is not a very user friendly way to setup OC specific shipping methods. People get overwhelmed easily and I think they would prefer to select which shipping methods are available in the OC interface. It might suit more advanced users who use tagging already, but most of our users don’t fit that category.

That said, I don’t know what the ‘ease of development’ factor would be. And whether, it’s worth developing this given the likely Inventory 2.0 changes, which might make it redundant.

@Kirsten Inventory 2.0 sounds brilliant. What kind of timescale are we looking at for that do you think? Would that be funded largely under the la poste work? Is there a spec anywhere?

I am not allowed to distract Rob at the moment (note not using his handle :wink: as he is exclusively focused on standing orders. But when that is done I would be keen to see if we can come up with an MVP of this. There are bits of specs in a number of places, so the first thing would be for me to spend a couple of hours pulling it together to do a draft ‘big picture’ spec, from which we could attempt a phase 1. Funding for it is really not clear, as is always the case for these ‘core but not urgent’ things. I think there could be bits in a bunch of places and essential to some of the more advanced wholesaler to retailer or buying group operations we’re anticipating. I suspect it could also intersect with some of the trickiness in Spree Upgrade at the moment

Ha ha ha ha - laughing and crying :slight_smile: I just came in to create a wishlist item for 'User can choose which shipping methods are available to specific order cycles" and found this discussion

Well it does seem that ‘inventory 2.0’ has come a long way from my comments above - but based on last night’s discussion might be strongly suggesting that we are comfortable with tagging as a way to manage complexity and flexibility (with lots of careful ux design)

So based on that - my vote is to progress this idea with tagging! and perhaps it might not even be that hard . . . anyone have a t-shirt size indication? @Matt-Yorkley @luisramos0 @maikel

@Kirsten I havent validated with other devs that tags are a good idea. Here I see Maikel suggesting normal associations.

The power of tags is not only the name they bring, the major power I think is that they are not an association between two specific entities, they can be used to connect whatever we want. For example, you can tag shipping methods and than use that tag in OCs to filter available shipping methods but you can also then tag products to only allow certain shipping methods.
Tags bring more complexity to the implementation but are then very powerful tool to solve user problems… we need find the right balance between simple associations and powerful more complex tags.

The tags UI presented by Lynne above is quite complex for the user and also for the developer.

In this particular case, I tend to think a simple association between OC and ship methods is enough? Unless we have other plans for these tags and are willing to pay the complexity price…

Maybe I don’t quite understand - can someone give me a quick example of how a ‘simple association’ would work? It would just be that I can select which shipping or payment methods apply directly in the order cycle?

yes, that’s what I meant by “simple association”. can be many to many: you can select multiple ship methods for an OC. That is still a “simple” association compared to using tags.

So - its like a simple association now with an enterprise fee for example? I set up an OC, and can select which enterprise fee(s) apply. I would be able to select which of my shipping methods apply. I could select which of my payment methods apply. ??

But, doing it by tagging - like tagging a shipping method to an order cycle - gives us more power - and future potential - with a short term time trade off. Is that fair to say?

Apologies - because to me from a user perspective, simple association and tagging seem like the accomplish the same thing. I’d like to understand the power/future potential LOST if we go simple association now. Will it impact network features for example?