Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
May 22 2013
May 22

We just launched Zact, one of our largest design projects to date at Chapter Three. We designed nearly 200 comps, including an e-commerce workflow, a customer dashboard that mirrors the functionality of the phone’s software, a Support section built on ZenDesk, and a consumer-facing website.

A disruptive new cell phone provider, Zact is a new company looking to redefine how customers purchase mobile services by making your plan 100% customizable right from your phone with no overage fees or contracts. They even give you a refund every month for any unused minutes, texts or data.

Helping Zact overcome business hurdles
As a new company in a major market, Zact turned to Chapter Three to help them solve some of their immediate business hurdles online.

  • Establishing brand trust
    To overcome lack of brand recognition and to educate new customers about the key advantages of the service, we created the “Why we're different” and “How it works” sections as a way for new customers to get to know us.
  • Paying full price for the phone
    To educate customers about the long term savings of buying the phone at full price, we created an interactive Savings Calculator. The calculator allows customers to compare various plan and phone options to their current bill to show their dollar amount saved over a two year period.
  • Buying a phone online
    Without the ability to physically touch the phone customers are buying, we needed to build in extra guarantees to make customers feel comfortable purchasing a device online. We featured a “satisfaction guarantee” statement prominently throughout the site, promising a refund within 30 days if the customer did not like the phone.

Herculean feats of UX strength
The complexity of interactions across the site gave us an opportunity to flex our UX chops. We collaborated with Zact’s usability specialist, incorporating feedback from weekly usability tests to iteratively improve our designs.

  • Customer dashboard
    To provide the functionality of the phone’s software on the website, we designed a web-specific interpretation of the phone software that empowers customers to access and control the full breadth of Zact’s service offerings. Because the software was being developed in parallel with our web design, we adopted an agile design approach to iterate in sync with the development team.
  • E-commerce
    Our team worked with Zact’s usability specialist to implement a checkout flow pulling from best practices across the web. We delivered a solution that pushes the capabilities of Drupal Commerce and its ability to integrate with third-party systems.

Agile design
An agile design process was critical in the success of this project. We needed to be flexible as requirements and scope were changing daily. We met with the client daily via WebEx with new design deliverables for review, which allowed us to gather feedback often and respond quickly. For any given page, we were able to explore a number of options on a high level before focusing on a more final solution.

In fact, some of the best ideas on the project came directly from the client, as a result of organic discussion during those meetings. The Savings Calculator, which allows users to more visually understand how they will save money over time with Zact, grew out of a conversation we facilitated.

Our first iterations of the Savings Calculator were pretty skeletal and didn’t quite feel right; the user had to fill out the form and click a button before seeing results. After further discussion, the client suggested that we make the actual dollar savings visible and dynamic throughout the page, so that as you interact with the form you can directly see how your savings are affected. This minor design change immediately made the page more engaging and an effective tool in communicating why Zact is a viable alternative to a traditional phone contract.

Starting up in Silicon Valley with Drupal
One of the most exciting and challenging parts of the project was the rapid pace of startup culture. The level of expertise and web savvy amongst Zact’s staff allowed for a flourishing partnership where we were able to push boundaries and do great work together. So far, the site has been covered by some major press outlets, including Gizmodo, Engadget, Forbes and TechCrunch.

The site is finally live, but our work isn’t over yet. We’re continuing to evaluate and optimize the usability of the site and will continue to roll out design updates over the coming weeks. We look forward to working further with Zact and seeing how users will react to the new site.

Jan 07 2013
Jan 07

A major focus of usability efforts in Drupal core has been around making it easier to edit things on your site. In Drupal 7, we introduced the Contextual links and Overlay modules to make it simpler for content authors and site builders to jump directly to the parts of the administration that relate to the things they see directly on the page, such as blocks or menus. Drupal 8 has now upped the ante with the new in-place editing feature, which allows for direct modification of content on your site, within the context of the page it is displayed on.

The next logical step is to take in-place editing to the next level by unifying contextual editing paradigms: combining the concept of "edit mode" with the ability to contextually edit more than just fields on content, in order to allow for contextual editing of everything on the page, in a mobile-first way.

Specifically, we need to address the following challenges:

  • Conflicting patterns confuse users: There are contextual gears to edit content, local tabs to edit content, and "Edit mode" to edit content. These patterns need to be streamlined.
  • Tasks are not intuitive enough: Seemingly simple tasks can often result in "pogo-sticking" around in the admin backend trying to locate where to change a given setting.
  • Unnecessary information slows users down: Drupal forms tend to be long and full of advanced/confusing options, which can overwhelm users trying to complete simple tasks.
  • Interactions don't work with smaller devices: With Drupal 8's Mobile Initiative, it is critical that these tools be as easy to use on the desktop as they are on a smartphone or tablet.

Here is a video showing what we'd like to propose for solving these problems in Drupal 8 core:

We've now performed several rounds of internal usability testing on this functionality, and it has tested really well so far, with a high emotional value: in general, people can't believe this is Drupal. :-) Check out the prototype yourself at https://projects.invisionapp.com/share/U2A4IAGX.

I'm very excited about these changes, and feel that if we can get this into Drupal 8 it could be game-changing. But what do you think? If you like it, we'd love help with implementation and reviews in the core issue at http://drupal.org/node/1882482.

Aug 21 2012
Aug 21

Drupal Commerce has seen significant user experience improvements in the last few months, mostly because there is now a focused installation profile called Drupal Commerce Kickstart that tries to provide a highly usable install for store administrators.

My involvement started in 2009, during an evening stroll through Paris – Mike’O Conner from Commerce Guys introduced me to the idea to build a eCommerce distribution from scratch for Drupal 7. It was a great opportunity for me, to learn how the patterns I was designing for Drupal Core are applied on a large scale.

The redesigned installer for Drupal Commerce Kickstart.

We quickly learned that doing all the technical work for such a large distribution and doing all the user experience work was nearly impossible. So the focus for Drupal Commerce 1.0 was to get all the major technical parts implemented and adhere to the new UI standards of Drupal 7.

Drupal Commerce 1.0, hard to use by store administrators

The first version of Drupal Commerce saw a lot of usage, and with that a lot of complaints that it isn’t quite usable for store administrators. With eCommerce solutions like Shopify people have high expectations for what an eCommerce package should offer in terms of user experience, and Drupal Commerce simply wasn’t hitting that level.

To get a clear picture what we needed to focus on, I performed a number of small usability tests with developers and store administrators. They were people I knew should be able to successfully use Drupal Commerce. The results were quite telling;

  • Participants struggled to create a product, the step between product and product display is completely alien.
  • Navigating around, the Drupal information architecture gets in the way of finding often used links such as “Store”.
  • Participants were unable to find the product they created, because there are no clear taxonomy settings.
  • Lack of common functionality is what people where most confused about; functionality like promotions is considered a fundamental part of an eCommerce tool.

However as Drupal Commerce saw more and more action, it was clear this could not be solved by doing small iterative improvements. Drupal Commerce is primarily a technical framework, and users are confused because they expect an out-of-the-box experience. This probably has a negative impact on the adoption rate.

Drupal Commerce Kickstart, a focused distribution

With Drupal Commerce Kickstart 2.0 the intent is to provide this out-of-the-box experience and really showcase all that Drupal Commerce has to offer. Commerce Guys has invested heavily in improving Drupal Commerce Kickstart and created a team that worked hard on building critical functionality and improving many of the problems that were found by community members, clients and in usability tests.

In July 2012 I collaboration with Allison Simmons to perform a number of usability tests on an early development version of Drupal Commerce Kickstart 2.0. We tested a total of 12 participants, 8 site builders and 4 store administrators for over an hour, where we performed common tasks such as creating a product, editing an order and creating a discount. People really loved the front-end theme that Kickstart comes with by default, but they struggled with:

  • Participants consistently missed functionality; from the ability to bulk create product variations, filter and bulk update products, to incomplete store settings.
  • Store settings are often overly technical and missing functionality required for medium/large sized shops.
  • The “Getting Started” section was designed to help people get started using Drupal Commerce Kickstart, but actually helped very little and caused its share of confusion as well.

To follow up on these findings I worked together with Allison and the team at Commerce Guys to find solutions to these problems.

Mega-menu to capture Store settings.

We revamped the installation to give more brand identity to this process; the installation process goes through the normal Drupal installation process and then allows you to add demo content. The navigation also saw significant change, which is now much more focused on store administration tasks. Where admin_menu provides a very deep insight in the information architecture and toolbar a very shallow, using mega-menu dropdowns we where able to provide a good depth and overview.

Redesigned listings using Views.

The listings provided by Drupal core are not very usable, we redesigned the product and order listing pages to capture all of the filters/bulk operations that are needed in daily store administration tasks.

These are only a few of the pages we touched following the usability testing results, we where able to fix a large number of problems in creating discounts, navigating help, creating product variations, managing your shipping services and much more.

UX lessons in designing a distribution

Distributions that have launched in the past two years clearly focused more and more on providing a great user experience. Those that succeeded went beyond what Drupal provides by default and created a product with a clear purpose and audience.

Some the lessons I learned are;

  • Seven has a lot of flaws: Create a sub-theme or create your own theme – to create a stronger brand identity and fix many of Seven’s usability problems.
  • Review the UX of each contributed module you add: Many of them add overly technical help text or violate Drupal UI standards that end up confusing your users.
  • Customize the information architecture to meet primary use cases: Although it’s a painstaking process because Drupal makes it hard, you can gain a lot just by providing a focused navigation.
  • Add additional form styling to capture more complex forms. Drupal Core has very few tools to visually manage complex forms, don't be hesitant to introduce titles, sections etc.
  • Take the open-design process for a spin, we did almost all of our design work in the issue queue and this generated a lot of valuable feedback from users.

I think the most important thing I learned is to be bold, although Drupal Core offers a lot of certainty in terms of established UI patterns - it also holds you back in providing a tailored user experience for your users.

Drupal Commerce Kickstart has a lot of potential in showing all that Drupal Commerce has to offer and truly providing a great out-of-the-box experience for doing eCommerce with Drupal. From a UX level it doesn't have the legacy and immense amount of complex features other eCommerce tools offer, but still has a way to go to make its features a delight to use.

*ComerceGuys asked me to write up my experiences, working on Drupal Commerce and Drupal Commerce Kickstart.

May 31 2012
May 31

The goal of the Spark distribution is to incubate authoring experience improvements in a Drupal 7 and Drupal 8. It was announced earlier this month, and since then we've been hard at work on initial research and design.

The Spark team's primary focus is on improving Drupal's content authoring and editing experience, and the first feature we're prioritizing is in-place editing: the ability to edit content, menus, etc. directly on the page, without the need to navigate to a separate edit form. Think of it as "true" WYSIWYG.

Members of Acquia's design team spent time analyzing how some of the most widely adopted Open Source as well as proprietary CMSs do in-place editing. We then prototyped some initial ideas, and performed usability testing on those prototypes to see what works and what doesn't. After a number of iterations, we're happy to report that the usability testing has validated Spark's general design direction. People loved the prototype. Now is a good time for us to share our initial prototype and to solicit further feedback from the community so we can shift gears into implementation.

The following 5-minute video walks through the HTML/JS prototype, and also provides a bit of background on the Spark project:

Our goal is to deliver this functionality in a contributed module for Drupal 7 first and foremost, which will live at the In-Place Editing project on drupal.org. This module will be bundled into the Spark distribution. Depending on how it is received, I hope we can also target this functionality for Drupal 8 core.

From a technical architecture standpoint, we are currently in the process of selecting the WYSIWYG editor to use in Spark for in-place editing of HTML content. For now, we plan to focus on supporting only the Filtered/Full HTML text formats in order to get us to something testable faster.

Later, we are hoping to branch out into other areas of authoring experience too, including helping with the content creation form improvements that the Drupal usability team has been spear-heading, as are well as the layouts UI work being actively discussed in the usability group. The Drupal usability team is doing an incredible job with these issues, and once fully staffed, I would like to see the Spark team help implement these improvements for Drupal 8 and backport them to Drupal 7 so we can ship it with the Spark distribution. (Did I mention that the Spark team is hiring? ;-))

As you can see, things are starting to move along quite nicely. Please join the discussion in the Spark issue queue if this functionality sounds exciting to you and you'd like to help!

May 01 2012
May 01

At DrupalCon Denver, I announced the need for a strong focus on Drupal's authoring experience in my State of Drupal presentation. During my core conversation later in the week, I announced the creation of a Drupal 7 distribution named "Spark" (formerly code-named "Phoenix"). The goal of Spark is to act as an incubator for Drupal 8 authoring experience improvements that can be tested in the field.

I hope for Spark to provide a "safe space" to prototype cutting-edge interface design and to build excellent content tools that are comparable with the experience of proprietary alternatives. While not a final list, some initial thinking around the features we want to experiment with is:

  • Inline editing and drag-and-drop content layout tools ("true" WYSIWYG)
  • Enhanced content creation: auto-save, save as draft and more
  • Useful dashboards for content creators
  • Mobile content authoring and administration support

The vision behind the Spark distribution is to be "the Pressflow of Drupal authoring experience". Pressflow provided a "spoon" of Drupal 6 with various performance enhancements that made their way into Drupal 7 core while it was in development. The same improvements were made available to Drupal 6 users so they could easily be tested in the field. With Spark, we want to test authoring experience improvements in Drupal 7 on real sites with real users and real content. We also want to target the best improvements for inclusion into Drupal 8 core.

I'm excited to announce that Acquia will fund the Spark distribution. Core developers Gábor Hojtsy and Wim Leers will work on Spark full-time starting in late May. They will work along side Angie Byron (webhchick), Alex Bronstein (effulgentsia), myself and other members at Acquia. While we have some promising candidates so far, Acquia is still seeking applicants to join the Spark team (with a strong preference to candidates located in or willing to move to the Boston area):

The Spark team will collaborate with the Drupal usability and the core development teams.

Mar 13 2012
Mar 13

Posted Mar 13, 2012 // 3 comments

So I can’t tell you how excited I am to go to my first Drupalcon as Community Manager of Phase2! While I attended both Drupalcon DC and Drupalcon San Francisco, I know Drupalcon Denver will give me the opportunity to meet more members of the community and to talk to you about your experience with our products.

Of all the things I do here at Phase2, one of the most important is helping our product communities contribute to each product's roadmap. Knowing how you're using the products, what features you want to see, and how you'd like to use them in the future is important for any product; but for open source products like OpenPublic, OpenPublish, and Open Atrium, it's vital to their growth and development.

While we can take what we think is best and create a product off of that, that doesn’t help the community work together on this product. Our goal is to work together -- with you -- to create a product that meets the most common use cases for all users. We could dictate what we believe those to be, but the work will be stronger and better if we decide as a community.

So while I’m at Drupalcon, I want to hear from you about what YOU want to see in our products. I’m currently in search of those of you who have been using our products, are willing to discuss how you've been using them, and have some feedback on their uses. What do you like, what don't you like, and what could we be doing better?

Some of the commonly suggested features and functionality might become part of our product roadmap, where we'll be seeking contributions and collaboration to get it built. No matter what, it starts with you saying what you'd like to see!

If you are interested in sitting down with me and providing feedback, please send me an email at [email protected]. You can also find me next week at the Phase2 booth. Let’s get the discussion started!

As our Community Manager, Danielle is responsible for the communities around our products, which include OpenPublic, OpenPublish, Open Atrium, Managing News, and Tattler, as well as the Drupal modules we maintain.  She is also ...

Feb 13 2012
Feb 13

Need a simpler UI to let administrators manage fields? We recently created a new contributed module called Simple Field. This module simplifies the UI for creating fields and adding them to content types and entities. It also provides granular permissions, so you're not stuck with a single catch-all permission for managing fields. You can see a demo of the module in action at simplefield-demo.ewdev.ca (login: demo/demo).

Why do I need Simple Field?

Imagine you're creating a Drupal site and you want to let your users create fields, but you don't want to give them the 'Manage Fields UI'. The Manage Fields UI is very powerful, but it also provides a lot of settings and configuration that can be confusing for non-technical users. Giving users permission to manage fields allows them to delete fields, and you might want more granular permissions to prevent users from deleting data on the site.

Simple Field Types

The Simple Field module includes a set of Field Types. Instead of a long list of cryptic types which can intimidate non-technical users, field types are things like 'Multiple Choice' or 'Yes/No'.

List of built-in Simple Field types

Simple Field types include a core field type, plus some field widget settings. For example, rather than choosing 'Boolean', users can choose 'Yes/No', which is a Boolean field with pre-configured options for yes or no. The user adding the Simple Field will not see the 'Options' field and won't be able to change the option values.

Of course, we can't anticipate all the Simple Field types that other sites will need, so the module is extensible and allows developers to define additional Simple Field types in code.

Creating Fields is as Easy as Pie

With pre-defined field settings, creating fields becomes much easier for users. Users just need to enter the label, whether the field is required, and help text. Some Simple Field types, such as 'Multiple Choice', have an options field, but that's it.

Creating a 'Yes or No' Simple Field

Attaching Simple Fields to Content Types

You can enable Simple Field on a per content type basis, which provides a nice UI for managing the Simple Fields for that content type. The module uses modals to keep the UI concise. You can create and attach files from the same page.

UI for attaching Simple Fields to a Customer content type

An Alternative UI for Creating Fields

The Simple Field module provides an alternative UI for creating fields, which only exposes some of the field settings to users. Other administrative roles can still be given access to all of the more advanced settings through the Manage Fields UI. The fields are stored in the database in exactly the same way, so everything like Views integration still works. All settings and weights are synchronized between the two interfaces.

Simple Fields appear in the Manage Fields UI

Granular Permissions for Fields

Permissions for the Simple Field module are very granular. You can control which roles have access to which field types and whether users can delete fields or remove fields from a particular content type or entity. For example, you can configure your site so that the users with the 'service rep' role can add Yes/No, Multiple Choice, and Short Answer simple fields to the customer content type. This way, service reps can add fields on-the-fly if they realize that collecting a particular piece of information from customers is valuable.

Simple Field Permissions

Adding Simple Fields to Entities: Fields as Content

While the Simple Field module can be used to add fields to bundles (i.e. content types) it can also be used for adding fields to entities. This opens up a ton of new possibilities. For example, you can create a survey entity and allow users to attach fields to each individual entity. Used this way, the Simple Field module is kind of like an alternative to the Webform module, allowing you to add fields to pieces of content.

Presentation at DrupalCamp NJ

Alex Dergachev presented a case study at Drupal Camp NJ on February 4, 2012 and included a demo of the Simple Field module. The case study shows our original use case for the module in the context of a Drupal project for a university.


For information on creating new types, among other things, take a look at the documentation.

Feb 10 2012
Feb 10

I am excited to announce what a huge success the Drupal usability studies were last week! We livestreamed 8 usability sessions using both Google+ Hangouts on Air and Livestream.com and had over 115 people watching live! The exciting conversations taking place in the #drupal-usability IRC channel proved how powerful live events are; the community truly came together through a process of collaborative brainstorming and experiencing the struggles of new users collectively as they happened.

Our usability lab setup was flawless thanks to the masterful help of my friend and coworker Garen Checkley. Jen Lampton from Chapter Three served as the help desk support for study participants during the session. I moderated the sessions and walked participants through different tasks that we created along with the help of Bojhan Somers and Angie Byron.

We divided our study participants into 2 groups to study; one using vanilla Drupal 7 to observe where new users had trouble understanding the the basic system, and one working with a custom Drupal 7 install that already had specific contrib-modules installed and enabled to gain insight into usability issues with specific interfaces, especially the hugely popular module Views."

Currently we are beginning the process of turning our findings into actionable items that we can put into issue queues. The Drupal Usability group will work hard to act on the results of this study to improve Drupal. Recorded videos of the sessions can now be viewed on our YouTube playlist.

Additionally, I have posted a video of my presentation “User Experience for You and Drupal too!” with Jen Lampton from Drupal Camp San Diego (SANDCamp) in an article on my blog. Be sure to check out the video for an overview of fundamental principles of user experience and how UX has evolved in the Drupal community.

When our findings and results from the study become more refined, Garen will write another blog post on this blog to share our findings and some more links. Until then, make sure to get involved with the Drupal Usability group if you are interested in helping to act on the findings of these studies and continue to make Drupal better!

By Becky Gessler, Google Search Quality team

Jan 28 2012
Jan 28

Drupal is an open source content management system with thousands of active community members behind it. A popular solution for both small and large scale websites, Drupal is extremely flexible and offers thousands of add-on modules.  Drupal’s user experience (UX) layer, however, can be daunting and frustrating for beginners to learn. I am working on an exciting project in conjunction with the Drupal User Experience team and the Google Open Source team to help determine some of the key UX issues new users of Drupal encounter. The usability study will have participants (all Googlers) building a website and will help to gain insight into the stumbling blocks users encounter along the way.

The usability study will be streamed live and available for everyone to watch. The usability study is planned to take place February 1-3. Details about the live stream will be posted in the comments section below in the coming days. You can follow the discussion about this study on the Drupal.org wiki page.

Saturday, January 28 at Drupal Camp San Diego (SANDCamp) I will be presenting a talk called “Usability Studies for you and Drupal too!” on the fundamental principles of user experience and an introduction to the usability study. Jen Lampton from Chapter Three is co-presenting with me to talk about why UX is so important to Drupal, what the Drupal UX team has discovered through past studies, and how to get involved with the project.

Stay tuned for another post on the results, and make sure to check back on the Drupal.org wiki for details on how to watch live!

By Becky Gessler, Google Search Quality team

Feb 08 2011
Feb 08

In Drupal 7 you are now able to install modules and themes using the interface. This opens the possibility for contrib to create a browser of projects.

Showing a browser for modules, a listing and additional actions

Creating a better experience in exploring and installing modules is important for new users, to understand the Drupal ecoystem and the process of installing and configuring modules. Additionally seasoned users, are able to get everything up and running quicker. This is an design exploration, showing some of the possible interfaces for a project browser.

Exploring projects

Beside providing a simple listing of all themes and modules, the project browser could anticipate on already installed modules, versions and dependencies and from this able to give recommendations.

Many users at the beginning of the Drupal learning curve are struggling to find and install many of the modules we consider basic needs. Lets take a look at three very commonly used modules and the dependencies required for installation :

  • Views requires CTools
  • Rules requires Entity and Entity_token
  • Pathauto requires Token

All perfectly understandable requirements, but also often requiring many additional steps for the user. A project browser could eliminate this part and as we are moving more towards projects that depend on more on abstract modules, better separation of API & UI, distributions, features and so on - the need for a more intertwined approach to downloading and installing projects should be explored.

Showing Drupal core with a listing of themes, including a description, screenshot and install action link. Next to the sidebar filters are shown, to reduce the list.

The mockup above shows how-to explore themes, sorted by downloads. Some of the parts exposed :

  1. Listing of the projects, prioritized on overall usage.
  2. Filter pane, to quickly limit the number of results on your interests.
  3. Ability to make a list of projects you want to install

Installing projects

Installing several projects
Drupal 7 core does not allow you to install several modules at once. The project browser could allow this, allowing to install a list of modules.

Showing a install wizzard, its first step, a list of modules you are about to install

Backup website
You remember that "you should backup your database and files before installing..." message that is often ignored? By automating this process we can ensure that this step is not overlooked. Using a module like Backup and Migrate would make this possible.

The image belows shows this in a progress bar, I separated this process from that of installing modules to clearly show that a backup is being made and you don't have to worry (as much).

Shows the step of backing up your website

Enabling projects
This is a step we currently miss in Drupal core it's installer, the possibility to directly enable the modules that have been installed - this instead of directing them to a page with dozens of modules.

Shows the last step in installation progress of enabling modules using a check box list

There is a great opportunity for creating a better flow in finding, installing, enabling and configuring projects. The examples shown are above, are about solving some of the major problems that users encounter, ideally we also find resolutions for the next step that of configuring (but this might be Drupal 8 material).

The full sized screenshots with additional annotations can be found on Flickr :

How to make it happen?

The biggest roadblock for making it happen, is the technical implementation of browsing all these projects. Do we for example require users to store a big file listing all the projects, that gets updated continuously or do we solve it by querying Drupal.org? There are many questions, but it is solving a big problem both new and seasoned users encounter.

Stijn Vanden Brande who works at Krimson worked on this a bit and put his work up at Github, we hope people can help solving this technical hurdle and contribute to actually make it happen as Drupal 7 contrib.

What are your thoughts?

Update: A GSoC project has been started to do this, called Project browser.

Feb 13 2010
Feb 13

From the announcement on drupal.org presenting Sabir: a user-friendly news platform for multilingual communities.

Over the past year we saw two parallel community initiatives heavily influencing the development of Drupal 7: a huge effort in improving Drupal's usability that led to the introduction of solutions and features, radically changing the user experience in building sites with Drupal 7. At the same time, advancing on the direction taken with Drupal 6, many internationalization improvements were introduced in core and many more will be available through contributed modules.

Both initiatives were driven by key contributors of the community, to promote them and push them forward. Self-organized sprints were held both for UX and i18n improvements, which allowed people to know each other better, work together, drafting ideas, and participate in designing and developing ideal solutions.

As a natural consequence, we launched the Sabir proposal: a community-driven project which aims to produce a platform dedicated to communities with minimal technical expertise, allowing to easily share news in multiple languages.

Nov 04 2009
Nov 04

We are now in the User Experience, Accesiblity and Performance phase in the Drupal 7 development cycle. The focus is on small user experience changes.

At least that is the idea. We have had major user interface patches committed just recently with the intention of "fixing" the user experience issues afterwards. Given this situation, we still need to make some big changes.

This post outlines what needs to be done in this phase. With our unrealistic time schedule of 1.5 month (only 4 weeks now) to clean up 18 months worth of new functionality, we need to ensure to spend time on the right issues.

I have listed the most important issues per topic.

Fields in core

We put the old CCK interface into Drupal core, with minimal changes to its interface. The interactions and workflows in the CCK interface need work. Because this is such a fundamental "Site Building" tool, we need to ensure it is usable for more novice users.


The experience of using the Dashboard is vital for Drupal, because this is the first thing administrators will see. The initial commit of the Dashboard contained no widgets (blocks), so we still need to create good default widgets for the Dashboard. Apart from that, customizing your Dashboard is still difficult because we haven't worked on any of those interactions from a UX perspective yet.

Edit links everywhere

This interaction opens a whole new world of possibilities, allowing administrators to more easily edit menus, blocks and more. However, we still have to create a UI that is understandable and able to handle modules adding their links to this interaction.

IA, text, search and more…

Because we shifted our focus to mostly D7UX related issues in the last few months, we still have a lot of loose ends left in Drupal's administration. Each of these are similarly critical to D7UX, since in every release we have to keep improving existing features on known usability issues.

With all these incredible new features, it's still very important that people can actually use them. Since the devil is in the details, we need to work more on the issues outlined above. The UX-Team is available for feedback in #drupal-usability (on freenode.net IRC) and per mail.

If you have suggestions, or feel that an issue is missing don't hesitate to comment.

Jun 15 2009
Jun 15

I've been working on implementing Leisa Reichelt's design for the new node add/edit form. Gábor Hojtsy started the process off by creating a patch to move the submit buttons up to the right, and separate the node form into a "Content" and a "Meta" tab. I refined his patch to make the horizontal tabs a reusable form element, and in the current state of the patch, the node form looks as pictured:

The effect is a more streamlined version of the node form: all the traditional "content" fields—you know, the ones that people actually pay attention to—are presented to the user without any distraction. Should a content author need to mess with the date a node was published, or other information that Drupal allows to be altered (but isn't typically necessary to fill out), they can click the "Meta information" tab, which switches tabs through javascript. The "Save," "Preview," and "Delete" buttons are all located at the top right for easier access.

The next step in implementing the design was the pseudo-collapsible fieldsets on the "Meta information" page. The basic concept was to leave information available in a readable state, yet not take up so much room so as to block other information from the screen. While the layout I created isn't exactly like the design, I believe it cleanly captures the essence of the idea without requiring too many changes to the underlying code. With my current patch, the "Meta information" tab appears as pictured:

I like what I've done a lot, but what is usable for one person might be completely unusable for everyone else. I'm sure there's room for improvement, so please feel free to comment on either of the issues (horizontal tabs) (modified fieldsets) or add a comment to this post to voice your thoughts or concerns. There are many opinions on what makes for good usability, and the more opinions we get, the more accurate a picture we can make of what is most usable overall. Thank you!

May 17 2009
May 17

We are a Drupal shop and as such we deliver ready-to-use websites to our customers. We always tweak interfaces to deliver better user interface alongside our projects.

I'm following D7UX discussions and looking forward better and cooler and I've noticed that in the moment there's a focus on content type forms and other administration issues. Of course this is very important to Drupal World Domination, but when it comes to Drupal usability, I'm far more concerned with the underprivileged (i.e., without too much perms) content editor. How do we make a great node editing interface?

Here are my two cents on the "publishing options".

As we of today, Publish options comprises three checkboxes: Publish, Promote to frontpage, Stick at top of lists. They are actually loosely related.


It is quite common for CMSs to have a "publish" boolean in all its content. So has Drupal. But... why do we have to show to our users such a booleanish checkbox?

I like Wordpress approach better. There's a big blue Publish button. If we save (or better, "Save as draft"), we're just saving it, as an unpublished node for later editing. If we press the "Publish" button, we know for sure it's going live.

It is easier for our users to understand. "Being published" is not a characteristic of a node, like a taxonomy tag or an address. It's an action we inflict on it. "Publish it!", said the editor, not "make it with get the 'published' status".


The approach described above for publish would help a lot on drafts. Most people need some time to write a whole text. In Drupal, when we need to have a draft, we unmark the "Publish" checkbox and press "Save". But it is just too uninvinting for "drafters". If Drupal is uninvinting people to write drafts, it's not invinting people to use it as a text editor at all.

A simple change from a publish checkbox to a publish button would be very benefical and would allow people to easily save drafts.

But, what if we push it a little further? I'd love to see an automatic draft saving in core, just like - well - Wordpress. There are some issues, though: validation of mandatory fields. There are lots of fields that must be filed before puting a node on air: title, one or two obligatory taxonomy vocabularies. All of them waiting for completion, before getting the node on air. Imagine a complex node type with thirty CCK fields. How could we save a draft of it? Moreover, there always are pathauto URLs, triggered actions, etc., that depend upon node creation.

Draft Module circumvents this issue by saving the form, not the node. It works, but it is not ideal. It's too confusing to have two different entities: drafts and unpublished nodes. How could we tell them apart without confusing the heck out of our users with tables and internal Drupal structure? Perhaps we could relax validation on draft (unpublished node) saving, and enforce them on node publishing. But is still a topic open for discussion.

Promote and Sticky

In today's world of Views and Panels and custom ways to exhibit content in fronpage, these two options are quite meaningless for most sites we build. Consequence? We must get rid of them, in some node types, to avoid confusion by our users. Or give new meaning for those booleans in other node types. Not nice.

I propose that we allow admins to choose, for each node type, whether that node type is "promotable" or "styckiable". For instance, blog posts would be promotable, but pages would not -- even to overprivilege user!.

Moreover, in the same way as "publish" described above, we could convert those two options into buttons. "Promote to front page!" and "Make it sticky!". It would be very interesting to see implement in the edit on page form proposed by Mark & Leisa.

Next steps

As we speak, our interface guy, Danillo is implementing these features in a module in Drupal 6 and we'll port it as one or more patches to Drupal 7. Stay tunned.

Apr 13 2009
Apr 13

Content Overlay

I traditionally find content overlays extremely useful for simple content operations and modal dialogs. For instance I patched and advocated an issue that would promote the delete operation on a node to a Menu Local Task like Edit and View currently are. This is in line with my views on implementing actions as decorators on the objects they perform their work on.

The proper use of a content overlay in this situation would be as a confirmation dialog for the delete operation. This would save us a page load and still provide the users protection against unintentional data loss. Another valid use of this system is the on the fly creation of a taxonomy term for a node that is being created, terms are simple concepts and their creation as an interruption of the node creation process makes sense because it inhibits the nodes creation (which is after all the real purpose of a modal overlay).

A misuse of this content overlay system would be in the creating of a complex piece of content like a node. Take a quick look at most REAL sites and you'll see that the node edit form can get to be rather large and complicated. Trying to stuff all of this content into a content overlay will surely result in having to scroll (even with the new vertical tabs in d7). If you want to see a deer in headlights give a user a content overlay that requires scrolling to see the submit button or the rest of the form. You might be there for hours if you don't break the spell on the poor subject.

I see the problems you are attempting to solve by introducing content overlays for node creation as two fold: the first is that you perceive the creation of content as too disjunctive form the normal sites flow (i.e. you create it, where does it go/live, and where should you go when you're done). The second is that I think you perceive the task of content creation as overly arduous and complicated. Reducing it to a content overlay would certainly provide the push to fix this issue. Let me start by saying that i think both concerns are valid but that i think the solution is suboptimal and might introduce more problems than it solves.

I'm a fan of making easy things easy and hard things harder. Applying that to this scenario might lead to an additional "Settings" tab (aka Menu Local Task) to accompany View, Edit, and (Delete)[http://drupal.org/node/196758]. This section would contain all of the "default settings" we've defined in the content type administration section. It could include comment (disable, enable), workflow (published, unpublished, promoted), and authoring information. It would also provide a place for contrib modules that operate in this same fashion to override their settings. For example pathauto module could be set on the content type with a pattern and the path could be overridden on a particular node in the settings tab with the user never having to know what generated the default path, only that if they want to change it they can do it there. We could reuse the forms and most of the validation logic for such a setup because it is a perfect mirror of itself.

We should be able to assume that the "defaults" we set in content type administration decently fit the usage scenario of the content type in question and not have to provide places for this to be changed during the simple act of creation or editing the actual content. This further reinforces the value of separating these actions from the node form (aka "add/edit).


I traditionally favor decorating objects (nodes, comments, users, categories) with the actions that you can perform on them (view, edit, delete, categorize, etc). To that end using the header as a decorator on the whole site works very well as a natural relationship for me.

Where the header concept seems like a really good idea for items that don't usually belong to something but instead belong to the site. These tend to include "1 off items" like account, status, creating content, search and shortcuts to administrative sections (content type admin, site info, user admin, etc) and help.

Where this analogy fails is when it attempts to extend that relationship to specific items on the site or page in question. Using the header to create a distance between the item being operated on and the action being performed on it seems detrimental to the process of getting the user to understand the relationship dictated above. I would favor the approach of decorating the actual content itself with that operation along with the other you might wish to privilege the user to perform (track, delete, etc).

Furthermore, while I understand the reasons behind wanting to hide what could amount to a cluttered list of actions on each content item (e.g. node, block). The concept of an "activation edit" button, assumes a false dichotomy between the normal use of a page and the interaction with its content. Because so many diverse sites are created with drupal we cant always predict how the functionality we write might be deployed on a particular implementation.

As a simple example "Developer A" might deploy the five star rating system on the site of a movie reviewer and "Developer B" might deploy it on a Yelp or Netflix style site that solicits normal users for input. In the first case the voting action is clearly administrative and would occur while creating the content but in the second case the user would interact with the widget in a much more casual fashion. This is just the simple example I could come up with on the fly. I'm sure talented others could extend it across other modules and actions for you if you'd like.

Instead of implementing a page wide "edit mode" thats enforces this dichotomy perhaps a more content item specific hover effect similar to the way "Views2" embeds administrative function links above displayed views could be adopted. This would unclutter the base interface while providing context sensitive actions that the present user has privileges to perform. For the example above "User A" might be able to rate a movie or a business by clicking on the widget, and "Administrative user B" might be able to clink on a link to the itemized result list.

Inline Editing

I LOVE inline editing. It appeals to every inclination of every person ive ever watched use drupal. Editing content where it lives is a great and noble idea. Unfortunately a lot of the power of drupal also lies in a developers ability to hook into various stages of the contents rendering and modify it before it is output for display. Teasers and computed fields are wonderful examples of "content you cant edit" because it isn't content but is the aggregate of user input from multiple places mixed with the context of display. This makes it VERY difficult to "edit this content" in any meaningful way.

I could imagine using multiple callbacks to discover how the field is computed and provide the necessary forms and items for the user to manipulate the field but this might significantly hamper possibilities with out current infrastructure that are key to drupals value proposition (it would also greatly complicate the modules that had to implement them). We could disable such fields but then we introduce inconsistencies in the UI that mean less predictable interfaces for relatively little gain on the simple fields that do allow it. There are much better people to approach about the complexities and possibilities of edit in place as it isnt a new desire by any stretch of the imagination but i think it si a complicated one that might be better (or at least more easily) served by simply providing more contextual "edit actions" on content as it is displayed throughout the site.

Apr 02 2009
Apr 02

There has been a lot of excitement the last few weeks since I gave my presentation at Drupalcon in Washington DC. Where I spoke about how the usability team of Drupal has been working on changing the workflow in issues queue, allowing user experience people to review interface changes to Drupal and how the larger design process conflicts with our current process.

One of the things I noticed during my review of this presentation, that the title doesn't really reflect it contents. So in the upcoming week I will spend time, on writing about my thoughts about Drupal's future releases.

We are having a lot of conversations with Mark Boulton and Leisa Reichelt, who are working on Drupal 7's user experience . As the weeks progress, we need to make sure that we don't just work hard on getting involved with all of their work but also fix all of the low-hanging fruit (issues) that has been found at the usability test in Baltimore.


Mar 15 2009
Mar 15

I worked with some kind folks in the UX team to promote the delete button on the node edit form to a local menu task (aka tab) like edit, view, track and revisions are. The general consensus is that this is a good thing but Dries would like to unify the interaction model across core if we push it through. I couldnt agree more.

I plan to submit an issue for each affected module and work through the efforts that way to keep the patches small and reviewable.

The reasons behind removing the delete from the edit form are numerated in the isssue mentioned above: Move delete node button on edit form to a local menu task


LMT = local menu task (aka menu tab tab)
DLMT = Default LMT


The changes listed below focus on letting you modify (edit and delete) the items "in place" instead of relying on an all of the administrative interfaces (which are still provided and more UX friendly) for those interactions. The LMTs automatically determine if you have permissions via user_access(). The changes will also be focused on letting you take an action with fewer clicks (e.g. click delete from the forum itself, or the administrative menu (admin/build/forum) instead of requiring you to navigate to the admin section then edit then delete.)  I will be tackling 4 main interaction modalities:

  • Provide a link to "Add item" at the bottom of lists of items (e.g. admin/user/roles)
  • Provide a Local Menu Task (aka Tab) to edit and delete items where they live (e.g. node/#/@action)
  • Provide a link to edit and delete item in the administrative list tables (e.g. admin/user/roles)
  • Remove the ability to delete items from the edit form (e.g. node/@nid/edit)


Existing delete items on edit form and suggest resolutions:

  • Node
    • Remove "delete content type" button from edit menu form. (admin/build/node-type/@type)
  • User
    • Add "Delete" LMT to user page (user/@uid)
    • Add "delete" link to user overview table (admin/user/user)
    • Add "Add user"  link to the bottom of the list.
  • Forum & Forum Container
    • Add an edit and delete LMT to the forum container view page (forum/#) with a DLMT for "view" provided as well.
    • Add "delete" link to the overview page (admin/build/forum).
    • Remove delete button from forum edit page.
  • Menu
    • Add overview table on menu over view page (admin/build/menu). Issue
    • Add edit/delete items to new table on menu overview page (admin/build/menu).
    • Add delete LMT to menu page (admin/build/menu-customize/[email protected])
    • Remove delete button and form processing logic from menu edit (admin/build/menu-customize/[email protected]/edit)
    • Remove delete button and form processing logic from menu item edit (admin/build/menu/item/@menu_id/edit)
    • A few changes to the Add item will be desired on menu page (admin/build/menu-customize/[email protected]) UX guys refer putting Add item functionality at the bottom of lists as wella s in a LMT im begining to agree.
  • Aggregator
    • Add "Add feed/category" to the bottom of the feed and category overview tables. (admin/content/aggregator)
    • Add "delete" link for each feed in the feed and category overview tables (admin/content/aggregator)
    • Remove "delete button" and form processing logic from feed and category edit forms (admin/content/aggregator/edit/feed/@cat_id)
    • Rename "Operations" header "Feed Operations" and add "Item Operations" header (admin/content/aggregator)
    • Rename Update Items to "Refresh Items" (Trying to distinguish better from "editing the feed") (admin/content/aggregator)
    • Add "delete" link to the feed operations header on the category overview table (admin/content/aggregator)
    • Rename "configure" LMT to "edit" and add "delete" LMT on category page (aggregator/categories/@cat_id)
  • Taxonomy
    • Add "Add Vocabulary" to the bottom of the vocabulary list (admin/content/taxonomy)
    • Create a user facing page to view a vocabulary (name, description, term list with link to content assigned to term, Add term link at bottom of table) (suggested menu path: taxonomy/vocabulary/@vid)
    • Remove "list terms" and link "vocabulary name" field in overview table to the new page created above.
    • Provide View (DMLT), Edit, delete LMTs for user facing vocabulary page above.
  • Filter
    • Rename the "configure" link in overview table to "edit" (because it links to an edit LMT which also has a configure LMT :). (admin/settings/filter)
  • Add "Add text format" to the bottom of the overview table (admin/settings/filter)
  • Profile
    • Compliant for both "edit on delete form" and "add items on bottom of lists"
  • Roles
    • Existing patch by me: XXX
  • Block, Contact, Path, Locale
    • Compliant with regards to "edit on delete form"
    • Need to add "Add item" on end of item list.
Feb 24 2009
Feb 24

Image handling in Drupal is a hot topic. Most users agree that there should be a solution in core but there are so many different cases that it’s unlikely that one general solution is going to cut it. I’m not here to debate one way or another because I’ve built sites using Imagefield + Imagecache and others using just IMCE and TinyMCE, but one module that I haven’t explored for a very long time is the Image module.

When I started using Drupal in version 4.6, the Image module was pretty much the only solution. Since I couldn’t get it to work the way I wanted back then, I’ve pretty much avoided it since. When I decided to try it out again this week (because IMCE doesn’t yet work with the Wysiwyg API) I was pleasantly surprised. It integrates nicely with TinyMCE and works very well with Image Resize Filter. It also makes sense to store images as nodes when they’re added to the body text, especially for non-technical users (even when I thought it was a bad idea in the past).

I don’t want to fuel any debates about which image solution is the best, but if you haven’t checked out the Image module in a while it’s probably worth your time. Drupal has come a long way and modules that you might have sworn never to use again back then may have also changed a lot as well.

Jan 08 2009
Jan 08

The logo of a Web site is not only important for branding but also as a navigational element, that many users expect to link to the home page. According to usability guru Jakob Nielsen the first of Ten Good Deeds in Web Design you can do is link your logo to the home page except you are on the home page.

Mr. Nielsen conducted many usability studies and has written groundbreaking articles and books on Web usability. Good reason for me to trust him when it comes to this topic, especially when it sounds completely plausible.

Why Linking with JavaScript?

There are many parallels between creating a usable and creating a search engine friendly Web site, but often enough you need to take subtleties into account. According to Rand Fishkin — let me call him the Jakob Nielsen of SEO — only the first anchor text counts for Google and he is not the only SEO expert who observed this.

On Linux-Netbook.com, a Drupal site I created a few months ago, the site logo did not link to the home page in favor of the site name, which appears later in the HTML source. I have no evidence and not tested whether anchor text is more important than ALT text, but that was my reasoning.

To fix this usability crime without sacrificing my SEO efforts, I added the following 5 lines of jQuery code to the theme's script.js file:

  if (document.location.pathname != Drupal.settings.basePath) {
    jQuery('#logo').wrap('<a href="http://www.seo-expert-blog.com/blog/linking-the-logo-to-the-home-page-with-javascript/' + Drupal.settings.basePath + '"></a>');

This code links the image with the ID logo to the home page unless we are on the home page, provided the user agent interprets JavaScript.

I assume that Google's engineers are smart enough to make Googlebot understand this JavaScript snippet, but I guess it does not play a role in the which link comes first game. In case it does, the ALT text contains the site name as well.

Aug 16 2008
Aug 16

Yep, I am coming to Drupalcon: its great to have a convention so close to home (at least it's the same East Europe). But before I'd like to have a little pre-conf rant, sort of an introduction of my thinking. I'd like to collect together some fundamental problems in Drupal user interface. Being out of active contribution phase but closely following the development from the shadows here are my observations.

But before getting to issues, first some meta-level talk.

We all know Drupal has changed from humble “nicely designed CMS” to hyper-powerful CMF and pains and complexities of UI decisions have grown exponentially. Being so open-ended, so plug-and-play, so drupal-is-whatever-you-want-it-to-be is in direct contrast of process of creating simple, user-friendly UI what removes say unnecessary config screens and makes some decisions for the user. Thing is: The key for Drupal end-user experience is often not what we do in core UI but the administrator what uses his super-Drupal-toolbox to shape the UX. He can either make it really nice, removing UI baggage, picking best possible UI components and themes (just look what Michael Angeles is doing over http://konigi.com/) or completely overload the site with ridiculous add-ons and non-functioning themes.

So what we should do?

As we giving the site builders the best possible code components and APIs we also need to give them the best possible UI components and enforce and share the best practices. We need “Drupal UI Police” what provides law and order in this rebel countryside. We need a good Drupal Human Interface Guide so developers and site admins can follow this and Drupal shops can base their own HIGs on Drupal HIG.

Now, on to the problems.

UI design process

The nature of Drupal development is shaped by several factors, such as being a OSS project and being heavily driven by talented coders. This is reflected both in human relations (decision processes) and available project managing tools. User experience-centered design has yet to find its place to this process. We do not have many things:

  • No lead UI designer or “core design team”
  • No “UI core committer”
  • No roadmap or vision for UI
  • No “visual sandbox” where UI designers can play around with UI prototypes (either views + panels – based, html mocks or static images) what we could crowd-source the usability testing
  • No proper UI / usability metadata for issue filtering. See http://drupal.org/node/282138
  • No proper usability testing process (different big academic initiatives on this have been great but what we often need are lot of quick crowd-sourced cheap tests in small scale).
  • How we could get some eye tracking coolness in? :)


We have lost (or semi-lost) several very talented Drupal UI contributors / consultants: Chris Messina, Michael Angeles, Steven Wittens, Peter Van Dijck (am I correct?). How to engage them, how to bribe them to come back?

UI challenges

Ok, now the UI challenges in no particular order nor grouped around common topics. I just had to let it all out, quick. I do not touch the issues what are listed on http://groups.drupal.org/szeged-uxsprint – these gonna be interesting sessions and hopefully filled with great solutions.

Lists UI

We need proper:

  • Selecting: standardized UI for selecting “all in page”, “all in page + subpages”, “none”, "
    " (think Gmail)
  • Actions on selected list elements: the current dropdown in inefficient: it does not give enough hints what are the outcomes of certain action, is there a confirm screen before real action, is the action reversible / undoable. Also, several actions need additional settings / tinkering / confirming what ideally would happen next to the action dropdown (example: associate with term → add new term).

  • Filter: current filter is hard to understand mess: replace with standard “smart folder / e-mail rules”-style filter

There already some word done with views plugin though.

Inconsistent “add new item” entrypoints and forms

In core we use a link on top of listings (“add new blog entry”, …), “add” tab, embedded add form in top of the listing or below the listing and in some contrib modules even popups.

This needs standardization and consistency.

Admin Space vs User Space

Ah, the lovely discussion, going back how-many-years. So far the alternative models for user/admin space have been “Joomla/Wordpress/MT” style clearly separated admin pages vs Drupal all-meshed-together approach.

Perhaps we should look it with a fresher perspective, there are already several developments what use smarter UI to both distinctively separate user / admin space _but_ still provide preview of live site for instant feedback of changes:

Edicy (screenshots and the blog post where from it all started)

Similar ideas can be also seen in Drupal client localization UI and theme helper palette.


There are clear steer in community to get it right, Gabor battle plan and some healthy discussion going on. My ideas on this are:

  • think in larger context: palettes, inline elements draggable inside content – this all needs not just pluggable wysiwyg API but more flexible / interwingled APIs (in the lines of sun's inline api)
  • provide best possible user experience for all “classic” editor options:

-- plaintext editor in core – markup editor in core or in contrib – wysiwym editor in core if drupal-specific and superlight: (think bloated SimpleTest → lean DrupalTest). Hide all unnecessary tools (or even better: work inside-out, start adding tools conservatively)

Using horizontal space

Drupal is very vertical e.g. we are not using much horizontal space what widescreen monitors and improved resolutions give us (compare the situation of early days Drupal).

There has been some UIs though what have been exploring using vertical space more effectively:

  • views 2.0 UI
  • panels 2.0 UI
  • fieldsets in node edit forms (dropped because on theming complexity and introduction collapsible fieldsets) http://drupal.org/….preview.png
  • 2-column layout of /admin

Views + Panels + CCK UI

These “developer eliminator” modules really provide a huge advantage for Drupal to break to the mainstream and differentiate from any other cms/cmf because the flexibility of these tools is just unmatched. And all can be done without coding!

In the same time the intuitiveness of UI of these modules really crumbles under the weight of flexibility (read: complexity). Views 2.0 has made some good progress, providing a glimpse of nextgen interfaces but there is still a long way to go. CCK builds on core content type UI and does not contain _that_ much of complex interactions but there are still loads of UI problems (some of them are noted below). Panels seems to be in worst shape: many elements and configurations screen are just way too cryptic and require a lot of background knowledge and endless screencast-watching.

Also note that these mission-critical modules are using non-core UI widgets and concept, everybody having their own visual language. It is good in terms of development and exploration (somebody had to do the advanced help, vertical tabs, live previews, drag-and-drop blocks etc) but in a final product this diversity kills consistency, lessons learned in one module do not help in other and user experience is hurt.

Cascading settings UI

We have a problem handling UI cascading, global-vs-local settings. It's a super-powerful concept in theory It's hard to understand for the user how toggling the setting in global space affects the local setting etc. Also, every such a case handles the UI a little bit different:

  • Views: global vs local overrides between subviews
  • CCK (global and field instance settings)
  • Theme settings: global vs theme-specific


Notifications API and UI are very inflexible and are riddled with problems

  • no icons (see the “No icon API”)
  • no notification aggregation, grouping
  • not scalable for big number of notifications or notifications with long content
  • placement is static: no way to do “Yellow Fade Technique”-type inline indications or inline, spacial context related notifications
  • perhaps not always optimal placement (see Googles “yellow bar”, it “jumps” dependent on the context)
  • permanent messages (“you are in offline mode”, admin/reports/status") vs temporary messages

Aging look of UI widgets and no icon API

Time flies fast and once-cool progress bar and ok/notification/error look aged and buggy There are some cool work done such as icon API and icon API guidelines – have not looked into it with that much detail but gut reactions say theme(‘icon’,‘error’); and icon filename standardization (and possibly name cascading in spirit of tpl.php cascading) is good and necessary – but the term “icon packs” give me shivers. Possibly there has been just too many horrible icons packs out there? Anyhow, some icons work well with some themes and some not and sometimes it is not really up for admin skills to specify it. Perhaps we need a ‘icon pack compatibility’ field on theme .info file? ;)

Broken Flows

Installer: not really broken but can really smoothened out: kill unnecessary steps (merge 1st and second screen of installer, merge 1st and 2nd screen of update, merge last screen of the installer and first welcome screen); simplify site settings form; clean up password strength UI etc

Adding new module: discussed to death but not much done in terms of indicating next steps after enabling the module. Literally we need to convert INSTALL.txt to the task-centric UI. Possibly has a strong dependency on nextgen notifications UI.

There are other critical flows and some of them – Where did my content go and 1st screen – will be discussed in Szeged BoF, that's cool.

No standardized UI and behavior for js popups

We use browser-frame popups, inline elements (password strength), expanding panels (form field groups) or we just taking user to another page, ruthlessly breaking the flow (extended filter hints)

We need standard UI pattern for these elements. This can be used for nextgen help, filter tips, inline term adding, all kind of palettes (panels).

No nextgen help

Discussed and projects underway, GHOP and Views 2.0-wise. My quick thoughts: help should allow inline, spatially contextual hints (see notifications UI and popups above), standardized “read more” behavior and look; clear distinction between local and drupal.org help pages.


Ah, poor tabs.

AFAIR tabs were introduced when more rigid page structure $title . $tabs . $content was needed and we did not wanted to mash everything to the $content blob.

Originally tabs were meant for “local tasks”: actions you do in local page context, under the same header. This is echoed in Menu API (MENU_LOCAL_TASK) and in many core pages where original guideline "tab titles have to be active verbs such as "view, edit, configure"" still exists. During tab introduction there was lot of talk that we need introduce tab UI guidelines and tout them to module developers as best practice. But pretty soon such a constraint proves inflexible and module devs AND core devs started to mangle and misuse tabs / local tasks in every possible way.

Tab's Problems:

  • people do not see tabs
  • some tasks are are more important than others: it's ok to hide complex, never-touched configuration form under a tab but poor “add” needs way more spotlight.
  • very OO-mapped, “object_id/action” (echoed in URL) based on system architecture (system mental model), not user mental model. Especially bad is search results approach to tabs: instead showing all results (grouped by type) in one screen as user expects coming from any web search around, search module “sticks to Drupal standards” and pushing the results to different tabs, completely ignoring the original tabs-as-verbs concept.
  • hard to use outside the originally designed context, such as $tabs . $title . $content
  • no support for js-enabled tabs such as jQuery tabs.
  • horizontal tabs have known scalability problems
  • LOCAL_TASK and it's rendering are too tightly coupled. We need to decouple them. Tabs rendering component should allow re-usage for different contexts (primary / secondary links, other global tabs, tabs in blocks – there are some initiatives around Views plugins on this)
  • LOCAL_TASKs could be rendered in a different way when needed, such as Basecamp or UI where tasks are on right column? Or should some tasks brought over to initial screen as inline/expandable element instead invisible tabs?

Pushing the limits of HTML form elements

Known issue, discussion is bubbling and hierarchical select module has been around for some time We need action!

Some broken, never-usability-tested UI widgets made it to interface

  • “Split summary at cursor”. No comments.
  • Password strength meter. Not totally broken, after redesign can even prove to be usable


It's great addition to Drupal UI but has several problems still:

  • Saving: the asterisk * next to a moved item and invisible footer message (again a non-standard one) just do not communicate the need to save page in order to store changes.
  • It works well only when dragging list items vertical dimension: in block configuration page users just do not get the limitation why they cannot move items around to to real block containers, especially when dragging affordance (4-way arrow) tells them so.

Now what?

While this all seems all-talk-and-no-constructive action, I am really trying to get time to get back to Drupal this autumn and help out in every way I can. See you in Drupalcon!

Mar 19 2008
Mar 19

Here's a small one-line usability fix for all module developers that I think will be a huge help to users.

In the early stages of a project, I'm often playing around with quite a few new modules: testing them, seeing if they meet my requirements, installing and uninstalling. After downloading a module, the sequence of steps is always the same:

  1. copy to /sites/all/modules
  2. enable at /admin/build/modules
  3. configure all exposed settings
  4. use!

However, sometimes just finding the settings page takes the longest time out of all those steps. Is it in User Management? Content Management? Logs? Who knows!

I'm going to use the example of the Bio module; not picking on the Lullabot team or Bio module maintainers, this one just happened to be the first example I thought of. :)

Bio's settings page is difficult to find, as it's not in "Site configuration" but rather in "User management". It also hides itself quite nicely using the title "User biographies" instead of "Bio settings", as one would expect. The readme.txt file doesn't mention how to find the settings page at all.

So what I had to do in this case, after becoming frustrated with searching for the settings in the menu, was pull up the source code and check out hook_menu() to see exactly where I should go.

And here's my suggestion: we're all used to seeing the "installation successful" messages (and looking out for php errors on install of course). For example, the Bio module has these:


What if this message held the link for the settings page? Then it's just one click away, instead of a potential 2 minute search to find it.


This is just one line of code in the bio_install() function:

drupal_set_message(t('You can edit Bio settings at ') . l('admin/user/bio','admin/user/bio'));

Seems like a small change, but if every module did this, it would collectively save me hours in the module evaluation stages of a project, because I find that plenty of modules seem to hide their settings and not explicitly detail them in readme.txt, requiring me to either hunt them down or open the source.

Since I talked about the Bio module, I've provided a patch in the issue queue. Hate to be a complainer that does nothing about it... :)

Mar 01 2008
Mar 01

I arrived in Boston yesterday afternoon, absolutely exhausted after Usability testing at UMN -- which was amazing. See the report at 9am on Monday to hear why. It was snowing heavily here this morning. Today I need to prepare for my presentation on Scalable Theming and my parts of the Usability presentation, and try open another US bank account.

Here's my photoblog to date:

A few NEW cultural oddities I've noticed in the US since my last visit 5 years ago:

  • Airport pager: "The security threat level... is orange" -- talk about
    fear-mongering. No need for foreign terrorism in the US -- the local authorities are terrorizing plenty enough here!
  • Control-culture doesn't seem to be so severe this trip but is still grating. I think that's more to do with the people and places I'm mingling with though.
  • You can't seem to fill up a bottle with water anywhere. They seem to be getting the idea of 'being green' with recycle bins and signs to conserve hand-drying paper in the toilets and not leave the tap dripping, yet it's difficult NOT to go through several styrofoam, paper or plastic cups, bottles, plates and fast-food trays per day. I wonder how effective the recycling actually is here? Given the amount of extremely cheap "recyclable" materials consumed, and the fact that these materials usually aren't economically worth recycling, I suspect very little of it is actually recycled. Even where recycle bins are present. Meaning all the recycle bins do is make you feel less guilty about being a polluting consumer.
    • Most annoyingly of all for me, I can't fill up a bottle with tap water anywhere except a public bathroom, which 'feels' unhygenic, although probably isn't.
Feb 27 2008
Feb 27

Currently there are three options for creating error pages in the Drupal system, that I know of. I’m going to show here which I think is the best, for reasons of usability, performance and general webmaster sanity. At the foot of this article, there’s some free code too!

The options:

Drupal’s build in error page support

Drupal provides, out of the box, two fields in the Error Reporting configuration screen. These fields can be set to any internal Drupal path. Usually, they will be set to point the user to a page created specifically for the purpose.

The downside to this is that these will now be nodes in the system, and as such they will show up in popular content lists, site searches and the like. This is clearly not desirable.

Update: I have been made aware of an outstanding issue in Drupal core with error pages. This issue means that a user without “access content” permissions cannot access 403 error pages that are created as nodes. This is true in Drupal 5.x and even 6.1, and is another weak point for this mechanism.

Search404 module

Until very recently I was using search404 but I became less than pleased with the results. To start with, I thought I was aiding usability, but as it transpires… not really. The real killer for me is that search404 often gives me empty search result sets, because the path elements just don’t relate specifically enough to the content.

For instance, the node “/blog/my-drupal-article” will almost certainly contain all the words “my drupal article”, but may not contain the word “blog”, except in the path. This means the search doesn’t catch that article, so you get no results. Given that every 404 page the module generates incurs a DB query automatically, this query is effectively just trash, but cannot be disabled.

Customerror module

Customerror module skirts round the issues of having nodes as error pages. The module makes error handling pages available as custom paths inside Drupal. These aren’t nodes, so we have no issues there.

The configuration screen offers up two textarea fields which will contain the page content to be rendered on each of the 403 and 404 page errors. The key to making this more special than just a plain text or html page is the availability of PHP processing for these fields whilst not requiring nodes for the task.

Ok, so what I’m doing here is recommending customerror as the best choice for this task. That said, let’s throw down some code and make this more useful.

To start, visit the standard Drupal error reporting page at “/admin/settings/error-reporting”. Here, set the default error page fields to “customerror/403” and “customerror/404” respectively, if you’re going to override both these pages.

Now, on the Custom Error module’s config page at “/admin/settings/customerror”, enable both checkboxes that say “Allow PHP code to be executed for 40x”. Now let’s look at handling the 404 error. I’ve added the following code for this site, in the “Description for 404” textarea, and a suitably snappy title in the other field: “404 Not Found Error: No content found at the requested URL”.

<p>Sorry, no content was found at the requested path - it's possible that you've requested this page in error.</p>

<p>Use the search form below, or go to the <a href="http://www.kinetasystems.com/">home page.</a></p>

// check that the search module exists and the user has permission to hit the form
if (module_exists('search') && user_access('search content')) {
// cool! - customerror doesn't trash the page request and the full path is available
$path = $_REQUEST['destination'];
// bin anything that's not alphanumeric and replace with spaces
$keys = strtolower(preg_replace('/[^a-zA-Z0-9-]+/', ' ', $path));

  // retrieve the search form using the data we've pull from the request
  // note that we can override the label for the search terms field here too
print drupal_get_form('search_form', NULL, $keys, 'node', 'Search terms');

In the 403 error fields, we adopt a similar technique. I’ve used “403 Forbidden Error: Access to this page is denied” for the title. Here we display different content depending on whether or not the user is logged in. If you’re running a site with lots of members, you can uncomment the user login line towards the bottom and the login form will be rendered on the 403 page!

<?php global $user; ?>
<?php if ($user->uid): ?> 
  <p>Sorry <?php print $user->name; ?>, you don't have permission to view the page you've just tried to access.</p>
  <p>If you feel that you have received this message in error, please
    <a href="http://www.kinetasystems.com/blog/creating-custom-error-pages-in-drupal/contact">contact us</a> with specific details so that we may review your access to this web site.</p>
<?php else: ?>
  <p>This page may be available to clients and registered users only. Please select from one of the other options available to you below.</p>
    <li><a href="http://www.kinetasystems.com/user/login?<?php print drupal_get_destination(); ?>">Login</a> to view this page</li>
    <li>Use the <a href="http://www.kinetasystems.com/blog/creating-custom-error-pages-in-drupal/search">search</a> facility</li>
    <li>Go to the <a href="http://www.kinetasystems.com/">home page</a></li>
    <li>Go to the <a href="http://www.kinetasystems.com/blog/creating-custom-error-pages-in-drupal/sitemap">site map</a></li>
<?php //print drupal_get_form('user_login'); ?>
<?php endif; ?>

Now we’ve got friendly, usable error pages that are helpful and don’t scare off visitors!

Updated 24th April 2008

Feb 19 2008
Feb 19

The Drupal community is very active and always looking for new ways to improve the system. In D6 the user is an important player: i18n, the new drag&drop capability, better performace.

With the support of companies like Sun, Drupal has a very bright future.



Posted by theBorg on February 20, 2008 at 04:23 AM PST #

Jul 12 2006
Jul 12

In part 2 of their "Using open source software to design, develop, and deploy a collaborative Web site," IBM developerWorks has posted a great tutorial on analysis and design of putting together a website. I will probably use this in my writing for the web class in the fall.

Oct 06 2005
Oct 06

The annual report from usability expert Jakob Nielsen:

  1. Legibility Problems
  2. Non-Standard Links
  3. Flash
  4. Content That's Not Written for the Web
  5. Bad Search
  6. Browser Incompatibility
  7. Cumbersome Forms
  8. No Contact Information or Other Company Info
  9. Frozen Layouts with Fixed Page Widths
  10. Inadequate Photo Enlargement

I agree with all of them, especially number 3 (Flash). I'm starting to like most of the AJAX sites popping up around me, but I have yet to find a Flash site which I really like.

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web