May 10 2019
May 10

Things seen here are configured there.

An elaboration on underlying considerations that make simple suggestions as this one not so simple after all.

An important consideration when deciding whether to “add something to core” is that generally speaking, core doesn’t do one-offs. The underlying principle is not “make it do X” but “make it possible to make it do X (and X2, X3,…)

Linking from a create context to a configuration context

In this particular case we have a proposal to link to the screen where you can add new content types from the page that lists available content types to create content with. Or, in url speak: on /node/add, put a link to /admin/structure/types. Or once more: on the screen that lists existing content types that you can create content with, add a link to the screen that lets you define new content types.

Notice the distinction between “create content of type X” and “define a new type of content Y”. The first is a content creation task, the second is a content definition task (in Drupal jargon usually captured under “site building”). This distinction then should clarify why a link to define a new content type should not use the “blue + button” pattern on a screen that is in service of a content creation task.

Back to the “no one-offs” principle. Where and how can we add a link of this kind? To answer that question we should look for possible patterns. Is there a more generalised definition for the type of problem that this single link to elsewhere wants to solve?

The example is: put a link to the content type definition area on the screen that lists already available types to create content with. Restated more generally: link to that area of the Drupal admin where the things on this screen are configured.

Connecting the dots is important

You know those links at the bottom of product pages in an online store: “people who bought this item also bought X, Y and Z”. In our case it’s more like “Things seen here are configured there.

I noticed a sort of similar pattern in the Android OS settings pages, where the screen ends with suggestions of related topics to the ones already shown. It’s a way to provide meaningful next places to go if the current page didn’t offer what you were looking for (and is of course a symptom of how many settings there are in the first place).

“Things seen here are defined there.

If we can find more examples of where this would be meaningful and helpful then we might have a good case for introducing a new user interface pattern. See image for some initial examples.

Jun 10 2018
Jun 10

Laying the foundations for POSSE

This is my version of the steps you need to take to make your site part of the indie web community. Swentel helped me getting it all setup on this here Drupal site using his indieweb module. It’s all a bit complicated still, so this is mostly me trying to retroactively understand what’s going on.

As it says on the site, the IndieWeb is a people-focused alternative to the corporate web. Its main tenets:

  1. Ownership – your content is yours, it should not belong to a corporation.
  2. Connection – starting from your own site you can share your content to all other services.
  3. Control – post what you want, in the format you prefer, using your own URLs that you keep permanent.

While 1 and 3 are essential and relatively easy to achieve (use your own domain and post your content there), it’s number 2 that is the most alluring.

Owning your stuff and being able to share it across multiple platforms combines ownershop with reach. This is what “POSSE” is all about: Publish (on your) Own Site, Syndicate Elsewhere. Drupal lead Dries Buytaert has written several posts outlining his POSSE plan.

Getting started

This “Connection” part of indieweb publishing is also the most complicated. There are quite a few moving parts to getting it all up and running.

For Drupal sites, the setup for the community/sharing/syndication parts of indieweb publishing has gotten much more accessible with the release of the IndieWeb module created by swentel. It doesn’t necessarily reduce the number of things to set up, but it provides a centralized UI for all of them: Webmentions, Microformats, Feeds, Micropub, IndieAuth and Microsub.

Before going over the details of configuring the indieweb module itself, we have to take care of some basics first.

Introduce yourself (right on)

To own your content on the web, you have to establish that you are in fact, you. That’s why IndieWeb starts with having your own domain and posting some initial content there. Important part of this initial content is a specific bit of HTML that establishes you as the author and owner of things published on this particular domain:

<a class="h-card" href=""><img src="" alt="This is me" /> Roy Scholten</a>

The specific part here is that “h-card” class added to the anchor tag. This “h-card” is one of a collection of so-called microformats. With microformats you give more structure and semantics to information presented in HTML. In this case, h-card is the microformat to use for publishing information about people or organisations. We’ll need to add other microformats to (blog) posts you publish on the site, but that’s for later.

To do in Drupal

The indieweb module does not (yet?) handle adding this information to your site. Add your version of the HTML snippet above to a (new or existing) Drupal block. Place that block to be visible on your homepage. The site footer or maybe a sidebar are obvious places you can put it. Mine’s in the footer below.

You can check if all is fine with Enter your domain name there and it will report back with what it found and suggest additional elements you could add to enhance your h-card.

Even without posting any other content to your own site, you now have your own space on the indie web and setup your identity in a way that you own and control.

Next: add links to your existing social media accounts

You’ve seen those signup forms that let you create an account by using your existing Google, Facebook or Twitter account details. In this step, you configure your own domain to be your IndieAuth identity. This lets you use your own domain to sign in to other sites and services.

There are not many sites outside the indieweb circles itself that offer this, I think. It’s still useful to do this though. You’ll likely want to use some of these indieweb services, especially to automatically share (links to) your content on other platforms like Twitter or Facebook.

To do in Drupal

Detailed instructions are here. In short:

Add links to your other profiles and add the rel="me" attribute. Might as well add this to that h-card block you created in the first step. For example:

<a href-"" rel="me">@royscholten on Twitter</a>

If you have a Github account, that’s also a good one to add.

To do on the external sites you link to

Link back to your homepage from your profile page on these services. The indieweb wiki has direct links to edit your Twitter and Github profile.

Then, try logging in to to see if it all works.

So far, so good,

So what? By establishing your identity on your own domain you stake out your own spot on the internet that you control. With this set up, you have created an environment for publishing on your own site and syndicating elsewhere.

Next time: configuring the indieweb module to start sending and receiving webmentions, the indieweb catch-all term for comments, likes, reposts and the like.

May 02 2018
May 02

Defining aspirations and the building blocks and guidelins to achieve them.

Reviewed a list of design system sites today.

Not super strict, but mostly these are design systems that aim to support multiple apps, tools and services on multiple platforms.

I specifically looked at:

  1. The guiding design principles: which ones and why
  2. Top level sections for exploring the full system

Top level sections

Can be short on this: a quite consistent pattern of entries for "Getting started, Styleguide, Resources/downloads. What’s behind there varies a lot in depth and quality, mostly depending on the size of the organisation behind it. IBM goes very deep, Nachos understandably less so.

Design system principles

The most common pattern is to list a noun or short statement that expresses a characteristic of the type of designs the system wants to support. “Clarity”, “Empower but dont’t overwhelm”, “Universal”, “Engaging and immersive”, “Approachable”, etc. Material only lists 3 high-level ones but has more per section below. Nachos maybe goes a bit long with 10.

Not many of the systems listed mention content, text, words as an important part of a design. Shopify says: “Thoughtful, consistent interface content is a core element of a well-designed user experience.” IBM puts “Defer to content” as the first guiding principle for their visual design guidelines.

Even less mentions of designing for people. This may be inherent to what these sites do: describing the aspects of the system itself. Most of the times the human centered part is put under a usability or accessibility section further down the hierarchy.

One interesting outlier

IBM design language takes a different approach. Instead of listing the high level characteristics the systems aspires to, it defines 6 universal experiences:

  1. Discover, try and buy – Meet users where they are. Show, don’t tell. Create a seamless transition from “try” to “buy.”
  2. Get started – Invite users in and show them what they can do.
  3. Everday use – Users should get personal value every time they interact with your product.
  4. Manage and upgrade – Upkeep and receiving the newest improvements should be as elegant and predictable as using the product every day.
  5. Leverage and extend – Everything wants to be mashed up. Each part of your offering should be available as an API.
  6. Get support – Support users in the ways they want to get help. Expand their knowledge and encourage them to share.

These put user-centered design center stage, using a life cycle approach. It acknowledges that there are different stages in familiarity with the product and identifies different clusters of scenarios and tasks. Everyday use is something else than Manage and upgrade. Different frames or lenses for looking at the same product(s). This also implies that the same app, product, or even a single new feature has to worked on from all these perspectives.

Thinking about first time use (getting started), regular use (typical tasks), advanced use (extending, customizing) and managing/upgrading are all very relevant perspectives on how people work with Drupal. One example: “Getting started” currently gets special attention, see improving the Drupal evaluator experience.

Feb 22 2018
Feb 22

During this weeks UX meeting we explored what it would mean to redesign the core Field UI. It’s definately in need of an update.

Currently all mashed together in a couple of tabs on Field UI:

  • Data modelling – Define data types and storage formats for individual fields & their relationships
  • Content modelling – Compiling individual fields into appropriate content (entity) types and configuring the input form for creating content items
  • Display modelling – Configuring different ways to display these created content items

One of the first steps towards a new and improved user interface for Field UI would be to unbraid these different types of tasks. Take it apart and put it together again in more user friendly ways.

Would be nice to kick this off with some kind of (virtual) UX design sprint, no?

Feb 18 2018
Feb 18

My previous post inspired Joeri to some improvements on his site. Nice!

I built another step towards POSSE this weekend: tweet-sized notes posted as content on that get pushed to Twitter via RSS and Zapier. Here’s how:

Create a new content type “Note”. This one needs to only have a text area. And here we run into Drupal always requiring a title. We can’t create entities without giving it a title. The title itself is always a text field, so not ideal for writing 280 char bits of text. Two contrib modules to work around this:

  • Auto entity label to define an automatic pattern for the title of these Notes. I set it to use a simple timestamp.
  • Exclude node title to actually hide the title field on the Note creation form and on display.

Next I defined a new text format that does not use CKEditor but allows tags and automatically transforms URLs into links. I set this to be the default text format for the text area on the Note using the Better Formats module (sadly currently only available as an old development release). This step is optional, it helps remove user interface clutter. This gives me a content creation form with just a single plain text text area, a “published” checkbox and a Save button.

I updated the views that list blog content on this site to also include content of type “Note” and configured a Notes RSS feed as well. I use this feed as an input on Zapier where the Notes body is extracted and posted as a tweet.

Feb 14 2018
Feb 14

At Drupalcon Vienna there was a lot of interest and preparation work done around modernizing the Drupal administrative interface. I wrote up a high level summary here. As a result this initial issue was posted.

My previous post with a small concept for the editor UX triggered some interesting discussion on Twitter.

We also discussed this topic during yesterdays UX meeting.

As a result, ckrina now proposes an initial round of research to learn and get inspiration from other systems. Mind you, this is the woman that brought us the redesigned status report page and is a member of the team that made the Umami demo that’s now in core. Good things can come from this!

Your help in researching these topics is very welcome. Have a look.

Feb 07 2018
Feb 07

A smoother path to posting pictures from phone to site

An experiment triggered by Dries’s blog post To PESOS or to POSSE? and my comment there about the friction in the UI’s for the POSSE approach. The Drupal content creation UI is not as optimized as the ones in native, mobile apps for Twitter, Instagram and the like.

I was curious how far I could take things just by stripping down the default Drupal content creation UI, optimizing it for posting an image + caption as an entry to this here blog.

What I did:

  1. Create a custom, stripped down content creation form
  2. Use evil CSS to hide superfluous items

Custom form mode

The first step was to remove most of the fields that are not required to create a post. The Form Mode Manager module lets you do just that. I set up a “Minimal piece” form mode which hides the fields for inputs like a separate summary, tags, file attachments, url alias, author, date, sticky and the “promoted” checkbox. These are optional (not required) fields that can be left empty or provide sensible defaults (me as the author, use “now” for the publishing date).

This alternative form comes with its own URL I can go to to create that new post.

Phone screenshot 1: optional fields removed but still a long form

Evil CSS

The stripped down form still shows bits and pieces I don’t really need to be reminded of every time I go to post something. Nothing a few display: none; CSS staments couldn’t fix. But, I’m using the default Seven admin theme here, which does not provide a body class to uniquely identify a specific page. I couldn’t add my CSS hacks to that theme’s (or sub theme’s) stylesheet because those would then apply to all admin pages.

I use the Firefox browser on my Android phone. Stylish to the rescue. We’re definately in proof-of-concept territory now! Stylish lets you define custom styling for all sites, a site or one or more specific URLs. I made one specifically for the URL where the minimal entry form lives to clean up that screen even more: hiding the header, breadcrumbs, form field descriptions, etc.

phone screenshot 2 with CSS hacks applied. The save button is nowvisible in the intial viewport.

And, does it work?

Yes. It’s far from elegant but it’s already a much more focussed and faster experience. I think I already knew but was happily surprised to see that the regular image field does provide access to both the camera (for taking a new picture) and the gallery (for choosing an existing image).

screenshot 3

What could be next

One thing that makes the Drupal approach feel old school is the required title field. Twitter, Instagram, Tumblr all let you just type something into what basically amounts to a “body text” field. In Drupal it has to at least be just like email: a subject and a message: a title + a body. I can make the body optional but I want my text to go in there. Hiding the title field is not straightforward, I think because it is tightly coupled with the unique ID for that content item. There’s modules that let you hide the title input field but those still automatically generate a (gibberish) title.

Still, my focus was on smoothing the path for posting an image to my blog from my phone. That “Browse…” button is old school too, but it does provide access to camera and camera roll. Saving a bookmark for this comes with the option to create a shortcut icon for it on the phone home screen for quick access. Not bad for an hour or two of experimenting without coding :)

A couple of years ago swentel created Drupoid, an Android app that let you save an image from your phone as a content item on a Drupal site. It would be an interesting exercise to recreate something like it with React, Drupal’s (future) JavaScript toolkit of choice and figure out how smooth and snappy we can make it there.

Feb 05 2018
Feb 05

“Plan and model digital products for today and tomorrow.”

The Designing Connected Content book has arrived. “Plan and model digital products for today and tomorrow.” I have yet to dive in but I see Drupal screenshots and lists of field types like entity reference, long text (formatted), boolean, number (float), etc.

Today a content strategist collegue asked me about that list builder thing in Drupal. Show items of type x, filtered by y, sorted by x and only show fields 1, 3 and 6 of each item. And is it available for Drupal 8 as well?

Yes, that’s 1. Field UI and 2. Views module, which are both part of the Drupal core package.

We take Drupal core features for granted that other systems are still struggling with. They are also features people struggle with in Drupal because of hard to use user interfaces. I would love to see research and design work happen around how we can improve Field UI and Views UI.


Jan 15 2018
Jan 15

Drupal is 17 years old today. Quite an achievement for a web software to stay around, let alone stay relevant for such a long time.

I’ve been around for 12 years. Quite a stretch as well. Getting involved in this open source project as a designer has taught and brought me a lot. I put quite a bit into it as well.

I get a lot of benefits from things I learned in Drupal that I can apply in other contexts.

  • Provide rationale for design decisions. So much typing in issue queue comments!
  • Help people see the other’s point of view and then come to a shared decision.
  • Or agree to disagree, then still make a choice.
  • An appreciation and at least a “gist of things” knowledge of the complexity of software development. It helps with clarifying scope, finding a good place to start, and understanding what is difficult and what can be relatively straight forward.
  • Pragmaticism over purism
  • Edge cases are important
  • There’s a difference between patience and stubborness
  • Accessibility, multilingual, extensibility, modularity are hard but worth it
  • If you can’t imagine why somebody would want do do X, it’s always from a lack of imagination from your part
  • There’s always so much more to do
  • There’s only so much you can do
  • When you start taking things personal it’s probably time to take a break
  • It’s amazing what people can get done when driven by a passion for doing a good thing and doing it well.

… and many returns!

Jan 02 2018
Jan 02

Short recap of an interesting discussion during today’s UX meeting.

About inserting media items from within the WYSIWYG editor. These could be different types of media files, like images, video and audio. You could even have different flavours for the same file type. For example with images, you might want to store different information and metadata on product images than on images used in press releases or for the company blog posts.

The question was how to provide the starting point(s) for this. Of course the goal would be to make this as transparent as possible, reducing the amount of administrative busy work to the required minimum. But, structured content does not yet create itself automatically, we do have to provide forms that present the required fields to fill out when adding a media item.

We discussed two basic approaches

There are likely more and there’s room for subtle variations inside these two as well.

Option 1: start with a single button to add media

Workflow sketch of option 1

  1. Click 1 generic “add media” button in the WYSIWYG editor that launches a media upload form
  2. Upload the media (image, video, audio, …) you want and save
  3. Figure out the media file type and present the corresponding form with the required (meta)data fields in a second step
  4. Save and return to the editor

Option 2: choose from multiple buttons to add a specific media item

Workflow sketch of option 2

  1. Find and click the add button for the media you want to create. There would be separate buttons for inserting an image, a video, an audio item
  2. Because the type is known we can directly show the form for the required (meta)data.
  3. Save and return to the editor.

(Although this list only goes to 3 instead of 4, there is a bit more work for the user to do in step 1: finding the right media button to click)

After a bit of back and forth we chose option 2, because:

  • A one-on-one relationship between WYSIWYG button and media type to create is easier to understand
  • The upload process can be contained within 1 step because the system knows upfront which form to show for the required info.
  • With this one-to-one relationship, per media type permissions can be handled more elegantly (you either have a audio upload button or you don’t)

The trade-offs are:

  • it’s not super elegant to require the user to do the upfront work of explicitly choosing the type of media to create.
  • With multiple types of media available we’ll have to see how to expose all those different options in the WYSIWYG editor toolbar.
Dec 11 2017
Dec 11

Creating time and space to do the work

DropSolid in Belgium are the first organisation to sponsor some of my time to work on Drupal core.

It is very liberating to set apart dedicated time for tackling bigger chunks of Drupal core work instead of sneaking in bits and pieces at the edges of the day.

In the time available I was able to:

Many thanks to Nick Veenhof for reaching out and to DropSolid for supporting my work to help design a better Drupal!

I’m open to more organisations sponsoring me to work on the ux and product side of Drupal core. If that is something you are interested in, let me know.

Oct 30 2017
Oct 30

A selection of Drupal design topics and issues that are moving or should be :)

Small big win: status report pattern reuse in the migrate UI

A nice success from last week was closing a critical issue for Migrate UI. Particularly pleased that we were able to apply a new “summary” user interface element we recently introduced on the status report page.

Big one: redesign the administrative UI

There was a big interest in this over several meetings and workshops at Drupalcon Vienna and after. Seven theme hasn’t evolved much over the last years and it shows.

The right issues are not yet in place for this but I see and hear multiple people thinking about this. There’s multiple parts to this, of course:

  1. A visual update. What would the next version of this style guide look like?
  2. Improve the information architecture. Lots of solid thinking around this already.
  3. Introduce new interaction patterns. We still mostly rely on tables, select lists and other basic form elements. Experiments with JavaScript frameworks should help here but we should design these starting from user needs.
  4. Modernize the underlying theme architecture.
  5. Update and extend the user interface standards documentation.

Drupal core could use another usability test

The core feature set has grown considerably over the last couple of 8.x releases. On the one hand it would be smart if we found a way to do more smaller tests more often. On the other hand, since it’s been more than 2 years since the last big usability test we could do with one of those as well. Lets figure out what we can do. Check in here if you’re interested in helping with this.

Something to look forward to: Layout builder

The layouts-in-core team has been steadily working towards this. Looks like we are in great shape and on track to really honestly add a visual layout builder to core. There’s a patch going through the last stages of review and refine in One cool smart detail is that this will also introduce a dynamic way to dynamically generate icons for different types of layouts. Very nice indeed.

Permissions UI

Core and contrib modules often come with their own (set of) permissions. It’s how you can configure which roles get access to do what. This permissions UI is currently an ever growing sea of checkboxes. This does not scale, for user nor machine. The current model of a grid lists all available permissions in rows and all roles in columns needs a thorough rethink. Lets figure out a plan for how to do that.


& some more pointers to where you can go to find out what’s going on.

Enjoy your week!

30 10 2017

Sep 25 2017
Sep 25

From organic to deliberate

At the Drupalcon Vienna Business Summit on monday I presented a quick overview of how the roadmap for Drupal core comes together. A short bit of context and then on to how the new 6-month release cycle creates room to evolve the core product faster.

Drupal 8.4 is done and just about to be released. Here’s the roadmap for Drupal 8.5 core the product management team put together. In short:

  1. Migrate
  2. Media
  3. API-First
  4. Layouts
  5. Workflow
  6. Outside-In
  7. Out-of-the-Box

Of course no talk is complete without a section about how you, yes you can help make it all happen:

  1. Help inform the roadmap priorities: share survey data, usability testing results, client feedback
  2. Help validate the roadmap: are we working on the right things? Does it help fill actual gaps?
  3. Help build, because process does not replace people: sponsor development by providing time, money, space for getting things done.

25 Sep 2017

Sep 19 2017
Sep 19
start in the middle of the arrow between current and better

Help your peers get up to speed before Drupalcon so that while at Drupalcon you can more quickly go beyond “getting everybody on the same page” and move on to making decisions and defining next steps.

We can always do with more feedback from people using the Drupal toolkit to tackle, specific, challenges.

Get a blog post out, tweet out those “plan” style issue links, share that google doc, let us know which BoF you’ll host, etc. Help more people understand what’s moving where and what’s needed now.

It helps getting this info out there before Drupalcon because Drupalcon itself is where you then get together to decide and agree on path(s) forward.

Help people prepare so that you can start in the middle.

Maybe the feedback forces a restart from scratch after all because the problem is actually a different one than initially imagined. That’s still a win :)

Drupalcon is a great way to connect with the known experts and to onboard new experts.

Let us know what you hope to achieve.

19 Sep 2017

Aug 30 2017
Aug 30
Communication communication communication

Many channels, but the weekly meetings some teams have are a great way to get started.

It’s a big project, Drupal is. Many different areas that people are working in. The project is it’s own stack of technologies and skills, from low level framework considerations to the last bit of people-facing interface. Composer, Documentation, Accessibility. Each layer in the stack comes with shared considerations about goals, priorities, standards, documentation and getting code written, reviewed, committed.

There are whole teams working on specific feature sets. Media, Workflow, Migrate. But how to find out what’s happening inside each of these areas? PHPUnit, Out of the Box, API-first.

These links all go to long, dense outlines of plans and issues where current state of things and what to work on next is not super obvious. But there is a predictable and reliable way to see and hear people discuss their projects and initiatives. Outside-In, Admin Information Architecture, Progressive Web Apps. Many of the larger initiatives have weekly meetings to discuss progress, status and next steps. Mentoring, Multilingual, Diversity.

Where and how these meetings are held differs per team. IRC, Google Hangouts, Slack. Many interesting channels on Slack lately, check those out.

These meetings are an easy way to start listening in and getting up to speed. The timing is predictable and you can be sure it’s the experts talking about what is happening and important now. Layout, Security, Frontend components. Don’t let that hold you back to ask questions or share your thoughts. They are nice people and always looking for more people to help out. You are welcome.

30 Aug 2017

Feb 15 2017
Feb 15

Putting something in the box

A quick reminder that there are a few days left to apply as the designer for the new demo installation for Drupal 8.

Drupal wants to make a better impression fresh out of the box and for that, we need to put something nice in the box first. We now have the opportunity to experiment with sample content in a new “Demo” install profile. That’s why we are now looking for a designer to make that sample content look and feel good.

If you are a designer and want to have a big impact on the initial Drupal core user experience, have a look at the plan and consider joining this cool project.

Fair warning: getting design work done in Drupal has been notoriously hard, but this project is well scoped and has buy in from the product managers, so I do hope you (or the designer friend you will pass this link on to) will put your name in the hat. Thank you!

15 Feb 2017

Feb 12 2017
Feb 12
Stylized screengrab with colorfull circles overlaid

Not seven years but nine months in the making

The status page redesign got committed to core the other week. This is a good thing because it shows that we can actually get decent design work done in core.

Or is it, because it has become the longest issue on d.o. and took way too long and seems too much work for redesigning a single page. It shows we still can’t get good design work done in an effective way.

But if you look closer you’ll find that:

A first iteration was committed at ±60 comments in. This was 5 years ago. Then another 60 or so comments of discussion about what could be improved about that initial redesign.

“Only” 9 months ago, Bojhan kicked off a whole new redesign. That actual design was agreed on in a decent amount of time and discussion (35 comments, 2 months and 2 or 3 discussions of it in our UX meetings). We spent a lot of time with a first and maybe even second round of implementation approaches before settling on a core worthy architecture. Refining that approach still took a lot of effort to get right but not extremely so.

In summary:

  • 60 comments for the first iteration, this was a long time ago
  • 60 comments discussing additional details of that first iteration
  • 35 comments to agree on a whole new design (!)
  • 170 comments to arrive at a core worthy approach for the frontend code
  • 150 comments refining the code, reviewing it and fixing minor design issues

Some lessons maybe:

  • Restarting a whole new redesign in an already years old and fixed issue is not how we normally work. It might have been better to start a new issue for the redesign.
  • I think we’d now also choose to create and agree on the design in one issue and implement it in yet another. Although we really didn’t redesign by committee that much in this issue. 35 Comments to arrive at a whole new design is in fact a quite spectacularly short amount of time.
  • Learn to recognise when a design introduced new frontend patterns. Because we need expert guidance on how to implement it correctly.
  • Outline and agree on the architecture for implementation before starting to write code.
  • Getting good design done + changing a stable core feature is still lot of work. It needs visual design, interaction design and information architecture. It needs HTML, CSS, JavaScript and PHP code. It needs to be checked on correctness for each of those. And don’t forget about accessibility (we didn’t). Without breaking backwards compatibility because we were changing a stable core feature. That’s a lot of disciplines that need to be involved, which means it takes more people to complete.

I’m happy the issue got committed. I had mixed feelings about whether this is really is an achievement worth celebrating given the length of the issue. Looking back at how the process went, it shows that we did in fact manage to redesign a core feature in a reasonable amount of time. And despite the length and complexity the discussion never went off rails and tone remained civil at all times.

For the design part it has been very valuable to discuss things in our UX meetings where we can share screen and provide feedback while looking at the actual thing. Imagine that! :-)

Thank you Christina, Sumit, Chris, Joel, Lauriii, Gabor and everybody else who chipped in. Well done.

12 Feb 2017

Sep 13 2016
Sep 13

“Kevin, talk sample content to me”

Another fun live hangout with Drupal UX peoples. We review and discuss current issues and provide feedback or guidance where needed. These hangouts are recorded and available on YouTube. I try to link to the right segment in the recording when updating issues with team feedback.

Discussed today:

A separate queue for Ideas

I marked Agile process for bigger changes in core (Part A: Ideation) RTBC today. It’ll be open for final thoughts for a few more days. Looks like we’ll have a dedicated place to work through ideas soon.

Sort of like a Display Suite lite in core

Or as we say: Add ability for entity view modes to switch between two hard-coded layouts.
Eaton called it, this is very inside baseball, but adding layout options for arranging the fields in your content type is super exciting.

Media library design

We have an issue going that collects examples of media library features in other systems. Super useful. We (you!) can start sketching out Drupal specific user interface screens and flows now and post them there. (This is one of those issues that would start in the above mentioned Ideas queue).

Sample content

There’s Lee’s post about what it means to provide the tools that enable you to add your sample content to your flavour of Drupal installation. And then there’s adding some (hardcoded?) sample content to core itself, because, well, onboarding. Starting with the latter, that means figuring out what sample content to add in the first place.
The brand new Drupal user guide uses the example of a website for a farmer’s market. Wouldn’t it be great if our sample content and configuration would support that scenario? Yes, yes it would.

14 Sep 2016

Sep 09 2016
Sep 09
White red print

A platform needs a killer app

Tim blogs about core development being hard. Lee talks about adding sample content. Jeff’s comment there (the first) gives a good example of why core dev is so difficult:

…what we need is a tool that allows modules or profiles to optionally install content after their other setup steps

It’s never just the direct application X or feature Y that gets added. It’s the tools that enable X or Y that get added to core. And for a long time this generalized approach was considered enough.

What’s changing is that on top of the enabling tech we now strive to also add a more opiniated example, a more concrete and specific expression of those new capabilities. I’m reminded of of Stevey’s Google Platforms Rant: “A platform needs a killer app.”

It’s interesting to see this shift in balance and I’m curious to see how it will play out.

09 Sep 2016

Sep 01 2016
Sep 01
lab test illustration, druplicons in an erlenmeyer flask

Something something usability testing

The basis for knowing what to focus on for evolving Drupal core is learning about what people want to do with it.
Testing the initial experience of core as a whole has had our main attention so far. Now with focussed initiatives (content workflow, media handling, outside in, layouts,…), we’re adding experimental features with the assumed requirement that we validate and improve them trough feedback from usability testing.
So, we could (should!) create a more regular schedule of more smaller instead of few bigger usability test sessions. What’s our version of getting out of the building and increasing our exposure?
What would it look like if we did test every 6 weeks?
Produce testing scripts for each initiative. These can be reused, eventually updated where needed. Every 6 weeks we run those tests for each initiative. We learn what works, what needs to be improved. Initiative teams can prioritize fixing UX bugs. All things are connected anyway so we’ll learn about overall issues as well.
Feedback from the test participants can feed into ongoing persona work: what are people trying to achieve? Voilà, we’re learning about the Why.
Of course this requires planning, recruiting participants, having a setup for remote testing, getting access to a usability testing lab once in a while, observation, analysis, designing possible solutions, reporting back to the community, creating actionable issues to work on etc. But wow, we’d learn so much about where to focus our efforts.
Who wants to help make this happen? Mail, Slack (get invite) or lets talk at Drupalcon Dublin.

01 Sep 2016

Aug 24 2016
Aug 24
4 handwritten index cards

This is a pretty radical change

We’re probably misusing the term MVP when we try to frame what we would like to see make it into core. But the actual mode of working we use there is quite an achievement. We used to grind it out endlessly, where proposed changes could be discussed endlessly, with a high risk of not committing anything at all in the end. What we’re doing now is: agree up front that it’s a good idea to improve feature X or rework interface Y. And then focus on keeping the scope as small as possible.

Yes, I, J and K are also good ideas, but we’re trying to do X here and while these are all related ideas and together would like make for a nicer whole, we should really focus on shipping X, and X alone, before turning our attention to I, J and K. If at all, because while shiny, interface Y actually presents people with more problems, so maybe we should focus on that. Though it’s never that strongly a case of either/or, and we should definately not stop iterating after the initial commit.

This is a very new and different way of working. Deliberately lowering our standards for the goal of introducing change. This is uncomfortable at times, but even that is good, because it means we’re stretching ourselves, which means we’re doing and learning new things. I’m excited and proud to see this happen. More like this.

Doing it like this means that Drupal 8.2:

  • Has content moderation tools (draft! review! publish! etc.)
  • Provides a new way to add new elements (blocks) to the page you’re on, without having to go to some far away corner in the admin section
  • Those elements (blocks! menus! logo & site name! etc.) can then also be configured in the context of the user facing page. A side tray will show up and expose the relevant settings.

Looking forward to learn how these additions will be received and how we can improve them. In the mean time, lets add more useful and usable things to 8.3 (sample content! media handling! better dates! etc).

25 Aug 2016

Aug 23 2016
Aug 23
Color reduced screengrab of youtube grid of recorded meetings

Topics du jour, how we work, where you can help, the usual

Two meetings every week since end of march this year. Safe to say we’ve found a consistent rhythm.

And it’s working. It’s become a useful way to check in on current priorities, review patches while screensharing (visuals, transitions, flows!), decide on next steps and generally discuss hard problems without having to type so much.

The agenda for today was

  1. Roadmap – The core roadmap was updated to current state of things. Use this page to get a bird’s eye view on where Drupal core is moving towards.
  2. Ideation process – The first part of going from idea to plan got positive feedback and helpful questions and suggestions. Maybe a few words from actual maintainers and then we can make it so.
  3. Status page – We have a beautiful new design that now needs review and more code to create a complete patch. If you know your core markup and CSS, go have a look!
  4. Block place design update – An issue that iterates the design of an initial commit. We quickly discussed what the feedback should be and I added a comment to that effect right then and there. It’s an example of managing scope, pushing to focus on the actual fix first, and defer new, potentially good ideas to a followup discussion.
  5. Sample content – Kevin shared his initial thoughts and ideas for adding sample content, structure and configuration to core. More questions then answers but that’s just where we’re at for now. You are welcome to add your questions and ideas, please do.

As always, most welcome to join if you’re interested. Find us in the ux channel of the Drupal Slack room, or follow @drupalux on the twitters.

23 Aug 2016

Aug 21 2016
Aug 21
Concept map of the content workflow initiative

Must not make spelling mistakes or I have to start over again

Mapping out the moving parts of the content workflow initiative we arrived at this high level grouping of related activities:

  • Create content
  • Review & approve content
  • Publish content
  • Manage the creation, review and publishing process
  • Configure the tools that enable all of the above

For either single items of content or a set of multiple items, bundled in a workspace.

Create content

Everything related to creating new, editing existing content in the first place.


  • Author
  • Copy writer
  • Photo/image editor

Tasks & activities

  • Review assignments
  • Create content
  • Format content
  • Preview content
  • Request review
  • Edit content based on feedback
  • Review other people’s content
  • Review existing, live content

Review & approve content

All the things that need to happen to get new content ready for publication. Here’s a more elaborate example of a moderation workflow using a workspace.


  • Editor
  • Marketing associate
  • Archivist

Tasks & activities

  • Review content, give feedback
  • Edit content
  • Preview content
  • Get notified of content conflicts
  • Adapt content for different channels
  • Analyse impact of content changes
  • Review existing content
  • Recover content

Publish content

Actual publication of content and managing its life cycle from then on.


  • Section editor
  • Legal
  • Compliance

Tasks & activities

  • Define/specify content packages
  • Review content (packages)
  • Audit (legal, compliance)
  • Preview content
  • Approve revivisions
  • (un)publish content items
  • (un)publish content packages
  • Schedule (un)publishing of content
  • Archive/delete content

Manage content workflow

Set the strategic agenda, coordinate with other business units, oversee all of the above.


  • Managing editor
  • Marketing executive
  • Support & maintenance

Tasks & activities

  • Define content strategy
  • Content planning
  • Coordinate with the business
  • Coordinate with IT
  • Coordinate content delivery
  • Define content assignments
  • Schedule content production
  • Monitor progress
  • Review audit trail

Configure content workflow tools

Providing the tools and processes to enable all of the above.


  • Administrator
  • Developer

Tasks & activities

  • Configure workflows for content moderation
  • Configure content workspaces
  • CMS configuration: content types, roles & permissions, notification settings…
  • Technical development

Have a look at the visual definition of a workspace and a more fleshed out example of a moderation workflow as well.

Hope this helps clarify the main concepts, activities and relationships in the workflow initiative.

21 Aug 2016

Aug 20 2016
Aug 20
3 generic target audiences: individual, small group, everybody

Tabula rasa is not an effective onboarding strategy

First impressions matter. The first glance has a lot if impact on further expectations. Drupal core doesn’t do well there. As webchick points out, after installation the opening line is “you have no content”.

Yeah, thanks.

This empty canvas makes Drupal appear very limited in functionality. Which is the exact opposite of how Drupal is advertised (flexible, extensible, there’s a module for that!)

This is not news. The issue for adding sample content is over 10 years old. The image I posted earlier is from a core conversation 6 years ago. Eaton and moi presented on Snowman in Prague 3 years ago.

But now we do have Drupal 8, with essential features available right out of the box. We have a new release schedule that encourages shipping new features and improvements every 6 months. And we’re settling on a better process for figuring out the part from initial idea to fleshed out plan first, before implementing that plan.

So lets work together and come up with a plan for sample content in core. Which means answering product focussed questions like:

  • Audience: who do we make this for?
  • Goals: what do these people want to achieve?
  • Features: which tools (features) to provide to make that possible?
  • Priorities: which of those tools are essential, which are nice to haves?

But purpose first: audience and goals.

We’re always balancing product specifics with framework generics in what core provides. Pretty sure we can do something more opiniated than our current default “Article” and “Page” content types without painting ourselves in a corner.

We’ll discuss this topic during upcoming UX meetings and in the UX channel in (get your automatic invite here).

20 Aug 2016

Aug 17 2016
Aug 17
iterate on the idea before implementation

Agree on why and what before figuring out the how

We’ve made big strides since Drupalcon New Orleans in how we add new features to Drupal core. The concept of experimental modules has already helped us introduce features like a new way to add blocks to a page, content moderation and workflow tools and a whole new approach for editing all the things on a page while staying at that page.

In New Orleans we started to define the process for making these kinds of big changes. Probably the most important and defining aspect of it is that we’re (finally!) enabling a clearer separation between vetting ideas first, implementation second.

True to form we specified and detailed the latter part first :-)

So, on to that first part, vetting Drupal product ideas. In my core conversation I outlined the need for making bigger UX changes, faster and suggested possible approaches for how to design and develop those, borrowing heavily from the Lean UX method

Since then, we’ve been reminded that we really do need a clearly defined space to discuss the strategic value of proposed new features. A place to decide if a given idea is desirable and viable as an addition to core.

The point being: core product manager with help from Drupal UX team members wrote up a proposal for how to propose core product ideas and what’s needed to turn a good idea into an actionable plan.

It needs your feedback. Please read and share your thoughts.

17 Aug 2016

May 30 2016
May 30

After a couple of weeks of setting up with mostly free-format meetings in IRC we’re going to try a more structured format for our weekly UX meetings:

  • First half hour: people can introduce a problem + proposed (possible) solution
  • Second half hour: we review any work that has progressed over the past week. Often a core committer will be around to provide guidance or even actually commit changes that are good to go.

We did a first ad-hoc version of this last week, including a hangout with screen sharing. It worked really well, was productive and a lot of fun. Seeing the same thing in action is helpful when discussing user interface changes!

Next one is coming up and people from Acromedia will present on a topic and outline their proposed solution. For the second part I’m hoping we can review the “Place block” experimental module patch.

The meeting will take an hour. Here’s a calendar for the date and time.

Want to join? Join the UX channel on Get an automatic invite here. We’ll link a hangout from there and make sure we’re broadcasting live so at least everybody who wants can follow along and use Slack for background chat.

See you there!

Feb 15 2016
Feb 15

Drupal UX can be problematic. Many of the big conceptual issues have their roots in a user interface model that maps the UI directly to the underlying technical model. There is no translation made to map functionality to how people expect things to work. Currently, Drupal UI follows how the system works. Turning Drupal outside-in means making Drupal UI work like people expect it to work.

Example: adding fields

The capability to define different types of containers for your content is a core Drupal strength. For example, you could have an Event content type for your workshop or conference. Suppose lunch is included and you want to let people choose some options for lunch, like vegetarian, vegan, no preference, thanks but no lunch for me.

What people expect to do

  1. Lets add some checkboxes for lunch options
  2. So that I can capture lunch preferences when people register for this event

People usually start from the specific form widgets they want to use (text field, date picker, select list, checkboxes) and (after realising out that those checkboxes don’t work automagically) then configure more specifically what those checkboxes should do: storing some pieces of data.

What Drupal asks you to do

screenshot of add field UI

  1. Define the type of data you want to store
  2. Define which user interface element to use for the input of this data

Drupal enforces a flow where you first have to think in more abstract data storage format terms. For this lunch options example, you first have to specify that you want to store a list of text items and only then do you get to choose “checkboxes” as the way to present these options.

This is a great example of “the UI is the application”, and turning Drupal outside-in means exactly that: finding ways to expose all the great functionality in a way that maps to people’s expectations. Otherwise, for many people the functionality might just as well not exist.

Feb 05 2016
Feb 05

We want to be faster and bolder in shipping design improvements for Drupal 8. But how? Lets have a look at a relatively big (but not super huge) design change built for Drupal 8 during the development cycle and see what we might learn from it.

Redesigning the content creation page

Drupal 8 ships with a significant overhaul of the content creation page (“node form” for intimi). It’s design process and subsequent implementation are extensively documented on This is a high level summary of how this redesign come to be.

Steps in the process:

  1. Research
  2. Sketch
  3. Design
  4. Test
  5. Implement

Who were working on this? In the earliest design stages primarily 3 people: Bojhan Somers, Jared Ponchot and moi, Roy Scholten. Many more helped with finetuning design elements, usability testing, writing and reviewing code and all the other little and not so little things that go into getting a big design change committed to Drupal core. Thanks all.

Research & sketching

We didn’t spend much time building the case for a better content creation page. No problem because most were already aware of the big room for improvement.

The research was two-part: “what does Drupal do?” And “what are other systems doing?” For the Drupal aspects, we looked at how and where contributed modules add functionality to this screen. We reviewed other systems looking for patterns in how functionality was grouped and arranged on the page.

That input was then translated into very generic concept sketches, comparing and contrasting several arrangements of the three basic feature groups: content, settings and actions. From there, we proposed to pursue one specific direction in more detail. Before we did that, we opened up the work so far for feedback:


Starting from that very rough initial layout we started exploring the details of that arrangement. Which items belong in which area and how would they behave? How would it work on small screens? Which items to call out, which ones to push back?

Then Jared Ponchot stepped in and pulled all that sketching together in high-definition mockups. And on these we iterated again a couple of times, detailing the arrangement of interface elements, the use of color and other ways to (de-)emphasise certain parts of the whole. A comparison with the then current state of the Seven admin theme identified how we would have to extend its visual language to accommodate this new design.

And that’s where we opened up for another round of feedback:


A working prototype of the design proposal was coded and made available on a test site. A usability test plan was drafted and several people used that script to test the prototype with people both new to and experienced with Drupal. One of the few times we actively pushed for community driven usability testing actually. Results from the testing were reported in the implementation issue and individual issues were opened for the necessary changes.

Usability test plan:


The prototype for testing was created in context of the implementation issue. We spent a lot of time translating the design proposal into actionable tasks.

The distinction between rough prototyping code and actual core worthy implementation was a bit unclear at first but we very quickly got to a usable demo. The overarching “meta” issue has over 300 comments. Which is usually a sign of a large undertaking that’s not sufficiently broken down in seperate actionable tasks. But, we got there in the end!

Implementation meta issue:

Lessons (not? :-) learned

  • Good: working with a small team. It allowed us to focus on what needed to be done and move relatively fast.
  • Good: Publicly documenting the research and sketching phases was a lot of work but worth it. Pulling a finalised glossy photoshop design out of the hat would not have created the same engagement and constructive feedback
  • Good: counter to the previous point but also a good thing was that the initial sketches and design mockups were shared only within the very small team of 3 to 5 people. This kept momentum up but more importantly allowed us to focus on the actual design work. A broader discussion would very likely have shifted towards discussing implementation challenges, which is not what you’re after when still exploring multiple options.
  • Not so good: we prototyped only one working version quite late in the process. Only after a lot of time invested did we get to see and feel a somewhat working version. This narrowed our bandwidth for subsequent changes, which were relatively small tweaks, keeping the basic paradigm intact. We never really pitted two or more radically different approaches against each other. This was mostly a time and energy issue: we only had the bandwidth to work through one design direction.
  • Not so good: Doing the design phases outside of the issue queue (where implementation happens). This was a necessary but difficult trade off. The issue queue doesn’t lend itself to explorative work with lots of ambiguity so the design work wasn’t tracked there. Many core developers did not closely follow the process as it happened on, so when we brought the design over to the issue queue with the proposal to go build this, much of the earlier discussion points got brought up again.
  • Not so good: Not having a primary code architect as part of the team. We could have prevented at least some of the rehash in the issue queue if we had had a knowledgeable core developer on the design team. Having somebody who could answer to the technical implications of the design and help break down the work into manageable tasks the would probably have gotten us off to a better start with implementation.

A quick tally of the number of comments across the main discussion threads and issues for this project: more than 1200. And that doesn’t even include huge additions like the WYSIWYG editor and the improved previews. Not to say that this doesn’t happen in other initiatives, but you can see how demanding it is for anyone who wants to keep track, especially if you want to make sure that the big picture doesn’t get lost in the myriad of details.

How to get better, faster?

The nature of design changes like these is that they touch many aspects: backend & frontend, php & javascript, visual design & performance, accessibility & multilingual, etc. If we want to go faster we might want to consider replacing the research intensive work with building multiple (rougher) prototypes earlier and testing those for viability. That might lead us to a general direction and a plan for implementation faster. As for the actual core worthy implementation, we might win some time if we can provide a design spec together with an initial plan identifying the technical challenges and strategies to overcome those.

The amount of work will always be huge. I think the gains are in finding a better balance in:

  1. Feeling free to write quick throw-away code in the initial explorations so people can get a feel of what might work and we can test it.
  2. Reducing wasted efforts (in code and discussion) during implementation.

Understanding the distinction between these two, and being clear about when the first ends and the second begins will already be a big step forward.

Further discussion: Determine process for big UX changes

Jan 22 2015
Jan 22

On January 31 and February 1 the 15th edition of the FOSDEM event will be held in Brussels, Belgium. FOSDEM (Free and Open Source Software Developers’ European Meeting) is the largest gathering of open source community members in Europe. More than 5000 people will come from all parts of the world to meet, share ideas and collaborate.

As the name says, the event is highly developer centric, so the main focus has always been on the technology and the code. But open source software has graphical user interfaces too! Buttons to click, sliders to drag, forms to fill out, boxes to check, screens to swipe and what have you.

Useful software attracts users. To keep them around and attract more users, the useful has to be made usable. Which means uncovering and prioritising user goals and needs and doing the work to find out how to best serve those. That’s where design comes in.

This year FOSDEM will have it’s first ever “devroom” dedicated to the topic of open source design. User experience architects, interaction designers, information architects, usability specialists and designer/coder unicorns will share experiences and discuss the good and bad of design in open source environments.

Open source software is a driving force behind all things online. As more aspects of business, culture, society, humanity as a whole move into the digital domain it becomes just as more important to ensure that people don’t get left behind because of the sheer complexity of it all. There’s a lot that the craft of design can contribute to ensure this.

I’ll deliver a short talk about how we started, grew and maintain a user experience design team within the Drupal project. Otherwise, the schedule is looking great. I’m looking forward to meet my open source designer colleagues.

See you there?

Sep 29 2013
Sep 29

And Drupalcon Prague is a wrap. It was a good one. Some of my highlights:

Although the code and architecture apparently leaves much to be desired, the top user-facing feature requests have all been added to Drupal 8. Multi file uploads, WYSIWYG integration, re-use of media through a site-wide media library are all in place.

The conclusion was that there is no clear overall picture of all the moving parts on the API level. A brainstorm session was held on sprint Friday. Have a look at the proposed architecture.

As a user experience designer, it was great to see that Janez had conducted user research and that the sprint focussed on getting a shared understanding first, possible solutions second.

Keynote: Experience Driven Open Source

Aral made a compelling case for the importance great user experience in open source projects. All those awesome free web services are free because you provide your data. Owning your data is an important topic. So yes, there’s definately room for what Aral calls “Experience-driven Open”. Read more about his Codename Prometheus project here.

My take-away for Drupal here was yet more confirmation that we really do need a more usable and useful initial setup for Drupal 8…

Viva Snowman!

The idea for a core install profile that serves a more specific use case has been around for a couple of years. It’s only now with Drupal 8 that we actually have enough tools and features in core that such a specific configuration is now possible.

It was fun to see the room agreeing that this is a good idea yet immediately go looking for ways how to keep it outside core :-)

Has to be in the box to be available out of box though! Keep an eye on the Snowman discussion group.

Future-friendly evolution and the Drupal release cycle

Larry took a packed room of core developers through how we have been working now, roughly summarized as a three year cycle of slash-and-burn-out without really evolving the APIs of the current release.

But what if we did allow/force ourselves to improve and evolve Drupal 8 instead of directly diving into Drupal 9 to reinvent and improve all the things?

Take 6 months for each 8.1, 8.2, 8.3 release and allow new features and API improvements. Open up Drupal 9 development not before 1 year of Drupal 8 being released.

We’ll see more discussion around this topic for sure. Larry provided us with a great framework for how we can live up to the level of maturity the Drupal project has achieved by now.

Announcing Drupalcon Amsterdam

A personal highlight was announcing Drupalcon Amsterdam for 2014 with Baris and Bert. Our orange suits performed well it seems :-) Looking forward to yet another greatest Drupalcon ever in Amsterdam.

Meeting all of you content working group meetings, beers in the lobby, sponsoring ycheds new laptop, late night walks through Prague or coding in the coder lounge…

The best thing of course is meeting all of you. So great to talk, drink and dine with the real humans behind all those nicknames in IRC.

So many very special people with a heart, it’s inspriring and energizing. Thanks all.

Apr 02 2012
Apr 02

Recapping some of the main UX related discussions and topics from Drupalcon Denver:


Dries expressed his desire to win the hearts and minds of people with Drupal 8.
Hangover spot or not, that’s exactly what Luke Wroblewski did during his Mobile first keynote with an engaging mix of poignant statistics and some plain funny jokes. Luke returning back to the stage to allow for some extra questions in person was a nice gesture too.

Mobile sprint

On Sunday and Monday, Denver based Drupal shop Elevated third generously provided office space, drinks and snacks for people working on the mobile initiative. A small but dedicated group worked on all kinds of improvements for the mobile space. The goal was to make the core Stark theme use a responsive layout. That goal was met. On friday, these changes were committed to core. Good work. Thanks again Elevated Third for providing the environment in which the work could be done.

Many more interesting patches are in the works. You should join the fun, from what I can see there is a lot of potential to really move things forward with relatively small and simple patches. Lets keep this train rolling.

Layout initiative

We want to ship Drupal 8 with new and improved tools for building full-page layouts that let content publishers easily create the exact page they need. This is a big project with many moving parts. I spent a good amount of time talking and working with Michael Keara to define an approach that lets us tackle these big UX challenges. Especially the BoF session where we split up the group and brainstormed around our understanding of ‘Context’ and ‘Page’ were good exercises that drove home the crucial point of getting our terminology right.

Michael has already put in a lot of work in this area through his analysis of the Page manager and Panels modules. His work has been most generously sponsored by My Planet Digital. I’ve been thoroughly impressed by the clarity and focus Michael has brought to the discussion so far and I hope he can continue to be as involved as he has been so far.

Create content page

It has been amazing to hear so many people saw our designs for a better content creation page. Very positive feedback too, thanks for that, it’s been very encouraging. Bojhan wrote up some conclusions.

In the mean time, we’ve opened an issue for implementing the new design. Would you like to help improve one of the most crucual interfaces for the Drupal content management system? I’m looking for a code architect that can help guide contributors towards realisation of this design.

Google usability test retrospective and next steps

Becky and Garen presented on how they planned and executed their big-impact usability study. Just the day before they had released a 5-page PDF summarizing the main findings, grouping the issues found into four main types of problems. You should all go and read it.

The one overall challenge is that right now, Drupal does not empower people that start using it. The talk rightfully hooked into Dries’s theme to win the hearts and minds of people with Drupal 8. Right now right from the start, the Drupal message is ‘this is difficult’.

Becky and Garen then presented a proposal for getting people up to speed. The idea is to finish the installation process with a quick guide that explains some of the main Drupal concepts like content, content type, field, block, menu.

It is one direction to explore for solving some of these problems. Later that week we spent some more time talking through this idea. Lewis Nyman hacked up a quick implementation of the general idea in real time. Prototype code is hard to beat for efficiency and quick turnarounds when you know how to do it!

In the mean time, one more big thank you to Garen and Becky for doing this and to Google for providing the time, space and participants to make it happen.

Core product core conversation

Wednesday afternoon I presented my 3 suggestions for a more focussed and useful Drupal core install. I think it worked well enough as a conversation starter. And I really liked the way Daniel ‘sun’ Kudwien extended the idea and suggested that the community should pick one of the use cases to learn what it actually takes to design, build and maintain a distribution.

During the friday code sprint I sat down with Aimee and Eaton to kick around some more ideas on how to make all this into an interesting exercise in product development. More on that some other time.

Best Drupalcon ever! Thanks to all who made it happen, I had a great time.

Mar 13 2012
Mar 13

Proposals for changing Drupal UI and UX are heavily scrutinized (as are all other changes) once they hit the issue queue for implementing them. To keep discussions on track and prevent “opinion wars”, it helps to bring some solid research.

I’m excited to see more people taking the time and effort to provide exhaustive overviews documenting specific parts of the Drupal user interface. For example:

This is design grunt work. Clicking through the user interface, collecting screenshots to document existing patterns, analysing what works and what doesn’t and deciding which direction to explore towards an improved design.

Design is for a big part about making the right trade-offs between conflicting requirements (“Easy yet powerful!”). Together with solid usability testing, it’s this kind of research that gives us solid foundations to build and improve on.

Great work people, much appreciated.

Feb 29 2012
Feb 29

Not long until Drupalcon Denver kicks off. At least three days jam-packed with talks covering the full Drupal spectrum. As ever, with over 100 sessions on the schedule, the trick is to choose which sessions you want to attend.

If you are into design, ux, theming and/or general front-end awesomeness, the “Design & UX” and “Mobile” tracks are the ones to check out and pick your sessions from.

(Note: I’m a global chair for the Drupalcon Design and UX track)

Here’s a handy link to all 13 sessions in the Design and UX track. And here’s one is for all mobile sessions. Lots to learn from in there.

The main themes running through these tracks are nicely captured in their featured sessions:

But wait, there is indeed even more!

Consider these sessions about lean startup and customer development, learn about todays requirements for editorial workflows for big publishers, or get up to speed on the ins and outs of Drupal products.

And of course there’s a keynote to look forward to. On Thursday, Luke Wroblewski will show you why thinking mobile first really is the smart thing to do these days.

I’m looking forward to all of this. UX designers that want to meetup outside of the sessions, go chime in here. Hope to see you there!

(And one final plug: And if you’re not going to make it to Denver, check out this great front-end focussed Drupal conference in The Netherlands in April)

Feb 24 2012
Feb 24

The slides above are from a core conversation I would have presented in San Fransisco if a certain ash cloud hadn't gotten in the way:

  1. Drupal can do anything. There's always a module for that.
  2. Drupal core does nothing (really well). No specific use case, and that's by design.
  3. Yes, decouple framework from platform from product specific features and configuration.
  4. Wouldn't it be awesome if the installer would let you choose from a list of pre-configured products like Awesome blog, Newspaper, Portfolio or Team toolkit, etc? Yes it would.

That was 2010, and even then this wasn't particularly new thinking.

It's a given that core alone can never be turned into a full-fledged product serving one specific use case. Instead, providing a useful onramp experience is what we should focus on. What can we do to get people 60% of the way there, so that they are invested and want to dive deeper and explore contrib?

What kind of products? For whom?

The two hardest questions. It will make things a lot easier if we allow ourselves to think in multiples here. Three is the magic number. These are the three high level use cases I think we should brainstorm around:

  1. "I" - The individual site. Working title: Portfolio (it is not a blog). For content creators.
  2. "Us" - A small group project. Communicate among each other and the outside world. Working title: Snowman, for site builders.
  3. "World" - A tour d'API for developers, exposing the best new core concepts that live under the hood. Working title: Butler.

We had tremendous fun with the #drupalfilms meme on Twitter. Drupal trainings are modeled around 'build Flickr, Twitter, YouTube in a day. We could use some of that playfullness here.

I'll have another go at this in a core conversation in Denver. But what do you think?

Feb 20 2012
Feb 20

Today we’ll have our 14th edition of UX open hours in IRC. It’s the best way to stay up to date on Drupal UX work and you’re all invited.

We started these bi-weekly meetings in July 2011 as a means for experienced contributors to check in on each others work. But more importantly, these chats are for anybody interested in contributing to a better Drupal UX to introduce themselves and find a good place to cut their teeth.

And it’s working. We’re steadily growing the team of people that help with research, usability testing, design and development.

Why then don’t you see much activity around UX issues?

Because we’re following a design process of Research > Design > Build. It should be no news that the issue queue is really only fit for that last ‘Build’ stage.

The work happens in Google docs and spreadsheets, shared Dropbox folders, Skype calls and IRC discussions with the occasional Skitch screenshot back-and-forth.

It’s not ideal to not have this process tracked somehow in the issue queue. We’re running the risk of hitting the issue queue with ‘final’ designs that seemingly come out of nowhere, which is counter-productive in getting people excited to help with implementation.

Join us today

So, if you want to keep up to date on the redesign of the modules page and the content creation page, where we are with the analysis of the Google usability test findings or how we think we can improve the core account signup process and learn how you can join the fun, come join us today in IRC.

If you can’t make it, we post notes of previous meetings

I’ll see you there.

Jul 22 2011
Jul 22

We’ll meet in the #drupal-usability channel on IRC and discuss actionable Drupal 8 UX tasks and goals. We’re especially interested in what you would like to see happen there, so bring your ideas and battle plans, too!


We’ll present opportunities for working on UX improvements that are specifically not of the grandiose paradigm-shifting variety but focus on the actionable things that can be worked on right now. Again, we’re curious to hear your ideas for this.


We’ll use the last part of the meeting to review the user interface for contributed modules. Last time we discussed possible improvements for the Theme settings extras module. If you maintain a module and have questions about its UI, prepare a screenshot or maybe a demo site and we’ll have a look.

Looking forward to see you there!

May 11 2011
May 11

The University of Minnesota has graciously offered us another opportunity to gather data and insights from observing smart people using Drupal for the first time.

The two lab tests we did with Drupal 6 really brought home the fact that Drupal can be hard to wrap your head around. The community has responded with a drastically reworked Drupal 7 and next week will give us fresh insights on what we improved, what has become worse and which new problems are out there.

The plan

On May 17 and 18, eight participants will each spend 75 minutes working through tasks around building an event site, touching the essential basics of creating content, menu links, blocks and modules.

This test will be attended by community members including Drupal 7 co-maintainer, Angie Byron (webchick) and key members of the Drupal UX Team: Bojhan Somers (Bojhan), Brad Bowman (beeradb), Dharmesh Mistry (dcmistry), Jen Lampton (jenlampton), David Rothstein (David_Rothstein), Chad Fennell (cfennell) and Erika Stenrick (estenrick).

Initial results will be shared at Drupalcamp Twin Cities which happens right after testing on May 20 and 21, on and at Drupalcon London in august.

The results from this test will be invaluable in helping the community make better design decisions while building yet another best version of Drupal ever.

Make it happen

Improving the Drupal user experience is crucial to the long term succes of Drupal. Sponsoring this test is a great opportunity to express your support. Many individuals and corporate sponsors Acquia and Krimson already chipped in.

Will you?

Thank you!

Nov 11 2009
Nov 11

If you want to contribute actual changes to the Drupal software, you have to do it through patches. Patches are a kind of text file that describe the changes in a way that lets them easily be applied to the official code base. To create them, you have to jump through a couple of hoops, especially checking out Drupal head from CVS and creating the actual patch from the changes you made.

Contrary to popular belief among the developer community, creating patches is not easy for some. Using the text-only interface of the command line is a big hurdle for the more visually oriented. I finally found a way to do this CVS-checkout-and-patching thing without using the command line but through a free app with a graphical user interface.

I'm sure it’s way more elaborate and slower than through the command line, but this works for me and it might for you, too. Here's a slideshow that walks you through the process, best viewed on Slideshare as it will show the slide's notes there, which you'll need to make sense of this.

Oct 06 2009
Oct 06

“…Surgical teams that follow a basic checklist in the operating room, from discussing expected blood loss to confirming the patient's name, reduced the rate of deaths and complications by more than a third.” (source)

Drupal module development will hopefully not cost human lives one way or the other. But when building your module's UI the same principle is at work. It's all too easy to skip the basics, and go straight for the more complex parts of the problem. That’s the interesting part after all.

There’s literally thousands of contributed modules out there. If you have forty of those installed on your web site, the user experience will be much improved if the UI for each behaves in consistent ways. We hear developers wouldn’t mind having some advice on how to do this, either.

At Drupalcon Paris Bojhan and I presented the talk ‘Building blocks for your module's UI’. Consider it the kick-off for creating this checklist. We'll call it a user interface design pattern library.

A design pattern is a generalised, reusable solution to a commonly occurring problem. It should:

  • Describe the common problem
  • Offer a solution
  • Give a rationale for why (and when) this solution works
  • Provide visual examples

In our presentation we do this for fieldsets, tables and vertical tabs amongst others. There’s a big part on copy writing in there as well. But we’ll save that for another post.

So, now to make this first outline into a useful reference for core and contrib developers that will actually get used! The outline and inital content is there. We'll need some help getting it done for real though. Have a look at the presentation if you will. Then, we'd love to hear from you if want to help with documenting and writing these patterns.

Jul 01 2009
Jul 01

The modules page is a typical example of a long list that gets hard to manage pretty quick. The categorization is not ideal, with big modules providing their own category and a quickly growing 'misc' section.

The usability tests have shown that after installation, modules do not provide clear starting points to where you can find their configuration pages. Same goes for the new permissions a module might expose. No clear indication that there are new permissions and no clear pointers to where to find them.

  1. Finding functionality once a module is installed
  2. Finding functionallty a while after the module is installed
  3. Finding functionality (with no knowledge of modules whatsoever)

In general, this gives us two areas of attention:

  • Managing the big list of modules as a whole
  • Finding related tasks per individual module

For the latter, we need to show more info per module without cluttering the interface. Finding related tasks per module is something the accordion concept (yes, accordions, I mixed up my musical instruments there) could help fix this by showing links to configuration and permission pages from within the context of the module itself.

During the UX sprint we discussed ways to make it managing the big list itself easier. The main idea is to provide 3 top level boxes for modules to live in: New, Enabled and Disabled.

Let's take a look at how this would help solve some of the problems:

Box 1: New This would make it pretty easy to find the module you just installed on the page. You'd find both enabled and disabled modules living in this box. Of course, we'd still have to provide messages on other admin pages so that you know you have to visit the modules page at all. Box 2: Enabled It seems sensible that below the list of 'New' modules is the list with 'Enabled' ones, no? These are the ones that provide the parts you built your site with. Box 3: Disabled For the modules that are installed and fully configured or have been enabled before, but are (kept) disabled, well, you probably don't want to have them clutter the top part of your screen.

Yes, but…

What about the categories? It would still be handy to be able to filter on everything 'media' or 'ubercart' yes. Propose to make the categories a filter as a select list on top of the page. What about modules that consist of multiple modules, like panels, views, ubercart? What if I enable some of them, some not? Yes, the New/Enabled/Disabled segmentation would seperate these 'sub-modules' from each other. Currently these modules are grouped into their own category. I don't expect the seperation to be a real problem. On first usage (after installation) the module family would be shown in full in the 'New' box. After configuration, the category filter would allow you to see all panels, views, ubercart related modules together again. This would mix up core and contrib modules! From the users perspective, does that really matter? Again, the Category filter would come to the rescue in providing a filter to show 'Core modules' only. In itself it is not a very relevant disctinction to make. How would the modules within each box be sorted? Sorting alphabetically, although about as helpful as 'random' in most cases, seems to be the most logical option here for the New and Disabled boxes. For the enabled section, which would normally be the longest list, we can re-use the categories from the configuration page (the new name of what currently lives under /admin but reorganized).

Any other edge cases I missed? Any other problems that might arise from this new grouping? Point them out please and talk us through it. If the concept still holds after discussing them, then just this new grouping of modules in New / Enabled / Disabled boxes would be a worthwhile improvement for the modules page.


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