Roles are quite hidden at the moment

Use "patch -up" (unified) when creating patches.

Also, please submit a patch without the unrelated changes (bootstrap.inc and system.module changes)

Totally agree. Not sure if it's too late to change this for D7.
In any case, let's get the bot to test it.

I agree wholeheartedly. The tiny little roles button was a major usability WTF for me too.

The patch works as advertised.

The weight setting below however should probably just be deleted and not commented out:

@@ -1607,7 +1601,7 @@
     'access arguments' => array('administer permissions'),
     'file' => 'user.admin.inc',
     'type' => MENU_LOCAL_TASK,
-    'weight' => -5,
+/*     'weight' => -5, */
   );
   $items['admin/people/permissions/roles/edit/%user_role'] = array(
     'title' => 'Edit role',

This seems like a reasonable improvement. Patch looks good and works as expected.

This patch makes roles into a separate tab. I haven't changed all paths. The main path is now admin/people/roles, but editing is still admin/people/permissions/roles/edit, and should probably be changed as well.

This still stands. This can't be done halfway.

And it's still debatable whether this is 7.x or 8.x

This needs sign-off from the UX team. I could go either way here. Permissions and Roles are coupled together pretty well, but on the other hand roles are something you generally set up once and only go back once in awhile to tweak; analogous to any other module settings page which we put under /config now (and don't bother cluttering the "frequently accessed" UI for). Permissions, on the other hand, you tweak almost constantly during site building and beyond, each time you enable a module, each time you fiddle with content types, etc. so it makes sense to make it a lot easier to get to.

One possible alternative is the use of action links on the perms page to link the roles page more closely.

Oops. Cross-posted.

And agreed about being debatable between 7.x and 8.x, but it comes up often enough as a complaint that it might be worth considering for this release, despite the UX freeze breakage. UX team's call.

This change impacts http://drupal.org/node/120614/ which I am working on now. Tagging Needs Documentation

I'm happy to hear that this is considered for 7.x
Removing a level is a good idea, and I can roll another patch if the UX guys approve it.

Let's get Bojhan's opinion.

This is not for consideration in Drupal 7, we took a clear decision bringing the permission tab to here - considering the prominence. That your weight to this prominence is different from ours, is too bad. Permissions are clearly the parents of roles, in terms of concept - permissions is what you look for, not roles (so encountering it here, is not weird at all).

As webchick outlined, in Drupal 7 there is a new concept of "not everything is equally important" hence we don't have a big ass list of links anymore, this
also counts for tabs. Sadly we cannot add more visual clarity to the 3rd level tabs, we already did that numerous times - lets figure that out better in D8.

berenddeboer: Sure there are cases where its a prominent feature, however in most cases its something you configure once kind of functionality, which you revisit only very rarely.

FWIW - I find it really annoying having to load the entire permissions form just to be able to get to Roles. It's a major PITA when working with sites that has alot of roles, which make the form take a while to load.

I definitely think the after mockup is much more intuitive. It took me way, way too long to find the roles tab in D7 (and I have been using Drupal for 5 years). I do not agree that it is logically a child of module permissions. Roles can also control node access grants, for example, entirely independent of module permissions. (Or, put otherwise, roles are properties of people, not of module permissions.) I also agree with blackdog that having to navigate through the huge, slow permissions page to get to roles is frustrating even after you know where to look.

The "after" screenshot seems like an improvement to me also. Drupal very consciously keeps roles and permissions as separate concepts (even in Drupal core, block visibility is done via roles but has nothing to do with permissions) so I don't think it's good for the user interface to blur these concepts like it currently does.

But, we don't have to make this decision based on opinions. We can do it with data. I think the next step for this issue is to write up a very short usability test script that addresses the question; then once that's ready a few people spend 15 minutes having a friend try to do the task (either with or without the patch applied) and report back here with the results. The few times we did that kind of quick, informal usability testing in the D7 cycle it really helped, and I think we need to be doing more of that in Drupal 8.

FWIW - I find it really annoying having to load the entire permissions form just to be able to get to Roles. It's a major PITA when working with sites that has alot of roles, which make the form take a while to load.

If you're using the Roles page often enough that this bothers you, you should add that page as a shortcut (http://drupal.org/documentation/modules/shortcut) or use admin_menu or some other solution that lets you get to it via one click.

I wouldn't want to change Drupal's information architecture based on this concern alone, personally :)

The usability test script sounds like a great idea, I'm just wondering what exactly we are going to test.

As this issue showed, there are different use cases to consider, which one do we actually test?

For example, "Create a role X, give that role the permission Y" could lead to totally different results than "Create a role X, allow that role to view block Y" and is exactly the problem that we have here.

Maybe we could do both to see if there are any differences...

Yeah, maybe we could do both.

Another option could be to do neither, and just focus on the roles themselves? Something like this:

"Three people in your organization need accounts created on the website. Each person has different things they're allowed to do on the site. Person A is an administrator. Person B is an editor. Person C is just a regular user."

And see where they go with it from there.

Subscribe and yay for tests, so tracking this to come back to later with better input. FWIW I prefer the after screenshot with Roles as a primary tab rather than a secondary tab (secondary tabs need work imo anyway, lots of reports about people not finding things when buried in these semi-invisible tabs).

So is the idea that you ask each person to try the test only one way? (Since performing the task the first time would make it easier the second regardless of which method came first.) Or do you randomize who gets which first, and then let them try it the second way? I have a number of IT coworkers in a range from moderate Drupal experience to none, none of whom have used D7, and I think they'd be more than willing to help out.

I think David's script in #21 is probably safest, because that way we aren't leading the user with another task they need to think about. In that scenario, should the user accounts for Persons A, B, and C already exist on the site?

So is the idea that you ask each person to try the test only one way? (Since performing the task the first time would make it easier the second regardless of which method came first.) Or do you randomize who gets which first, and then let them try it the second way?

In my very limited experience with this, I let the same person try both (basically because it doesn't hurt to have the extra data, and to be able to ask them for their opinion afterwards as to which they "liked" more). But yeah, you can't conclude much from the second test, for the reasons you mentioned, so it's fine to only do one.

I have a number of IT coworkers in a range from moderate Drupal experience to none, none of whom have used D7, and I think they'd be more than willing to help out.

Oh, that would be very very nice...

In that scenario, should the user accounts for Persons A, B, and C already exist on the site?

Either way seems like a realistic scenario to me, so I think either would be fine? Probably depends how fast you want/need to get the test finished versus how much of the user system you want to test. I guess having the accounts pre-created would be a little more focused on what we need to specifically test here.

A newer issue adn patch is in #1262812: Make "Roles" a tab of "admin/people" instead of "admin/people/permissions".