You may have noticed that this is a WordPress blog. Both the D7UX and the Disambiguity blogs run WordPress. Mark Boulton Design uses Expression Engine. Since we first started working with Drupal there have been questions (and the occasional shout of #fail) that we continue to use these platforms and haven’t switched to Drupal.
Don’t we know Drupal can do all that WordPress can do and more?! Don’t we love Drupal?!
Well, yes and yes. We know Drupal is amazing and we love it (well, more to the point, we love the people all around Drupal), but unfortunately, for the time being, it is too broken for us to be able to do the work we need to do on this project at the pace that we need to do it. We don’t have time to ‘learn’ Drupal, nor the skills to bend it to our will (and make it look acceptably pretty), we can’t even get a blog post on the homepage (as you’ll see in the videos that follow the installation video about which I’ll post as soon as they finally make it up to YouTube).
We appreciate all the offers of porting this blog over to Drupal, but to be honest, I really like using WordPress and nothing I’ve seen of Drupal makes me want to switch over at the moment.
See, I love the *idea* of Drupal, but the sooner we all agree that from a User Experience perspective it is horribly broken and concentrate on FIXING that, the better it will be. Admitting this doesn’t make us Drupal Haters, far from it. It just makes us honest and informed. After all, we use a whole raft of tools to make and administer websites all the time – we actually have a pretty good perspective to be making this call.
If we didn’t *really* care about making Drupal amazing, we wouldn’t start difficult conversations like these ones. And there is a big reason why one of the key success criteria for this project is that once this project is done Mark & I will *want* to switch from WordPress and Expression Engine to Drupal.
And what of ‘eating our own dogfood?’ – well, again, back to that success criteria of Mark & I using Drupal once the new UX is implemented. If we’re not using Drupal then, I’m happy to be called on this. For now, the fact that we are NOT entrenched Drupal users is actually a great advantage to us, rather than a disadvantage. It gives us perspective, distance from the project that allows us to see things differently, to challenge accepted ideas and approaches, to re-hash conversations that have been had a thousand times already and have them a little differently. It helps us not see that things might be impossible (and, at this stage of the project, that’s a good thing).
We’re not entirely ignorant of Drupal, not at all. And becoming less so every day. And we are surrounded by an incredibly informed and amazingly helpful community who give us *way* more help coming to terms with Drupal than the average ‘newcomer’ would have.
We know that Drupal is not WordPress, and we have no intention of making it so, but using WordPress helps us get our work done faster and easier for the time being, and it helps us maintain perspective and distance – and for now those things are really important to us.
But if, this time next year, this blog isn’t running on Drupal and if it doesn’t look amazing – then please come and shout #fail as loudly as you can. Because then you’ll be completely right, we will have failed.
Let’s not do that. Let’s make Drupal amazing.
And thanks so much to everyone who has come on board and started to help shape D7UX by responding to our initial Experience Strategy, Audience Matrix and Personality Quiz. The feedback has been incredible and insightful. We’ll have more for you to look at soon!
So, there we were, just starting to work through the workflow for Drupal – we got as far as the login screen when we thought ‘let’s write something nice on this screen’, and, pen poised… we were stumped.
We wanted to write something friendly like Moo would. Or Innocent drinks. We wanted to make it visually interesting like Vimeo do. Or Picnik. But… is that Drupal?
We realised we have no idea what Drupal’s personality is. And it would make our lives much easier, and help make a much better User Experience, if we can work out what it is.
Isn’t this completely touchy-feely and a waste of time?
Well no. One way or another, words will go on screens and a personality will emerge. Or, worse still, a few personalities, or a few dozen personalities. Much better that we spend a little time and give a little thought and see what we can come up with.
So, here’s where you come in:
The Personality Exercise:
Take a minute to v quickly answer the following five questions. Go with your gut reaction, don’t over think it. Try not to read everyone elses’ responses first. Don’t worry about being silly! (This is a kind of silly exercise after all, albeit useful)
If Drupal was an animal, what would it be?
If Drupal was a celebrity, who would it be?
If Drupal was a car, what would it be?
If Drupal was a profession/career what would it be?
So your answers might look something like this:
Drupal would be a squirrel/Paris Hilton/SS Commodore Ute/Teacher*
Get to it – what do you reckon?
*the opinions expressed above are not those of the author. Except for the SS Commodore one.
Over the past week or so Mark and I have been working out the details that go on the panels of the Audience Matrix that we shared with you last week (or dress-up-doll document as it has otherwise been named). We’ve made a few changes and added a bunch of definitions.
Here’s what we’ve come up with so far:
Content Creator: a user who primarily creates, reviews, and edits content for a site. Key tasks: Add content, edit content, find existing content, view list of content creation/revision tasks.
Site Editor: a user who has authority to approve, edit or reject content and who may be able to manage some editorial workflow and user permissions. Key tasks: Add content, edit content, find existing content, view list of content creation/revision tasks, review content, reject/feedback on content to original author, schedule content,
Site Admin: manage user permissions, manage site structure, adding new content types, create and review reports and manage some site settings (RSS Publishing, IP Address Blocking). Key tasks: Manage user permissions, Add / Edit / Delete Content Types, Manage Information Architecture (site sections, sub-sections, taxonomy (as in, vocabulary), Create a report, Review a report.
Site Builder: creates site from scratch by choosing, writing, customising modules and/or themes, manages setup and maintenance. Is a developer (for the purposes of audience definition, themers are considered developers). Key Tasks: Develop site functionality, implement site design.
question: who can/should be able to create new content types? who can create new site sections and subsections (vocabulary and/or terms) etc.
TYPE OF SITE:
Brochureware Site: hierarchical structure of relatively static content, often includes forms (eg. contact/feedback), may be multi-author
Blog: sequence of chronological posts that may be assigned to categories, may also include ‘fixed’ pages, often includes comments, trackbacks, RSS feed, most often single author
News: a categorical/hierarchical grouping of content usually ordered chronologically but often ‘curated’ by an editorial team, may also include comments, trackbacks, RSS feed, often multi-author, often requires multiple templates
Events: a combination of content supporting an event, including content about the event, a schedule/calendar of events, list of participants, online registration, may also require online submissions, social networking functionality, news, email update list
Social Site: comprises member profiles and communication between those member in the form of discussion forums, wikis, events, blogs, require member signup, subscription, RSS,
NO. OF USERS
1 : no permissions, no workflow, that user does everything (one stop shop) BUT most like to have simple requirements (how manage giving access to all functionality when the mostly won’t need it). Likely to generate small amounts of content.
2-5 : multiple authors, may require permissions, may require workflow (simple approval process), may require separation between content management tasks and site management tasks but usually not overly complicated requirements.
6-15: multiple authors and editors, likely to require permissions, likely to require workflow, likely to require separation between content management tasks and site management tasks may have some complex requirements, will have significant amount of content generated.
15+ : requires permission management (several permission profiles), probably requires workflow (content review/approval), likely to generate a lot of content to be managed and require content scheduling – it’s a complicated machine and it needs a whole section around managing the machine, let alone making the content to feed the machine. Involves a lot of content and likely complex taxonomy.
question: should it matter how much ‘experience’ you have with Drupal? Should we add another row for this? (Insider/Midsider/Outsider) – we can’t decide. One one level it seems like it does matter, but we also think that it shouldn’t matter… would adding this add unnecessary complexity? (For the time being we’re leaving this out).
PLAY ALONG AT HOME!
This is going to be a pretty instrumental tool for us on this project and we’ll be referring to it regularly. If you’re interested in checking it out in more detail or if you’d like to get more involved in this project, the perhaps you’d like your very own copy. Yes? Well, you’re in luck because you can now download a copy here: Audience Matrix PDF
HOW TO USE THE MATRIX:
Over the coming weeks we’re going to be inviting you to submit your ideas for revisions to the Drupal7 Admin interface and overall user experience. It will be very helpful for us all to use this document to help make sure that we’re designing for the 80% and not necessarily just for ourselves! And it is also a really great way to expose missing elements and possible flaws in our concepts. Using the document to test the example we show in the video above helped us to realise that we needed things like a close button on the dashboard (I know, d’uh!), a place to hold the user generated content from things like comment as well as contact forms, and got us thinking about a whole host of thorny permissions and workflow issues. (Don’t get me started!)
This is, however, a living document – we welcome your feedback and questions on the changes we’ve made and how we’re using it – so, please – let us have it! (but don’t pay too much heed to the concept we’ve presented as an example in the video, it is very early days and it’s just one of many ideas we’re working on.)
My name is Leisa Reichelt. I am the Head of User Research at the Government Digital Service in the Cabinet Office.
I lead a team of great researchers who work in agile, multidisciplinary digital teams to help continuously connect the people who design products with the people who will use them and support experimentation and ongoing learning in product design.
If you're interested in working with me or would like to talk more please email me