Views configuration: why saving every field/group/filter edit is a bad idea ...

[Jan-Hendrik Spieth]

I really don't dig how/why the views save each and every edit that one makes to the visible fields, grouping and filtering!

As a view "editor", I have a certain purpose in mind. Say, I want to create a view that allows to make idea assessment. So I set up a table view which displays all relevant rating fields, and I choose a certain sort order (e.g. by date created), so that it's easy to find the latest ideas and start assessing them.

Then, imagine other team members visiting the view as "viewers" or "users": while doing assessments, they may want to change grouping or filtering, e.g. to see only ideas relevant to a certain project or product area.

Currently, when a viewer does such work and leaves the view, the view will permanently remember all field, grouping and filtering edits the viewer did.

This oftentimes renders the view hard to use for the next person opening the view, to the point of contradicting the view's purpose (if the previous visitor configured sth that doesn't suit the next visitor's context), or even rendering it ineffective for the intended purpose (if the previous visitor e.g. removed one or more ratings fields).

Long story short:

What we would want is to be able to "pin" a certain state for a view as permanent, so that only certain people/roles can change the view config.

Whereas regular viewers can make changes to e.g. grouping or filtering (imagine a person from a certain team to drill into ideas that are relevant to his/her project), but their changes aren't saved.

Also, an "Undo" button would make sense in this regard, so that you can go back to the state that was intended/pinned for that view, after changing sth (like grouping or filtering).

What do you guys think about this?

Finally, in the case of search/text filtering, I find it actually very confusing that a previous search is saved as a filter, and when you start typing in a new search, you kind of layer another filter on top, usually yielding zero results:
Sorry to be blunt - but that really doesn't make any sense to me, at all.

[Tanguy Crusson]

Thanks for the very clear feedback @Jan-Hendrik Spieth.

This piece of feedback has come up numerous times in the past couple of weeks actually - we're looking at how we can best approach it.

Initially it was mostly product managers spending time in Jira Product Discovery (and this spreadsheet-like behaviour was not perfect but OK), but now that we're seeing more and more other roles engaging in the product it's definitely something we have to address.

[Jan-Hendrik Spieth]

Thanks, @Tanguy Crusson for the clear anwer. Makes sense to me! (I'm just another product manager;-)

Great to hear you have it on the radar. Looking forward to changes in this regard, I hope it won't take too long. Let's make JPD a hell of a productive and fun tool to use for all stakeholders!

[Minesh Patel]

Tanguy,

Just sharing some thoughts on this topic.

Remember that we use this to allow transparency amongst various stakeholders in the organization and each has a different perspective, some are strictly view only. 

We use dashboard to help with filtering and displaying key info to stakeholders on specific projects, allowing us to build a view that can be part of the dashboard would be helpful. 

Minesh. 

[Jan-Hendrik Spieth]

The Atlassian team has been busy!

We now have an "Auto-save" toggle that allows a view manager to "lock" a view to a certain state, concerning its fields, filters, and so forth.

Regular viewers can still modify the view (e.g. filter), but that state won't be saved, unless the view manager has allowed it.

Also, from what I can see, my observations about the search box are not reproducible, any more, either. Super!

Thanks, JPD, thanks @Tanguy Crusson !

[Tanguy Crusson]

Nice! you're one of the early adopters for this actually 🙂 I'm glad you found the feature (we weren't sure about the icon)

Let us know if you face any issues with this!