On Nov 1 2012, we tested the Views UI (7.x-3.5) with intermediate-level Drupal users at the BADCamp UX/UI Summit to provide the community with a clear picture of the usability bottlenecks in the Views UI, which is now in development in Drupal 8. We have identified a number of major problems and a large number of small ones, each of which now has an issue in the Drupal Core issue queue, where we discuss solutions, provide code patches with screenshots of the changes, come to agreement and put these changes into Drupal 8.
The study planning, participant profile, findings, videos and more are explained below.
Screeners and study guide
Findings from study
Video recordings (YouTube)
Participants thought that Views was â€œpowerfulâ€ but complained about the steep learning curve to understand the concept and using the Views UI when they were first introduced to it. They relied on extensive Googling, face to face explanations from colleagues and video tutorials to learn Views. When they were thrown into unknown territories, their frustrations with using the UI were palpable.
- Number of participants: 8 (1 advanced user, 6 intermediate users, 1 beginner user)
- Session length: 45 minutes
- Study Focus: Using Views in Drupal 7
- Understand existing userâ€™s views usage & experience [behavior focused]
- Uncover critical/major issues with existing users [UI focused]
- How users navigate and operate the advanced settings
- Gather data quickly so that actionable improvements can be incorporated into Drupal core before the feature freeze
- Compensation offered: Google Open Source t-shirt
- Recruitment method: Twitter (from BADCamp, @lisarex, @dcmistry), email to BADCamp UX Summit attendees. The email was quite successful.
- Date: November 1, 2012
- Type of study: Moderated usability study (in-person)
- The sessions moderated by Dharmesh Mistry (dcmistry) and Lisa Rex (lisarex). Our volunteer note takers were Olga Biasotti, Angie Byron, Neerav Mehta, Lewis Nyman, Bojhan Somers, and Brian Young. Other volunteer contributors to the usability study planning include Bohjan Somers, Becky Gessler and Garen Checkley. Special thanks to Jen Lampton for coordinating the UX/UI Summit and putting up with us!
- All the sessions were streamed live on Google+ and are available on YouTube (linked below)
Screeners and study guide
Potential participants filled in a screener survey to see if they matched our profile, and a followup screener was used to help us clarify, when the scope of the study was narrowed.
We wrote a Views usability study guide (like a script), with the input from the Views in Core team.
- Participants were targeted to be intermediate users who have done Drupal site building and have familiarity with Views (They have created basic Views and have dabbled with the advanced views). To keep the data focused, this is a report of findings of 6 intermediate users and 1 advanced user only. Data from the beginner participant will be added to future beginner level study data.
- All participants were screened to be fluent in English.
- Participants are comfortable with technology in their personal and professional lives.
- The first screen of Views UI getâ€™s the userâ€™s foot in the door
- Participants rated their experience ratings higher as they got more exposure to views
- Participants like the ability to preview and create custom CSS
- Participants found theme template information useful
Critical, major and moderate usability issues
- Critical Lack of guidance: The views UI wizard page helps participants get the foot in the door but provides little guidance when they land on the second page. This is because the terminology is unclear and the visual hierarchy is flat. The problem gets severe under â€œAdvancedâ€ section.
- Use the Views UI wizard anytime a new display type is created.
- More visual hierarchy on labeling and/or positioning
- Contrib module with guided tour of Views
- tooltip on hover of difficult labels
[needs exploration + design]
- Major Too many items under configuration options for fields/ filters/contextual filters/ relationships: Participants feel â€œoverwhelmedâ€ when they see the long scrolling list of options. The problem gets worse because the participants do not necessarily see the â€œSearchâ€ option. The search option is visible only when you are on the top of the modal.
- Limit initial list to user created fields/filters.
- Reduce visual clutter caused by descriptions.
- Divide â€˜filterâ€™ (e.g. content, global) and criteria (e.g. Body, Comment count) into two columns, making the criteria more scannable
- Search box has no visual weight and/or fixed positioning.
#1832862: Users feel overwhelmed by handler listings
- Major Using â€œContextual Filterâ€ is difficult: When a participant selects a field in contextual filter, they are presented with a lot of options in a flat structure making them unsure how to proceed. This is mostly because of lack of workflow. The expectation was to select a default argument first and then move into related steps based on the choice. A related issue is the help text was unclear â€œAlso look for node and node author IDâ€ The advanced tools like contextual filter, relationship, exposed form require more guidance because it is a harder thing to do.
- Progressively disclose the functionality instead of all at once
- Revise the text to be less Boolean, more human
- Provide short UI / help text in a standard help block on these section to explain what they are
[needs exploration + design]
- Major Several participants forgot to save/didnâ€™t realise they need to save in order to see their changes to the view when they click â€œview pageâ€. On smaller screens you canâ€™t see the drupal_set_message() warning of unsaved changes.
- Provide an â€˜Unsaved changesâ€™ signal/notification within the main area of the Views UI, where they are looking [needs design]
- Move save to button towards the bottom of the page (between preview, or at the end, or both)
#1831894: Users miss "save" button and can't distinguish "editable" and "preview" areas
- Major Participant had difficulty determining where the view showed up. If itâ€™s a Page you can see the path. If itâ€™s any other display type, you have no way of knowing where those displays appear on the site (P4).
- Show on the views listing the region where the block appears
- Show in the views ui where the block appears (Attachment does this!)
- Show when thereâ€™s an attachment in the Views listing (Block, Feed, Page appear in alphabetical order)
#1834576: Improve details on the Views listing
- Major Disconnect in the workflow of adding a block, as you have to create the block display, then save, then go out to the Blocks UI.
- Add â€œplace block in regionâ€™ to the Views wizard.
- Add â€œplace block in regionâ€to the advanced views.
#1836390: Add â€œplace block in regionâ€™ to the Views wizard to help workflow and #1836394: Add â€œplace block in regionâ€™ to the Blocks settings in Views UI
- Moderate People often forget to add a path on a page, and if they hit save, they donâ€™t see see the dsm() letting them know. If they havenâ€™t saved, they still donâ€™t realise the path is missing because the default / is very small and subtle. Itâ€™s also a very small target area for such a critical step in creating a page view. (P3)
- Replace the / with text such as â€˜path is undefinedâ€™
#1831142: Path is never empty in option summary.
- Moderate â€˜View pageâ€™ link goes to the home if the path isnâ€™t set, causing confusion because people think that is what they created when in fact its not.
- â€˜View pageâ€™ is not an active link until the view has been saved
#1831696: View page link goes nowhere, if you have not saved
- Moderate â€˜All displaysâ€ is the default option, even when thereâ€™s only a single display. This is unnecessary and is one more decision a new user has to fret over.
- Hide â€œall display/This pageâ€ options e.g. filtering when there is only one.
- Significantly decrease the visual importance of this functionality.
#1836384: The views UI should display "All Displays" option only when there are more 1 displays.
- Moderate Other related issue to â€œAll displaysâ€/ â€œOverride this displayâ€: In order to override a display you have to go to the drop down on the top left of the modal and to apply the display you have to go to the bottom right. As users are focused on the task at hand, they donâ€™t realize that they have to change the filter and may accidentally apply to all displays. What makes the matter worse is that when it is changed to "Override this display", the label changes to "Apply (this display)" but the difference is so subtle that the user did not register the difference.
#1836392: In the Views UI, the interaction pattern of â€œAll displaysâ€/ â€œOverride this displayâ€ is confusing
- Moderate Participant did not understand the Preview was updated automatically. They didn't use it, and just went straight to 'view page'.
- Show when the last time the preview was updated
#1836470: Participant did not understand the Preview was updated automatically
- Moderate On Views listing, participants have trouble determining whatâ€™s active and whatâ€™s disabled.
- Split them into two tables, with disabled underneath
- Have the inactive views on a separate page, which is a gallery of possible views.
- Change them to a tabbed display, with Active being the default tab
- Fix the accessibility of the listing:
#1830822: Split the Views UI listing into two tables for enabled and disabled
- Moderate The More section only contains the Administrative title. The â€œMoreâ€ area is perceived as this magical area, where you might find something magical. Participants opened it and were disappointed to only find the administrative title.
- Move it out of this section until thereâ€™s more than one item, or label it with something less vague.:
- Only show it upon clicking a checkbox using states, e.g. Add administrative title.
#1831080: Remove the "More" area from the bottom of handler configuration
- Moderate 'Theme: information' label is misleading.
â€œTheme information name is misleading because we are talking about templates. I have been on this page so many times and itâ€™s still complicated. How are you supposed to know that this has themeâ€™s real output?â€ (P4)
Another participant didn't know what Theme: information meant.
- It should be relabeled to something like Theming: templates (P4)
#1833834: Theme: information label is unclear
- Moderate People often click the â€œSettingsâ€ link when they see â€œHTML list | Settingsâ€ which causes them to miss how to change the main formatter settings.
- Merge the two settings
- Make settings a tab of HTML list.
- Moderate When adding a field, â€œCreate a labelâ€ is checked by default but we observed most people deselecting this. Itâ€™s only mostly useful for table display. (P4, P6, P7, P3). Needs more discussion to determine if this observation is accurate.
- Deselect by default, collapse options. Limit # of items isnâ€™t labeled so participant was unsure how to limit items on a block display. Assumed Pager label was specific to pages.
#1831674: â€œCreate a labelâ€ by default is a confusing default
- There are 3 places the user sees for titling the page. (P2) http://screencast.com/t/S3BL6wdcflj
- Medium: Help text is not helpful â€œalso look for node and node authorâ€ (P4)
- Large: Participants arentâ€™ clear on what contextual filters are or when to use them (P2, P4)
- Large: Participants arentâ€™ clear on what relationships are or when to use them (P2, P4)
- Medium: Grouping on fields is not widely understood
- Grid display is not responsive because it is table based (P1)
- Format level doesnâ€™t signal about display (HTML/settings) (P6 & P7)
- Preview contextual filter doesnâ€™t have format settings (P6)
- Large: observed people applying changes to All displays when they meant to override
We will discuss the issues and explore other alternatives in the Drupal core issue queue. Relevant issues are tagged BADCamp2012UX.
Video recordings (YouTube)
Participant 8 (new user)