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:
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.)