Published

Drupal7UX – The Audience Matrix Evolves (and you can play at home!)

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.

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

Published

54 Comments

Comment navigation

I’ve actually been looking around for another CMS because of Drupal’s current UX, but this is so exciting, I might just stick around for v7. In fact, it seems to me that the direction you’re taking is so revolutionary, that it warrants (at least thinking about) naming the release something other than “Drupal 7.” To community newcomers the new version won’t be anything like the previous versions.

Mostly your approach looks promising. Re. the question of whether to break things down by new/experienced user I would very strongly urge you *not* to go down that road (maybe for organizing your own thoughts but not for anything that’s actually user-facing). It’s a very arbitrary distinction and impossible to know where any person draws the line (even for myself, the line shifts from one day to the next as my thoughts change). It just winds up being extremely confusing because noone (except the absolute beginner) will know where to place themselves on the continuum. And then there’s the problem that some things that look impossible are actually easy in Drupal and some things you’d think would be easy are actually advanced.
We have this problem now in the documentation with the Getting Started and Beyond the Basics handbooks. Both titles are totally misleading and confusing.

As a new comer to Drupal and a native English speaker, I remember the first few times I heard the word Drupal and thinking it sounded like “droopy”. This of course is a simple language difference. However, with my marketing hat on and looking at the future uptake expected from all the great new product features, perhaps it’s time to consider the name Drupal also “going global”? At the risk of sounding highly controversial, how about the name “Drop”?

In general, people mean something different with the role names you provided:

– Your “Site Builder” is most often called “Site Admin” or simply “Administrator”. Has most or all privileges, most likely developed the site. The guy(s) who solve the hard and fundamental issues. “Most” privileges, because even as an admin, you do not always want to have all permissions. To fix the misnomer here, why not simply call the role “Developer”?

– Your “Site Admin” role is more often called “Site Builder”. Given tools like CCK, Views, Panels, etc., they “build” up the site’s structure, creating/managing content-types, taxonomies, managing/positioning blocks, creating/managing users, etc.

– Your “Site Editor” most often is referred to a “Publisher” or simply “Moderator”. Title says it all.

– Your “Content Creator” is usually known as “Editor”. Works with the tools and structure provided by the Site Builder.

Given these titles:

– Developer
– Site Builder
– Moderator
– Editor

I would have said on very first sight: TRUE. (without having to read any description at all)

Personaly I feel the term Community Site a better description of the Social Site. (Or is this more restrictive in meaning?).

In Community Sites we have “Users”, they only create content (most of the time unmoderated), can edit their own content only. They need to know in where to put their contribution best.

Users are best described in your Content Creator type, but not in sun’s Editor function.

On the matter of “experience” with Drupal I would not make a difference. In the first place it is already inherent in the Role definitions, and secondly a good UX would benefit insiders and outsiders alike.

Hey Mark & Leisa, the admin concept is genius!
But, and I’m constantly worrying about how to blend the Drupal administration in a site.
How will your D7 admin concept reduce the amount steps a themer/site_builder has to take to blend the administration in a site design? Or is this question a little too early to ask?

According to me “creating new content type” is a “Site building” activity. Normally content types are defined at the very beginning of the development of the site and are an important part of the content architecture strategy.

Of course a site may evolve and you may have to add new content type, or modify existing content types but I don’t thinks this should be stated as admin tasks. Even if it is a webmaster who does that he would then take the role of a site builder.

At the same level you have “creating new views”. Again it is more of site building that site admin.

Admin tasks should be routine activities that have to be done to ensure operational efficiency.

I wanted to add that, while names are important, it’s much more important to get the right *scope*. Any given name or title will always mean different things to different people. What we want to do is segment the audience in a way that can be explained very briefly (e.g. one sentence). For example “Administrator” might mean different things to different people but “Administrator: the person who does the daily technical and administrative tasks that keep the site running” should give the reader a reasonable idea about scope.

I love this. I’ve been trying to think more about the sites I work on and where they’d fit in. Most of my work is on “brochureware” sites (I’m not in love with the name but have yet to come up with an alternative). Two other indices that I think are worth tracking include size of site/amount of content (I work on some sites with 20 pages, another with 7,000+) and number of page types/content types/content templates.

I would agree with ineation, but not as much with sun. I think your name breakdowns are fine, but as ineation points out some things need to shift from site admin to site builder.

Managing the data model (content types) is a site builder task, not a site admin task. Managing the content organization (eg, adding things to the menu) is a site admin task. Views and Panels, well, I can see going either way. Most of the time they’re a site builder task, I’d say, but there are cases in which a site admin could generate a new view to stick into the menu somewhere. I’d still probably put it under site builder, given my experience with the sites I’ve done.

I am also very much against making “experience” a first-order axis like the three you have no. That would lead very quickly to some variant of an “Advanced” tab on everything, which I find to be one of the dumbest UX models ever; it’s essentially giving up on figuring out how to guide users from novice to expert and just saying “yeah, smart people use this, everyone else just use these few.” That’s not UX design, that’s UX surrender.

After watching the video, something else occured to me. Well, two things actually.

One, there’s another type of user: site member. They really only apply on social sites, but I would make a distinction between “content creator”, which I see as “the people posting news items for the main news feed” and “random person with account”, which is all the thousands of people in the forum. They have different needs and workflows. For them, there *is* no site administration; there’s just the site, be it nodes or comments or whatever they’re doing.

Which leads me to point two, which is that the content editing workflow needs to be very different for each type of user as well. The fancy ajaxy preview tabby edit-in-place stuff you describe is great.. for content creators on limited sites, or possibly on sites with less strict designs that won’t break as easily if handed to a content creator or editor that has no sense of visual design whatsoever (like yours truly).

For random users in the forum, I don’t think it works so well. Sometimes you do want a page reload. It’s not just a matter of hiding some tabs or whatnot. I manage an RPG club site in Drupal. The data model necessitates a somewhat different workflow for content creation (creating/editing characters, creating new posts, etc.), most of it heavily contextual.

Which I suppose is my main concern with this entire project. Let’s be sure we don’t design The Drupal Interface(tm). Let’s design the patterns and tools to support those patterns to make building Drupal-based Interfaces(tm) really really easy, and make doing things in a “best practices way” the path of least resistance (while keeping it straightforward to still do something wacky and off the beaten path). The ease of developing custom administrative workflows is, honestly, what drew me to Drupal instead of Joomla in the first place. :-)

However, with fields in core, CCK UI, Views, Panels, Form builder, SimpleViews, etc. emerging and steadily improving their usability, my point is that we should take the future into account and design for it. Really, there is not much missing to make all of this stuff so grokable that even regular “Site Admins” can understand and work with it.

You no longer need to be a developer to accomplish such tasks, as long as the developer provided you the right tools and a flexible theme.

First, what Larry says re the content creation workflow being different for each type of user absolutely holds true. Within some orgs, you have multiple types of content creators, creating content with very different purposes/audiences. A different UI for these different responsibilities is essential.

Also, re your 4 roles, I’d also recommend adding a 5th: user maintainer, who just has responsibilities over maintaining user accounts. While this role isn’t needed on all sites, it’s a pretty critical piece of community-driven sites.

RE the Site Admin, Site Editor, and Site Maintainer roles, these roles are generally accurate for most sites, but they will nearly always need some adjustment based on the staffing of the company/org that will be using the site. And this is one of the main challenges of creating a more usable Drupal: it actually requires several parallel usability improvements for each role. For the last few years, we have been solving this by grouping admin functionality by the specific roles that align with the staff on the ground in the various orgs who use the sites we build — but, as each org has its own staffing needs, we have been customizing these on a site by site basis.

So, as I see it, a huge usability improvement could be the ability to create (via an intuitive UI) admin panels that group tasks for the Site Maintainer/Site Editor/Site Builder roles.

At the risk of stating the obvious, I haven’t thought this through fully (it’s early here, and I have yet to finish my first cup of coffee). But, one of the biggest usability issues we have needed to address has been how to get people in different admin roles easy access to the pages they need to do their work efficiently. Being able to flexibly group these links could simplify this process, and increase the usability of the site over time.

I was just about to suggest a customisable admin UI… What would be ideal is some kind of developer interface for creating custom admin UI sections/pages.

It should be made possible for the developer to pull in parts of forms and embed them into a custom UI. It should also be easy to filter out parts of forms either by role or user (there is a module called formfilter which works like this but it’s not based on role or user).

Adding content is reasonably easy but the node form is too cluttered for non-technical people. Adding more permissions doesn’t fully solve the issue. If a user has 2 roles and one role contains a permission that overrides the other role then they get access. Obviously this is how it should work from an access point of view so maybe being able to create these custom admin UI pages would be the solution.

I think we are missing the most important role of a User or a Visitor to the website. The experience of a User to the website should be of our highest priority when redesigning the website.

I feel if we make things simpler for a User, they would cascade down and make things easier for other Roles. The UI enhancements for a non-technical user would automatically improve other’s user experience i.e. making forms better when doing things like posting in a message board or posting a comment.

Also, I am not so sure if there is a huge difference between content creator and site editor. They are very similar with just few extra permission for editor. There doesn’t seem to be too much difference in experience for both, with huge overlap.

I’m not sure how this fits into your scheme, but there’s a few “use cases” that IMHO need to be covered. All of these involved a single (somewhat technical) person doing all the “behind the scenes” work of setting up the site, and all of these are non-commercial. For example: a website for a child’s soccer team (role-limited access, image galleries, event listings), a website for a school/family reunion or a wedding (blog, image galleries, forums), etc.

The scenario is also where the single person doing this is probably a volunteer, or doing it as a favor (say for the “happy couple”). They’re probably the group’s resident geek/nerd/techie, but they probably don’t have the time/inclination to learn every last detail about Drupal. This is absolutely not their day-job :-)

These “use cases” don’t seem to fit into any of your site “types”, but if we could make the out-of-the-box experience easier to create sites like these, then I think a lot of “casual” geeks would adopt Drupal…

First off, I really like your approach to the work but I’m not so sure about hard set roles and designing strictly for them. This definitely simplifies the scope of what you have to deal with and it would make it easier for those who fit the roles but Drupal is so many different things to different people. And the tasks involve so much more when you get into contrib modules. I understand your going for the 80% and that’s a nice goal but it may actually be less when considering the whole Drupal ecosystem.

I haven’t thought this through but if it was possible to focus on patterns and allowing a finer granularity of how tasks are presented without throwing out another mess, it should be looked into. For example, for this type of task you get this type of UI and for that, you get another. With all the elements in place, have your tasks for the common roles that make the most sense out of the box but don’t confine it to the prepackaged roles. If there’s time and the effort, allow custom roles and their associated tasks to be imported/exported to be reused and shared.

One thing I’ve always wanted was consistency. An underlying logic where once I learn one part of the system, the rest falls right into place. Kind of related, I think Mark mentioned this about the d.o redesign. How everything is connected. The tiny details informs the whole. That kind of thinking needs to be done for all the administrative elements and how its presented to the user.

Learn once, apply many. A guide for core and contrib to keep everything inline would be great too. It’s a little irritating when when I run into a module with a completely custom ui that doesn’t fit the system. This makes it especially hard to maintain any consistency when theming and it’s jarring for the end user. Maybe it can be prevented if we had a broad enough range of UI elements to satisfy most types of tasks. That might be more of a dream.

Sorry if I’m going ahead of myself. This is a difficult problem to say the least and confining it specific roles and their tasks simplifies it too much to be useful beyond the targets considered here.

I am just joining this discussion, but are we making good defaults for site types, roles and nomenclature or are we “hard coding” these into Drupal. It better be the former and we need to make it clear that these are defaults not set in cement. The great thing about Drupal is it can do anything, but when you first start using it, it’s hard to see how to make it do any of your bidding.

I am all for sensible defaults, installation wizards to make site types, and roles but somehow we also have to make it clear that these are only defaults for common tasks, roles and site types.

I think you are right about keeping out the level of user. I believe strongly that the skill set/knowledge of the user goes alongside of the role they play. Editors you can assume are newer users and admin/creators are really familiar. Even if that isn’t exactly true, the task of editing content should be the easiest and the management functionality should be doable with some understanding.

I think you guys have done a great job of engaging the community and an especially great job trying to bring some clarity to all of this.

experience should be an arc, not a role. The journey from outsider to insider should be smooth, but at an atomic level it affects everything differently. So i think that should be a higher level guiding principle: designing for 80% means: smooth arc.

One way to do that is to make default choices the ‘outsider’ wouldn’t know how to make and put the switches in an advanced tab for the pro.

Here’s a nice example of usability in CMS even though lacking in functionality:http://bit.ly/wyP2M

One of the things that’s a little bit odd in terms of Drupal and usability is that there are lots of defaults that you can change via settings or modules, but the defaults are quite important because a lot of people won’t change them or would rather not have to. One example for instance might be the default registration process and related activities (such as retrieving a forgotten password and uploading a profile photo).

The people experiencing these are likely to be normal users of the site rather than content creaters etc. Watching your video, one of the questions that sprung into my head was to what extent these fell into the scope of your work or whether you were just looking at drupal from the perspective of running a site (in its various guises).

If you are interested in the experience from the perspective of ‘special’ site users, I was wondering too to what extent you were interested in the experience beyond the web interface itself. I get the impression that you’re looking at things like the installation experience, but are you planning to extend this to e.g. installing new modules or setting up a server to install Drupal on in the first place. I don’t know how easy it will be to draw the line here. I presume you’re not going to go as far as looking at the usability of Drupal for module development, but there’s a whole grey area I think.

I wish to add my voice to those saying that you missed a type of site. I think that we are all thinking similarly. There needs to be a type of site where different groups of users see different content.

For instance we have a site that has two primary groups of users. They share access to significant amounts of content. However, there are some cases where one group needs to see one set of content and the other group needs to see a completely different set of content. However, the content is of the same type.

I guess this technically falls under the social site. However, the given definition does not make it clear that this functionality is possible.

I personally have not yet figured out how you are “supposed” to do this despite a fair amount of Drupal experience.

In a Drupal site I’m building there’s also one other user role that’s worth considering: the rep.

These people can publish newsletters (so their own small section of the site to manage), but also view their earnings reports once logged in. They can’t view anyone else’s – these are restricted files.

Now this role falls between site editor and a specialised consumer. Currently Drupal handles the UX for this very badly, and I have to hack around to create the concept of sub-sites in this way.

I have the feeling that the frontiers between roles are blurred in practice. The same can be said about type of sites of course.

For instance:
– The site builder needs to be able to create content types, to manage the IA, etc. during the initial development of the website, without having to resort to the site admin… therefore he regularly achieves site admin key tasks
– Creating content types involves adding new views and writing some PHP, the site admin can therefore do tasks a site builder would normally do

What’s more, I think there should be some way to define these roles on a per content type basis. Don’t you?

Isn’t there some place for a new user profile representing website visitors when user-generated content comes into play (comments, feedback, etc.)? (Note that Drupal already handles this fairly well, but only in the form of “yes/no” user rights)

2 Month ago i first heard of Drupal, right now i am running two completely different sites with it. and i am far from being any web- or coder guy.

I was quite happy with not being forced to remember preset roles and nomenclature.

Think of different concepts and their success: The first Apple-Newton PDA learned your handwriting and translated it quite unsatisfactory to “real” text. Whereas the Palm PDA forced you to learn its special gesture-alphabet. For some people it was a hard time to learn it and some never tried but used the keyboard instead, but when you got through it, the text-translation was much more accurate than Apples.
So decide whether you want the user to learn the drupal setup or make drupal learn the users setups. I personally appreciated the latter.

“question: who can/should be able to create new content types? who can create new site sections and subsections (vocabulary and/or terms) etc.”

A SiteBuilder would be the only one who should be adding new features of any type as they are the one who understands the pre-existing structure and the influence that this will have over the rest of the site.

“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).”

I’m a little uncertain what this question is referring back to. The pride in my wants to say, “absolutely it matters”, but in truth I think it doesn’t if we’re talking about site permissions. If I have a few drupal “insiders” adding content to my site, I still want to maintain control as I’m the one who is responsible for it, not them. They get to add content and they need to be happy with that. They may know enough to do more, but that doesn’t mean that they should do more. Then again, maybe I don’t understand the question. Maybe ask it a different way?

One thing, that in practice will be important is a way to easily draft up the permissions for a new role. I’ve created several sites where I have people that are allowed to add one type of content and another role that adds the other type of content. I don’t want to hand out access to break things that they shouldn’t have access to in the first place. As a sys admin, that’s a basic rule of security. Give the least expected and then add as needed.

Interesting stuff. Just please incorporate the Admin Menu module (or similar) into core. It’s quite indispensable and would work nicely with this matrix idea. In particular, filtering the main list of content should not be the chore it is now. Something AJAX-enabled is clearly called for here.

I think you guys are right on with your concept of user experience/ attributes, although I wouldn’t separate them out too much. One should be able to move between roles of content creator to editor to site builder pretty easily, and thus would need one interface (not one for beginners and one for advanced users).
We need a sort of platform to talk live with other people working to improve our particular site, and it would be excellent if Drupal could provide this platform.

I’m in agreement with ineation – seems like content types should be an inherent part of the creation of the site to begin with, i.e., part of the role of site builder/developer, with continuing input from admins and editors.

In reference to the levels of Drupal experience, it doesn’t seem like there’s a need to differentiate between experience levels – this would only add more complexity to a platform that should thrive on clean, simplistic design and functionality.

Dividing users up into these categories suffers from a couple of problems. First, it presumes to know all the possible users of all sites for which the UX is being designed. I don’t believe that is a knowable quantity for Drupal 7 users. Second is the information architecture product based on those categories. As Jacob Singh and Peter Wolanin pointed out in their DrupalCon DC session “More than search; how ApacheSolr changes the way you build sites,” trying to build menus (hence UI/UX) based on such information architecture will always fall somewhat short. What’s needed are some novel new ways of helping users get to where and what they want on a site. They proposed flexible, powerful search technology, e.g. Apache Solr. I suggest viewing the video and the slides that Peter has posted here: http://acquia.com/blog/apache-solr-changes-way-you-build-sites

Looking at these roles I can relate to them a lot, the roles may overlap a lot in the beginning but especially at larger sites there is a important distinction to be made. Maybe I should be surprised that I didn’t find anything really new.

I always feel you can learn a great deal about understanding the information gap between a beginner and expert, hence why I always call on trainers to work with me on projects. We learned in the usability testing at Baltimore that their is this thing “Drupal Paradigm” where people perceive interactions of Drupal and major contribs as Drupal, not something that’s “extending”drupal – therefor saying insider/midsider/outsider is far less relevant then uncovering what is part of this “Drupal paradigm” ;how these different roles learn about it and how they apply it. Since being an midsider, by no means you understand Drupal it only means you know, you don’t know Drupal and for an insider it might be even more.

What would have been interesting, if you had left out the titles and let us figure out the role from their tasks, because then you will see how the first one would have been caught within a second but the other three would have been discussed endlessly. So why is this? Because without knowing the goal, of what they are trying/have (to) build it is nearly impossible to draw any clear distinction between what they do, also these tasks tend to be dependant on the time frame is it early in the project (then) the following tasks, later in the process a wholedifferent set.

Almost all of the initial experiences of Drupal are related to the roles content creator and site editor, so right of the bat we lose 50% there (I just made that up) so should we go more in depth where it goes wrong there? As when they get over that bump, people seem to really like Drupal with all of its major usability issues

@Crell The goal to eliminate the developer to me still sounds like a very realistic goal, but as you said we need to be able to guide users from novice to expert.

@sun first comment, I think that sun proposes titles that are more fitting to identify the tasks that come with these – Site Admins are usually indeed given far more privileges then just content management related tasks.

Question: Site Admins and up, although creating site sections in a “tagging” environment is a content creator ability.

Type of site
I think this about right, although we are missing Enterprise in the list – that’s “our” fault :). With all of the recent developments I wouldn’t take events as a separate entity, a event site can either be a brochure-ware site or a social site – there is not really an in between.

No. of Users
1 Is the one who does least, but also turns out a lot of times as the one that goes out to learn everything there is on Drupal.

For the 15+ I think the description should be more aimed at developers and less at content management, usually such large sites have content added that is part of this social system of things working together. Complex taxonomy, is a side effect its the working space people are in that is important.

Goals vs. Tasks
I am really interested in your choice, for going after tasks instead of goals. Maybe its an old debate, but to make it more interesting for all of the ixda/ia guys also reading this :) Notably, going after tasks in Drupal for now has resulted in the sitemap interface on /admin (notice the sort on task tab).

Perhaps it would be more helpful if you present this question to two groups of experts: librarians who have professional training in Taxonomy and Drupal Ninjas who know everything about taxonomy module.

It is a great idea to base your project on solid taxonomy implemented in Drupal itself.

I like the “artificial intelligence” model – create an online application (similar to “personality tests”) that ask yes/no questions of someone who’s setting up the user taxonomy for a new site, and based on the answers, churns out the right taxonomy (and permissions set).

On the back end, an open source team looks at how well the AI is functioning by answering questions from projects that have been completed well with good user role differentiation, seeing what gets generated, and tweaking it.

And alongside that is a wiki where people discuss what’s not in the system yet, and how to make fewer better questions.

I haven’t really given an alternative for events, but I think local community websites are what Drupal can be used for a lot. So the local soccer club or school, they tend to be updated quite regularly but have only 1/2 administrators.

Be cautious. Very, very cautious not to design ourselves into a corner. The “type of site” especially raises red flags to me, because Drupal can and is used for a lot more types of sites than we can simply imagine. Also the number of users can be absolutely deceiving — you might have a ton of users and yet a very simple workflow — multi user blog, for example. Or you can have as little as 2-3 users and have an insanely complex workflow (two people need to approve the third’s content before it appears). And guess what? The user roles read fine at first sight but then again, given Drupal’s complexity, it’s very likely to oversimplify.

Of course, you need to put things into bins before you can deal with them but please do not forget that there are a lot, lot more bins.

Here are some of my thoughts after reading this post and watching the clip.

Having developed site in drupal, wordpress and messing around with other CMS like Joomla, one charateristic/feature I like a lot about drupal is that it does not differentiate between a front-end login to a backend login (like wordpress does) and user with more permissions simply can access more links after logging into a drupal site. I hope this simplicity could be retained.

And watching the clip, the dashboard idea is great albeit wordpress-like. From experience, I don’t use much of dashboard feature and only use dashboard for general statistics of the site occasionally. When it comes to administer a site daily, dashboard is an extra layer to get pass to do the daily maintenance, adding new contents, etc. To me, dashboard if present, should allow each user to hide or turn off easily. Or it could be flexible enough to allow for more-detailed customization to have all daily links available right on the dashboard to go directly to do their job of administer content, etc. Having said that, I am not sure how the simplicity of having one login (no front-end, back-end separation) would prevail with the inclusion of a dashboard, or maybe it could? Not sure…

I like the classification of roles, type of site and number of users as these classifications would speed up the process of building a site (with the preset list of steps or tools, etc to building a site) and also it would be more “inviting” for people getting to use and adopt drupal.

For the part about ROLES: with the preset roles, i assumed, it would be great to have a preset roles with the ability of adding one or two more permissions specific to only one or two users. To elaborate, a user can belong to a group and also able to be assigned 1 or 2 more specific permissons not included in that preset role. This would truly make user/group management for drupal more flexible and powerful.

I am excited watching the clip about the hovering boxes / blocks to edit contents as this feature will be very useful when it comes to not so IT savvy user like clients, as they see contents of any page as just that, and the easiest way for them to edit a content is to go to that page and press edit, a hovering box to edit it, simple and sweet!

The question about how much experience someone needs to have with drupal, personally my concept is this. A person is either a left brain dominant or right brain, and learn and adopt easier with icons at first and as that particular person has more experience with drupal, he / she could “turn off” or “hide” those icons, leaving only text links to have more screen estate to get things done faster. Or possibly hide the text and only work with icons only. Conceptually, it is something like the “customise toolbar” UI found in a lot of mac’s application with the ability to Show “Icon Only”, “Icon with Text” or “Text Only” (http://switchtoamac.com/guides/images/finder_customize_toolbar_02.png). So giving user the choice and ability to switch and select the their own style of style using drupal comfortably and conveniently as they progressively develop a mental image of using drupal.

I hope my comment make sense as I am typing it out without giving much thought and also coming from having using a few cmses out there. Can’t wait for drupal 7!

I always add a few extra roles, which more or less map out to the ones already suggested. I think if these roles were to become “pre installed” it might make it easier for developers to set the correct permissions if module developers included suggested permissions for each role. I spend too long trying to understand the consequences of giving or not giving a role a certain priveledge.
Few years back I used Mambo/Joomla whichhad 7 or 8 preset roles, but it was hard as I often had to give certian users more priveledges than they needed in order for them to do one task which was important (unlocking edited pages where the session had been lost) resulting in way to many choices for them to navigate, I like how with Drupal the permissions are so granular, but a bit of help from module developers would be handy.

Also sometimes I’m glad I’m not going to actually be administrating the sites I’m tasked with building.While adding test data/users etc I find it frustrating that to see information about something I have to open/edit it, more table like views of users (or option for more detail) would be handy, sometimes the quickest way to get an overview of something is look in the DB using MySQLGUI tools or PHPMyAdmin, not really an option for the final users/administrators.

I have never built or used a site that conformed to any of the matrix’s narrow (taxonomically, not value-judgementally) site types, except maybe brochureware sites, which I hated to go to but needed something from the repository of data they held.

I think that you are using site type to refer to content type. Site type, to me, connotes how the content types are organised and interact with one-another, where a brochureware-type site is product centric and generally one way and a community-type site is many-way.

Here is a real use case that I am supporting now, though it is not ideally realized in the website ATM:

Agricultural Service Site, supporting a paid membership and public site viewers as well. They have:

1. static pages (rules and regs, docs on how to do whatever, descriptions of programs) which are either pages or articles.

3. scheduled events, both cyclical and singular, in several categories such as meetings, seminars, excursions and comment/voting periods. Some of these require registration, all require gridding on a calendar.

6. Important announcements that folks who go to the site need to notice.

Some of the above are available only to site members. Membership is moderated against paid group membership.

Anybody can write for the site (though few actually do), only some folks can publish (meaning ‘allow site visitors to view, interact’ with items).

It is clear to me that many content types only differ slightly. blog differs from article only in frequency and presentation ordering, calender events are merely articles with extra date information, I cannot even really tell much difference between pages (static) and articles except for how they are presented.

@brandon The matrix helps identify different needs and tasks for different kinds of sites, but I don’t think we have to limit the scope and think of it as describing an entire site exclusively. The site you described sounds like a combination of several “sites” but we might call those features, or sections, or aspects, or whatever. The point is figuring out what Drupal users do to build their sites.

Also, I’ve built some multi-faceted sites in Drupal like the one you described. Each “section” you described might require very different tasks and modules, but they’d also involve doing a lot of very similar, repetitive things: creating content-types, configuring CCK fields, setting-up views, etc.

I believe one of the major strengths of Drupal is it’s enormous flexibility allowing to implement so many different web applications, workflows, and solutions for an apparently unlimited variety of use cases – including the web site types you list in your matrix. Yes, there are different roles in any web site (or application), and they all depend on the use case that you are trying to solve. You do list some of them – for some use cases. The same is true for different activities.

If the aim of this exercise to come up with a list of selected use cases and out-of-the-box Drupal implementations fulfilling those needs, I’m all for it. Especially if it helps promoting Drupal to more users.

If the matrix helps identifying the most relevant micro tasks in a website (like adding, editing or deleting content), that’s also great – especially if it results in improved UIs. Although I must admit that tasks like editing content deserve well done UIs regardless of the site type or size or user role.

If concentrating on this (limited) set of use cases yields to limiting choices in the functionality and internal design of Drupal, though, I’d be worried that the flexibility of the framework might be sacrificed in favor of the masses. Or the 80%.

This is more than just not standing in the way of developers. Doesn’t (software) design follow function? You shouldn’t limit your imagination to just a few use cases (or web site types, workflows,…) then.

I agree with the various comments about users having an arc of experience. Some users grow to be administrators of their own sites based on what they encounter as missing in purpose from another site. That means quite often there is an inexperienced administrator at the helm.

I’ve been jumping through site after site at ning.com, and some at collectivex.com also. These “massive community sites” leverage your base of community as you move from site to site. Making it extremely easy to grow your community as you move from one to another.

OpenID I thought had similar promise, but I’m not seeing it. If there was an easy way to establish community that would span Drupal sites it would be amazing. Perhaps this is more of a module, but if core had the ability to tap massive community as a selectable option that would be awesome. Enable people to use OpenID to bring their contacts with them onto a site.

Furthermore if the base of knowing your massive community included the experience level of its members as administrators, editors, … that would encourage growth of community sites based on who you know and what you know about them. Do this at the core and you’ve snagged the market ning.com hasn’t quite reached.

This means your OpenID community having additional information about roles in the massive community. Perhaps as easy as tally the number of builder, admin, editor, user sites and possibly allow weight by size.

I was on CeBIT this year, and showed Drupal to a person who was not so techy and not so knowledgable about CMSes. When I showed him our forms, he showed me a nice little Ajax tool you can use on any html site.

It gives you a Adobe-like Toolbox on the right and makes all content elements editable inline. A pain I cannot find it anymore. Concrete5 uses pretty much the same approach for content editing you sketch.

This is very intuitive for the user and it is clearly the future.

Been wanting to make a demo video of it. Now that you already showed the concept, I won’t be able to surprise anyone anymore :), but I think I still will. Got some ideas how to make this play with CCK content types with a lot of fields.

Thing is – we don’t need to change the technical basis in drupal, because it’s brilliant. No – it is ‘just’ the way we present it to the user. Witch Ajax you can implement most anything, and you don’t even have to invent much, because there are enough systems out there that do exactly this and we can draw from.

In my humble opinion the best way to make user interface flexible, simple easy and intuitive is make “something” like Office ribbons or “widgets stripe”. Of course some users love it others not so this functionality should be optional.
What I meen under “something like Office ribbons”. This could be graphical interface menu (for example in stripe) with large, legible icons represents basic user/administrator tasks. Tasks related to current work.

Ten icons to related tasks, different for each section or subsection of Drupal is much more legible then large menu with hundreds of options.
Additional advantage could be option of personalize this menus by adding or removing icons according to our needs.

Simple way to realize this. Each section or even subsection of Drupal interface have icon and tags described this section. When you do something in menu you get 5-10 icons related to current site by tags. If you mind some icons to important you can add one and save menu configuration for this view.

Add icon could be made by simple text-input field where we write word (for example “user”) and get icons of sections related with this word, then could add one or more icons to current menu.

Roles; Site visitor & Site member, the lower end of Drupal’s users. We primarily need to make it easy for the site Builders to make it easy for these roles, however the default should be generic and easy anyway.

Sites; Ecommerce sites are not covered by the ones you have, and are an important part. Project management sites are also not covered well by the ones you have listed, and I think these are common too (though perhaps just because of the niche I work in?).

These are different to social sites in that they are tailored to focus users energy on managing several aspects of multiple different projects that are core to the website owner’s mission. So while they have a lot of user:user interaction and collaboration, they are not primarily there to enable social interactions or sharing of content (like social sites).

My current use case is a staff intranet. For this site I am setting up several new roles besides the Drupal defaults. To me these roles have separate needs within the Drupal admin UI:

administrator (Drupal default) sitewide admin. This is the only one who has to see all Drupal admin. Also responsible for installing and updating Drupal itself. (I agree with your breaking this out into two similar but distinct audience members. The site admin may not always be the Drupal admin aka site builder; someone with massive sitewide privileges over content and structure of the site may not be the one who should be seeing those red UPDATE ME NOW messages on every Administer page.)

sitewide editor – has many permissions but not burdened with seeing all admin options. Can adjust permissions for other users. Can approve content as well as perhaps make theme adjustments (?)

section editor – has a similar level of power as the sitewide editor but limited to a single area of the site. (How, I’m not sure yet! That’s my big usability issue with Drupal right now — figuring out how to make role permissions apply at levels of granularity other than “own” content and sitewide content. This is probably perfectly doable, just haven’t learned how yet. I don’t know if my experience indicates a need for Drupal out-of-the-box to support more of this granularity of permissions. Putting this in core could be a terrible idea! But I would argue that in practice a section editor role is just as separate from site editor as the site admin is from the site builder.)

I’d like to add two things I think are important to note with this user model, thinking from the perspective of a web-designer creating a site for a client.

* I would, I guess, be site builder. It’s not only important that the back-end provides me with as many options as possible, but also that it allows me to tweak the admin interface for the actual users; the admins, site editors and content creators. I can of course start with your predefined admin interfaces for these roles (which is a lot more than we have now, so great stuff already), but I’ll also know a lot about my client’s specific needs and abilities, so it would be great if I could start with the roles you’ve laid out here, and tweak them to fit my client perfectly. That versatility is, after all, one of the greatest assets of Drupal.

* The only reason I build brochureware websites in Drupal is that I expect websites to want to grow. It would be a lot less work to build it in a simpler CMS, but I want the client to come back to me with ideas for adding a blog to the website. Or maybe a wiki, or an event calendar. Drupal allows them to explore that possibility by themselves (they have access to the full admin interface, and maybe a private testing website to experiment with), and when they need to polish the modules they’ve installed by themselves, they come to me.

So what I’m saying is, that besides looking at these classes of websites, you really need to look at the transitions between them. What if brochureware website wants to add a blog? What if the director wants some interns to start writing content? Maybe they want to start letting users register and slowly grow into a social site. All these transitions should be as seamless as possible

I think that if you really nail these two issues, then Drupal will be the perfect CMS for web developers, since it allows websites to grow smoothly, all the way from a simple brochureware website to a full-blown social networking site, or a company portal with a complicated editorial workflow.

I can’t think of any CMS that lets you grow that far and still keeps it as simple as it possibly can be for the smallest websites.