Page MenuHomePhabricator

Make it more likely to see assignee & reporter in task view without having to scroll down
Closed, ResolvedPublic

Description

CURRENT SITUATION:
In the task view, in the bar/box on the right, the following items are available in the following order:

  • Task actions
  • Tags
  • Subscribers
  • Tokens
  • Assigned To
  • Authored By

My screen resolution is 1440×900 and my viewport is something like 1440×714, given the browser title bar, menu bar, tabs, address bar, and the OS panel at the bottom:

Currently I cannot quickly gather all relevant task information without scrolling - Author and Assignee are missing.

EXPECTED SITUATION:
It feels more relevant (at least for my workflows and according to anecdotes of co-workers) to see the potential assignee and the author than if anybody is subscribed or has handed out tokens to a task, to allow me judging the reporter's 'reputation' (whether I need to triage the task or not) and (in case of urgency) whether someone is already supposed to work on a task.
I'm personally not aware of use cases when tokens or subscribers are more important than assignee and reporter (but maybe there were design and usability decisions I'm just not aware of).

PROPOSALS:
#1: Reorder the side bar items:

  • Task actions
  • Tags
  • Assigned To
  • Authored By
  • Subscribers
  • Tokens

#2: (Probably more controversial:) Do not have the task title full width; move the side bar up.
Given my viewport, implementing these both proposals would allow me to gather most relevant information at once (Tokens would not fit on my screen anymore but that's obviously okay):

NON-LEGAL DISCLAIMER:
I know there is no one perfect solution given different screen resolutions, browsers, and OS elements out there.
Plus it looks slightly uglier to move that bar up and not have the task title full width.
Still hoping these two proposals could be acceptable (or at least a base for discussion).

Event Timeline

I'm happy with the new UI but only because I happen to work with a monitor in portrait mode. :)

Three improvements that I would recommend, sorted by severity:

  1. Assigned To is a very important data point, and having it down there is really inconvenient. I think it actually could belong to the header, under the title, next to "Open, Needs Triage"+ "Public". If that is too much, then at the top of the right column.
  2. Authored By is also more relevant than what its current position indicates, not only because of the author, also because of the creation date. I bet in many organizations and communities, that combo provides a quick and useful context. I would reposition it next to Assigned To, wherever that element goes.
  3. The idea of moving the right column up, taking space from the 100% width title makes sense to me. In most circumstances, this would make the entire right column visible without scrolling. Now most titles won't ever reach that right margin.

Actions - will get reduced in size and sidebar content will move up as a result. We're heavily prioritized right now so no current ETA. It is our intention to reduce these globally. This will raise content underneath significantly, we expect to remove about 1/3 to 1/2 the actions globally if possible.

Authored Date - Author/Date has been added to the sidebar, This is a new feature that did not exist in the old layout. This information was previously only in the timeline (where it also still resides)

Assignee - We may move Assignee into the "gutter" like we do in Differential, but we've had I think one other install request this, so overall it doesn't appear a hot button issue for most installs. We'll keep it on the radar.

Comment Area - This is still under design and final UI has not been shipped. There are some mocks in M1461.

Knowing who you're talking to - To me this isn't an issue to be solved above the content, but rather in context on Timeline. We've done [Author] tags in Differential for inline comments and I'd like to bring [Assignee] and [Author] over to other apps. So this would, next to the users name, let you know whom you're speaking to in relation to the task/object.

Screen Size - I design on a 12" MacBook, and planned an 1140 grid layout with this latest iteration, which will come in an optional fixed-width layout as well. We can probably move the tablet breakpoint up (I think it's 768) if that's needed, but I'm surprised if people are using a significantly smaller screen than I am daily.

Mostly, "Meta" information, that is information that you may want the first time to orient yourself, has been de-emphasized and the important information, title, description, comments, have been brought up significantly higher on the page. For example in the old design, the description would be cut off and not displayed on the screen at all because the actions pushed it off the page. So the trade off is now you can read the meat of the entire reason for the task existing at the slight expense of who opened it. In 9/10 cases that's the more important piece of information.

Here's the example that kicked off this design change from Babel:

It's just dreadful the whitespace. The content starts 80% down the page. In the new design this information starts just under the title. Contrast that to the current UI, which now starts the same content about 40% higher on the page:

(not opposed to reordering the sidebar, either)

I've been hoping for the actions and information to swap places. It seems like the information is what should be read first, before getting to the actions...

What information specifically in the sidebar should be read first?

FWIW I really like proposal #2:

I've gotten used to the new interface and my main complaint that remains is that some stuff is pushed down below the fold by the menus.

I also like the solution employed by the 'tablet' UI where the buttons are collapsed into a dropdown menu.

Thank you for the explanation, @chad, very useful.

I think one extra problem we have in the Wikimedia instance is that a "Details" box frequently appears, with a "Security: None" field and frequently with blocking/blocked tasks. It might still be that counting pixels the description is higher than before, but the proportions of that box look generally big.

Many options in the right menu are greyed out, and the user cannot do anything with them. What about showing only the active options, saving vertical space?

And yes, the sorting in the mockup makes more sense imho:

  1. Actions
  2. Tags
  3. Assigned To
  4. Author
  5. Subscribers
  6. Tokens

Security: None displaying is maybe a bug, we default don't show custom fields that do not have any value. Is this a custom field or an explicit patch?

I think it's a custom select field with an explicit nonempty "None" value, so display is expected.

If this was a fully-custom custom field you could change that behavior, but I don't think it is (I don't immediately see it in https://github.com/wikimedia/phabricator-extensions).

You can make it never show by setting "view": false in the configuration for the field.

(You could possibly hide it unconditionally and then write a CurtainExtension to show in in the side bar instead.)

@epriestley: Thanks for the tips. That field is actually a legacy thing at this point and probably should just be hidden everywhere.

epriestley claimed this task.

I reordered these elements in D21200. See also D20967.