Openfoodnetwork: Backoffice Product List table UI uplift

[mariocarabotta]

What is the problem we are solving

As part of the network inception work, it's been highlighted several times that there's an internal interest to move away from the Inventory functionality altogether. It’s hard to understand for some users, it has been adopted from others when it’s not actually needed, and it also present some technical challenges that we want to minimize in the future.

We’ve also run interviews with producers and hub contributors, asking open ended questions and showing some digital prototypes. Some of the positive feedback we got was around a cleaner user interface for the product list, and consolidating the functionality available in the product list with what’s in inventory.

From a tech stack point of view, there have been several discussions around moving to React for the backoffice. This is a good opportunity to start the transition.

Slack channel

backoffice-ui-uplift

Discourse
MAIN Backoffice Product List table uplift: https://community.openfoodnetwork.org/t/backoffice-product-list-table-user-interface-uplift/2098
Network Inception: https://community.openfoodnetwork.org/t/backoffice-product-list-table-user-interface-uplift/2098
A new admin interface for OFN: https://community.openfoodnetwork.org/t/a-new-admin-interface-for-ofn/1784

Objectives and key metrics

Product: Reduce the number of people that use inventory just for ease of use
Experience: Provide a better interface for all of OFN enterprises
Technology: Move to a more modern system for the backoffice that might also attract new contributors
Design: Build the foundations for a backoffice design system

We would measure the success of these objectives by looking at

• reduction in % of variants with variant overrides with at least one order in the last 6 months that don’t have neither stock nor price overwritten
• reduction in % of users using inventory altogether

How this could look like

Explanatory videos have been posted in the main Discourse thread for community feedback. The main prototypes are:

Create first product

• Landing experience for a new producer opening the product section of the backoffice
• Creating the first product (no changes)
• Viewing the product list table for the first time

Columns selection and table scrolling

• Selecting columns
• Scrolling laterally when many columns are visible
• Scrolling vertically

Edit fields inline and add tags

• Edit unit
• Edit stock
• Add tags to product
• Add tags to variant

Filter by categories and tags, sort

• Filter by category
• Filter by tags
• Tag filter rules
• Sort by stock level

On demand and unit display fields

• Change variant to on demand
• Change unit display

Figma files

Project specific: https://www.figma.com/file/kBvKYXnaNU0thSnKJUoyup/Product-List-UI-uplift
Library: https://www.figma.com/file/A1RDmHC9dMxhjF7JTtiMuB/Components-library

Note: these mockups are based on the Material-UI react library. Icons are part of the Community Material Design Icons.

Milestones

This project is divided into 2 main milestones:

1. Product list table feature parity
2. Table uplift

The first milestone replicates all of the existing functionality of the product list.
The second milestone introduces a few new features that ideally would encourage the users above to migrate from inventory back to product list, specifically:

• ability to add tags to products and variants
• ability to filter product list by tags
• ability to sort table by fields different from creation date (current)

After milestone 1, the improvements could potentially be released to the public, hence splitting this into 2 chunks of work.

[jaycmb]

This looks great!Until we have the Epic broken down into stories, some quick feedback on the designs here:

• Overall: Reminder that an additional column for Unit Prices is needed on product list page

• Creating variants:
  To me the "_New Variant"_ looks not intuitive enough for a (first-time) user to add new product variants → what about adding a "+" icon in front of _New Variant_ and possible make it a clearer Call-to-Action, like the "+New Product" button ?

• Columns/ UX Writing
  Seeing this for the first time, to me is not entirely clear what _On Hand_ means. Maybe adding a tooltip here?

[mariocarabotta]

Thanks @jaycmb for the feedback!

• Unit price - Yes, it was still kind of in progress while I was designing this, so I did not include it. Do you think it would need its own column? otherwise we could make the price field open a small overlay window (like unit) and display actual price and unit price fields

• New variant button - I played around in previous iteration with the idea of having a plus icon next to it. I removed it because it made it a bit too noisy, but we can definitely re-assess this as we build and find lighter icons or use a different colour
  

• I agree on the On Hand copy. I've always been a bit confused about that too, and I wonder if we could just move to a _Stock_ labeling convention here. I'd be curious to know what name is used in other languages too!

Cheers

[jaycmb]

Notes of Product & Design Meeting Nov 17th

with @kirstenalarsen @RachL @Erioldoesdesign & Hernan (OFN Colombia)

Further details on the points discussed here in Notion

High Level Summary on open questions discussed:

1. Tech-Related Issues

• _Responsive for a v1?_ : Agreed on that responsive is a necessity (and different from building great mobile UX), so needs to be implemented from the beginning

Decisions on the following topics postponed, until devs/teach lead join the discussion:

• CSS Framework: Use of UI component framework vs utility-based framework?
• Tags: or will this be introduced to users who are not using inventory first? -> tech input is needed for setup architecture behind tags in product list (will inventory tags keep working in parallel / are there overlaps with tags used in other parts of the backoffice?)

2. Product-Related Issues

• Confusion around product variant stocks are adding up to product stock < remove this functionality

Next Steps / Actions

• [ ] Sync existing feedback / information (across Notion Pages, Discourse Posts, Inception Pipe..)

• [ ] Product & Design Discussion documented here in Inception Pipe, Community feedback gathered in Discourse

• [ ] Discuss Tech-Related Topics (see above)

Mock up requests

• [ ] Prototype an example product with on demand stock info

• [ ] Include "display as" (example of milk bottle @Erioldoesdesign ;))

• [ ] Include Unit Prices

• [ ] Remove the 'total' stock number from the 'original product' (on hand)

• [ ] Propose an alternative for "On Hand" that´s more intuitive

[Erioldoesdesign]

Design round up of Mock-up AC's

Mock up requests

• [x] Prototype an example product with on demand stock info
  I actually don't think this is needed, it already existed.

• [x] Include "display as" (example of milk bottle @Erioldoesdesign ;))
  Done across all the prototypes on the existing link on milk bottle examples and also the jar of marmalade example
  Something to consider is how it's then displayed in the UI which is a bit odd:
  

You get a little bit of text underneath each drop down stating the changed display name:

• [x] Include Unit Prices
  Done:
  

• [x] Remove the 'total' stock number from the 'original product' (on hand)
  Done!

• [x] Propose an alternative for "On Hand" thats more intuitive

One demand was tricky, I don't have any better ideas only this alternative which isn't better, just different:

Other things I did and updated

• [x] Variant button now has the [+] icon
• [x] Added unit prices into the column list and reordered the column list to be same order as left to right display.
• [x] Added an arrow after the 'NAME' column to show that it is, like 'last updated' a sortable alphabetically click action.

A long comment on responsive stuff

Responsive is proving to be trickier than i'd hoped but I'm glad I've investigated it. I explored some ideas where even though we have 9 columns max that are available to display horizontally, we limit the max amount to 4 or 5 across the width and find a way to display some functions vertically, or collapse columns (kind of like how zenhub does this) but it looks like there's already a part of the design where the product image and name is 'sticky' to the left hand of the screen and then the remaining columns are horizontally scrollable.
I also started to think what if some columns are traded out for others. So you get a max of 5 columns seen at once. This is all speculation on what would be useful so I don't think it should go in any of the UI uplift work. But I have big critical questions as to whether the optimum workflow for users making edits to products in the product list is to jump around edits that chaotically. I'm not saying it's impossible or doesn't happen, but is it the behaviour we want to encourage?

To be honest I don't think there's a particularly good way to get multiple, functional (as in editable) columns across a smaller screen. I've looked around at complex dashboard and even google analytics pretty much just makes users deal with a horizontal scroll but it's worth looking at GA's mobile app for a more 'streamlined' workflow. I worked on products like this twice, that are basically spreadsheets in mobile app form and it was essentially an exercise in compartmentalising certain operations into forms in individual pages and menus.

[Erioldoesdesign]

Do we still think that the column 'on hand' needs a tool tip?

[Erioldoesdesign]

Design next up for UI Uplift

• Any settings page changes that are affected by product list changes? (e.g. tags in settings)
• Connection between product and BOM (and other areas) for table style changes?
• Tool tips needed?
• Multiple shops mock up
• Filter by producer mock up
• Is the cards and non-cards visual hard on eyes? Test out all card design.

[jaycmb]

Feedback on Designs

Unit Display I find not understandable without the explanation text
-> better: _“Displayed as”_ or _“Shown as”_, to make it consistent with the phrasing in the variant overview

One idea that came to me when looking at the new designs related to Unit Prices:
what about having a _“shown as 5€/kg”_ description text underneath the Unit price, same style as the “shown as 1 small bottle” underneath the Unit?

• [ ] By “propose an alternative to ‘on hand’”
  was meant the phrasing in the column where it currently still says “on hand”, not the on demand. See comments further up this thread:

I agree on the On Hand copy. I've always been a bit confused about that too, and I wonder if we could just move to a Stock labeling convention here. I'd be curious to know what name is used in other languages too!

So, to your question: the column does not necessarily need a tool tip, but clearer phrasing. Maybe simply: _“In Stock”_?

But yes, the _"On Demand"_ is a separate thing and I personally find "Unlimited" slightly easier to understand than On Demand (not intuitive!) but also not optimal, because it´s technically not unlimited supply. I think that would be a case for User Testing :)

Responsiveness

Agree on it´s certainly a challenge “to get multiple, functional (as in editable) columns across a smaller screen” 😅

That again brings up the question of: How likely is a user going to edit columns from mobile? Which columns are essential for these use cases and even which functionalities do they need?
Considering Jen´s research insight _that farmers wanted tech that they could manage on their phones because for many standing at a market stall in the city is the only time they have great internet connection_. maybe more users than we would expect?

Yes, we decided that´s out of scope for the V1, but still I feel put effort in setting up a flexible system from the start that allows users to easyly(ish) manage the columns they want to see (and possibly edit) across different screensizes is well invested.

But I have big critical questions as to whether the optimum workflow for users making edits to products in the product list is to jump around edits that chaotically.

-> You mean by displaying only 5 (or x) columns max, user would have to jump around different views if they d like to edit one of the non-visible?
If yes, I agree that this is not desired behaviour and can easily lead to more frustration.

[jaycmb]

Is this still Blocked by "Product Input needed"?
Or currently Tech & Community?

[RachL]

@jaycmb we need @kirstenalarsen 's input on scope to have final community approval. Then a lot of question are remaining for the new dev that will pick this up with the nex tech stack.

[kirstenalarsen]

Only additionl comment I have here I think is that @mariocarabotta did do a lot of thinking about positioning and selection of columns. This included lots of looking at other ecommerce and food / product / inventory systems and shaped his suggestions as to which ones should be left, prominent, sticky I think. Not sure how this plays into responsive, but might suggest that the five suggested by default were considere as the most important.

For my 2c, on mobile i'd be inclined to suggest that bulk edit isn't really needed as much. I we had great display of search and filter, display of the key info and a nice big edit button that opened a nice modal to easily change stock, price, upload new photo or edit descrition that might deal with most of the needs. with ability to go deeper if they need

[kirstenalarsen]

re. scope

• Any settings page changes that are affected by product list changes? (e.g. tags in settings)
  I don't think so. as discussed on slack the tags in product page are not goin to be connected to tag rules in this iteration and perhaps not even soon

• Connection between product and BOM (and other areas) for table style changes?
  this is broaer UX strategy that is more a question for you than for me @Erioldoesdesign - how do we want to go about applyin new admin styling across admin? Nothing is yet prioritised or proposed. The orders page would defnitely be a contender, but that might be uite a thorough redesign and I doubt it wll be prioritised above network, aPI, reports etc

• Tool tips needed?
  I don't know

• Multiple shops mock up / Filter by producer mock up
  are these kind of the same thing? but anyway YES I think this is a priority. I think it did appear in earlier versions but then disappeared. It definitely needs to be understood how this will work and ieally before we start builng in case it has any significant implications

• Is the cards and non-cards visual hard on eyes? Test out all card design.
  not sure what this means

[Erioldoesdesign]

There's some further questions that came up from my conversation with Theresa and Laurie last week that I've briefly spoken to Jana about but need some organisational PM input.

[Erioldoesdesign]

Both the notion document, Figma designs and the discourse post have now been updated!

[Erioldoesdesign]

This moving into the dev pipe?

[Matt-Yorkley]

CSS Framework: Use of UI component framework vs utility-based framework?

There's no clear plans on this yet, right?

[Erioldoesdesign]

CSS Framework: Use of UI component framework vs utility-based framework?

There's no clear plans on this yet, right?

Hmm I think @jibees would be the best person to answer that, we're building a 'pattern library' and I assume that it's compatible with Reactive Rails but unsure if that means we can use Tailwind CSS et.c or not.

Some of what was designed for UI Uplift followed some of the Material UI which is something I'd like to understand more as far as potential restrictions or not

[Matt-Yorkley]

I think we need a bit of discussion and a really clear picture of exactly what we're doing in regards to those tech choices before we move this into dev ready :+1:

[Matt-Yorkley]

Some of what was designed for UI Uplift followed some of the Material UI which is something I'd like to understand more as far as potential restrictions or not

Material-UI is specifically a React component framework, right? I don't think it's an option.

So the question is; what _are_ we going to use? There's MaterializeCSS, which might have a similar feel?

Tailwind

Oh god... :see_no_evil:

[Matt-Yorkley]

There's a Material Design Bootstrap package that looks pretty good: https://mdbootstrap.com/

• reasonable licence
• lots of ready-made styling on components and UI elements
• great documentation
• the JS bits don't depend explicitly on jQuery
• should be simple for first-time contributors to work with
• looks very similar to Material-UI

[jibees]

@Matt-Yorkley What's the problem with Tailwind or any utility first CSS framework? I would be in favor of going on this (and not something like MaterialUI or Bootstrap which is good to create a POC and bootstrap, but a hell to customize as it's not designed for this)

[Matt-Yorkley]

Tailwind

The creator of Tailwind themselves says: "If you can suppress the urge to retch long enough to give it a chance, I really think you'll wonder how you ever worked with CSS any other way". I guess I'm still in the retching phase :joy:

Don't get me wrong, I'm all for utility-based CSS classes, composition over sub-components, and content-agnostic component naming. I'm also not a fan of the BEM approach to solving the traditional problems with inheritance in CSS.

I'm a big fan of Bulma, mainly because the utility classes are actually _human-readable_.

Bootstrap 4 is not great, but Bootstrap 5 has basically been heavily rewritten to focus on utility classes. It's also highly customisable via SASS variables. MDBootstrap combines Bootstrap 5 and Material Design 2.0 (if that's the aesthetic we're going for?).

If we go with Tailwind we'd be styling every single element from scratch, right? As opposed to having 99% of the styling handled already by a library that already has the look we want?

I don't like the overall results of Tailwind's approach of condensing absolutely _everything_ into tiny utility classes and applying all styling by adding an ever-increasing list of non-human-readable classes-with-modifiers onto each element. eg:

Dumping 100% of the styling into the markup doesn't seem like a big leap forward to me... :man_shrugging:

[jibees]

If we go with Tailwind we'd be styling every single element from scratch, right? As opposed to having 99% of the styling handled already by a library that already has the look we want?

I think it's the main point here, driving all the decision we should take in a near future concerning any CSS _framework_.
I personally think that believing in: _99% of the styling is already handled by a library_ is mostly true for a POC driven by developers, but, over time, mostly false for an application driven by a UX/UI team.

I don't like the overall results of Tailwind's approach of condensing absolutely everything into tiny utility classes and applying all styling by adding an ever-increasing list of non-human-readable classes-with-modifiers onto each element.

Yes, it should be ugly, and maybe it's not perfect. But as we want to work more in a _component driven development_ way, once a component is customized, you don't have to edit any of the classes just use the component. Thus, code is written once.

_To be clear:_
I originally used to develop buttons like this:

<a class="button">
  Button
</a>

and yes, I really enjoyed _CSS framework_ that gives me this button class.

But now, in a _component driven development_ way, we use:

<Button>Button</Button>

and I really enjoy writting highly customizables components like this:

const Button = (label) => (
<button type="button" class="focus:outline-none text-white text-sm py-2.5 px-5 rounded-md bg-blue-500 hover:bg-blue-600 hover:shadow-lg">{label}</button>
)

[Matt-Yorkley]

once a component is customized, you don't have to edit any of the classes just use the component.

That would be equally true if we leant on an existing library whilst making components, right?

99% of the styling is already handled by a library...

If we're working towards designs based on Material Design and we can either a) import something that's already done 99% of the work (and includes utility classes and SASS variables), or b) painstakingly build everything from scratch (starting from zero)... that's not a trivial thing, right?

Thus, code is written once

Is it though? I was chatting to someone recently who worked with Tailwind and they ran into a conundrum of how to refactor their code. It looked like this: they had a set of styling applied to all H1 elements in the codebase. Every time they wanted to use a H1 title in a page, they had to replicate it, and ultimately it looked a bit like your button example, with a huge string of classes.

class="focus:outline-none text-white text-sm py-2.5 px-5 rounded-md bg-blue-500 hover:bg-blue-600 hover:shadow-lg"

They had three options for how to deal with this:

1. Copy-paste this chunk of code for every page title. Obviously that's bonkers. It's apparently common for Tailwind devs though!
2. Use Tailwind's @apply function to wrap that long list of classes into another class. This is a bit of an antipattern, it goes in a big circle and ends up back at the beginning with the exact same problems of specificity and inheritance that Tailwind is supposed to fix. It also requires a bunch of additional tooling added into the stack (which I think Tailwind requires in general, and that's another issue).
3. Extract the code into it's own component. If even a simple H1 tag is so complex it _has_ to be extracted to a separate file just to use it, I feel like there's something going a bit wrong...? This is basically the "sweep it under the rug and then we don't have to look at it" approach. Also very common!

In the immortal words of Gwen Stefani; this shit is bananas! :banana::banana::joy:

[Matt-Yorkley]

By "going round in a big circle and ending up at the beginning" I mean Tailwind essentially starts by saying this is bad:

<button class="btn btn-green">Click me!</button>

and this is good:

<button class="py-2 px-4 font-semibold rounded-lg shadow-md text-white bg-green-500 hover:bg-green-700">Click me!</button>

But then when it comes to the issue of DRYing code, dealing with all that mess, making it re-usable etc, Tailwind ultimately suggests doing this:

  .btn {
    @apply py-2 px-4 font-semibold rounded-lg shadow-md;
  }
  .btn-green {
    @apply text-white bg-green-500 hover:bg-green-700;
  }

and then doing _this_ (wait, isn't this bad?!):

<button class="btn btn-green">Click me!</button>

What? :joy: We're back to arbitrarily-named classes that encapsulate a whole bunch of styling and are thrown on to elements in whatever way we feel like, right?

This is the main solution proposed by Tailwind in the docs, but even Tailwind's creator has stated multiple times that it's an antipattern...

[jibees]

@Matt-Yorkley

That would be equally true if we leant on an existing library whilst making components, right?

Yes, if the existing library handles the customization of its _components_ (for Bootstrap, the class btn for example). As you said, seems to be done by MDBootstrap.

Thus, code is written once
Is it though?

At least, it's an objective. I know this can't be 100% applicable, but it's great to have such a thing in mind (and I know you have).

I don't know if we can reach an agreement if we both discuss and exchange arguments / counter-argument.

To step further, maybe we could:

• Invite more people to discuss here, or elsewhere?
• and/or give a try to _your_ solution and _mine_ by creating one of the first components needed by Backoffice Product List such as #7199 inside the StyleGuide (#7284) with the two solutions. We can after compare them.

What do you think?

[jibees]

We are wondering if @openfoodfoundation/core-devs and @Erioldoesdesign (and others designers, UI/UX owners?) can add some thoughts about the Tailwind or not (or CSS utility first framework vs. _I don't exactly know how can i call them_ framework, but Material Design for Bootstrap seems to be the perfect example) debate.

Thanks! 🙏

[mkllnk]

I learned a lot just by reading your posts and following a few links. And my conclusion is that you two know a lot more about CSS frameworks than me. :stuck_out_tongue:

I'm not sure if the question here really is Tailwind vs MDBootstrap. Taking a step back, you expressed several needs:

• Plenty of theme work already done (e.g. a material-ish design).
• Easy to customise.
• We can build components with it.

What else do we need?

Once we know the needs, we can rate different options accordingly:

Tailwind

Using all the little classes can become messy. We can create new classes for our components. Why is that bad?

There may be a Tailwind theme that suits us so that we don't have to build everything from scratch.

The tailwindcss-rails gem needs Rails 6. dhh created that gem. He's creating lots of good things.

My understanding is that Tailwind provides a large set of potentially useful building blocks and a framework to serve only the classes required. It seems flexible enough that we don't have to use it in a way that we don't like. Could it make our work more efficient?

MDBootstrap

I'm out of the loop with Bootstrap. It seems to have become a lot better and Matt says that it's a lot more customisable now.

[andrewpbrett]

I had a similar conclusion as @mkllnk :)

I read a little about tailwind, and also had the urge to throw up a little bit when I saw all the tiny classes adding up on elements. But reading some other posts about it all follow the same pattern - there's a phase of disgust followed by enlightenment. So I wouldn't be terribly upset if we went with it. Plus if dhh is creating things for it... that's a pretty good indicator that there's something there that's pretty good.

[sauloperez]

Seriously, I :heart: TAILWIND :joy: you got to use it to understand it, and indeed you have an "aha! this makes total sense!" moment. It basically brings encapsulation and composition into the world of CSS.

However, it's also true that it favors full flexibility as opposed to having a set of components ready to be used (as most frameworks aim to provide). Nonetheless, I've been following the project and they've tried to overcome that drawback with things like https://tailwindui.com/ and https://headlessui.dev/ but still, we would still be on our own (these target JS frameworks) building our own ViewComponents. I understand our needs may require already made components. Is that it @Erioldoesdesign ?

[Erioldoesdesign]

Many of the UI Uplift designs take inspiration from Material design or may even be exactly as material design describes but my concern, which I've said before is that restricting ourselves to a framework that encourages or forces you to use their vanilla components means that we'll end up building custom components anyway or designs will be restricted when designing new features and improving older one to a sort of 'pain by numbers' or 'here are your building blocks' process.

For example, Mario used Material design chips in the new 'tagging list' UI: https://material.io/components/chips#usage

I mean he's changed the colour etc. but that's not hard to change in Material design so no biggie:

So if we have a framework that allows us to use some material design elements we like, great! but what if Mario had a design idea for this tagging list that wasn't the material design 'chip' but a component not currently described in material design?

He had two options either:

1. Pick a piece of UI from material design that kind of works (not great for designers or users)
2. We create a new component in material design (extra dev time to create a new component in MD)

I think the decision is ultimately up to whoever will be maintaining the FE and working on the FE to choose what is the best choice of time and effort. I'm happy as long as design (and therefore the users experience) is restricted by us not being able to build custom components easily and pushing design to 'pick from the framework shelf' OFN is too much of a complex and detailed tool to get by on a 'simple' framework UI.

[jaycmb]

Does the Uplift take into account this one?
https://community.openfoodnetwork.org/t/quantities-on-hand-adaptating-when-variants-are-a-sub-product-of-the-main-product/480/4

I remember it being discussed but can´t recall anymore if that´s part of V1

[Erioldoesdesign]

@jaycmb Yes it was handled and changed to a different kind of UI and function when you click on the drop-down that is under the 'on hand' column heading:

[RachL]

Wow! I always thought UI wasn't introducing any new features! And this particular one was always defined as complex, glad we could find an easy way to do it :muscle: :tada: