Archives

Roles & The Admin Header

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.

31 thoughts on “Roles & The Admin Header”

Yes this is a troubling issue with the admin menu going mainstream Drupal Core. What about our members? How does that “in context” stuff happen?

Here’s the linchpin: “Admins would see the Admin Header but Members would see their tools and admin menu in the page context.”

What I want to see is a visual example of how “in the page context” works. The pop up is awesome because it removes “Drupal” from the theme, but when we put it back into “context” how does it work visually?

overlay Josh, not popup! 🙂 (not modal either, for that matter… I am going to have to write a blog post about that soon, I think 🙂 )

no, definitely not.

the ‘overlay’ treatment is very much an ‘admin’ thing. I would envisage that all of the ‘member’ add content tasks would be as conventional as possible and, as such, adding content would be very much ‘in page’ just as you’ve experienced here (although much better than this add comment interface which, I agree with your previous comments, is pretty rubbish)

Why do you want to have two different user interfaces for creating content? And why do you want to couple them to the admin role? I’d have thought that:

Either the new (overlay) interface is a usability improvement for both beginners and experienced content creators, and then we want it for all users.

Or: It’s a usability improvement only for experienced content creators. But then it should be a separate permission, not coupled to the admin role/permission. (You might have authors who create a lot of content but don’t have any admin powers, and admins who spend most of the time administering the site, and very seldom create content.)

exactly, we’re working how it will work visually that at the moment, stay tuned!

Having said that, we know that we will need to create a non-overlay version of all the work that we’ve been doing to date – for accessibility/no JavaScript/other themes etc. and that will involve the forms/lists being shown in the page rather than in an overlay – I don’t think it’s going to be a major departure from the Drupal we know and love today (as mentioned in the post, more of a spit and polish), we just need to work through all the scenarios and make sure we have them covered.

One thing that struck me immediately is that I don’t like the terminology “member”. I run a website for a club, but anyone is allowed to create an account on the site. Club members just get a few more privileges, hence they get their own user group/role. Having a group/role named “Members” as well as another group (that I suppose would have to be “Club members”, then) would be thoroughly confusing. I can imagine many more scenario’s like this, basically for any kind of organization that has an “off-line” concept of members.

I have seen “Registered users” be used as a group name, which I like. The current default, “Authenticated users” is OK too, although I think that might be not as clear to the non-techy (I suppose that from a technical standpoint, “Authenticated user” is more accurate, because a person could be registered – or a “member”, for that matter – , but as long as they’re not logged in/authenticated, they would still show up as an anonymous user).

So the idea here seems to be that when you create a role, you designate it as ‘member’ or ‘admin’. Admin roles get the admin header, and member roles don’t.

This seems OK but I’ve got a few questions as usual…

1. Drupal usually uses a permission for access to things rather than roles themselves – i.e. it’s very easy to add a permission which says ‘use admin header’ and show it based on that. If that’s the only thing that’s going to be based on this distinction, then I’m not sure it needs to be more than a permission. (similarly inline editing).

2. There’s a module in contrib called ‘admin_role’ – which lets you define a role as administrative, and when new modules are installed, automatically enable permissions for it (it’s very possible to have permissions in Drupal to enable a module, but then not to configure it, unless you go and give yourself the permission). There’s a couple of stalled core patches which try to introduce this to core, and it’s one of the most annoying workflow issues when configuring a site. Having ‘administrative’ roles which don’t have this kind of auto-permission creation apart from the admin header might make that harder to do. Even if permissions move to inline on the module form, I still don’t want to have to click checkboxes and save before I can do any configuration.

2. It’s very common on Drupal sites for a user to have multiple roles, one site I’ve been running since 4.5 has these:

However all the admins on that site are also contributors and editors. And all the editors are also contributors. Because permissions are cumulative across roles, this is a common set up to avoid clicking lots of checkboxes. Presumably the header would get shown to editors and admins, even though they were also ‘members’ – but it’s important to remember that roles at the moment just means ‘collection of permissions’ rather than ‘type of user’.

Is this a new categorization of roles – some roles are for members, some for admins?

Or is it a new member role and a new admin role? I just realised I’m not clear on this given the above comments and it’s a very important distinction.

I also agree on the word ‘member’ – a lot of existing sites will have roles set up as ‘member’ – and many thousands will have a role called ‘admin’ – so adding these labels could be tricky in that context – an admin admin role, and an admin editor role, and a member member role?

Actually, that’s a good point… Why is the ability to view the admin bar so inevitably tied to the roles that are available by default? Is this not “just another permission”? A permission that you wouldn’t give to just any user, and hence should not be given to “authenticated users”. Should the situation still be as in D6, that would land the admin bar with the #1 user, exclusively, out of the box. Just like any other number of “not-for-the-average-user” permissions are, right now.

Don’t get me wrong, I think it’s a good idea to flesh out the default roles a bit, maybe add roles like contributor (who is able to submit content) and administrator (who gets most, but maybe not all administrative permissions). I just don’t see why that is being tied so strictly to the admin bar.

Like everything else, this needs to be a simple "access administration header" permission. There are plenty of use-cases for Drupal, and you never know whether someone might want to grant "access administration pages" (i.e. all pages below and starting with the path /admin), but still do not grant access to that administration header bar.

I agree that it should be a simple permission instead of an additional role.

However, that is the easy part. The bigger issue I have is the (potential) duplication of functionality. It might require us to build two UIs to do the same thing, for example, one add event form accessible from the administration header, and one add event form accessible to regular users from the site. It would also require more documentation, more tests, more theming, etc. We can probably solve that reasonably elegant, but it is something to keep in mind.

The words being used for the default user roles in Drupal is a great example of how and why Drupal is unfriendly to “non-geek” people.

“Authenticated User” and “Anonymous User”? The words authenticated and anonymous are complicated words that require the non-geek to stop and think before knowing what they mean. And that moment that is required to stop and think before knowing — that moment is bad.

I’m sure most Drupal geeks will object this idea, saying “it’s not that hard!” … and yes, you are right. Understanding the word “authenticated” is not that hard. But is it not easy. You have to stop and think. And guess. And perhaps be wrong. That moment creates a seed.

And that seed of doubt is exactly the thing that makes many people think, “oh, this Drupal-thingy is not really for me. I have to guess if what I am doing is going to count for authenticated or anonymous or wha? Is this right? I don’t know. I guess maybe. This program is really not meant for me. It’s meant for people who are good at computers.”

WordPress, for example, doesn’t use words that alienate “I’m-not-good-at-computers” people. Subscriber, Contributor, Author, Editor, Administrator. These are very easy words for anyone to understand. They create a sense of expectation in newbies, a pretty-good-if-not-totally-right idea of what these roles are going to do. Later, as someone masters WordPress, they begin to memorize exactly what the roles mean.

[Now, I KNOW WP is different than Drupal. In WP you basically get those 5 roles and are stuck with them. You can add functionality via plugins to get more power to define the roles… but honestly, Drupal’s way of doing it is much better. The developers of a Drupal site can create any roles they want, with any names they want. And give those roles any powers they want. I know. And I like Drupal better for it. But I still want you to hear my point… ]

The default is alienating. Because of the choice of words. The words were chosen by computer geeks, for computer geeks. And those same geeks are now asking, why do people think our software is only meant for geeks? We want more-non-geeks to use it!

Well, here’s a perfect example of why people get scared by Drupal and feel like it’s not for them. Words like these. “Authenticated User.” “Anonymous User.”

Let’s change these words. To things like “Member.”

“Member” might not be the perfect choice. But it’s an easy word. Anyone can and will guess what that means. Let’s not be totally geeky and insist that the default words be exactly perfectly precise. Choosing friend words instead of technically-precise words, will go a long way in getting more people to use Drupal.

I just opened http://drupal.org/node/479708 to rename ‘authenticated user’ to ‘logged-in user’ and ‘anonymous user’ to visitor. But 5 minutes later I saw David Rothstein’s patch to remove these hard coded roles altogether http://drupal.org/node/468768 – which would really let you have proper division between logged-in and logged-out without messing about with roles vs. states.

Just to take one step further (being a Drupal newbie myself, I think there is a lot of sense in what Jen Simmons is saying), the “other” software, which I took inspiration from when suggesting “Registered users”, uses the term “Guests” for what Drupal calls “Anonymous users”.

One of our guiding UX design principles for this project is ‘Provide Smart Defaults’.

A ‘member’ of a site is a user who, yes, has limited permissions. Who can add content, but in-site, not with the header – as that is for ‘admins’. This is designed to answer another one of our UX principles: ‘An admin should be an admin, and a site be a site. I should know where I am’.

Now, of course this could be a simple permissions thing. An ‘admin’ could choose to turn on the header for ‘members’ if they so desire. We know Drupal can do many things for many people, but what we’re aiming to do is provide *Smart Defaults*. Wherever possible, those smart defaults should be written and presented in a language that makes sense to real people – to the Jeremy’s of the world. I’d argue that people *get* what a member is in the context of their usage. If they’re in a forum, wiki, whatever. If they’re in an events site, then maybe ‘member’ would be renamed to ‘delegate’.

So, what we’re suggesting here are the defaults. Hopefully the smart defaults. Of course, they could be built upon, changes, added to. But member/admin is an important distinction to make and am important problem to solve.

We currently give a few permissions by default to ‘authenticated users’ but don’t have any real roles in core (anon and auth are hard coded special cases).

Seems like whether an extra member/admin layer above the roles themselves is needed or not, we definitely need to add a third, administrative, role to core to make this work – that role could be given the admin header permission by default. Auth users or members wouldn’t. Any kind of role categorisation over and above that is still going to require an extra role to put in the admin category in the first place.

As linked to by Catch above, while the menu should be tied to a permission and not a role, in order to provide sensible defaults we will need to create an administrator role for core to attach that permission to.

Would it make sense for the permissions hook to be expanded to be able to suggest permissions be associated with certain types of roles? As is, when installing a new module, a user has to go back to the permissions page and figure out what they need to set. If when a module is enabled, it could be set up so that you could go through your roles and see what permissions are recommended by the author for what classes of users, then it would be much easier to have sane defaults. Theoretically, a site manager wouldn’t have to deal with individual permissions at all – they could just say “assign recommended admin permissions to x roles, member permissions to y roles, and visitor permissions to z roles” for each new module.

I’m not a hardcore developer, but drupal’s become my favorite platform to work with, and I’ve built a number of sites with it. I’d be a pretty good “middle-of-the-road” person when it comes to experience and ability.

So for someone in my context, I’d vote for a third default role of an admin. I don’t have any brainstorms for better terminology, but guest, registered, admin are the 3 roles I’d like to see as default. Every site I build I create this as one of the first steps, since I’ll be a full admin and need a separate role for registered users.

(As an aside, on catch’s comment: “(it’s very possible to have permissions in Drupal to enable a module, but then not to configure it, unless you go and give yourself the permission”…yes and yes! This annoys me to no end when installing and configuring modules. If I have permission to install, I should have permission to immediately configure. This is especially true when field-level permissions are enabled – having to go give myself permission to access every field I just created is tedious at best.

Now, I must confess I’m not sure of an elegant solution at this point – the Admin Role module helps, as does just having my account be user-1 (bad Michael, I know! But it speeds up the admin workflow so much).

Oh, and the same is true of running updates…if I’m a full admin, but not user-1, I can enable and configure a module, but then I need to switch to user-1 to run update.php when I update modules. Why is that? Could access to update.php also be a permission that user-1 can set?

ok. I’ve talked at length with Catch and Yoroy in IRC about this today. I think we’re a little clearer about what the point of this is and how it might work. Catch has even created an issue for the queue that you can review here:http://drupal.org/node/480660

As Mark and Jen and others have noted above, this is all about trying to take the decision-making out of creating roles for people who are newer to Drupal and who don’t understand the intricacies of how this all works (and it is pretty confusing, you have to concede).

So, I’m agreeing with Catch that the ‘member’ role I was proposing actually already exists, it’s the ‘Omnipotent God Of This Website’ Admin role that doesn’t exist (as a role you can share with others at any rate) and which needs to be created.

After all this, I still have no clear idea what a “member” does. Frankly I think it’s a terrible term.

A “member” on most of the sites I go to is someone who can post comments or suggest stories. It’s not someone who can actually edit stories or maintain content in any meaningful way. It’s not a very powerful role at all.

What I hear you describing is what I’ve termed a “Site Editor” or “Site Maintainer”: Someone who can publish new pages, add to the navigation, read webform submissions, add and adjust blocks, and do a few other important things. This is, for me, the most important role to be able to create, and right now, it’s a damned hard role to create — and not for any terminological reason, but because there are a lot of things that aren’t controllable at a fine-grained enough level to strike the balance between power and safety that is really needed for such a role.

I really do think that additional roles beyond anon and auth user are best left to installation profiles, and not added to core.