Making Drupal more editor friendly: admin/content modifications

October 2, 2016

ux

Here's a few things I've learned along the way to make Drupal a little more editor friendly. When appropriate, I will show how these improvements fit in with Nielsen's ten usability heuristics.

Make admin/content work for your editors

Recently I was explaining to a client how to edit pieces of content on their site. The site contains a fielded taxonomy term called Insitutions that is used to categorize the Programs content type. As I was explaining to the client how to edit taxonomy terms I realized that it sounded ridiculous. To edit every other piece of content I tell the client to go to admin/content. For this piece of content, however, I was telling them to dive into the depths of a Drupal admin interface.

For Drupal developers or people who have worked with Drupal for years, I don't think they realize how strange this is because to them it makes sense. I admit, to me it makes sense too. However, we build Drupal sites for content editors, who are sometimes not Drupal experts. I think that is very important to keep in mind.

Here's what I did to make this area work for me: Clone the default administration views to create tabs of different types of content.

clone

After cloning the View, edit the view name to your liking. For example, for the Events tab, I made the View name Administration: Events.

First, disable the System view and click +Add to create a page display. Under Path, be sure to set it to /admin/content/. Under Menu, create a tab and give it an easily recognizable name. Now, configure the view so that it shows the appropriate exposed filters and content. Example:

cloneview

Note on access/permissions: I've found that if you set the Access rules of the view to a Role or Menu system path, then anonymous users will be able to access your view if they know the URL. They won't be able to actually perform any operations, but it's still not ideal to expose it to anonymous users.

Repeat the cloning process until all your content that you want to be easily accessible are represented in tabs.

Example:

Drupal content tabs

Now when editors login to the site, if they click on "Content" in the admin nav bar, they have direct access to everything that is needed for them to edit the content on their site. No more wondering "Where was it that I edit Institutions?"

Consistency and standards This creates some standards and consistency in the interface.  There is now a standard that editable content be available within the admin/content interface. This is comforting to users because they no longer have to explore Drupal's admin menu if they simply want to make a change to a piece of content.

Recognition rather than recall By putting all the tabs in one area, the user no longer has to remember information as they click through the interface. This allows the user to recognize what it is they need to edit, rather than trying to recall how to edit Institutions, Events or Programs.

Match between system and the real world According to Nielsen, "The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms." When trying to edit an Institution, words and phrases like Structure, Taxonomy, and List terms are hardly speaking the user's language. They know they have a piece of content to edit and will be looking for ways to edit it within a list of content. By providing tabs to directly edit taxonomy terms within admin/content, editing content within Drupal becomes a little less scary to novice editors.