search

openfoodfoundation / openfoodnetwork

Connect suppliers, distributors and consumers to trade local produce.
https://www.openfoodnetwork.org
GNU Affero General Public License v3.0
1.11k stars 718 forks source link

Backoffice Product List table UI uplift #7198

Closed mariocarabotta closed 1 month ago

mariocarabotta commented 3 years ago

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

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

Columns selection and table scrolling

Edit fields inline and add tags

Filter by categories and tags, sort

On demand and unit display fields

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:

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

jaycmb commented 3 years ago

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

image.png

mariocarabotta commented 3 years ago

Thanks @jaycmb for the feedback!

Cheers

jaycmb commented 3 years ago

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

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

2. Product-Related Issues

Next Steps / Actions

Mock up requests

Erioldoesdesign commented 3 years ago

Design round up of Mock-up AC's

Mock up requests

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

Screenshot 2020-11-24 at 22 00 26

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

Screenshot 2020-11-24 at 22 00 03

Other things I did and updated

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 commented 3 years ago

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

Erioldoesdesign commented 3 years ago

Design next up for UI Uplift

jaycmb commented 3 years ago

Feedback on Designs

image.png

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?

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 commented 3 years ago

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

RachL commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

re. scope

Erioldoesdesign commented 3 years ago

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 commented 3 years ago

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

Erioldoesdesign commented 3 years ago

This moving into the dev pipe?

Matt-Yorkley commented 3 years ago

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

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

Erioldoesdesign commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

jibees commented 3 years ago

@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 commented 3 years ago

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:

tailwind-markup

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

jibees commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

What do you think?

jibees commented 3 years ago

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 commented 3 years ago

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:

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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: Screenshot 2021-04-22 at 15 50 45

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 commented 3 years ago

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 commented 3 years ago

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

Screenshot 2021-05-10 at 10 19 54

Screenshot 2021-05-10 at 10 20 01

Screenshot 2021-05-10 at 10 20 09

RachL commented 3 years ago

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:

RachL commented 2 years ago

@Matt-Yorkley @lin-d-hop @filipefurtad0 and myself sat down in Portugal to refresh our memories on this feature and bring us up-to-date. While going through the issues, we reach agreements on some ideas that we are proposing here:

  1. Issues were made with components in mind, which is interesting but very difficult to pick up to understand what to deliver in the end. We would like to propose to rewrite issues in terms of user stories, with components as acceptance criteria. Rachel would be available to take on the creation of issues but would need to team up with a dev for the acceptance criteria.

While we rewrite issues, we need to keep in mind that some of them should be pick-up by back-end devs. So we need to make that more clear.

  1. We need to be more clear on what are the expected results in terms of experience for the user. Some example of questions we had :

So it's linked to 1. but design decisions are needed.

  1. The scope of the project is really wide, so we started to look at what would be the first minimal bits we want to ship in production. The proposal is the following :

The first release should only focus on:

This means that we propose to do a first release without tags (which are not intended to work with existing tags in this project, so difficult to explain to user in the first release) and bulk actions on products. To be clear: we are not saying we want to remove these features from the project, just not targeting to have them in the first release / reveal of the new page to users.

Any thoughts @openfoodfoundation/core-devs @openfoodfoundation/train-drivers-product-owners @openfoodfoundation/testers ?

kirstenalarsen commented 2 years ago

Sounds great - let's get this show on the road!!

On Tue, 21 Dec 2021 at 02:23, Rachel Arnould @.***> wrote:

@Matt-Yorkley https://github.com/Matt-Yorkley @lin-d-hop https://github.com/lin-d-hop @filipefurtad0 https://github.com/filipefurtad0 and myself sat down in Portugal to refresh our memories on this feature and bring us up-to-date. While going through the issues, we reach agreements on some ideas that we are proposing here:

  1. Issues were made with components in mind, which is interesting but very difficult to pick up to understand what to deliver in the end. We would like to propose to rewrite issues in terms of user stories, with components as acceptance criteria. Rachel would be available to take on the creation of issues but would need to team up with a dev for the acceptance criteria.

While we rewrite issues, we need to keep in mind that some of them should be pick-up by back-end devs. So we need to make that more clear.

  1. We need to be more clear on what are the expected results in terms of experience for the user. Some example of questions we had :

    -

    We should be careful about how the pagination works: infinite scroll or what we have now?

    How do filters behave : use one and get instant results ?

    Apparently we are introducing autosave! This should be shown to the user in some ways. Maybe a message at the top of the page? "All changes saved" ?

So it's linked to 1. but design decisions are needed.

  1. The scope of the project is really wide, so we started to look at what would be the first minimal bits we want to ship in production. The proposal is the following :

The first release should only focus on:

  • removing Angular / introducing Tailwind (or whatever we choose)
  • improving the current experience of the product page by introducing the new design. But the scope of features remains the same.

This means that we propose to do a first release without tags (which are not intended to work with existing tags in this project, so difficult to explain to user in the first release) and bulk actions on products. To be clear: we are not saying we want to remove these features from the project, just not targeting to have them in the first release / reveal of the new page to users.

Any thoughts @openfoodfoundation/core-devs https://github.com/orgs/openfoodfoundation/teams/core-devs @openfoodfoundation/train-drivers-product-owners https://github.com/orgs/openfoodfoundation/teams/train-drivers-product-owners @openfoodfoundation/testers https://github.com/orgs/openfoodfoundation/teams/testers ?

— Reply to this email directly, view it on GitHub https://github.com/openfoodfoundation/openfoodnetwork/issues/7198#issuecomment-998021633, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAWGXSE6M6NKFL7FU7WDDPDUR5C55ANCNFSM4ZXDBRUQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

RachL commented 2 years ago

We had a little chat about the project today with @jibees

Summary:

We are still discovering new features hidden in the design! So again, for the purpose of scoping the first release to the bear minimum and ease dev work, the following changes will be made on the designs (I'm including stuff mentioned in my previous post + new stuff we discovered this morning):

  1. Duplicate variants (only products can be duplicated)
  2. You can't delete a variant when it's the only one left (only products can be deleted in that case)
  3. Bulk actions on products will be removed, which means action button on top right + checkboxes
  4. Tags are removed: filter options and column
  5. We won't do infinite scrolling yet, so we keep pagination as it is today (only changing the UI / look and feel)
  6. We do introduce autosave, so we need on the top left for example a little spinner that ends with the text "All changes saved"
  7. Filters won't be used instantly, so we are introducing back the "filter results" button (easier on the dev side)

Actions:

jibees commented 2 years ago

I tried to :

Capture d’écran 2022-01-26 à 10 43 43
kirstenalarsen commented 2 years ago

Would it be scope creep with the pagination to have the option to ‘show X results’ that defaults to smaller number but lets them change it? Seems that’s pretty standard and if we’re setting precedent for admin pagination handling here would be good to include?

I am sad to see tags go but I understand. I hope we can have them back soon because they are critical step towards removing Inventory

On 26 Jan 2022, at 8:45 pm, jibees @.***> wrote:

I tried to :

add pagination remove all references to tags remove all references to bulk actions (including checkbox then) add a "Filter Results" button It's not perfect, but it's a first iteration that can be improve https://user-images.githubusercontent.com/296452/151140176-f88633ae-807f-405f-8b3c-fab1d8849a5e.png — Reply to this email directly, view it on GitHub https://github.com/openfoodfoundation/openfoodnetwork/issues/7198#issuecomment-1022030680, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAWGXSCPFOO63LFEJDS3BLLUX67C5ANCNFSM4ZXDBRUQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.

jibees commented 2 years ago

Would it be scope creep with the pagination to have the option to ‘show X results’ that defaults to smaller number but lets them change it? Seems that’s pretty standard and if we’re setting precedent for admin pagination handling here would be good to include?

Right, we mention that during the chat we had, but I forgot to add in the design. Will do.

jibees commented 2 years ago
Capture d’écran 2022-01-27 à 10 21 53
kirstenalarsen commented 2 years ago

Thanks! Would it usually be down in the footer with the page numbers? I guess if setting it where you have it is more intuitive for them to be setting something that is saved as their default? (Like columns?)

On 27 Jan 2022, at 8:22 pm, jibees @.***> wrote:

https://user-images.githubusercontent.com/296452/151329704-86ff125e-942c-4b4c-8f84-5c409c8678dc.png — Reply to this email directly, view it on GitHub https://github.com/openfoodfoundation/openfoodnetwork/issues/7198#issuecomment-1023005426, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAWGXSBSLXWJMQO6OZWRW4TUYEFFLANCNFSM4ZXDBRUQ. Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub. You are receiving this because you were mentioned.

RachL commented 2 years ago

Currently we have them on the top left of the table. They are not triggered by the "filter results" button. So what's the easiest on the dev side @jibees ? To make them work with the filter button or outside the button?

I am sad to see tags go but I understand. I hope we can have them back soon because they are critical step towards removing Inventory

@kirstenalarsen Yep. It's because we agree on that that we've removed them actually. The way they were thought until now was just to add a new tag field NOT linked with the other tags in the system. Which - when discussing with the team - felt very weird for the user / difficult to explain. So the idea is to introduce them, but with a link with the existing tag system. I think that when we do this FR will not have any inventory user anymore :D

RachL commented 2 years ago

@jibees just noticing that your design is missing the action button per product, see: https://github.com/openfoodfoundation/openfoodnetwork/issues/8931

Also can we go up to 100 results per page? Or at least 50. 10 could be just one product and its variants, so it's tiny.

More generally: Now that have read every comments possible. I've found out that autosave wasn't planned at first. Here are the designs for the bottom button :

Screenshot 2021-03-31 at 09.47.04.png

When a user saves the bottom bar displays a 'saving message' or if the user cancels the product list page refreshes.

Screenshot 2021-03-31 at 09.54.17.png

Aaaaaaand do you need an issue for this bad boy?:

image

Let's have a call when you're back :)

audez commented 2 years ago

hi! I hope it's not too late to comment. First I really like the new UI, very nice, more intuitive, and the fact that all the variants are unfolded will be really precious for users!

The only thing that bothers me is that the "edit", "duplicate" or "delete" buttons will now be hidden under an "Actions" button. Screen Shot 2022-09-09 at 15 17 42

I think it is very nice to have them "outside", as you have direct access to it, it's more visible and it spares one more click. And for the "duplicate" button, it is very useful as you can stay on the button and click several times on it and it will create several new products. Screen Shot 2022-09-09 at 15 20 36

As the process of creating or editing products is already long, I really think it's a good think to have them outside, and keep the "Actions" button only for bulk actions.

But maybe there's good reasons for this choice?

dacook commented 6 months ago

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

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

RachL commented 1 month ago

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

dacook commented 1 month ago

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 commented 1 month ago

@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 commented 1 month ago

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:

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:

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: Screenshot 2024-09-03 at 10 15 27 am

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