Make it visibly clearer that a Phabricator user account has been disabled
Open, Needs TriagePublic

Description

In Wikimedia's Phab instance, we have both volunteer and "paid" (such as WMF) users (and their associated user profiles).
Paid users sometimes change jobs. Hence their work Phab accounts gets disabled, as part of an offboarding process.

I'm having the (anecdotal) impression that many users have a hard time to "realize" that a user is not active anymore.

Current UI when a user account is disabled:

  • On the user profile page, the only hint is the line "Roles: Disabled", right above a misleading "Availability: Available".
  • In tasks, there is a small grey dot (handle-availability-disabled) in front of user names. (I do know it's a hint meaning either "unverified account" or "disabled account". Others might not know.)
  • In tasks, the popover on user names does not offer info about "disabled" accounts either (only: "username", "title", "user since", and again "availability").

Problem:
Users request feedback from disabled accounts. Which will never reply.
Users think that a certain disabled account still is in their job position (which is often listed in the "title").

Thoughts:
I'm not sure what's the best approach since browsers don't support <blink> anymore for "Role: Disabled" on the profile page. ;)
Many resolved/archived objects are strike-through in the UI. So I could imagine to render the account name and title as strike-through in both the popover and on the profile page. I could also imagine strike-through for the account name in tasks, however that might be seen as inconsistent with the small dot (e.g. a red dot is used when not being available, afaiu).

This was originally brought up in https://phabricator.wikimedia.org/T115579 and I got asked about this very topic again today in a private conversation by anothe user, hence I decided to upstream this issue.

If your impression is different, feel free to decline this request.

aklapper created this task.Thu, Jan 26, 5:32 PM
chad added a subscriber: chad.EditedThu, Jan 26, 5:51 PM

I'd probably want to fix this at the source, not the Profile Page. I think if you have to get this information from the Profile Page, we've let you down in the UI elsewhere.

I think we have some discussion of this somewhere, although I don't immediately recall where and it's not in the obvious places. I might be conflating discussion of the recently-reworked "Available" status.

I think this reasonable and worth iterating on. In particular, user profiles have become more rich than they used to be, which has buried "Roles" a bit.

For reference, @demo is currently a disabled user on this install.

I think these changes, or general changes in this vein, are worth pursuing (@chad might also have some input):

  • Move the "Administrator" and "Disabled" information on user profiles to an obvious banner or badge, particularly "Disabled". When looking at a disabled user profile, the fact that they are disabled is probably the most important information on the page, and currently gets one line of unremarkable text in the middle of the properties box.
  • Clearly and explicitly explain the grey dot on hovercards. Note that there are several different afflictions which cause grey dots to appear: unverified email addresses, disabled users, unapproved users. Hovercards in general haven't received an iteration in a while, I think there are a few outstanding tasks.
  • In the @ autocomplete in remarkup boxes, render disabled users in an obvious way so that there's a stronger piece of "this user probably isn't going to reply" feedback when you start typing @username, please give me feedback on this.... It would be nice to put "Disabled" here explicitly, but we're a bit limited on space. Grey text with strikethru would probably be approximately good enough (i.e., cause the user to take notice and investigate) if putting a second line of text into the UI proves involved. In making this change, I'd be trying to target users who are mentioning disabled users and expecting a response. If you have a sense of it, it would be helpful to know whether this is mostly happening with @mentions or with explicit "Change Subscribers" actions -- my theory is that it's about 95% @mentions because they don't provide a "disabled" hint, while the normal typeahead does. (A third channel might be quoting, but hopefully the other stuff would clean that up).
  • Maybe make the rendering of disabled user tags (like: @demo) in remarkup more obviously abnormal (grey out the whole thing and maybe give it strikethru like tasks and revision, not just a grey dot).
  • Maybe caveat or remove the title field on user profiles and hovercards for disabled users.
  • The browse dialog for users already seems fairly clear (this is the only context where we use strikethru today, I think):

  • In contrast, the fulltext search result UI is particularly un-clear (this user is disabled). I think this might be the only context where we don't provide any hint.

  • Normal typeaheads are pretty good too, but maybe should pick up strikethru if we start using it more widely in other contexts, for consistency:

  • Maybe strikethru in timelines, too, to provide a stronger hint against quoting these users? Or even change the "Quote Comment" text to "Quote Comment FROM A DISABLED USER WHO DEFINITELY WILL NOT REPLY TO YOU" and then require the user to confirm that they really want to do that with a dialog. I think this is almost certainly unnecessary, but they're steps we could reasonably look at if a lot of this mis-discussion is the result of quoting and less aggressive changes don't remedy it.

Downstream, @20after4 calls out that mentioning disabled users in comments still subscribes them, as though they were normal users. This behavior would be easy to change, but I could sort of go either way on it.

If the surface-level cues discussed above were better I think it would probably be moot in most cases, and subscribing them is more consistent (no "why didn't this user get subscribed?" magic to explain) and maybe useful in some edge cases (users who are temporarily disabled can come back to a better subscription state, perhaps?).

chad added a comment.Thu, Jan 26, 6:27 PM

I'm cleaning up Project/Profile UI with the nav changes, I'll just pop a tag in for Roles.

This task got cross-referenced with https://phabricator.wikimedia.org/T115579. My impression of the Wikimedia Phabricator task was that we wanted a way for Phabricator admins to be able to edit the title of another user without needing to edit the database contents directly (cf. https://phabricator.wikimedia.org/T115579#2973336). I'm not sure this task captures that request.

If someone puts abusive text in the title field of their Phabricator profile, for example, can a Phabricator admin then edit/remove that text from another user's profile via the Phabricator user interface? If not, that should be the subject of some task, if not this task.

  • Maybe strikethru in timelines, too, to provide a stronger hint against quoting these users? Or even change the "Quote Comment" text to "Quote Comment FROM A DISABLED USER WHO DEFINITELY WILL NOT REPLY TO YOU" and then require the user to confirm that they really want to do that with a dialog. I think this is almost certainly unnecessary, but they're steps we could reasonably look at if a lot of this mis-discussion is the result of quoting and less aggressive changes don't remedy it.

For what it's worth, I sometimes read "disabled" in Phabricator's user interface as equivalent to "handicapped" (i.e., physically and/or mentally disabled). I'm not sure there's a better word that could be used.

chad added a comment.EditedFri, Jan 27, 3:31 AM

This is what it looks like (note the "role" is completely removed):

epriestley added a comment.EditedFri, Jan 27, 3:33 AM

This task does not capture abuse cases. If you'd like us to build anti-abuse tools, please file a separate request describing the abuse you're seeing. See also T10215.

If the abuse is purely hypothetical, you could leave a note on T10215, but it is exceptionally unlikely that we will proactively build tools to protect against hypothetical abuse, especially if the hypothetical abuse would cause no substantial damage if it occurred.

I don't see any evidence from the downstream task that abuse has actually occurred.

This task does not capture abuse cases. If you'd like us to build anti-abuse tools, please file a separate request describing the abuse you're seeing. See also T10215.

Okay. I'm subscribed to that task.

I don't see any evidence from the downstream task that abuse has actually occurred.

It was an example. I tried to label it as such with "for example." In my mind, wanting to change the title field of a Phabricator user profile because it says "I work for the Wikimedia Foundation" (after the user has departed the organization and no longer works there) is technically equivalent to wanting to the change the title field because it says "John Doe is a bad guy and his phone number is ..." I think both are potentially valid use-cases. I thought that's what was being requested at https://phabricator.wikimedia.org/T115579#2973336, which is why this task confused me.

Your suggestion to remove/hide the title field altogether for disabled accounts seems worth considering.

For completeness, the "20 other subscribers" dialog displays disabled users in a different, unique way that isn't like any of the other ways (grey, no dot, no strikethru):

I think there are some more things worth doing here, but user profiles should be significantly more clear after recent changes. Here's @demo on this install now:

I like. ♥. Thank you a lot!

eadler added a subscriber: eadler.Thu, Feb 16, 2:16 PM

D17374 makes hovercards a little bit more clear too, although that might get some design feedback still (see "Horse" here, for example):

@chad did another pass on user hovercards and they should be even more clear now (this screenshot doesn't demonstrate it clearly, but we also greyscale the profile photo);