[UX] Better UX for Views UI

[mikemccaffrey]

As we briefly touched on at the Backdrop Summit, one of the biggest UX challenges in Drupal has been the most recent version of the Views UI, which rearranged all the options in a way that baffles even seasoned drupal developers. Mindbogglingly, this doesn't seem to have been addressed at all when they migrated the Views module into Drupal 8 core, so improving this problem could be a great opportunity to show how Backdrop could become the more-usable alternative to Drupal.

One idea that I've had is to use vertical tabs to organize the different aspects of views configurations. It would kinda be like the top-to-bottom configuration workflow from Views 1, but with less scrolling. I'm thinking the tabs for each view display could be something like:

• Content selection (base tables and relationships)
• Filtering (both regular and contextual)
• Display type (configuration and fields, if applicable)
• Header, footer, and empty text
• Additional settings (permissions, caching, query settings)

Does this sort of approach make sense? Perhaps we could create a contrib module for this alternate UI now, and then consider merging it into core for backdrop 2.

[klonos]

Does this sort of approach make sense? Perhaps we could create a contrib module for this alternate UI now, and then consider merging it into core for backdrop 2.

:+1:

Vertical tabs sound good to me because they can be swapped for accordion-style fieldsets on smaller screens. ...not that I plan to start managing my websites on mobile/tablet ...just saying it would benefit the rest.

[docwilmot]

:+1: to this as well. Although Views UI is such a mystery that I agree it should/could incubate in contrib.

Are you self-assigning @mikemccaffrey?

[jenlampton]

I'm not sure this is a candidate for core in 1.x. Since seasoned Drupal developers already know their way around Drupal 7 views, showing them something entirely new in Backdrop might be too much change. That said, Views is a very complicated interface, and there's lots of room for improvement!

We do need to be careful with suggesting the use of things like vertical tabs, since those have a very specific purpose, and that is to tell a user "IT'S SAFE TO IGNORE THE STUFF DOWN HERE". I'm not sure anything in the views UI meets that qualification. There may be better tools for building a new/improved Views UI.

... I thought we had a follow-up views issue already scheduled for 1.3.0 that was about making views UI responsive, but I can't find it now. :/ Anyway, I was going to say we can iterate on the current UI for 1.3, but I would love to see an-entirely-new views UI module develop in contrib. We can test it in the 1.x cycle, and move it into core in 2.x :)

[klonos]

...seasoned Drupal developers already know their way around Drupal 7 views, showing them something entirely new in Backdrop might be too much change. [...] I would love to see an-entirely-new views UI module develop in contrib. We can test it in the 1.x cycle, and move it into core in 2.x :)

I think that would be the best way to go about it too.

[wesruv]

@jenlampton is there an opportunity to create a 'contrib Views UI' that could potentially make it into 2.x if people like it?

There is a lot of stuff wrong with the current implementation, as I complained about in #1412 before I saw this ticket.

I agree that this isn't the right use case for Vertical tabs, and I don't think the mockup I had is the right answer either. I'm feeling some design iteration might be the quickest way to hash out some ideas and see what works.

Especially now that I have a version where I have all the bits created, it'd be easy to move them around and manipulate them.

But for 1.x we (me or someone else) should just do a simple responsive update, so this at least works on most screens. I'm not convinced it's possible to get the current UI working well @ 320px wide.

@mikemccaffrey wanna tag team a new Views UI :D I can do Front dev for the admin, but I'd be completely lost on anything deeper than that.

[wesruv]

Something in the back of my mind re: reworking the UI: I'm really starting to question the amount of 'features' Views has. For example, the way every type of element in Views UI can inherit to "All displays" or "this display (override)" seems like overkill. Adds UI complexity for designing; and even now (6 years in) I still have maintenance issues and get bit with this.

I think it'd be simpler if only a couple of things inherited and could be overridden (thinking of the stuff that relates to the query like filters, contextual filters, relationships, etc), and all of the other settings could be cloned from an existing display when you create a new one.

</randomthought>

[wesruv]

I've also been thinking about some of the similarities that there could be between Views UI, Layouts Admin and Field UI.

They all have some query/data/config admin UI and a distinct presentation admin UI. Might end up that they can't share much, but there might be some really good benefit in thinking of them as a whole and figuring out if we can use similar UI patterns between the three.

forreal this time </randomthought>

[klonos]

@wesruv I find inheritance onto other displays a very useful feature. We shouldn't nix it. The way you had it as a drop-down in your mockups in #1412 was very limiting though IMO. Here's what I envision for it:

1. Since it can be considered an "advanced" setting (as in that people need to delve deeper into Views to grasp the concept of displays and inheritance), we should hide it under a link/button next to every element/setting bit that can be inherited.
2. We can be more descriptive about it, like for example "copy this setting to other displays" (instead of just "apply to" as it currently is).
3. Have it open in a modal dialog.
4. Have the dialog offer a list of checkboxes for all the displays available in the current view (with the display which the dialog was initiated from perhaps having appended a "(current display)"). This way people can select one, some or all.
5. Include an extra "All" checkbox (could also be a "Select all" button) that simply selects all checkboxes/displays.
6. Hide this link/button completely if the view has only one display (less confusion and UI clutter for newcomers).

Thoughts?

[sutibun]

@wesruv I actually liked where you were going with your initial design. I just think it needs better organization. What I tried to do is mimic the node edit page... so instead of Views looking like a different monster... it's not too different from editing any other content.

This is a high level view but basically, you'd put each View forms/button in the appropriate place.

I think that what maybe makes Views complex is how it integrates Content and Design... almost like how HTML and CSS used to be mixed together in the past. This is a quick idea I am throwing out there as haven't fully thought out but what if we separated Content and design in views.

In the content "mode"/tab, you're presented only with stuff that modifies the content whereas the design "mode"/tab more faithfully renders the Views Page BUT provides like an "edit" button to each element, allowing you to edit markup, css, etc. Design stuff.

Just an idea. If not good, hope at least gets the juices flowing.