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.

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/network-phase-1/1906
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

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

• 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:

• Include Unit Prices
  Done:

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

• 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

• Variant button now has the [+] icon
• Added unit prices into the column list and reordered the column list to be same order as left to right display.
• 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 👍

[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... 🙈

[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 😂

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... 🤷‍♂️

[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! 🍌🍌😂

[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? 😂 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...

[dacook]

Before a full rollout, we should ensure that server monitoring is fully configured, so we can measure any impacts:

• Update New Relic redis monitoring configuration  ofn-install#922

( I wasn't able to add this to the milestone because it's in a different repo)

[RachL]

I don't think we need this epic anymore 🎉 (yes there is still work to do but we are managing it with BUU2 milestone now)

[dacook]

It caused me to look back at the original goal of this epic, which was to encourage Inventory users to use the Bulk Products screen. It seems like tagging is intended to do that, and maybe scrolling laterally (side-scrolling).
Hopefully we get to do that one day :)

[RachL]

@dacook yes we've never updated the epic content, but tagging will be on of the next priorities ;) Regarding side scrolling, do you think you could do a rough estimate? I wonder if we could fund this, I think it would be very helpful.

[dacook]

We can do a 1hr spike, but I think it will require a few rounds to get right. It might require some re-structuring of the code too.
Also it's worth noting, it's probably not possible/practical for it to adapt to content (for example, if I have very long product names, the product column won't automatically expand). Maybe we would like to add column resizing but that's another story.

A very quick roundup of requirements:

• First design:
  https://www.figma.com/proto/kBvKYXnaNU0thSnKJUoyup/Product-List-UI-uplift?node-id=10-8745&viewport=116%2C270%2C0.04911578819155693&scaling=scale-down-width&hide-ui=1
• Second design: (I'm sure Mario set up a preview in the new design but can't find it right now)

When the viewport width is smaller, or a large number of columns is selected,
And the columns reach a minimum width (to be experimented) and no longer fit on the screen,
The remainder of the columns can be visible by horizontal scrolling to the right.

Considering:

• visual indicators to show when there's more content to be scrolled to (drop shadow on left/right)
• image and name columns to be sticky on the left
• actions menu to be sticky on the right?
• horizontal scroll bar should appear at bottom. It doesn't need to be sticky on the screen (there are ways to side-scroll with any mouse or touchpad)

I guess it depends how much we want to polish it.

---

Also, there's another enhancement we can do separately which will help for large screens. The Admin interface has a maximum width, but we can allow the table to break out of this:

Notion has a really cool way of incorporating this with side scrolling, but I'm not sure we need to try that:
https://www.youtube.com/watch?v=TZ85oNlV7XA