I think we possibly all agree that the big jump into API-standalone is ultimately where we really want to go.
BUT on examining this, there are some relatively minor things that can make embedded shopfront do the trick (including for Village Centres) for the short-medium term - especially if:
embedded shops can be made operational on mobile by fixing G2425 . . (fingers crossed)
There are some additional relatively minor requests from Village Centres for changes to the shopfront and tweaks to embedded. Two of them are already requested more broadly and covered in Pt 1 (make/keep filters and search accessible when scrolling; and +/- buttons for adding to cart)
The others are listed below. I think they’re all technically quite manageable - likely using shop preferences. They may present ‘philosophical’ questions for community discussion:
Ability to hide order cycle selector and info, default to only or soonest closing OC - not needed / taking up space / confusing people where OC is always on (I think there would be other users that appreciate this)
Option to hide tabbed info menu (About, Content etc) as this would be handled in host/embedding site - doesn’t need to be duplicated here
Move ‘Powered by OFN’ from the header to the footer
Option to not display link to Producer name / modal … this is the one I am most unsure about … further discussion as to importance / reasons i suspect ofn community hesitant pending
Interesting ‘philosophical’ questions - basically, does the OFN community want to ‘insist’ on certain features/appearances because they evidence our values? I’d say ‘yes’ - certain things in the platform are there BECAUSE OF our values and they should not be removed. So for example - we believe in transparency - so producer name should not be removable. Removing the producer from the picture is exactly what the dominant, consolidated, unfair, food system does. I don’t think we want to go down the same path. Having the producer identified, in my view, is mandatory for someone who wants to use OFN. I care less about 2 or 3, and I think we need to keep 1 - I’m also thinking there are users who need this.
I think 1 as you say can be some more general request and not only linked to standalone website use.
I would vote against option 4, especially because if the producer is not communicated transparently, the hub will attach the product to their own profile so user will see the product is supplied by the hub and no further info has been transmitted. We want to support transparent food system, so allowing to remove transparency is a bit contradictory to me… when the API is usable and users want to do their own thing, that’s ok, but as long as it is powered by OFN I wouldn’t encourage removing transparency.
For 2 and 3, this is work that we would ditch when we switch from embed link to API strategy (or will we still keep a basic embed link?) so if it is super easy and that enable to get Village Center in we can do it I would say… else I would try to make them understand our API path strategy and support it I guess shopfront module will be the first one we will want to APIze so the question is then to prioritize…
yes - good to support generally as multiple users who would need it, could be a shop preference and not just for embedded use. I am still a bit unclear on the DorV actual need, and whether what they really need is just ability to customise the text so it says “Order in next ‘10 mins’ for Delivery tomorrow” I note that is also linked to @ybo’s questions that have come up in UX design. I will create a wishlist item to discuss possibilities for options and customisation of OC display . .
As above, yes but general not just embedded. We have issues in Mobile Ready design and project to automatically remove empty / unused tabs (e.g. #2710) so I think this will be a pretty straight-forward follow-up. GH Issue.
Some info: we had a conversation with the OFN devs (in Porto) and @Sacha today and he is going to propose to build a standalone “shop” website consuming the OFN API to display and propose products for sale on a standalone website to his Ruby student fellows
We will know early next week if the project is taken, it would be 4 students for 2 weeks full time on a prototype. So I would move to “discovery” if this project starts as it would fuel the brainstorming on our API solution for this use case.
Moved that to curation as it seems vague, we are not sure what we want to vote on and prioritize, need to be worked on a bit and separate wishlists open to each of the needs. We can do that after part one is done maybe to learn from it
Further context notes on slack.
I guess shopfront module will be the first one we will want to APIze so the question is then to prioritize…
