People have asked about who will see the proposed D7UX Admin header. I wanted to take a moment to talk about that and about Drupal default ‘roles’ and get your thoughts.

For those who aren’t familiar with Drupal here’s a quick overview that I copied from a Drupal 6 installation:

Roles allow you to fine tune the security and administration of Drupal. A role defines a group of users that have certain privileges as defined in user permissions. Examples of roles include: anonymous user, authenticated user, moderator, administrator and so on. ….

By default, Drupal comes with two user roles:

* Anonymous user: this role is used for users that don’t have a user account or that are not authenticated.
* Authenticated user: this role is automatically granted to all logged in users.

Clearly, to begin with, we’d be proposing that the Admin header is shown only authenticated users – that’s obvious enough!

I’d now like to introduce another concept that seems natural to me and to many others that I’ve spoken to about this (although perhaps not so much to experienced Drupal users) and that is a default differentiation between ‘Member’ and ‘Admin’.

The idea being that the Member role or roles based on the Member default are for people who have ‘signed up to’ or ‘registered with’ the website (as a member) in order to participate more fully either by creating content (submitting a session idea for a conference, a discussion post to a forum, that kind of thing). The Admin role and roles based on the Admin default are for users who have a closer association with the website – the website ‘owners’ or ‘managers’, the people to whom we’re happy to show the ‘underwear’ of the website. Admins would see the Admin Header but Members would see their tools and admin menu in the page context.

Now, of course there are many, many variations on roles that need to be created and sometimes the differentiation between whether or not a role should be a ‘member’ or an ‘admin’ is not clear. I think there is an inherent guide in the name ‘member’ that should be helpful – a member has a particular kind of relationship to a site and there are kinds of content and functionality that is less appropriate to a ‘member’ and more appropriate to an ‘admin’. There is sufficient flexibility in the system that means you can make a call whichever way you think is appropriate to your particular scenario, and to change your mind later if you like!

This is not dramatically different to the way that many Drupal sites work already and almost all of the infrastructure required already exists and just needs a little spit and polish. No architectural changes are required to achieve this – it is really a tiny and superficial, but from a user experience perspective I think this will make a significant difference in helping people understand Drupal roles and how to best implement them.

What do you think? Any questions?

People Index Page
Larger image here

People/Events Index page
Larger image here

Description: Any large lists of people are managed in this section, including site administrators, site members (authenticated users), event attendees and group memembers.

Current thinking/roadmap:

• Shows lists of people divided into tabs like Admin (site admins), Members (authenticated users), Events (event attendees), Groups (group members) etc.
• Management tools for each type of ‘person’ is shown in their corresponding tab. For example ‘roles’ would be shown with Admins, ‘Broadcast’ tools would be shown with Event Attendees etc.
• Uses same visual language as Find Content table

Note that roles, permissions and user settings will be migrated into the Modules & Configuration section of the site so that this section is focussed on ‘everyday’ usage and Modules & Configuration will hold the less frequently accessed functionality.

Aggregated Feed (Pipe) of Related Discussions

Please feel free to add your thoughts as comments below or if you’d rather publish them elsewhere you can have them the pipe by using this tag #d7ux_7_0

go back to Project Framework to view all project components