Page MenuHomePhabricator

Saving vertical space in tasks
Closed, WontfixPublic

Description

Tasks take a lot of vertical space before showing a first action. After reading the task once, most of the times what users want is to get to the new comments. Can we save them some scrolling?

In most tasks, the vertical nav bar in the right (with no less than 10 items) already creates extra white vertical space between the summary and the description, e.g. T92. Can those 10 items be less? Can they be organized differently? Can they be collapsed somehow?

There are also tasks with lots of details in the description, which is very good for new readers and even to document as you go. Still, for most users working around a task regularly, most of the times they will simply want to skip the description to find the new comments. Collapsing actions already helps, but what about collapsing the long description as well?

I will create some artificial vertical space here to bring something interesting that would become quickly annoying if you would have to come here and comment several times a day. :)


||     *                            *                    ((   *  ||
||        *                 *                *            ~      ||
||                ___.                          *          *     ||
||       *    ___.\__|.__.           *                           ||
||            \__|. .| \_|.                                      ||
||            . X|___|___| .                         *           ||
||          .__/_||____ ||__.            *                /\     ||
||  *     .  |/|____ |_\|_ |/ _                          /  \    ||
||        \ _/ |_X__\|_  |\||~,~{                       /    \   ||
||         \/\ |/|    |_ |/:|`X'{                   _ _/      \__||
||          \ \/ |___ |_\|_.|~~~                   /    . .. . ..||
||         _|X/\ |___\|_ :| |_.                  - .......... . .||
||         | __\_:____ |  ||o-|            ___/........ . . .. ..||
||         |/_-|-_|__ \|_ |/--|       ____/  . . .. . . .. ... . ||
|| ........:| -|- o-o\_:_\|o-/:....../...........................||
|| ._._._._._\=\====o==o==o=/:.._._._._._._._._._._._._._._._._._||
|| _._._._._._\_\ ._._._._.:._._._._._._._._._._._._._.P_._._._._||
|| ._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._._||
||---------------------------------------------------------------||
                                                -Manoj Jain

               _.--""""''-.
            .-'            '.
          .'                 '.
         /            .        )
        |                   _  (
        |          .       / \  \
        \         .     .  \_/  |
         \    .--' .  '         /
          \  /  .'____ _       /,
           '/   (\    `)\       |
           ||\__||    |;-.-.-,-,|
           \\___//|   \--'-'-'-'|
      jgs   '---' \             |
     .--.          '---------.__)   .-.
    .'   \                         /  '.
   (      '.                    _.'     )
    '---.   '.              _.-'    .--'
         `.   `-._      _.-'   _.-'`
           `-._   '-.,-'   _.-'
               `-._   `'.-'
             _.-'` `;.   '-._
      .--.-'`  _.-'`  `'-._  `'-.--.
     (       .'            '.       )
      `,  _.'                '._  ,'
        ``                      ``


 

Magellana- nef 'Trinidad'

                                 P___----....
                                ! __
                        ' ~~ ---.#..__ `  ~  ~    -  -  .   .:
                       `             ~~--.               .F~~___-__.
                       ;                   ,       .- . _!  
                      ,                     '       ;      ~ .
                     ,        ____           ;      ' _ ._    ; 
                    ,_ . - '___#,  ~~~ ---. _,   . '  .#'  ~ .;
                  =---==~~~    ~~~==--__     ; '~ -. ,#_     .'
                   '                     `~=.;           `  /
                                             '  '          '.      
                    '                         '               
            \                                  ' '            '
            `.`\    '                          . ;             ,
              \  `  '                            '             ;
               ;   '                           '               '
             /_ .,                           /   __...---./   '
             ',_,   __.--- ~~;#~ --..__    _'.-~;#     //  `.'
             / / ~~ .' .     #;         ~~  /// #;   //   /
           /    ' . __ .  ' ;#;_ .        ////.;#;./ ;  /
           \ .        /    ,##' /   _   /. '(/    ~||~\'
            \  ` - . /_ . -==-  ~ '   / (/ '     . ;;. ', 
           /' .       ' -^^^...--- ``(/'    _  '   '' `,;
##,. .#...(       '   .c  c .c  c  c.    '..      ;; ../ 
%%#%;,..##.\_                           ,;###;,. ;;.:##;,.    raf 
%%%%########%%%%;,.....,;%%%%%%;,.....,;%%%%%%%%%%%%%%%%%%%%............

Related Objects

Event Timeline

qgil raised the priority of this task from to Needs Triage.
qgil updated the task description. (Show Details)
qgil added a project: Maniphest.
qgil updated the task description. (Show Details)
qgil added a subscriber: qgil.

There are some UI nubs built for this, they just haven't rolled out everywhere. You can also turn off apps your not using (like Phrequent) to reduce size.

chad triaged this task as Low priority.Apr 29 2014, 2:39 AM
chad added projects: Design, Badge Awarded.

@epriestley - my thought here is to go ahead and implement header buttons for just 'edit' and 'subscribe' across all objects that would support it. It'd provide an easier, quicker means of finding the two (usually) most used actions and reduce height or provide more space for other actions.

We've used them for a bit, so if you feel they should get tweaked, essentially now is the time to let me know. =)

That seems kind of arbitrary and not especially scalable, if the goal is strictly to reduce vertical height. It will reduce height by 2, but if we add 4 more "link this thing to some other thing" in the next year we'll be in a "worse" position.

I would also guess that "Subscribe" is used often on this install, but rarely on non-public installs (I use all other actions except "Start Tracking Time" more often than "Subscribe").

Generally, I guess I'm not really convinced that "there are too many actions" is really a problem. In an extreme case, we could hide object descriptions entirely behind a dialog, and then put all of the actions in an "Actions V" dropdown, so every object had a fixed very small height, but I think this would make the UI dramatically worse. The only application where I feel like there are too many actions right now is People, and that's only because I dumped all the admin stuff in there and we have the relatively-fluff "View Tasks / View Stuff", which should probably just get nuked.

Moving "Edit" to the header will be relatively consistent across most apps, but it feels kind of arbitrary. I don't think anyone has difficulty figuring out how to edit things right now.

Maybe the best way to move forward is to break this down a bit.

Object Descriptions: Part of this task is about descriptions: lots of images, text, or other formatting elements can make a task (or other object) description large.

Personally, I haven't encountered this as an issue on real tasks, and don't find it annoying or cumbersome. A possible caveat here is that I almost always use Phabricator on a large monitor with a mouse and scrollwheel, but I think the tool would be worse for me overall if descriptions sometimes collapsed. I can't remember a case where I found this annoying or where it got in my way, and even this task isn't difficult for me to navigate. So my inclination is not to change this. What do you think?

If we do want to change it, I think the most obvious fix is to collapse the remarkup partway through and put some kind of "Read more..." element. This also potentially gets a little bit messy with things like lightboxes, Command-F in the browser, Javascript-enriched links with Asana/JIRA, and future features like T4190, but is probably technically relatively manageable.

Actions: I think this is essentially what's left over in T4426. My understanding of this issue is: it's not a usability problem and no one has difficulty locating or using actions, but it is an aesthetic problem on some UIs where there are way more actions than properties.

I personally find this problem very mild. The worst case by far is People, and it's a little odd there, but doesn't jump out at me as being significantly "off". I think you and some other users find it more severe, however.

This problem is also at least somewhat more severe on this install than on other installs, because we do not have custom fields (which reduce the severity of this problem by expanding the content on the left) and do have all applications enabled (which increase the severity of this problem by adding content on the right).

So far, we've consistently attacked this by moving a small number of actions to other places on a one-by-one basis. This doesn't scale, and will never actually solve the problem, just spread things across different parts of the UI. I worry it may make things worse overall, by making them look better but be less accessible. In the case of Projects, where we've moved "Workboards" into the Header, I have seen some users have difficulty finding it. This is an exceptional case for a few reasons, but my general point is that we could theoretically solve this problem in an extreme way by finding many new places to put actions, so there were 5-6 clusters of actions all around the edges of the object box. I don't think we'd actually do this, but shifting some actions realtively arbitrarily into the header feels like we're starting down that path.

I'd like to find a solution which attacks this problem systematically instead. Particularly, these menus can have items added via third-party events, and will continue to grow in all applications: Maniphest will get more things to attach to, Differential will integrate with more systems, we may build new infrastructure which spans across applications, etc.

Some approaches which would offer systematic solutions are:

  • adding hierarchy to these menus -- I was pretty into this, but I mocked it up somewhere and it looked and felt a lot worse than I thought it would. This might mostly be an issue of me not designing the interaction well, but it could also just be a bad idea.
  • designing some other multi-stage interaction, e.g. "Administrate User > Change Username", via dialog or some other kind of thing that isn't a submenu per se. (Generally, I still think some approximation of hierarchy is the most promising approach here.)
  • cutting the menu off arbitrarily after X items and adding "show more..."
  • allowing the element to scroll vertically
  • preventing applications from integrating on this menu and then manually curating the items (then: where do we put the application integrations so that they can scale without limit?)

At least for Wikimedia this is definitely a Low/Wishlist task; the current implementation has nothing wrong. However, I believe there is room for improvement. Some ideas to be taken separately or combined:

  • A single "Edit" link, always at the top. Clicking it send you to the edit mode of (task, revision, etc) and from there you can also edit other objects available.
  • "Subscribe", "Flag" and perhaps "Tokens" are candidates to become an icon with tooltip and no label on the right side of the title grey bar.
  • This would leave you with core action underneath "Edit" (here the combo creating subtasks / merging duplicates) plus whatever entries are added by other applications (e.g. Tracking Time).

As a thought exercise, here's what this menu might look like in 1-2 years, off the top of my head:

  • Edit Task
  • Merge Duplicates In
  • Create Subtask
  • Create Dependency
  • Create Similar Task
  • Edit Dependencies
  • Edit Revisions
  • Edit Mocks
  • Edit Commits
  • Edit Pull Requests
  • View Nuance Sources
  • View Facts
  • Share
  • Start Tracking Time
  • Flag for Later
  • Create Event
  • Create Conpherence
  • Award Token
  • Create Short URL
  • Pin to Dashboard

This is an extreme case and we're unlikely to ever build all of those, but users have at least asked for almost every feature these items represent at least once. And this is only first-party applications that we've currently thought of.

But, overall, I'm assuming we'll get there eventually, which is why I'm hesitant about any solution which selects a few specific elements and moves them around: it might work today, but it probably will not work well on the menus of tomorrow.

I would echo the desire to put "Edit X" in the header. Its purposeful, in that if it's the only button in the header, it's specifically about editing that object. Rolling something like this out consistently helps onboard users better to Phabricator. An example I recently ran across was in the Wikimedia discussions where a member couldn't find how to add reviewers to a diff. Obviously there are plenty of places to do this, but new users may not fully understand some of our terminology immediately. "Edit Revision" when listed next to other "Edit" links could confuse users that maybe there is an "Edit Reviewers" button they can't find or don't have access too. So I think there is value in the NUX and eco-system when we can train people to look for "Edit" in a consistent location. For Profile, Projects, etc, this button should be a drop-down to their respective areas.

That said, I also have a pretty good idea on cleaning up the accordion / group diff, we can kick that idea around some more and find a good solution to ship as well.

chad claimed this task.

D8685 provides some relief here, but I don't think that applies to Maniphest per say. In general we'll always be improving general UI libraries on Phabricator and Maniphest will get them for free. I don't see anything uniquely actionable here.