Shipping methods: product decisions

Software improvement (Archived)
1

@enricostn @sauloperez and @Hugs are working on Spree upgrade. Pulling some dark rope they encountered an issue with the way we manage shipping methods today, which is blocking Spree upgrade.

What is the need/problem with shipping methods

1- As a Mary/Shannon I want to be able to set up the shipping methods I want for my online shop

  • this can already be done

2- As a user managing multiples hubs, I want to easily set up shipping methods for all the hubs I manage

  • for example we have in France 2 cases where a user manages complex ecosystems with one coordinator enterprises (coordinates OCs) and 15 “distributor” enterprises (each one is a buying group, all managed by the same user). For this user, when he wants to set up a new shipping method, if he needs to go separately in each of the 15 enterprises to set up the same shipping method it is pretty annoying.

What is current behavior

1- Today as a user managing multiple enterprises, I go in one enterprise and create a shipping method and I can apply it to all the enterprises I manage.

Screenshot%20from%202018-04-13%2011-54-54
Screenshot%20from%202018-04-13%2011-54-54961×714 41.1 KB

2- In one enterprise, in section “shipping methods” I see all the shipping methods listed in all the enterprises I have managing permission, so I can choose if I want to reuse shipping methods in other enterprises I manage (apply/unapply).
Screenshot%20from%202018-04-13%2011-54-33
Screenshot%20from%202018-04-13%2011-54-33981×626 47.9 KB

3- If I click on “manage shipping methods” I can access the whole list of the shipping methods attached to all the enterprises I have managing permissions. Strangely, this page appear in no menu (no green menu in the main menu) > this is because technically it is in “configuration” menu but as a regular enterprise user I can’t see that menu)
Screenshot%20from%202018-04-13%2011-55-40
Screenshot%20from%202018-04-13%2011-55-40963×716 42.6 KB

What other problems it causes?

1- UX issues: if I am granted manager rights of an enterprise but manage others that are completely separate, I am “polluted” with useless information when managing those other enterprises.
2- Permission logic could be broken in some case and could open security issues (see Rob comment in #admin on 22nd March on Slack for more details)

What do we want at product level?

It seems to us that we have to decide between 2 approaches:

Screenshot%20from%202018-04-13%2013-40-29
Screenshot%20from%202018-04-13%2013-40-29740×277 66 KB

Option%201%20creationOption%202

On tech side option 2 would be much much easier for the Spree upgrade (on top of solving other UX and security issues…).

Action items

@tschumilas @NickWeir @sstead @CynthiaReynolds @enricostn @sauloperez @Kirsten to decide we need in each of our instances to:
1- Ask our multi-hubs users:

  • Which of the two green sentences they prefer if they had to choose (to see if they value more convenience or flexibility).
  • How often do users change or add shipping methods? (If not often option 2 might be cleaner. We can still improve UX to make users life easier.)
  • Would it be ok for them if we choose to go for option 2, so if they would have, the very few time they have to set up or change a shipping method, to go separately in each enterprise and do the change there? (as a first step before eventually we work on some new feature to make their life easier)

2- Get data on:

  • How many users are in the situation of managing multiple hubs enterprises? (If not a lot also goes in direction of option 2.)

As this is blocking Spree Upgrade we need your feedbacks within a week to be able to move forward (deadline = 20th April)

Connection with payment methods

We foresee that this reasoning will be the same for payment method. Do you agree?

2

On French instance:

  • we have 3 multi-hub managers cases, representing 80% of all the activity and turnover on the French instance. This is because they are pretty big projects, with many consumers ordering collectively through various buying groups coordinated by a single user.
  • in the 3 cases, all the hubs are using different shipping methods (because they use different pick-up points by definition as they are different buying groups!)
  • I asked those 3 users:
    • if they had to change the shipping methods already and if yes, how often?
    • if they feel a need to “share” shipping methods between hubs and if yes in which cases?

My feeling is that they don’t need to share shipping methods really and that they might have changed the shipping methods but very punctually. Anyway as they don’t share today shipping methods if they had to change them they did that only for a specific enterprise at a time. Will confirm when I get their answers.

1 Like
3

I will think about this, but my first response is unfortunately “is this the problem we need to solve”

I don’t know if now is the time or not, but part of our architectural issue is that Shipping Methods are getting used often to transmit Locations and Times (and probably other things) for buying group locations - rather than being used more strictly as shipping methods e.g. collect or deliver

The alternative is to create a whole lot of duplicate Enterprises (w same business information) so that they can be managed with required flexibility in Order Cycles (e.g. issue that @rbarreca raised today)

I feel like 2 would be a much more acceptable solution if we didn’t require creation of these different Enterprises in order to manage timing issues in Order Cycles. Given that people use this as a workaround (and end up w multiple enterprises), making them duplicate their shipping methods (and have to change each of them if they want to increase their home delivery price for example) might be harsh?

BUT that also means that perhaps taking the 2. path is heading us in the right direction (as well as being technically much easier), because perhaps where we want to go is that Shipping Methods are connected with particular Enterprises, and those Enterprises might have multiple Locations (which are identified more with place and time). @oeoeaio have had something like this on our ‘refactor in magic fairy resource land’ list for a long time

@sstead will have a better idea than me, but my understanding of Aus users is that Most are only operating the one Hub enterprise. Except Food Connect which has a couple, but more like 2-3 than 15, so 2 is probably pretty manageable

Sorry it that muddied rather than helped

4

@MyriamBoure do you still want us to answer your questions or do you want to re-frame them in the light of Kirsten’s comments?

5

I think still answer the questions @NickWeir - my comments are more spanners / reminders / stream of thought - unlikely to be resolved within the week to unblock Spree Upgrade

6

I agree with you @Kirsten that the problem is deeper than this but we need a path as you also phrased it.

I feel like 2 would be a much more acceptable solution if we didn’t require creation of these different Enterprises in order to manage timing issues in Order Cycles. Given that people use this as a workaround (and end up w multiple enterprises), making them duplicate their shipping methods (and have to change each of them if they want to increase their home delivery price for example) might be harsh?

Actually real life is that when they do so, they create different shipping method for each enterprise (exactly for the reason you tell, each enterprise has a different shipping method with the specific “LOCATION”) so they don’t really need to share shipping method (or only if they have one share method like “home delivery” that they want to apply to all enterprises but I have not seen yet that case happening.

7

Right now there are 2 ‘food ecosystem’ type users (complex hubs with many locations) who are on-boarding. In doing so - I’m helping them create different enterprises so they can address location complexities for shipping methods (as well as for delivery days, and for product list customizations for location/day - ie: site A doesn’t have refrigeration, on day 2 we don’t have a freezer in the truck…) So - for me, option 2 is fine as we are already down that path. Note that this need for flexibilty around days and locations for a single enterprise is big. For example I’ve been talking more with CSA farmers (now that subscriptions is coming) and many of them will also - in the current system - need to create multiple ‘delivery day’ enterprises too. So its not just a problem of the big, complex ‘ecosystem hubs’ - even small scale CSA farmers have a remarkable amount of complexity in their order cycles - esp re: multiple days, multiple locations, products & fees varying by days and locations… Sheesh.

8

I got the answers from the 3 users concerned in France:

  • 2 doesn’t need to share any shipping method between their distribution location enterprises (15 in one case, 6 in the other case, using multiple enterprises just to be able to offer different locations as pick-up point, so by definition they don’t share the shipping method). Also they never had to change them since they set them up.
  • 1 is using 4 shipping methods shared with 6 distribution hubs but he never changes them so he is ok to accept the small regression that will force him to recreate the 4 shipping methods if he creates a new enterprise (instead of just reusing the existing ones) > so option 2 is ok for him. (Note: also he is using those 4 shipping methods a a hack to ask a 10cts, 50cts, 1€ or 2€ social complementary contribution, so the user can choose between the 4 amounts and the corresponding fee is added up to total. As this use is a hack in any case I wouldn’t take it into account in our decision)

SO we can go for option 2 regarding French instance. :slight_smile:

9

We don’t have any multi-hub users in Australia at the moment. I can’t see a problem with Option 2 (I see the point Kirsten raises, but I don’t think it’s facing anyone here atm). I think a more common issue in Aus is people wanting to apply shipping methods to order cycles - does this current decision impact on how easy it will be to make shipping methods an OC setting (one day)?

10

@sstead I think it could be possible for any option to do it. No impact as technically if a distributor choose which shipping method they want to apply to an OC the system will read into the shipping methods associated with the distributor. Which is the case in both options. For some thoughts I have documented my views on OC redesign linked to network feature overhaul: https://community.openfoodnetwork.org/t/order-cycle-redesign-in-new-product-chain-model/1255 feel free to comment :wink:

11

@NickWeir @lin_d_hop do you get any input from UK so that we can act the decision that we go toward option 2?
Any other comment / opinion on that @oeoeaio @maikel ? Would be great to decide by tomorrow as blocking Spree upgrade.

12

@MyriamBoure - can you give me access to this order cycle design discussion? Seems odd I don’t have access.

13

I am happy with option 2. The whole idea of shared shipping methods has always given me the heebie-jeebies.

At the risk of opening a can of worms, the same issues apply to payment methods, and IMHO this is the more urgent problem to solve, but happy to tackle this as the test case and deal with payment methods later.

14

It makes sense to me that one order cycle can have different shipping methods to others. And if we associate s shipping method with an order cycle, then it seems the cleanest to have only one order cycle per shipping method. Sharing makes everything complicated. When changing a shipping method, we need to display all order cycles it affects. Adding features to bulk-edit un-shared shipping methods seems a much clearer interface.

15

Ok so @enricostn @sauloperez @Hugs continuing our disccussion in Barcelona, it seems that you have the answer to the question you were asking regarding Spree upgrade: we all agree for option 2. Do we want to open an epic or story within an epic for it? Also do we want to open an epic/story to cover the payment method case as well, which seems pretty prioritary as well? (don’t know if impacts Spree upgrade as well or not…). Let me know if you want me to open them on GH or if you do it.

16

@tschumilas you should have access now, you had not been added to the “close” section of community for “staff” but it is done now. We tend to forget to add people there, sorry :frowning:

17

Let me put here the tech decisions we took at the Barcelona gathering.

Firstly, this does not depend on the upgrade and can be done in parallel. There are no major changes affecting either shipping or payment methods.

Secondly, in terms of the data model, we will have a join table that associates shipping/payment methods and enterprises and they won’t reach beyond the scope of the enterprise. We may have duplicate data but we trade security for redundancy (and so storage). As it has been said before, we’ll make it easy from the UX perspective to copy methods if needed.

The join tables stem from the desire to avoid touching Spree, which means not adding columns to its tables.

As for the data migration, we’ll clone any methods that are being shared between enterprises into separate copies for each enterprise.

The one below is the only photo I found about the discussion back in Espai 30.

IMG_9154
IMG_9154.JPG1024×768 144 KB

@Matt-Yorkley @enricostn @lin_d_hop feel free to add anything I may have missed.

18

hello! I am coming very late to this shipping methods party :slight_smile:

I am sorry but I dont understand the problem we are trying to solve here. In the main post " What is the need/problem with shipping methods" we have two points, 1 says “this can already be done” and point 2 seems to be the problem that we would create if we implement Option 2 proposed below… can someone clarify please?

The same question for payment methods, what is the problem of sharing payment methods? Maybe what’s being requested is to separate permissions to “manage an enterprise” and to “manage that enterprise’s payment methods”, so that I can share management of my enterprise but I do not share permissions to change my payment methods?

19

I’m flagging this older discussion @Mario. I was just reviewing all things shipping related to see what issues were already out there as I prep my papercut suggestions. BUT when I read this I thought of the network features. leaving shipping controlled at the enterprise level might be insufficient in our long term vision for B2B2C. We are now talking about multiple shipping steps - first from the supplier to the hub, then from the hub to the consumer. I don’t know if we should be rolling shipping discussions into network or not - but I’m just flagging. We already know - given above discussion - that controlling shipping at the enterprise level is insufficient for what we need NOW (ie - it needs to be controlled at the OC/store level) but if we imagine a fully fleshed out Network feature - our current shipping approach is inadequate. (FYI - just putting on your radar for the back of your mind.)

1 Like
20

I just moved this to the wishlist category. This is now not related to the Spree Upgrade. It’s just something we want to improve in OFN.