Hello everyone, I’m Vicky. I’m a UX designer (at Orange Bus) a longtime Drupal designer and dev (since Drupal 6, I think my first Drupal site was in October 2008, a personal blog that I completely ruined. Luckily I learnt a bit more after that!).
Drupal is great for a lot of things, but usability isn’t one of them. Admittedly, it’s a lot better than it used to be - for anyone who remembers Drupal 6 - but there are still a number of issues that are always worth ending up getting fixed: and in fact are often one of the things that makes it clear to me that a site has been built on Drupal. Well, that and that Webalyser on my computer shows it up as being Drupal. I’ll admit that there’s been a serious push on usability for Drupal 7 and that a lot of this is being actioned in Drupal 8, as Adam pointed out earlier today with a lot of the changes happening with Drupal 8. (I know that Leisa Reichelt, the head of gov.uk and one of the two designers involved in the Drupal UX project a few years ago, has noted that a lot of the things they pointed out have started getting pushed through now). I’ve seen that some things I’ll talk about today are going to get fixed (hopefully) in Drupal 8. However, most of us are still on Drupal 7, and will certainly be supporting them for a fair while.
I’ll admit that this is based on a combination of my own experience as a Drupal developer from the last few years, as well as some of the changes that our UX team at Orange Bus always implement on Drupal sites we build or end up picking up when clients have existing sites running on Drupal. However, our developers tend to custom code a lot of options, so the modules I suggest are often my own experience rather than our agencies. I have used most in the past and tested all of them, but I felt that it was important to provide easy options for site builders to implement rather than just saying ‘go talk to the devs’.
I’ve also focused on front end options rather than back end, for that I recommend looking at the fantastic set of modules put together in Tasty Backend by Jenny Tehan.
on to the 10!
I read a post from a few years ago complaining about why for some reason Dries had decided that usernames could have spaces rather than the standard ‘no spaces in username’ pattern. The entire issue of usernames is problematic when it comes to sites that you don’t go to very often: the old ‘what on earth did I register this as’?
To be fair, this isn’t specific to Drupal. This is from a damning review of healthcare.gov (not a drupal site) where one of the many things they pointed out as being wrong was that people had to select a user name to register. This is a particular issue with ecommerce where not having a guest checkout is likely to make people leave.
Luckily there’s a fairly well known and reliable answer to this: logintoboggan gives you a lot of options that all help with usability: it allows you to log in using an email address as well as a user name, and a lot of other great details that I’ll discuss later. Some other ones to think about are: email_registration: which completely removes the need to set up a username at start: it guesses at one based on your name which you can change later. `
My colleague Joanne Rigby previously worked on the TV licencing site which was all about forms, and as a result we’re pretty thorugh when it comes to checking them. However, out of the box the Drupal validation system is problematic: it shows errors on submit and at the top of the page. It’s not always the best languaging either.
Luke Wroblewski is the UX form guru (as well as possibly the mobile guru) and has done a lot of evangelising for form usability, and has shown that good validation makes a difference. We’ve also found this doing tests (namely that often sites without good validation were harder for participants to use and so they were slower).
In a lot of situations, we’d amend the theme and/or write this into a custom module with hooks. However, for site builders, inline form entity and clientside validation work well together (though you do have to turn on ‘on blur for all fields’. It’s also worth looking at tipsy, which moves the help text into a tooltip (though I would be careful with this and test as it can be overwhelming if you have lots of text), and dramatically string overrides which will let you change some of the text in the validation fields.
My cat is sad because a Drupal site is spitting out computer talk. There are different types of errors: the errors where a user may have made a mistake (e.g. 404s) and those where the computer has made a mistake.
For those that don’t know, Jakob Neilsen is the grumpy old man of usability (apparently wasn’t always grumpy, but that’s another story for later). However, NM Group gives a lot of useful guidelines.
One element of making user elements visible and helpful is ensuring that they’re appropriate and feel like the site rather than the CMS is talking to you. I say this particularly because it’s easy for error messages to miss being themed. In this respect styleguide is useful in showing base UI elements that a theme uses to check for
For those messages that shouldn’t be seen, you can either amend in your theme or use the disable messages module. I would use this carefully as it doesn’t always differentiate between user and system errors: and users can miss important information (though this is captured by the clientside_validation and ife modules).
I know that meta information can seem as much about SEO as UX.
However, I bring this up as there are different things to consider when it comes to metadata. While some things such as page titles and page descriptions are part and parcel for Google, the game is shifting so much that they’re starting to become less important. We’ve always advised our clients that good content is good SEO. However, the rise of social media means it’s worth getting things looking good for the various networks. The fun
The metatag module gives you good options for considering these things off the bat. I haven’t added is as I haven’t had a chance to investigate it yet (and am waiting for a Drupal project to investigate) but there’s a module for structured data on Drupal so that you can create a ‘content once publish everywhere’ COPE system.
Ah, drupal comments.
I have to admit I added this from doing search on online as I know personally I’ve always hated that Drupal by default expects comments, and other people have been vocal about this too. For years. I don’t think I’ve ever done a wireframe that has a subject header for comments!
Sadly this is the one example where as far as I know you do have to amend the theme. I have to admit it’s always an option that’s felt incredibly buried as well.
There are also other options,
The rise of ecommerce has made sort and filter more important. (Oh, for site builders who don’t know about it already, devel_generate is a great quick way to test sites using dummy content). However, this has also made them more sophisticated.
I have to admit that this taken from another project of mine as the act of
Other ones to consider: metatag.
10 UX Changes for Every
Drupal 7 UX needs
Some things will get sorted out in D8.
WTF is my username again?
If possible, use email as registration [and login]
“In 2008, Forrester estimated call-center calls to
cost $5.50 per call versus 10 cents for a user who
HealthCare.gov’s Account Setup: 10 Broken Usability Guidelines
“Our participants [in a test of 22 average users
on six variations of a typical web registration
form] were faster, more successful, less error-
prone, and more satisfied when they used the
forms with inline validation.”
Inline Validation in Web Forms
“Make [user] error messages clearly visible, reduce
the work required to fix the problem, and educate
users along the way.”
Error Message Guidelines
(see from /admin/appearance/styleguide and make sure you have permissions set)
disable_messages (with caution!)
consider: stringoverrides, customerror (pay attention to your 404s!), logintoboggan
“The incentives for adding social structured data are
● It can improve your CTR [click through rate].
● You can tailor content for each social network.
● It gains you extra real estate and exposure.
● If you don’t use it the resulting data can look a bit
messy, as a computer will have to work out which
bits of information you want to show.”
The three types of social structured data and why you need them
“I'll add my pet peeve, though: COMMENTS SHOULD
NEVER HAVE SUBJECTS. Never. Not just no Subject
field, but NO SUBJECT AT ALL. A comment is about
the post, so the subject is the post.”
‘Barry’ as comment (2007) on
Drupal Usability: Comment Configuration
Amend settings to remove title + amend
theme: or use Disqus/Livefyre
also: Mollum is good, or reverse CAPTCHA
6. Menus and navigation
Be logical and signpost
List of navigation and IA usability guidelines
1. There is a convenient and obvious way to move
between related pages and sections and it is
easy to return to the home page.…
29 navigation and IA usability guidelines
thauto. And sitemap!
Consider superfish, up_to_top
7. Blocks and block titles
Not all blocks are the same
“So when are you going to ditch your sidebar?”
Commenter on “The key to modern blog design: promote UX by retiring your sidebar”
“The From field should show a recognizable
brand name (if available).… People simply
don't open messages that don't have
recognisable sender information . In both
rounds of research, this was the number one
reason users gave for not opening email.”
Transactional and Confirmation Email Messages
Review system emails, sender.
Consider: Mailchimp for newsletter sends
“Sorting and filtering are essential for helping
users to find the products they're looking for….
The options you provide for both should speak users'
language and be specific to the actual product listing
(and not generically applied across the site).”
Filter & sort: Improving ecommerce product findability
“The following features should be accessible via a
1. Personal Information / Contact Information
2. Security Information
3. Links to member-specific content areas
4. Information users have uploaded [contributed] to
Usable User Accounts
12. In site navigation: back_to_top
13. Search: search_api + facet_api
14. Making pages for print: print
15. Connecting things with each other:
16. Media and images: Media (/ARRGH)