Openfoodnetwork: 'Back' from Edit Product removed filters on Products page

[lin-d-hop]

Description

A small UX improvement such that a browsers Back buttons maintain filtering.

Expected Behavior

1. A user filters the Products on the Products page to find a specific product.
2. They then click Edit Product to make some changes to it.
3. They save this then hit 'Back' or the button 'Back to Products List'.
4. I'm taken back to the Products page and all of my filters are still in place meaning that I'm still shown the same set of Products as before I navigated away.

Actual Behaviour

1. .... As above
2. .....
3. ....
4. I'm taken back to the Products page but my filters have gone. I need to reload the filters, which takes time. If I'm editing dozens of products I quickly get annoyed!

Steps to Reproduce

See above.

Context

When I have a number of changes to make to multiple Products I get quite annoyed. For large hubs this becomes unweildy quite quickly as there are often sizeable changes to make and I can't make them on the Products page.

Severity

bug-s4: it's annoying, but you can use it

Your Environment

• Version used: 2.3.1
• Browser name and version: Chrome
• Operating System and version (desktop or mobile): Linux
• OFN Platform instance where you discovered the bug, and which version of the software they are using. UK

Possible Fix

[JacksonBates]

Hi @lin-d-hop, I think this is related to this issue: https://github.com/openfoodfoundation/openfoodnetwork/issues/4338

This PR addresses the request in that issue https://github.com/openfoodfoundation/openfoodnetwork/pull/4342

I think ultimately not forcing a new window and maintaining the filter state when navigating back is a nicer solution - but I just wanted to alert you to the overlap in case you missed it.

[sauloperez]

I think ultimately not forcing a new window and maintaining the filter state when navigating back is a nicer solution

exactly @JacksonBates ! That's what I think too.

I think the solution for that is to have a URL so the browser can track filter changes as regular navigation and keep track of it in the browser history. I personally lean towards doing so in the backend rather than in the frontend using Angular JS routing (I have no experience with it). It feels less complex to implement. Thoughts? @luisramos0 @kristinalim @mkllnk @Matt-Yorkley

Also, this same filtering logic will need to be implemented in other pages as well.

Given @JacksonBates change, we might have bigger priorities than this one.

[mkllnk]

I'm wondering about the idea workflow here.

• Scenario 1: The user opens products in new tabs, edit, save, close. This is the quickest way because the product list doesn't have to be reloaded at all and all filters are still there. That's what I would do. The downside is that the product list gets out of date and doesn't include the changes made.
• Scenario 2: Click on a product, edit and save. Going back in the browser needs to steps, right? One step goes back to the edit form and another step goes back to the product list. If we had the filters in the URL, we could apply them again. If the filters are applied in Angular, it's easier to manage the URL in Angular as well. Moving the filters to the backend is a technically simpler solution but needs us to rewrite the filter code and requires reloads every time the filters change. In this case I would vote for Angular.
• Scenario 3: Click on a product, edit and save. Then following the link "Back to products list". This is probably the simplest UX. We would need to store the filter settings somewhere to remember them. Since the filters are applied on the client side, it would make sense to use the web storage API.
  We do something similar on other pages where you can save your preferred columns to display. I'm not sure how that's implemented. It would definitely be worth it to check and then decide which solution is best and update the old solution if needed.

[sauloperez]

Now that I read again my proposal I see the problem you mention. If we implement that URL in the backend we require reloads and I understand it wouldn't be the best experience for the user. So perhaps is better on the frontend.

As for scenario 3 you mention. It feels to me like reinventing the wheel for something browsers already do and I'm afraid going down that path would bring in more maintenance costs.

[RachL]

I feel we need to be careful about this one. On other projects where the filters are kept I see lots of bugs happening and related to this need.

For example: how long are those filters kept? As long as the user doesn't leave the edit page? Disconnect?
In case of multiple tab open and filtering which tab has the correct info? The latest?

Another approach would be to open all products edit pages from the product list by righ-clicking on the edit button. It would save having to switch tabs as we do currently. But you would need to know that right-clicking opens in a new tab without switching to this new tab....

Last thing: the issue title is about the browser back button, and the issue about back buttons from our UI. Which is the correct scope: both?

[rioug]

If I am not mistaken, scenario 1 has been implemented.
Looking at this, the better solution would be something like Scenario 2 as proposed by @mkllnk but with the following steps :

• click on edit product, load edit product page.
• make changes, then update. User stay on the edit product page.
• click on "Cancel" ,"Back to product list" should open the product list with the previous filter passed in the URL.

Having the browser back button behave the same way would require to update the url when filter are applied on the product page, which I think should be doable.

I am going to look at this, unless anyone has any reservation ?
We can then apply the same solution for #4207

[RachL]

@rioug hello :) are you still working on this one?

[rioug]

@RachL yes still looking at this one. I didn't have time to work on it last week, but I will be later this week.

[rioug]

Quick update on this one, I have a working solution but I still need to clean up my code. I was hoping to finish this today but I am still leaning on how to navigate around the code base. I'll finish this next week.

[rioug]

As mentioned in the Pull Request, my proposed solution has some limitation:
On the product edit page, using any of the links under the "Product Details" will result in the filter parameters being lost.

This should be easily fix by passing the filter parameters around to the various page, I just want to make sure people are happy with the proposed solution before going around and fixing the issue.

[sauloperez]

Feel free to open a draft pull request so we can give feedback and see potential complexities @rioug

[rioug]

Sounds good, I started working fixing the limitations, I'll update when I have something ready.

[rioug]

So, I extended the solution for the various "product variants" pages, as you can see in this commit : https://github.com/rioug/openfoodnetwork/commit/b8b22ee8eae4c371964ecf33776e5e2c73dde7c2
I'll have to do the same for images, product properties, group buy options and search pages.

I am not a big fan on passing the parameters along, as they are not relevant to the various product related page. What do people think ? is it an acceptable solution ? our should we be looking at other alternatives ?
@sauloperez @luisramos0

[luisramos0]

Thanks a lot @rioug
You can move the PR to code review and we will have a look and provide feedback :+1:

[rioug]

I started working on extending the solution to the product related pages, as well as covering the changes suggested by Luis. Hopefully it won't take me too long to finish.

[rioug]

Done, I just updated the PR with my latest changes.