I find this type of hasty task closure really off-putting and inappropriate. There are many parts of Phabricator and Phabricator development that I like, but this issue tracker is a little toxic.

This request was open for less than half an hour. Several people have commented that the "sign in" icon is bad. Of those people, a few have suggested concrete improvements (such as adding a tooltip).

And yet the response here has been a "won't fix" accompanied by bulleted text that floats between "we don't like documentation" and "this isn't our problem." What on earth?

I'd be less annoyed if I thought that this were an isolated case of paternalistic and patronizing behavior in this issue tracker, but I know better.

What specifically about this reply is bothersome. I said "not at this time" and "thank you for the feedback". How can we more graciously say "no".

I do agree there is a disconnect with people who want features in Phabricator and what is possible for the upstream to ever build. If we can't build a task in 3-5 years, I don't feel it's fair to leave the task open to rot.

I honestly don't mind leaving this open if that's the main issue, but the only time I would expect it to get resolved is when the entire header is re-thought and re-built.

When I first wanted to report a bug to a project that uses Phabricator, it took me several minutes (!) to figure out how to login

This is probably the actual issue. You shouldn't need to click the "Login" button at all in order to report a bug. Here's the screen you get when you click "Create a Task" while not logged in (that is, you get the login screen):

Here's the logged-out UI element when you scroll to the bottom of the page to add a comment:

i..e, a large, simple button with the text "Login to Comment" and no icon.

Here's the UI when you try to edit a task while not logged in:

i.e., another very clear workflow taking you to the login screen.

What workflow did you follow which didn't hit any of these explicit, obvious screens?

I think it's a common pattern coming from other software that you need to make an account / login before finding a way to do anything. It's been in my head to just make the logged out header say [Login] instead of just the icon next time we went through that code (which is ... quite messy).

@MZMcBride, have you read the article from the documentation that @chad linked earlier?

https://secure.phabricator.com/book/phabcontrib/article/feature_requests/

We attempt to explain the upstream attitudes and positions in great detail there.

In T7073#132726, @chad wrote:

I think it's a common pattern coming from other software that you need to make an account / login before finding a way to do anything.

This could explain it, although I wonder if there's some specific workflow or configuration which isn't working very well.

For example, I believe we've only heard this feedback from WMF users, but as far as I can tell, the current flow on the WMF install for logged-out users is:

1. Click "Report a Problem", the most obvious link in the main content panel.

2. Login screen.

Maybe the flow was previously less obvious, or maybe this is an artifact of login integration or something.

Bring back the old homepage?

What about something basic, like a tooltip? (As suggested above.) I would assume it takes only a few lines of code and should not introduce any support and maintainance nightmares in the future.

Here are some of the reasons we're not just adding a tooltip and calling this done:

Root Problem: We don't understand the root problem, and this task hints that it may not be with the icon. The problem as described here is very focused on a specific fix (change icon / add tooltip) but we don't have enough context to really be confident that this is the root problem. As shown in the screenshots above, when you're logged out, every workflow which requires authentication already acts as a login button. For example, trying to create or edit a task takes you directly to the login screen. My expectation when I built these flows is that you navigate to the login screen by trying to take whatever action you're interested in performing, and you'll be prompted to authenticate if you haven't already.

So it's not clear why users are trying to find a login button to login at all: everything is already a login button. As @chad suggests, it might just be that they've used other software which works differently and are fixated on looking for a "Login" button, even though there is a "Create Task" link and what their goal is to create a task. But, particularly because we've only seen a small amount of feedback about this issue (and I think from only one install), this might also not really be the problem.

For example, perhaps the install was configured in a way that obscured the workflow for a while, either by accident or because of upstream bugs which made this kind of configuration easier than it otherwise should be. If this is the case, we'd like to fix those bugs or improve guidance for administrators.

To provide another example, the report also mentions NoScript. Maybe the user did follow one of these workflows, but it didn't work because they had NoScript enabled, and they then tried to find a login button. If this is the case, the root problem would be that we need to more clearly communicate to users that Javascript is required to use Phabricator.

To provide another example, maybe something was just completely broken and the "Create Task" link didn't even appear for the user. Since they were new, they wouldn't know to expect that "Create Task" should be present: a new user can't possibly file a bug like "Create Task link is not showing up for logged-out users anymore" because they don't know that it should exist. If this is the problem, we'd obvious prefer to fix the software to work as intended.

It's important to us to fix root problems. The features users suggest often aren't actually very comprehensive or very far-looking solutions to the problems they encounter, or may lack context or otherwise not be the best approach given more information. For example, it's somewhat common for users to ask that we add features which are already available through configuration or Herald. Obviously, the best fix for these kinds of problems is onboarding/documentation (to make it easier to learn about and learn to use Herald, which is much more powerful than individual features users suggest). In this case it's usually pretty obvious when a feature request is missing scope, but it isn't as obvious in general. Because users in general (and, particularly, new users) aren't as familiar with the software as a whole (and can't reasonably be familiar with our long term plans and roadmap), they are generally less able to identify the best solution to problems.

New users, in particular, may not know what to expect at all. A user who hasn't used the software before can't distinguish between "indirect workaround is unclear" (e.g., login icon isn't obvious) and "primary workflow is completely broken" (e.g., maybe the login workflow just didn't show up for them at all).

Fixing root problems is really important: it's how we build good software that we can continue moving forward on quickly. We attempt to really underscore this in the documentation:

https://secure.phabricator.com/book/phabcontrib/article/feature_requests/

Despite this, most reports we receive that ask for features and make a weak effort or no effort to describe the root problem. We're continuing to explore avenues to improve this, but some of the feedback we've received from users who repeatedly fail to describe root problems isn't really actionable, so it's not clear how much headway we'll ever be able to make.

Here are some possible root problems here, none of which are best resolved with a tooltip or icon change:

• UI is broken under NoScript.
• UI is broken in some other way that isn't obvious to a newer user.
• UI was misconfigured or unusually unclear on the WMF install specifically in the past.
• Some users have an extremely strong assumption that they need to login before they can take actions; this assumption is so strong that they'll, e.g., miss a large link or button labeled "Create Task" when their goal is to create a task. (If this is the case, it is likely we would want to make much more substantial changes than adding a tip/icon.)

Broadly, the design expectation is that new users essentially never use this button. If they are using it, that points to some other problem or design or usage constraint we don't have a good understanding of, and which also isn't explained in this task.

Tooltips are a Bad Fix: We want to understand root problems so that we can apply the best fixes.

I can't currently imagine a problem such that adding a tooltip is the best fix. If the clarity of the menu icon is really a problem, adding a tooltip just makes it a little less bad. This is awful! We don't want to build sort-of-ok software that's usable if you fish around because it has tooltips.

If, after understanding the root problem, we decided that making the action more clear really was the best fix, we'd likely replace the icon with text, as @chad mentions above. However, we haven't clearly established what the root problem is. If it's the "strong assumption" root cause above, we'd likely pursue even more extreme fixes.

Technical and Product Considerations: Phabricator is a complex piece of software, and very few changes are as simple as they seem at first. For example, tooltips interact with mobile (where they are not available), and with the modularity of the menus, and with accessibility. We need to consider both the current state of the software and the planned state of the software when adding features.

The menu has a planned technical rework to improve modularity, and a likely product/design rework. Adding features now makes these reworks more challenging and complex. Even though these costs may be small, it doesn't make sense for us to spend 15 minutes adding a feature today that will cost us 30 minutes in a month when we perform work we already plan to perform.

Priority: Our team is very small, so prioritizing is critical. It is very important for us to spend time doing the most valuable work we can be doing, because we have limited resources to accomplish the work.

We receive far more feature requests than we can complete, and receive them at an accelerating rate. The least important requests will almost certainly never be completed. This is one such request.

This request affects a tiny number of users, primarily from only one install. The root cause isn't clear. There are straightforward workarounds, and, at least at the time of writing, they've been implemented (the WMF documentation calls out the icon specifically). The WMF documentation also has lots and lots of detailed onboarding context which we couldn't possibly provide because it's unique to the WMF install. As @chad mentions earlier, we believe that installs writing onboarding documentation is the best solution to a large class of onboarding problems: we can not possibly anticipate what context users need when onboarding, and installs are far better situated to provide this information.

Onboarding Requests: When installs first adopt Phabricator, they often have a burst of feature requests related to onboarding, since all their users are onboarding. Once they get over that hump and spend some time using the software, their priorities usually shift to core feature development: they're no longer onboarding, and one-time onboarding issues aren't the major pain point anymore. Instead, they want the applications to work better or do more.

Although we do want to improve onboarding, these requests are often much less substantive than the second wave of requests which tackle more fundamental workflow concerns, and are usually no longer priorities for the original requestors after things settle down.

When WMF onboarded, we saw a lot of requests filed against the upstream which seemed consistent with this pattern of requests. Our current understanding of WMF priorities is that they are all fundamental workflow concerns.

Upstream Resources: Our team has flexible roles: there's no one dedicated to support. When we spend time on something, the person doing that is almost always doing that instead of higher-value work, and it almost always directly takes time away from priorities (like feature development). I've spent about an two hours responding to this task. I'm also the technical lead of the project, so that's two hours I didn't spend actually implementing features or fixing bugs.

As a user, it's nice to receive a detailed, personalized response when you file a feature request, but responses like this are a particularly bad use of our very limited resources.

Tasks like this are very frustrating for me, because they feel like a tremendous waste of very limited development resources. They're also frustrating for users, because they feel like they're getting shut down by an adversarial upstream.

We're looking at ways to improve this, but haven't had much luck with ways that don't have an ongoing cost to the upstream (e.g., documentation -- essentially everything in this response is already in the documentation), and generally all the ways forward we currently have are to just decrease the actual access users have to the upstream: emotionally, many users would rather be ignored than be rejected, since it's a less negative experience. Here, we were rebuked for responding to this request promptly! We currently tend to reject requests, but both sides of the equation might be happier if we effectively ignored requests, or just created an illusion that we're listening to them (e.g., a private queue where we thank you for your request and let you know we'll consider it, but actually throw it away).

We are likely to make some changes to the system which do one of these and have the actual effect of decreasing access users have to the upstream (like many other open source projects), which should help interactions feel less patronizing for users and less frustrating for us.

Some users have an extremely strong assumption that they need to login before they can take actions; this assumption is so strong that they'll, e.g., miss a large link or button labeled "Create Task" when their goal is to create a task. (If this is the case, it is likely we would want to make much more substantial changes than adding a tip/icon.)

This is the reason why I created this report, but I'd like to respond to https://secure.phabricator.com/T7073#132728: I do agree that once you actually try to do something, the login form appears pretty fast. However (and this is something that's probably more important to know for the WMF people), the "Report a Problem" button sits between an explanation of what phabricator is and a link to the phabricator help which, together with the wording, suggests to me that it's a "Report a Problem with Phabricator" button and not the "Click here to report a bug with any Wikimedia product" button. So now that there's no obvious way to report a bug with one of the wmf products, it's not that hard to imagine that a login button is the next thing to look for.

Finding the "Create Task" button on the Maniphest page is indeed easy on this installation of Phabricator, but it's (at least for me) harder on the WMF one: https://phabricator.wikimedia.org/maniphest/ is really really colorful and the "Create Task" button has the same color as the unclickable breadcrumbs next to it which makes it hard for the eyes to find it (I say that now, I don't know what it was like all those months ago).

In response to https://secure.phabricator.com/T7073#132729: This looks so much easier to use than the current homepage because I don't have to learn about the various parts of phabricator that I'll most likely never use to report a bug.

I wouldn't be opposed to a Dashboard Panel for Actions, as in, it's an Action Panel like https://secure.phabricator.com/uiexample/view/PHUIActionPanelExample/

I think that's reasonable, the edit UI is just going to be a bit messy. In some hypothetical world, it would be nice if it were WYSIWYG-ier, maybe.

I also want to modularize icon selector controls at some point since we have 3 (or 4?) of them copy/pasted now (Projects, Calendar, Badges) with 90% similar code.

Another approach would be for WMF to edit the link to be a picture of a bug with a "Click here to report a bug with any Wikimedia product" tooltip. HA HA MY WIT IS AS A RAPIER

Finding the "Create Task" button on the Maniphest page is indeed easy on this installation of Phabricator, but it's (at least for me) harder on the WMF one

Do you recall why you filed this task as "Login icon unclear" instead of "hard to figure out how to create a task"? That is, I'd expect you to have done something like this:

• Look for a "Create Task" / "Report a Wikimedia product problem" sort of link.
• Not find one (assume "report a problem" is for Phabricator itself).
• Think "maybe I have to log in".
• Eventually figure out how to do that.
• Still can't figure out how to create a task!

That is, it sounds like logging in didn't really solve the problem, and like it was an intermediate sub-problem in accomplishing your goal? Did "can't figure out how to create a task" also get filed elsewhere (maybe just on the WMF install), or was the login problem much worse (more frustrating?), or did you happen to end up in the right place after logging in? I know this was a long time ago so maybe you don't remember, but it seems like the login issue is incidental to this workflow.

Logging in puts the + sign in the top-right corner of every page, which I think is pretty self-explanatory and much like the workflow in jira.

In T7073#132775, @chad wrote:

I wouldn't be opposed to a Dashboard Panel for Actions, as in, it's an Action Panel like https://secure.phabricator.com/uiexample/view/PHUIActionPanelExample/

That is very smart solution: Huge click-able icon, good title, description, messages... Action panel with buttons on default dashboard would solve problem for WMF and then some 😉

Plus it would allow some rather good elements from very old-style front page to come back in style 😉

When I first wanted to report a bug to a project that uses Phabricator, it took me several minutes (!) to figure out how to login and I'm used to all kinds of bug-trackers (mantis, jira, trac, ...).

Just passed through exactly the same sinkhole.