Usability Findings: How is it to create a new content type or edit an existing content type?

dcmistry's picture

Usability Findings

How is it to create a new content type or edit an existing content type?

Background:

Note: The issues listed here are not added to the issue queue yet. The intent is to discuss them before we put it there

I recently conducted a usability study on content types. The most common tasks associated with them are creating a new type or to edit an existing one. To get a complete picture, I tested these scenarios in two different phases. In phase 1, I tested 7 participants with creating a new content type workflow whereas in phase 2, I tested 5 participants with the editing workflow.

Methodology and Demographics:

Phase 1:

● This study was conducted in February-March 2011 using Drupal Gardens (offers the same workflow as Drupal for creating/ editing content types).
● 7 participants were asked to create a new content type “Vendor” such that it captures the vendor name, description and industry (with the following options: Manufacturing, Pharmaceuticals and Retail)
● Of the 7 participants, 4 were new to Drupal / Drupal Gardens and 3 had some experience with Drupal / Drupal Gardens - none of the participants had created a content type before
● All the participants were site-builders
● Each session lasted for 45 minutes

Phase 2:

● This study was conducted at D4DBoston (Design for Drupal) conference in June 2011 using the latest version of Drupal 7
● 5 participants were asked to have a way to add a field that allows content creators to add attachments to “ Article” content type after being explained the concept.
● Given the time constraints and findings from the previous phase, the concept of content types was explained before the study
● None of the participants had ever created a content type before
● All the participants were site-builders
● Each session lasted for 15-20 minutes

Analysis (both phases including the summary and detailed findings)

Summary:

The same set of issues occurred while creating and editing content types: The issues were:

1. Navigating to and discovering content types was not intuitive
2. Workflow was inefficient as it involved too many clicks/ options and time consuming to add one field at a time
3. Terminology confused participants

It is also important to note that almost all the participants required subtle or direct hints from the moderator to complete their tasks.

At the end of the study, participants were asked to summarize their experience.
Phase 1 participants had negative responses as they struggled to create a new content type (because of UI and difficulty in grasping the concept through the UI). Once the phase 1 participants created a new content type and added one field, they were able to add additional fields of the same type. However, when asked to create a radio button field, participants struggled significantly. Also, recall that most participants needed help completing the first field, and many fields remain untested. Further testing is needed to determine if participants succeed at adding multiple fields of different types. Whereas, participants from phase 2 had mixed reactions to their experience. Below is summary of their responses:

Participant feedback

Phase 1: Creating a new content type

● "It is not as easy as it should be ... It's horribly frustrating.”
● “It should not let me mess up.”
● "I have to figure out if there is a problem, what is the problem and how to fix it... all on my own."
● "Process [of creating a custom content type] was painful. I did not know what I was doing."

Phase 2: Editing an existing content type

● “[I want] better terminology, better logic and how things relate”
● “Very Complicated”
● “I understand the power of Drupal but Wordpress is just too intuitive”
● “Once I knew where to go, it wasn’t bad”
● “It’s not too hard”

Detailed Findings:

Difficulty in navigating to and discovering content types

Almost all participants (phase 1 and 2) struggled to find "Content type". They expected this information to be under "Content". The issue was compounded in phase 1, as they did not understand the "Custom type" terminology. Phase 2 participants rummaged the settings on the “Article” page. On not finding the information there, they were certain that this information would be under “Content”.

"It is not obvious." (Phase 1 participant)
“Content type should be under ‘Content’” (Phase 2 participant)
“Knowing to go to ‘Structure’ and ‘Manage Fields’ is not intuitive” (Phase 2 participant)
“I would have never known to go to ‘Structure’” (Phase 2 participant)

Workflow is inefficient

Almost all participants complained about there being too many steps - possibly due to the fact that all the information is prioritized in a flat manner. New users either skimmed or missed important information, or read everything resulting in very long task completion times.The problem was further compounded with unclear terminology and lack of managing expectations.

"There is a lot of clicking ... A lot of steps to remember: I have to remember the path and what you are doing. You have to map everything." (Phase 1 participant)
“There were so many steps that I don’t even remember” (Phase 2 participant)
“All these are extra steps” (Phase 2 participant)
“I do understand the power of Drupal but Wordpress is just intuitive. Power give the capacity to do more but that should not be given [all] at the same time.” (Phase 2 participant)
“Am I at the end of it?” (Phase 2 participant)
“Unnecessary back and forth between two distinct sections - content and structure” (Phase 2 participant)

Phase 1 participants who created content types with multiple fields complained about the inefficiency of adding one field at a time (the process of going through the settings and adding another field). They wanted a quicker way to add multiple fields.

It’s worth noting that the participants (phase 1) who were asked to create a radio button list of industry (Pharmaceuticals, Manufacturing and Retail) struggled significantly with “Allowed Valued Lists” and “Number of Values”. They expected “simpler” way to chose between radio button or check boxes. For “Allowed Valued Lists”, they expected an easier to use way to add options.

Confusing or unclear terminology
As in other tests, we found users struggling to understand Drupal’s terminology. What makes the matters worse, is that the lack of supporting information (like hover or help text). In some cases when the information is available, it is not relevant which adds to the user frustration and offering no assurance to the participants if they are on the right track.

Participants did not understand: “Title label fields”, “_fields”, “Add existing fields”, “and Allowed values list”, “Number of values” and “Widget”. Participants (from phase 1) complained the description under “Content types” was not helpful.

“Nomenclature does not make sense” (Phase 2 participant)
● Number of values: “I don’t know what it means. I am just going to choose the maximum” (Phase 2 participant)
● Widget: “I don’t know what widget is doing… I want description” (Phase 2 participant)
“I am not going to change what I don’t understand” (Phase 2 participants)
“I only want ‘Edit’ and ‘Delete’. Edit / Manage Fields / Manage Display / Delete confused me” (Phase 2 participant)
“Where should I go? ‘Edit’ or ‘Manage Fields’?” (Phase 2 participants)
“I did not know there were deeper settings. Save was misleading” (Phase 2 participant)

AttachmentSize
difficulty in navigating content types.png260.75 KB
Too many steps - content types.png267.02 KB

Comments

The images

yoroy's picture

and

So in Drupal 6, content types

pwolanin's picture

So in Drupal 6, content types were under ?q=admin/content labeled as "Content management". The relocation to "Structure" in Drupal 7 was supposedly in response to usability studies. A failure or regression as compared to Drupal 6? What went wrong?

Interesting to see these

Bojhan's picture

Interesting to see these results, they are very broad - could you go more into detail on the workflow part? What do you mean by prioritized in a flat manner, what important information was missed and why? What expectations did they have? Can you visualize the individual problems participants had with each screen in the process, that will help communicate the problems better.

Same goes for confusing or unclear terminology, can you go more into detail? Describe the issues with each label, with these details we can make actionable issues to work on this terminology. Was there a trend regarding what is confusing, is it too technical - too ambiguous etc?

The quotes on why they would go to "Content" rather than structure makes a lot of sense. Could you explain more how you introduced them to it?

@pwolanin We don't know whether they will actually find it, if we place it under "Content" (probably a tab). We only know that some/many of the participants in this study looked for it there. A common problem in Drupal is connecting the dots between concepts, placing the content types link simply in content might solve this issue - but it will also create another problem of having to move about for site building tools.

And enclosing, where there large conceptual problems that you saw?

Some history...

David_Rothstein's picture

@pwolanin's question is a very interesting one. We have historical data on this issue that is important to compare with.

I looked into it a bit, and I think one answer is that we never actually had usability testing which suggested moving Content Types under Structure directly, but rather got there via a two step process:

  1. First, Content Types got moved under Site Building (http://drupal.org/node/240387). This was in response to some usability testing results from the University of Minnesota in 2008 (http://drupal.org/node/1166648) which showed that people were not looking for it under Content Management, and tended to look under Site Building instead.
  2. Later, Site Building got renamed to Structure (http://drupal.org/node/521474). I'm not sure if this was actually based on usability testing or not; there are some links on that issue, but they are unclear.

It is interesting that the Minnesota tests in 2008 showed that people weren't looking for it under Content Management, but the tests here showed that people were looking for it under Content. I'm not sure how to explain that discrepancy... could it be an issue of the task wording? In Minnesota, the task participants were given was "Create a form with some simple fields so users can list upcoming workshops" (the tasks tried to avoid using terminology that appeared in the Drupal interface as much as possible).

Dharmesh, what was the exact wording of the task you gave participants here. Did you use the word "content"?

Either way, the above data suggests than an interesting followup would be to do the same test with Drupal 7 again, only try renaming "Structure" back to "Site building" and see if people find it faster.

good history lesson

catch's picture

One thing to add was that the 2008 tests also went out of their way to avoid using keywords (i.e. content/content type etc.) - they were designed to describe a task without using any Drupal-specific terminology at all.

In phase 1 (creating content

dcmistry's picture

In phase 1 (creating content types), I asked:


SCENARIO: You are active at a local club. This year, they are hosting a conference for like-minded people to come together. You have been trusted with the responsibility of creating and maintaining their conference website.

TASK 1: As a part of creating a website, you have been asked to enter vendor information. You realize that the system does not have a preset method for doing this. How would you add “Vendor” information such that it captures the vendor name, description and industry.

To create the “Industry” field have the following options – Manufacturing, Pharmaceuticals and Retail.


From the previous phase findings that the beginners had difficulty understanding the concept of “Content types” and time limitation for the study in Phase 2, I explained the concept like this:


Drupal out of the box has two types of content: Basic Page and Article. If you look at “Article”, it has Title, Tags and Body. However, it does not meet the needs of your website. You would like to enhance “Article” in such a way that you are able to add pdf attachments to your “Article”. How would you go about doing this? While explaining the task, I also showed them this mockup: https://skitch.com/dcmistry/fefwa/skitched-20110705-103748


Focus of phase 2 was not on the discoverability but on the process and hence the word "Content" in the task. However, the findings did overlap with phase 1 when it came to navigation.

One might argue that using the word "Content" changes the results: My comments on that:
- Phase 1 results still hold true that people expect to find this information under "Content"
- Irrespective of knowing the concept or not, people expect this information under "Content"

My thoughts on the discrepancy:
In either phases, participants expect this information to be under "Content". They see it in relation to "Content" rather "Structure > Content types". I feel this is more in sync with the model of people who said "Blocks" are "Content". You also have to keep in mind that the toolbar is completely changed from D6 to D7, the other complimentary options also play a significant role in changing the user perspective. I am afraid that we might be too hasty in making this one to one comparison, which doesn't seem right.

Dharmesh Mistry
UX Researcher | Acquia,Inc.

Usability

Group organizers

Group categories

UX topics

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: