Mark Boulton

Leisa and I have spent a good deal of time look­ing at how we can define the audi­ence for Drupal 7. A couple of weeks ago, we spent a day try­ing to come up with an effect­ive model to use through­out the design pro­cess. Not just a model that we could use, but one that could be avail­able to the whole Drupal com­munity as we embark on the chal­len­ging task of look­ing at the user exper­i­ence for Drupal 7. 

The Flappy Paddle

Before I start to talk about this tool, it’s prob­ably bet­ter if you just watch this video Leisa and I recor­ded a week or so ago. 

This is the tool we’re using, but at this stage, it was pretty rough around the edges. So, we’ve spent a little more time defin­ing the vari­ous tasks and defin­i­tions for each dif­fer­ent user type, site type, and num­ber of users. Com­bin­ing this detail, in vari­ous dif­fer­ent com­bin­a­tions, gives us a list of require­ments for that type of user, using a par­tic­u­lar type of site, with a cer­tain amount of users. 

Sweat­ing the details

Yes­ter­day, we spent some time flesh­ing out the vari­ous tasks and defin­i­tions for each ‘paddle’. 

This is what we’ve come up with so far: 

Roles

• Con­tent Cre­ator: a user who primar­ily cre­ates, reviews, and edits con­tent for a site. Key tasks: Add con­tent, edit con­tent, find exist­ing con­tent, view list of con­tent creation/revision tasks.
• Site Editor: a user who has author­ity to approve, edit or reject con­tent and who may be able to man­age some edit­or­ial work­flow and user per­mis­sions. Key tasks: Add con­tent, edit con­tent, find exist­ing con­tent, view list of con­tent creation/revision tasks, review con­tent, reject/feedback on con­tent to ori­ginal author, sched­ule content
• Site Admin: man­age user per­mis­sions, man­age site struc­ture, adding new con­tent types, cre­ate and review reports and man­age some site set­tings (RSS Pub­lish­ing, IP Address Block­ing). Key tasks: Man­age user per­mis­sions, Add / Edit / Delete Con­tent Types, Man­age Inform­a­tion Archi­tec­ture (site sec­tions, sub-sections, tax­onomy (as in, vocab­u­lary), Cre­ate a report, Review a report.
• Site Builder: cre­ates site from scratch by choos­ing, writ­ing, cus­tom­ising mod­ules and/or themes, man­ages setup and main­ten­ance. Is a developer (for the pur­poses of audi­ence defin­i­tion, themers are con­sidered developers). Key Tasks: Develop site func­tion­al­ity, imple­ment site design.

Type of site

• Bro­chure­ware Site: hier­arch­ical struc­ture of rel­at­ively static con­tent, often includes forms (eg. contact/feedback), may be multi-author
• Blog: sequence of chro­no­lo­gical posts that may be assigned to cat­egor­ies, may also include ‘fixed’ pages, often includes com­ments, track­backs, RSS feed, most often single author
• News: a categorical/hierarchical group­ing of con­tent usu­ally ordered chro­no­lo­gic­ally but often ‘cur­ated’ by an edit­or­ial team, may also include com­ments, track­backs, RSS feed, often multi-author, often requires mul­tiple templates
• Events: a com­bin­a­tion of con­tent sup­port­ing an event, includ­ing con­tent about the event, a schedule/calendar of events, list of par­ti­cipants, online regis­tra­tion, may also require online sub­mis­sions, social net­work­ing func­tion­al­ity, news, email update list
• Social Site: com­prises mem­ber pro­files and com­mu­nic­a­tion between those mem­ber in the form of dis­cus­sion for­ums, wikis, events, blogs, require mem­ber signup, sub­scrip­tion, RSS,

No. of users

• 1: no per­mis­sions, no work­flow, that user does everything (one stop shop) BUT most like to have simple require­ments (how man­age giv­ing access to all func­tion­al­ity when the mostly won’t need it). Likely to gen­er­ate small amounts of content.
• 2–5 : mul­tiple authors, may require per­mis­sions, may require work­flow (simple approval pro­cess), may require sep­ar­a­tion between con­tent man­age­ment tasks and site man­age­ment tasks but usu­ally not overly com­plic­ated requirements.
• 6–15: mul­tiple authors and edit­ors, likely to require per­mis­sions, likely to require work­flow, likely to require sep­ar­a­tion between con­tent man­age­ment tasks and site man­age­ment tasks may have some com­plex require­ments, will have sig­ni­fic­ant amount of con­tent generated.
• 15+ : requires per­mis­sion man­age­ment (sev­eral per­mis­sion pro­files), prob­ably requires work­flow (con­tent review/approval), likely to gen­er­ate a lot of con­tent to be man­aged and require con­tent schedul­ing — it’s a com­plic­ated machine and it needs a whole sec­tion around man­aging the machine, let alone mak­ing the con­tent to feed the machine. Involves a lot of con­tent and likely com­plex taxonomy.

And also, as you saw in the video, we’ve looked at using this tool now as we begin sketch­ing out some ideas and con­cepts for how the admin may work. 

An evolving concept

The Audi­ence Mat­rix is work in pro­gress and it’s going to be an instru­mental tool for us in the com­ing months as we start flesh­ing out some of the design con­cepts. As Leisa says on her blog: 

Over the com­ing weeks we’re going to be invit­ing you to sub­mit your ideas for revi­sions to the Drupal7 Admin inter­face and over­all user exper­i­ence. It will be very help­ful for us all to use this doc­u­ment to help make sure that we’re design­ing for the 80% and not neces­sar­ily just for ourselves! And it is also a really great way to expose miss­ing ele­ments and pos­sible flaws in our con­cepts. Using the doc­u­ment to test the example we show in the video above helped us to real­ise that we needed things like a close but­ton on the dash­board (I know, d’uh!), a place to hold the user gen­er­ated con­tent from things like com­ment as well as con­tact forms, and got us think­ing about a whole host of thorny per­mis­sions and work­flow issues.

We need your help. We’ve pro­duced a PDF for you to down­load so you can use it in some of the upcom­ing crowd­sourcing activ­it­ies we have planned. (like the one’s we did for the Drupal.org redesign project).

There will be more from me

It’s a fair cop. I’ve not been as act­ive blog­ging about this stuff as I could have been. Both the Drupal.org redesign, and now the Drupal 7 UX work, are both break­ing ground on a pro­cess thought to be dif­fi­cult, if not impossible. So, as of today, I’m going to be talk­ing about it all a hell of lot more because, well, what other pro­jects can you talk about as you’re doing it? We’re in an incred­ibly for­tu­nate position.