The content creation experience is at the center of Drupal, its one of those screens that we want to keep improving. During the Drupal 7 cycle we worked intensively on making this page findable and having a pleasant to use admin theme. However we did not get around to actually improving much of the visual and interaction issues of this page.
- Creating content will be part of most first-time Drupal experiences. First impressions are critical.
- When a site is built and launched, creating, editing (and managing) content are the primary tasks for most of the people involved with the site.
- For many the look and feel of the content creation page is a defining part of Drupal. Redesigning this page allows us to explore a more engaging look and feel for the Drupal admin.
Currently, we don't make creating content as easy as possible. People will manage to type a title and some body text, but quickly after that some serious problems start to arise.
So what do we want to improve? Well, that is step 1. Lets do some research.
Each usability test so far has touched on the content creation page, and we have already fixed a whole lot of issues. In early 2008 we found that the way fieldsets were used on this page was confusing. This is where the vertical tabs were introduced. Every subsequent round of testing and design iteration uncovered new major pain points. During the last test in February 2012 at Google we found major usability issues with links while previewing.
We looked at the current state of open usability issues, what our competitors do and took stock of what contrib does in this space. This should give a complete picture of what we can do and what we can take as inspiration.
This research is not complete, it is not a full overview of everything related to the content creation experience, but rather a selection of the more interesting findings, that we might apply to a new design.
We have a lot of issues around the content creation experience, some that can be solved by minor tweaking but most of them require major changes in the functionality around this part of core.
A quick summary of the major issues in core:
- Previewing content is a true DrupalWTF, people are very confused by the fact that preview isn’t shown in the front-end and that the preview shows two versions (teaser and full).
- Vertical tabs are overloaded with many settings that are not relevant to the user, especially with contrib this area can grow to contain many on-off settings.
- If you don’t add a menu item, its too easy for a user to lose the content.
- Text formats are still somewhat of a mystery to people. Instead, people ofthen mention they miss a WYSIWYG editor.
- We miss the right tools to handle forms with a lot of fields. Currently this often becomes a plethora of fieldsets.
- It is often unclear what the publishing status of a content item is. Published, unpublised?
There are a lot of usecases to consider, when researching this page we always considered the blank (just core fields), regular (a couple fields) and flooded state (dozens of fields).
What are the others doing?
We have done a quick review of how other CMS’s handle the content creation screen. One of the most notable differences is the amount of “grouping” mechanisms, where Seven only uses a fieldset grouping pattern - Wordpress, Joomla, Textpattern, Hippo all make use of sidebars to promote Publishing options.
We also noticed that the content creation screens are visually often quite messy. Individual fields are not designed and the WYSIWYG editor is often a distraction because it doesn’t match the overall admin visual theme. There is no obvious pattern to where publish/save buttons are placed: bottom, top or sidebar are all used.
One of the major conclusions we can draw however, is that visually many of our competitors have more styled screens. From over the top like Joomla, to very minimalistic like textpattern.
What is contrib doing?
Contributed modules offer valuable insights into what is possible, and hint at what scenarios we should consider. This wasn’t an extensive review of everything in contrib, we looked primarily at a few popular modules.
Integrating wysiwyg editors and other contrib modules such as the Media module is visually still quite problematic. Although the WYSYWYG module does a great job at integrating many different client-side editors, the various visual styles are disconnected with Seven.
Inline editors offer a promising look into what the future of Drupal content editing could be like. Nevertheless, some are straight-out buggy. Aloha editor does a good job, working with several Drupal concepts and providing in line tools.
Inline editing is clearly still very much an experimental field. Things can easily get confusing when editing fields further down a page and it gets saved. However, there is a lot of potential in this pattern.
As we researched other ways of organizing the content creation screen one really stood out, which is the Field group module. This module lets you create groupings such as fieldsets, horizontal tabs, vertical tabs and accordion menus.
We also had a look at how modules embed forms and/or how multi-page modules work. All of these modules offer interesting functionality, but they are visually often very disconnected from the default Seven admin theme.
A clear trend we noticed in customized content creation screens is that people try to find more ways to grouping items beyond the fieldset pattern. In Drupal 8 we will hopefully introduce other way(s), to visually group related items.
Since we introduced vertical tabs in Drupal 7 it has become a prominent design pattern, applied to various configuration pages. Its strength is its scalability while remaining relatively easy to scan. Its weakness is its visual prominence, making users feel compelled to check the contents of each individual tab.
An interesting find was that most modules only expose one or two textfields or select lists for configuration. This leaves a large empty vertical space. Occasionally we found more advanced configuration as shown in the meta tags configuration example.
To start, we threw out some sketches to get our thinking started.
We brought these together to compare and review. A trend we noticed in our own sketches it that we where looking for multiple ways to group our configuration, going beyond our current vertical tabs pattern to a sidebar, accordion, dropdown.
From these initial sketches we took a step back and looked at the bigger picture.
Content, settings, actions - 3 zones
We found that on a content creation screen, there are three main areas to group functionality into:
A. Content fields
B. Content settings
C. Publishing options
The ordering in this sketch is what Core does now: it places fields on top, settings in a vertical tab area and the actions to save or preview at the bottom.
We explored different positions of these elements, primarily because B) Content settings are often too prominent.
Conceptually there are at least two obvious alternative configurations:
With the publishing options (C.) on top we mimic the model that a few other CMS’s apply, most notably Joomla. All actions are placed consistently across the top. Taking it a bit further one can imagine to also include publishing options such as date, author, menu, url etc. along the top. This would have the benefit of more focus on these settings, the downside would be creating a one-off design - because this pattern has less use in other screens.
Placing B) Content settings on the side, is a model that is used by most popular CMS’s - where the design often only accounts for a few options. This could be a consistent pattern across core where we place filters for example in a sidebar. The downside is that it can become too prominent and taking up too much horizontal space, requiring the content fields to be more compact.
Settings in a sidebar
A crude sidebar mockup in Firebug, floating the current tabs to the right of the content fields. As you can see, even without any optimisation to the labels and summaries it still manages relatively well within this restricted width.
One of the major challenges of this pattern is not whether we can make content fields more compact but rather whether we can account for complex content settings to be placed in the sidebar. As noted in the research, most of contrib only add simply 1 or 2 options in a drawer but there are the occasional more complex settings. We think a lot of this can be mitigated by optimizing the way that contrib displays these settings by relying more on correct labeling and less on long descriptions.
Publishing options along the top
This wireframe illustrates how we could place publishing options and potentially more along the top. It shows the different settings in a collapsed state while varying between 1) dropdown settings, 2) inline settings, 3) placement of actions in the top area.
We have a lot of breathing space for this concept in core. The current implementation of the shortcut bar could be adapted to swap in or append these kind of configuration options. It will have the added benefit of moving these settings away from the content fields, yet keeping them in view.
This pattern is especially interesting from a mobile perspective, because it allows you to put a lot of settings in a relatively small area.
The biggest downside is that it is hard to apply this pattern to other cases in core. We only have a few pages where you are creating items with a lot of additional settings like for example creating a new content type. However this pattern of “configuration along the top” holds a lot of promise, especially for exposing more contextual configuration in the front-end.
These research findings and design explorations should inform the direction we chose in designing this page. To summarize what we suggest to use as the foundation for more detailed design iterations:
- Keep the current approach of listing content fields in the main area but look into more ways to group related fields beyond fieldsets
- Rework the vertical tabs pattern into a less horizontal space consuming sidebar. (And look into applying a similar sidebar concept to other admin screens.)
- Move primary publishing options out of these tabs and position them closer to the Publish/Save actions.
We're working on more detailed designs for this, but right now we'd love for you to critique the research and wireframes so far:
- Do you think this is a viable approach? If not, where does it break, and how?
- Do you have more interesting examples of things that get put into a vertical tab?
- Have you seen other ways to group content fields besides fieldsets?
We would love to hear your feedback, we are especially interested in custom content creation screens you may have created or seen.
Thanks for reading this far, more soon!