Top level "Users" to top level "People" in admin

This seems a duplicate of #536612: Rename Users to People. Either way, closed the other one, since this one has a more indepth description.

let me provide a little context to the intentions of both of these points that Gabor raises:

1. Renaming Users to People

there are two main reasons for this shift. The first is around the information architecture strategy which is that this section would be the 'go to' place for anything associated with lists of people - so not only user accounts for Drupal site access, but also potentially Event Attendee lists, Group membership lists and any other module that outputs lists of people could add a tab to this interface allowing these lists to be shown here (presumably with an in context link where the actual 'event' or 'group' or other content is shown to enhance findability). This approach has had some user testing with a smallish group of both Drupal and non-Drupal users and has performed quite well.

The second reason for this shift is more philosophical, which is to say that 'users' is general considered to be a fairly impersonal and derogative term. One of the driving principles of the D7UX project has been to connect and give voice to the end users of Drupal who are not active participants in these forums, but who constitute probably the majority audience of the Drupal user interface - developing empathy with and understanding for these end users is critical to designing and maintaining a good user experience within Drupal. We believe that by making this significant shift away from using the term 'users' to a more empathetic and humane 'people' is symbolic of a much greater shift in Drupal's commitment to good end user experience. (And yes, I note the irony of using the term 'user experience' here - that's a whole other discussion that is ongoing within that profession).

It may take a while for people who have become used to the term 'Users' to readjust to the new term and yes there is a butt load of work to make the initial shift but I'd submit that it is a big positive shift and worth the effort. (Oh, and did I mention that it has tested well with people who aren't familiar with Drupal, they naturally identified 'people' as the place where you'd add new site editors etc.)

2. Filtering and Tabs

let me explain to you the vision for these tabs and I'll leave the implementation discussion up to you

the idea is that there are two main filters - one for people who have significant administrative access to your website, they'd see the Admin Header, the second is for people who have limited access. People outside of the Drupal community might call these groups 'Site Administrators' and 'Site Members'. Site administrators would see the admin header and site members would perform their tasks in page.
Within each of these two 'meta groups' there may be multiple roles assigned. So, for example, I'm working on a project at The Economist right now, and they might have Site Administrator roles for Authors, Editors, and Section Editors, and Member roles for Registered and Trusted Readers (I'm making these up for the minute to illustrate how this works).

Now, I know from Drupal's perspective, all of these roles are the same thing effectively, however from a UX perspective it makes sense in most cases not to mix those two groups together. I've discussed this briefly with Gabor and it makes sense not to base this on access to the admin header as there will be plenty of people who don't have the header activated... I suggested perhaps access to something like the Dashboard page might be a good alternative, but this is far from my area of expertise.

I agree that the 'All' tab is not very helpful and I'm happy to ditch it.

Look forward to hearing your thoughts on this

My understanding of people vs. 'users' is that people might also include anonymous users of the site, (anonymous user / visitor). Especially if we make some progress with #355513: Create an anonymous user API, that could lead to commenters, comment subscribers etc. having some kind of existence in a Drupal site. So I'd assume no major name change apart from the top level items, except we'd probably do quite well to rename 'anonymous user' to 'visitor' in a separate issue somewhere.

Completely agreed on #2, just not having the role tabs there makes the most sense to me.

Crossposted, seems like my version of how this was going to work differed from Leisa's a fair bit.

So if I understand on the tabs:

Admin = these are all some kind of 'person with administrative access to the site' with various combinations of actual roles, and we pick a specific 'these must be admins' permission to filter on.

Registered = everyone else, possibly filtering against that same permission to exclude admins.

I think filtering on a 'magic' permission which makes people admins or not would be really, really confusing as to who shows up in this list or not, particularly since we added an admin role to core which would be orthogonal to this division, and which has a setting as to which role is 'administrative'.

I also don't think we need a meta-role division for the vast majority of sites - small sites are only going to have a single 'admin' role with handful of people using it (or possibly one if it's a single user blog), very large sites with lots of roles probably have their own very specific rules as to who has what sort of role on their websites and don't need us imposing an arbitrary divisions on them.

fwiw this is exactly the same point I made at http://www.d7ux.org/roles-the-admin-header/ and I thought I'd been corrected in that discussion that 'meta-roles' weren't actually being considered, apparently not.

I also don't see any reason to change all /user/1234 URLs to /people/1234 here - that's a lot of link rot on many thousands of sites. If 'people' includes users who didn't sign up to the site yet, then we still need a distinction between 'people who signed up' and 'visitors', and to me that distinction is an user account.

Please keep "users"
+1 for what catch says, specially including the linkrot problem.

"User" or "Users" is a common term accepted and understood all over the net, from the days of usenet (not 'people'net) till today in email services, community sites etc.
All most all standard cms use this terminology (see diagram) and folks migrating from other cmses won't have to handle an extra stumbling block.

some related reading for those who are interested on why these words matter from a UX perspective, these are taken from a piece written by a User Experience Guru, Don Norman, who you may know as the author The Design of Everyday Things and several other classic design and ux books:

Little clues can point to significant items. Hotels that are hotel-centered will not treat their guests as well as ones that are guest-centered. Or, to generalize, companies that are company-centered still don't get it: they still lack empathy and understanding of the point of view of their customers.

Words matter. Psychologists depersonalize the people they study by calling them “subjects.” We depersonalize the people we study by calling them “users.” Both terms are derogatory. They take us away from our primary mission: to help people. Power to the people, I say, to repurpose an old phrase. People. Human Beings. That’s what our discipline is really about.

If we are designing for people, why not call them that: people, a person, or perhaps humans. But no, we distance ourselves from the people for whom we design by giving them descriptive and somewhat degrading names, such as customer, consumer, or user. Customer – you know, someone who pays the bills. Consumer – one who consumes. User, or even worse, end user – the person who pushes the buttons, clicks the mouse, and keeps getting confused.

....

Artisan? Customer? Consumer? User? Wrangler? Biot? Each of these words is a way to degrade the people for whom we design, a way of labeling them as objects instead of personifying them as real living, breathing people.

Years ago, in my research group at the University of California, San Diego, I remember Liam Bannon passionately arguing that the terms we used would control the way we thought, acted, behaved and, ultimately, designed. Do not make your systems idiot or fool proof, he convincingly preached, for why would you want to think of your constituency as idiots or fools? Yup. Bannon’s teachings apply just as strongly today. We no longer talk of idiot proofing, but why do we degrade people by the passive, inert term of “user.” People are rich, complex beings. They use our devices with specific goals, motives, and agendas. Often they work with – or against – others. A label such as customer, consumer or user ignores this rich structure of abilities, motives, and social structures.

Time to admit that we are people, that we design for people. Yes, I know, the various terms arose from the need to distinguish the many different roles people play in the world of artifacts, machines, and gizmos: those who specify, those who distribute, those who purchase (customers), those who actually use them (users). Those who stand by and watch. But that is still no excuse. All of them are people. All deserve their share of dignity. Their roles can be specified in other ways. It is time to wipe words such as consumer, customer, and user from our vocabulary. Time to speak of people. Power to the people.'

you can read the entire article here (it's not much longer than all of this).

To clarify the background for some of the points above.

In both of the formal usability testing sessions of Drupal I've attended, the only section which didn't cause any signficant issues was 'Users'. Participants knew where to look, what a role was, had no trouble assigning permissions, created new accounts happily etc. etc. So while I'm quite happy with a renaming of the overall section to 'people', I have major concerns with anything which attempts to significantly refactor how the basics of user accounts, roles etc. are presented - since there's no evidence that there are conceptual problems we need to fix there, and a lot of evidence to the contrary.

is general considered to be a fairly impersonal and derogative term

I've not seen any research posted to d7ux.org which shows the word 'users' being considered an impersonal and derogatory term - where does this come from? Other research studies? Is it a general UX trend, if so, how is it being dealt with elsewhere?

If we replace 'users' (as the description for someone who has a user account), then we need to be extremely careful that we don't replace it with a euphemism (because it's considered a dirty word) that doesn't convey the relationship of various kinds of people to the site at all (we have a big mess of 'content', 'post', 'node' in core interface texts due to trying to avoid 'node' in this way, while never having properly agreed on a replacement in the first place). Language borne out of avoidance is usually very awkward.

"Users" is a word which gives inherent pride (in a good sense) and sense of dedication or belonging to a product or service. That may be abstract but the REAL problem is ALSO in a translatable equivalent.
For most of the non-English like Asian or Indic languages this, if changed, will lead to utmost confusion or will be too generic and not imply "users". Drupal is now massively multilanguage and string changes need to be aware and respectful towards the multilingual population.

how is it being dealt with elsewhere?

All the leading CMS scripts are dealing by keeping the term 'users' or 'user'.
Have a look at the attached picture.

@leisa, I thought you said the decision to use 'people' was from user research? I'm surprised to be told things come from research, then get quotes from a guru when I ask for references. On irc you said that a personal opinion fight wasn't a good way to conduct usability changes, I agree on that, but it works both ways.

Also I don't find the Don Norman quote particular relevant to this discussion. It appears to relate much more to how he wants people in the UX industry to relate to their profession- it's an argument about 'human centred design' vs. 'user experience', not as to whether we should refer to 'the people who have user accounts on a website' as users vs. people vs. humans. While we're veering off-topic, I also find his historical references a bit bogus - words like 'consumer', 'commodity' etc. have been coined to describe particular interactions which have arisen as part of the development of capitalism. They describe various aspects of alienation, they aren't the cause of it, hence my point about euphemisms.

seems a bit of a big jump to assume all users are living breathing people.

I've often used a separate user for posts made trough a service or aggregated from some other site, in which case it wouldn't make much sense to find this user in a box labeled "People" whereas I would expect to find it under "Users", as the service is using my site

same goes for users that represent an entire organization rather than a single person. makes more sense to me to call an organization a "user" rather than a "person"

I can't add much more rationale to Leisa's other than we need to be mindful that we should not be making this decision in the issue queue alone. These changes are proposed to serve a *much larger audience than the Drupal community* and certainly larger than the people contributing to this thread. Please, we really do have to be mindful of this.

@catch You say there is lots of evidence to the contrary. Can I ask where? I'd say there is a trend in UX to make software more human-readable and human-approachable. Careful consideration of labels is one way we can do this. Users are users (from a system perspective), but they can be represented (in a UI perspective) as People. With this in mind, I don't understanding the objection.

The Normon quote was to illustrate our point I think. It was our aim all along for the Drupal User Experience to have a human voice. Functional, yes, but not voiceless. To design the UX around *people* not *users*. It's a subtle, but fundamental difference. To revert to voiceless functionality would only further drive a wedge between novice users and Drupal imho. But I'm getting off-topic here.

@markboulton.

On using the issue queue alone to make the decision, I participated in the discussions on d7ux.org (including specific ones about users and roles, on which I had a number of concerns), and was pretty much assured by Leisa that I'd misunderstood the proposal - hence adding an 'admin' role to core, rather than trying to categorize roles as 'member' or 'admin' - so left it alone after that. We have four weeks to implement this stuff, I was not aware of any big changes like this being proposed at all until today despite following (and helping with) d7ux issue closely. So I'm not sure what you mean by making the decision outside the issue queue - stuff was posted, feedback was given, none of that included a wholesale change in core concepts for user management as I (and I'm sure all other participants in that discussion) understood it).

There's a lot of evidence that the existing core concepts around user accounts, permissions, roles etc. aren't confusing to novice users at all (I'll point out that both yourself and Leisa refer to novice users in your post, not novice people - showing how natural a usage it is and how awkward the substitution is in general conversation). To me, evidence that something works well and needs only minor tweaks , is reason not to change it without very, very good reasons (IMO this only applies to User management in Drupal, I'd make no such claims about nearly any other administrative area).

As for actual data, in three rounds of formal usability testing, two of which I attended, User management has barely registered any issues at all. This despite being tested quite heavily. For a specific link, see http://drupalusability.org/node/98 which has a total of three quite small and easily fixed recorded issues about that section, most restricted to a couple of participants, compared to many more for other tasks. At UMN it was equally not found to be a problem.

For the record, I'm not objecting to changing 'User management' to 'People' in the toolbar, and having admin/user/user move to admin/people. admin/content refers to both nodes and comments and doesn't cause too much confusion in that area (our terminology around 'node' does, but that's a separate issue), admin/people can happily refer to users, visitors, people who used the site contact form etc. - no real objection.

However the answer to Gabor's question in #1 seems to suggest that the idea isn't just to rename the overall section, but to remove 'Users' as a core concept entirely, replacing it with people. This has far wider implications, and I don't see the compelling reason why it's such a good idea (not liking a word, and a blog post by Normon isn't a compelling reason for me).

Users/user and people/person aren't equivalents of each other. User describes a particular relationship between a person and some thing, people just, well, describes the fact that someone is a human with no other specifics. We introduced a lot of usability issues in core by trying to move to 'friendlier' terms like content/post/article from node without an overarching mapping of concept to concept - because content/post/article/page/node aren't equivalents of each other, so we ended up using all of them (yes 'Node' is still in the interface for permissions and the main help page) inconsistently, sometimes in conflict with each other. In the case of 'users', it's not a even a Drupalism being avoided, but the most common technical and colloquial way to refer to 'people who use something'.

So, if this is what's being proposed, it needs to be accompanied by a proposal for how our core concepts around accounts, roles, permissions etc. get mapped to new terminology - that's not an implementation issue, it's a fundamental conceptual / UX issue which I don't see any existing materials dealing with at all.

As Gabor asks in the opening post, do you change http://drupal.org/user/35733 to http://drupal.org/person/35733 or. http://drupal.org/people/35733 ? - the latter two sound more impersonal than the former to me, I don't mind being called user/35733 since that's my specific relationship with Drupal.org, the site which I have a user account on, being called person/35733 makes me sound like a convict. Not to mention pathauto offers an easy way to make user/35733 point to people/catch, or /catch or users/catch - which many, many sites make use of, depending on their own particular requirements.

What do you replace 'user account' with (surely not 'people account' or 'person account'?)

What do you replace 'user permissions' or 'user roles' with (again, not a candidate for find and replace so needs to be consistently changed to something else meaningful).There's many, many more constructs like this in core which have to be dealt with. Note I can't find any reference to the wholesale changes being proposed here (as opposed to changing the overall heading) on http://www.d7ux.org/category/projectframework/70-people/ - so if I've missed it somewhere, please feel free to point that out.

+1 @Seutje

To sum up so far

# People is not equal to user. Changing this to say the least is confusing, and NOT serving purpose
# Huge number of users not reading the thread will be at a loss if silently an illogical change is made
# There are problems in translation-ability. Multilingualwise users is acceptable, respectable, concise,clear
# Tech problems of linkrot, serious search problem as Drupal searches users only, NOT people
# Huge mass from all prominent CMSes (if or when they migrate) are already accustomed to 'users'
# Lack of uniformity in sitewide nomenclature - What's your 'People' name? Forgot your 'People' name?

admin/people can happily refer to users, visitors, people who used the site contact form etc. - no real objection

@Catch
So long as Drupal is not able to search all folks on the site, and since admin/people or admin/user contains a search it is disastrous and misnomer to call it admin/people. (Even then there will be unwanted problems of backward compatibilty as well as forward compatibilty of other CMS users who may come to use Drupal. - apologies for repeating)

This is becoming a very ironic token-issue. I'd much rather seen a some more general conclusions from the d7ux tone-of-voice survey than picking this specific term to drive home the point of the need for a more humane tone of voice. 'People' is better than 'Users' as the label for the top level item in the IA, as it wants to cover more than user accounts.
The technical implications seem to be quite large though, and I don't think this rename needs to be extended to the implementation side.

@Leisa and Mark: lose a battle, win the war…

Attaching a patch that just renames the current top level 'Users' menu item to 'People'. Probably needs fixing some more occurances in the ui text, but please don't ask me to grep :)

status

So I grepped to help yoroy with replacing 'User management', and decided to grep for all uses of User management/Users/User and their lowercase variants in core, here's the results. Excuse the separate .txt files, my command-line fu isn't that great, but this also has the advantage of showing in kb the number of core references to each we have. A quick look through these shows the various contexts 'user' is used, and the implications of changing this.

A lot of these are querying db tables etc, hard to filter that out consistently (and for a completely rename including APIs we'd need to do those too anyway), but gives an idea.

As far as I am aware Drupal search (there is Find people --> Search box in the mock-up) cannot find or search out a man/woman unless he/she is registered user. So is "Find People" not a misnomer till this issue is fixed. Or probably this is fixed already or going to be fixed soon ? Which is a good news then.

The core Drupal search has two tabs - Contents and Users. Are we going to call it "People" there too in tandem with this ?

If core Search finds only registered user then Event/Groups users are a subset of Registered users only and not separate entities.

@Kaakuu, the idea is that modules dealing with events / groups add their own tabs / filters to this area so it becomes a central hub to find both registered users and visitors with various kinds of relationship to the site. (maybe CCRM and other similar packages would add themselves here too - and they really are about finding 'people' who might have no relationship to the actual site itself at all, and already implement their own searches in contrib). However core can only provide what it provides, which at the moment is very limited. I've opened #539510: Core search should index user account pages which would help to improve things for registered users. comment module currently stores a lot of information about commenters, but not much gets done with that.

Hi Catch, this explains the things more clearly. Thanks.

Regarding #539510, though somewhat OOT, I think Drupal needs to find on search
the names of Anonymous comment posters ALSO as well as CONTENT of an auth user on user search when there is NO public access to auth user's profile.

Let's make the path match as well (just admin/people, not user/X, etc.) for consistency with other top-level paths.

After that, is there a reason not to commit this?

Somebody else please change the path with an updated version of the patch, out of skillscope for me ;)

Do we need humans review the code here or are we happy when testbot is happy?

Ok! rtbc it is then

It seems this doesn't touch to many of the controversial points raised at all, so lets go with this.

I also agree with catch in #14. Committed to CVS HEAD. Happy to follow-up on this though, but this looks like a first good step that we can agree on.