Views 3 UI, Review of Concepts

I spent some time reviewing UI design work on Views 3 (And Acquia Gardens "Data pages") UI concepts:

• "Views 3 UX Season is open", February 2010, Yoroy
• "Views 3 UX workflows and ideas, round 1", April 2010, Rasskull
• "View3 UI explorations, part 2", July 2010, Yoroy
• Acquia Gardens "Data Page" concept mockups, Jeff Noyes?
• "More Views 3 concepts", July 2010, Jeff Noyes

NOTE: I have not read all of (or even very much of) the related discussion, so am likely missing important developments.

There are some great "sky-high" ideas in most of these. However I think it's likely that all of them will run into issues as or more significant than the current UI, in that either;

• They will be be too restrictive upon advanced functionality and features and make them difficult or hacky to include in the (in the case of Gardens, that is likely intentional, as advanced features are probably not supported);
• They will have similar types of unforeseen issues to the current UI. Subtle and seemingly minor nuances or even features that actually make a big impact on the UX.

I think this Gardens concept would be particularly dangerous for Views-core, as it is much more like Views One's UI than Views 2, and I expect would have many of the same issues, annoyances and UX problems that Views' One's UI had — especially if it were scaled to the complexity that all of Views 3's features will take it to.

Developing Rasskull's concept

Of all the concepts I think Rasskull's concepts are the most likely to succeed in improving the UX — largely because they are not so radically different to the existing UI. The changes mostly involve just moving displays above the main config area, introducing settings groups as vertical tabs, and moving the "edit area" to the right of the settings table-summaries.

The new settings groups in Rasskull's rev6 are "Views settings", "Data Sources", "Filters, sorting and arguments", "Display settings" and "Overview". Views wants site-builders to build a mental model something like this:

• What data to render?
• Where in Drupal to render it (page, block, feed etc)?
• How to render it (list, map, table etc)?
• How to render each item (full node, teaser, fields)?

Considering that mental model, I think the following could be a better grouping of Views settings (in this order). Sorry for the underscores. GDO breaks the layout without them:

1. General
   1. Overview?
   2. Basic settings
   3. Advanced settings
   4. Page settings
   5. _______________________________________________________________________________________________
2. Data sources
   1. Base table
   2. Relationships
   3. Arguments?
   4. Fields?
   5. _______________________________________________________________________________________________
3. Filters & Sorts
   1. Filters
   2. Dynamic Filters / Arguments?
   3. Sorts?
   4. _______________________________________________________________________________________________
4. Display
   1. Header
   2. Display style
   3. Row style
   4. Empty text
   5. Fields?
   6. Footer
   7. _______________________________________________________________________________________________

Iterating the existing UI instead of exploring a new concept

Putting that whole concept aside, I think there is also a lot of potential that has not been explored with iterations of the current UI — which despite a few unusual/small but greatly-annoying nuances, is actually very good, and has already been through extensive wireframing, review and iteration (as well as implementation!).

As Yoroy puts it;

1. "Too busy! Everything all the time. Provide an easier path into the jungle please."
2. "There's got to be something else we can do for that bottom drawer settings part."
3. "This overriding thing confuses the heck out of me."

Starting from the end, with number 3.; "This overriding thing confuses the heck out of me."

Changing a setting or setting group from "uses default" to "overridden" or back needs to be very explicit and separated from the task of editing a setting. It is not a common task, relatively speaking. It is much more common to edit the setting, or to check it's overridden/default status, than it is to change it.

So for starters, lets lose all of the existing "Override" and "Use default" buttons.

Next, how to determine override-status?: Perhaps instead of using italic or non-italic fonts to show the overridden state (which is terribly vague and unclear), each over-ridable setting or setting group could have a status indicator icon — let's assume a green, yellow or orange "LED" for now;

• Green: The setting does not affect any other displays. It is overriding the default display. Or it is the default display and no other displays inherit from it.
• Orange: The display is inheriting the default setting. Editing the setting will affect other displays.
• Yellow: This display is the default display and other displays will be affected by this setting. (If no other displays use this setting from the default display then the LED for the setting on the default display is green.)

In order to help the site-builder to:

• learn what those LEDs mean,
• how settings can be inherited/overridden across displays, and
• not get terribly confused and frustrated along the way,

we can extend this warning-level LED affordance/metaphor to the edit-area, which can have;

• a larger LED next to the "Update" button,
• a background colour that is respective of the warning-level, and/or
• a status bar/strip that is green/yellow/orange.

The status bar or large LED could contain or be a link (and not a button) to the edit-area form/mode that changes a setting or settings-group from "overridden" to "uses default" or back again. Also, tool tips can aid discovery and help build the mental model of what Views overrides are. These tool tips can be on all LEDs in the settings-tables, and if Rasskull's concepts are pursued even in the vertical tabs summaries.

Moving on to item number 2.; "There's got to be something else we can do for that bottom drawer settings part.".

There is. And it's easy. I think this is simply a matter of making the state-change of the edit-area more obvious:

• Scroll the viewport to it so that the whole edit-area is in the viewport (if it's not already)
• Expand the edit area so it is a few hundred pixels high, and put an overlay with a big throbber over the whole settings-overview area and the edit-area.
• Once the edit-area's DOM has been updated and the overlay removed, a subtle animation like a pale yellow background that fades away or a jQuery fadeIn effect, will continue to draw the user's eye to it.

And finally, the first item from Yoroy's list: "Too busy! Everything all the time. Provide an easier path into the jungle please."

I don't believe this problem is entirely solvable, because Views is a damned-complicated tool no matter what you do with it's UI. The only way to make views easier to get in is to remove advanced features — which is obviously not desirable for views-core. Simple views, Gardens and others can do that.

However, these ideas may help. We can try them out and then further develop or pull them if they don't work;

• Shuffle around the settings-overview tables to be more like my suggestion above for Rasskull's vertical tabs-based concept
• Make some settings-summary tables collapsed by default. This was an idea in one of the above concepts — though I'm skeptical that it simplifies the UI more than it complicates the UI. Nevertheless, we could try it.
• Offer smarter defaults, checks for common mistakes, and easier ways to start building complicated views. E.g.
  • New views could always start with a page display
  • New node views could always include a node=published filter
  • Views could warn you when a filters-group does not have a node=published filter
  • The create-view wizard could introduce an optional step to create common and simple filters quickly, such as by node type or term.
  • Instead of exposing default views, contrib modules could offer "templates" which can be used to get started quickly with complex views that, for example have convoluted and difficult-to-reproduce relationships and/or arguments. E.g.
    • Related nodes by term: node->term->node
    • Other user's flagged nodes
    • "My" flagged users (aka "My Friends")
    • Nodequeues
    • _______________________________________________________________________________________________