Views is a super-powerful way to use all of your Drupal data in multiple ways. But it gets complicated quickly. So I of course had to attend the session at Drupal Camp Twin Cities 2011 on “The new Views user interface: How it works and how it was made,” led by David Rothstein.

The session description was:

Recently, the Drupal 7 version of the Views module got an entirely new user interface, thanks to a months-long partnership between designers and engineers working for Drupal Gardens and major Views contributors from the rest of the Drupal community. Working together, we revamped almost every part of the interface, with the goal of exposing the most common functionality in easy-to-use "wizards" while still preserving the full power of the module for advanced users. The result is a totally new experience for site builders who are using Views to build sites in Drupal 7.

• Go over the new Views interface and demonstrate how to use it, as well as give some background on the process by which it was made.
• Discuss the interface from the perspective of new usability patterns introduced in Drupal 7 core (highlighting places where it follows those patterns and places where it creates new ones), which should be useful for anyone interested in making usability improvements to other Drupal 7 contributed modules.
• Talk about lessons learned from the process of doing a design-driven overhaul of an extremely popular Drupal module.

Here are my notes:

---

Views is a powerful tool for making lists of things in Drupal, without writing code.

Because it is powerful, the interface gets complicated.

Interface history

Drupal 5

In Drupal 5, the interface mainly relied upon collapsible fieldgroups. You could create a page or a block. You could narrow down items with arguments and filters. Arguments typically narrows down results based on information in the URL, while filters narrows down results based on query results. You could set basic sort criteria. And you could determine what fields to display.

Drupal 6

In Drupal 6, creating a view required multiple pages.

First, you set the basic information and type of view (nodes, users, etc.): this was a new feature. Once chosen, this could not be changed.

Then came a giant page with tons of options. Tabs on the left let you choose where a view would show up, such as a page and block, with options for multiple instances of each type. Options could be inherited from the default settings.

For everything else, you would click on a particular thing you wanted to change, and the configuration options would show up below, which required scrolling and was somewhat clunky.

Below that, you could see a live preview of the view.

When configuration an option in the view, you had the ability to override the default for that particular option.

Typical issues people had included:

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

Views UI in Drupal 7

Views is found in the Structure admin section. Again, you get a list of the existing views: you can enable them and disable them. You can also add a view.

You can choose some options right away, and these options are written in plain language. These are some basic filter and sort settings: so a beginning user can easily create a view. The settings available are dependent on what features are available: if there is no taxonomy vocabulary for a content type, no taxonomy options are shown.

You can also choose some settings for the display type, such as a block or page. You can choose common display formats and menu options.

After you set those basic options, you can either save and exit or continue and edit for more details.

If you continue, you get to see a panel that is more similar to the previous views interface.

Display options appear as tabs along the top, rather than vertical tabs along the side. There is no default display that shows up by default, as that was confusing people. On the settings tab, you can choose to always show the master display in order to see the defaults.

Even on the detailed interface, the advanced options are hidden by default, to avoid scaring off new users.

Arguments have been renamed as contextual filters: again, this is filtering by information or the URL or other contexts. I like the new name. Arguments have always frightened me.

When you edit something in the details panel, the options appear in a modal window: an overlay on top of an overlay! There could be some accessibility concerns with this for older screen readers.

By default, you edit options for all displays: you can choose to override for a particular display. When you override an option within a particular type, such as fields or filters, it still detaches all options within that category from the default, at least that is how David thought it would work.

Now when adding a field you can search for the field you want, rather than having to scroll through a giant list (although you can still do that too).

Filters now have an and/or option. You can group together filters that should be joined with an and and filters that should be joined with an or.

Another nice thing: the published=yes filter is added by default. This is great, because you always have to add this, and if you don’t, unpublished content shows up on your site: not so in Drupal 7. Yeah!

In the preview area, you can use contextual links to help eliminate things you do not want. This is awesomely useful.

There is an option to add a view from a template. Modules can add templates to handle certain situations, somewhat similar to cloning a default view in Drupal 6.

Drupal usability standards used in views

• Action links have plus icons to add a view for example.
• Contextual links allow you to do things like choosing to edit a view right from where it shows up on your site.
• Checkbox reveals task details: Users are not overwhelmed with options until they choose to be. In many ways, this is better than collapsible fieldsets, because it is more action-based than settings-based.
• Dropbuttons: Allow you to focus on the main tasks, but if you click on a default button, you can quickly select less-used actions.
• Modal dialogs: Displaying options on top of what you were viewing before, like a lightbox. Agan, there are some accessibility concerns.
• Search filter: rather than a long list, you can search for an option as well.

Design process and lessons learned

Design

• 2010 and before: Lots of Views design work already going on in the community
• Acquia sponsored new work after deciding to add Views to Drupal Gardens: didn’t want previous interface to overwhelm target audience
• Jeff Noyes as lead designer (many others involved)
• Many interations, punctuated by meetings with Earl Miles (the Views maintainer) and community feedback.

For Drupal 6, SimpleViews was built in 2008 by Lullabot for Buzzr, their equivalent of Drupal Gardens. This was an independent module that also helped to simplify the views interface. This was a major inspiration for the Drupal 7 interface.

Implementaiton

• Worked off GitHub (essentially no issue queue): Changes were just made, rather than discussed
• Several engineerings, designers, etc. (communicating with Views maintainers)

Acquia-sponsored code sprint (February 2011) in San Jose

• Katherine Senzee (ksenzee), Earl Miles (merlinofchaos), Daniel Wehner (dereine), bojaine
• Others working remotely

Lessons learned

• The time and people were proportional to the job: critical to success
• Mix between working on own and collaborating with module maintainers: doing some initial work helped to show module maintainers that work had been done to understand the common problems before jumping in
• Sprint with expoerts towards end: good timing? Easier to get things done in sprints once major decisions have been made.
• Engaging wider community (“contextual filters” is a good example of something that came from the community)
• Design for its own sake, not just when required by new functionality Views 2 vs. Views 3

Other resources

• “Taming the Beast: Learn Views with NodeOne” screencasts by Johan Falk
• Usability testing and followup
  Preliminary testing in Drupal Gardens: Adding views is good, but editing views can still be confusing. Would be nice to send people to wizard page for users who do not want to see the details.
• Spread this to other modules: use some of the lessons here too make other modules better. Simpler modules will not take as long.

My take

Views for Drupal 7 looks far more user-friendly than Drupal 6. I am excited for when the critical mass of modules arrives to allow me to start using Drupal 7 for production sites. I will probably start with this blog.