I was discussing with a recent client about the next stages of their project. We’d more or less gotten the functionality he requested right but something was still missing.

He wrote, “The site basically does what I want, but I feel like something is not quite right.”

“What do you mean?” I asked.

“It’s not obvious how to use it,” he said and then hesitated. You could almost feel something in his head about whether he just didn’t understand or there was really a problem. He continued, “I like the videos you made showing how it works but I can’t really expect people to read a ton of documenation just to do basic things.”

This could have easily been a moment where I fight back and say, “It makes sense to me. Maybe we should add a bit more help text.” Instead though, I just asked him to explain as best he could his expectations.

While I often work and focus on the database and functional side of a project’s development, in the end my goal is to hand over the site to the admin users and let them handle all the day-to-day activity. It’s great to check on old sites I built and see the site owners still adding new stuff. Unfortunately, what sometimes seems obvious to me as an engineer is not so obvious to end users. The user experience in the final sites sometimes end up missing something. If the site owner doesn’t get it, then likely no one else on the management team will either.

Over the next several emails, chats and voice calls, we slowly pieced together some of what he was expecting and what was obviously missing in the current site. It was a back and forth. We eventually got down to the essentially of what were needed in the short-term and the more difficult changes were left for later, if needed.

These conversations (like other more professional tests and development going on in the drupal community) essentially aim at solving the next great challenge for Drupal CMS: building sites that do what users expect and act in a way that meets their needs quickly and painless. This expectation of easy usability has become an increasingly repeated aspect of all my projects and is a general trend in the web space at large.

Even though some claim to have “solved it” or “mastered it,” the only honest answer is that we are gropping with usablility. Usability is hard. Since frankly getting user experience perfect is next to impossible, we need to aim at continuously stiving to improve the obviousness of our sites, apps and software. Fortunately, this in my opinion is the next great revolution-in-progress with Drupal.

Prototype to Functionally Complete: What’s Next after you got the site working in X way?

Like a lot of early prototyping projects, I was able to use Drupal and some killer contrib to get a solid, functional and data-clean site up quickly. I was able to use core and contrib to take much of the early work out of SQL and coding and instead focus on building nodes and data types that we were able to quickly adapt and modify with the client’s vision. This is the “site builders” revoloution that Drupal 6 and 7 with CCK and Fields-in-Core helped bring about.

It’s a pretty trivial task to add various fields to any and everything. It’s also made it incredibly cheap in terms of time and money to build content types with fields and content displays with views. This has allowed me as a site builder/developer and Drupal as a collective, community project to engage in new challenges, specifically it’s time for us to think more about how people use and interact with the site and how we can make this better, more easily used and understood.

This is not a new moment for Drupal and the web as a whole, but it’s becoming a bigger and more vocal conversation in Drupal. Jeff Eaton’s Key Note in Toronto points exactly to the next stage of Drupal and to questions my client was asking: how do we make our sites and user experiences better?

When I look at the next stage of the Drupal 7 and Drupal 8, I’m starting to see another revolution in the works: focused improvements to user experience and user interfaces. Obviously it would be wrong to ignore all the other amazing work going into Drupal 8 but for now I’d like to talk in this post about this specific transition of improving how users build and manage their sites.

Revolution Drupal 6 and 7: Fields on Everything and Views for Content (SQL) Displays

Drupal 7 along with modules like Profile2, Entity API, Views and Rules take much of the early work out of coding and into building nodes and data types. This is the major transition that Drupal 6 and 7 with CCK and Fields-in-Core and with Views helped bring about: From a web-based UI, you can add various fields to everything and then use views to create an endless collection of how that content with fields gets displayed.

In my classes on teaching Drupal in China, this was pretty much all we focused on: How to add fields and different types of fields to content? and How to use Views and Views Contrib modules to display that content in interesting and unique ways? These are a truly empowering suite of modules that make building a custom site relatively easy. And by the end of a few weeks, I’m always amazed with how enthusastic the students become about building information sites using Drupal.

It’s difficult to put an accurate label on this CCK/Fields-in-Core work but combined with Views in contrib and now Views-in-Core with Drupal 8, these modules amount to the maturity of the “Site Content Builders Revolution”. Site builders can build and display their content through the web interface and don’t even need to know how to code to do it.

Drupal’s Installation Woes: Onboarding and What is this Drupal thing for? How do I use it?

Beyond just front-end appearances, Drupal 7 and 8 have seen focus on fixing how users use their initial sites. It comes up down to one of those aching moments when I first present Drupal to students. You’ve shown how to setup php and sql, how to use mySQL to create a databate and you’ve installed Standard, Vanilla Drupal 7 with the installer. Finally the installed site appears with a link for “add content.” And my students look at me with an extression of “What the heck is this thing for? What am I supposed to do next? This sucks.”

As I’ve said elsewhere, this blank page or open canvas post-installation is one of the more obvious aspects of Drupal’s philosphy: Don’t assume anything but your need to change.. Drupal doesn’t expect you want a blog or anything. The stanard install just offers you the chance to create what you need as you need it. There are various Drupal installations or distributions that improve this installation process by offering some kind of final site or solution. Basically it comes installed with something you can start using, instead of the general Drupal assumption that you need to starting building your site post-installation.

This first installation problem is pretty well-known in Drupal and there are various work at foot on how to improvement. The problem could described in a number of ways, but probably the clearest is to call it onboarding, which describes the problem new users or new employees have when they need to learn stuff before they can actually contribute or work with an existing system.

I’m not sure what we will have in the end with Drupal 8 post-installation. I’m guessing we’ll continue to see more distributions providing a clearer end-user solution. At the same time, the next step or revolution I see in the works is improving User Intefaces (UI) and User Experience (UX) so that new Drupal site builders can more quickly start building.

Drupal 7 and 8’s Revolution-In-Progress: Improving User Interfaces and User Experience

For various reasons, Drupal has been the preferred CMS by hardcore php developers. Drupal remains a developer-focused codebase. But it’s web-based CMS is also intended to build used by site builders, not just programmers.

Adding fields and views is helping to complete the core of the Drupal Site Builder’s Toolkit. These modules are the tools that will remain without a doubt with Drupal into the future. We all need to add different kinds of content with fields and we need to display that content in various ways. Learning these modules and skills can make you a very effective site builder, but unfortately learning these skills isn’t super easy or obvious.

The challenge with Drupal for site builders is that Drupal is a complicated system used to build complicated sites. It’s flexible and provides various ways to do things. From a developer’s perspective, we can’t make the system itself simpler or less flexible just because we want it to be easier to use and understand. So the challenge is to help make a complexe and flexible like Drupal easier to understand and use the first time.

Projects like Spark and Commerce Kickstart show that improving user experience and interface are valuable tasks in-and-of-themselves, beyond just the coding processes. These systems use Drupal’s underlying system and, in turn, attempt to make their final use-cases easier to use from the beginning and throughout the life cycle of the site.

This is a tough challenge. I don’t expect any quick solutions. Like the revolutions with CCK/Fields and Views, these tasks take a committed group of people to make them happen. Drupal’s front-end improvements have occurred by bringing more designers and front-end experts to Drupal. I see the next improvements will occur through recruiting and engaging in usability and user interfaces. These professionals will help considerably, but in the end, I think it comes to down listening and optimizing, questioning and responding to your users.

Usability Improvements Come Down to Giving Users an Experience They Expect

Like the conversation I evoked in the introduction, the key is to ask what your site users expect and then tweak things to create a situation where a site flows and functions in a way that just makes sense. We shouldn’t expect people to be trained to use Drupal or whatever functional site you are offering. We should be offering an experience that is as painless to use as possible.

While “usability” often gets convoluted with looking pretty, I don’t think the usability revolution in Drupal and in the latter stages of certain client projects is really just about the looks. Sure, there are small bits of text and edges that we can clean up or smooth out the look but the key is to optimize the flow and get the steps to go where you want and expect.

We shouldn’t need to train people to use our system, we should try to create things to work in a way that makes sense and puts users in contact with their most common and useful tasks. Getting people on the pages they need and acting in the ways they are supposed is not just a question of looks and fixing the edges is about engaging in back-and-forth conversation to create a situation where the site works without the work.

Usability is and will be the next great Drupal leap forward in the CMS space.

Post-Script Video: Baby Got Backend

Most of this post was already written when I came across this video on ways to improve usability. It’s great and I highly recommend you watch it and follow some of these tips.

Keynote: Jeff Eaton from DrupalCamp Toronto on Vimeo.

Tags: Drupal PlanetPlanet DrupalUIUXusabilitydrupaluser experienceuser interfacerevolutionprogressdrupal 7drupal 8

Mark Koester
@markwkoester
Mark has worked on Drupal since the early days of D6. He is passionate about open source as well as entrepreneurship. When he isn't building, he enjoys traveling and speaking one of his many foreign languages.
Chengdu, China

• var switchTo5x=true;stLight.options({publisher:'dr-8d62520e-c444-86e2-d911-ab27da97627b'});