We've begun rolling out some design updates to detail pages in multiple applications.
Boring Infrastructure Work
I did a lot of very boring infrastructure work this week on Almanac, Harbormaster and Drydock, to prepare for making "bring your own hardware" builds available in the Phacility cluster. This mostly just made these applications more modern and consistent.
Exciting Design Changes
We've made some design changes to minor applications this week (like Paste and Countdown) that we're planning to bring elsewhere (including Maniphest) in the coming weeks after some refinement.
(@chad's contribution to this change was doing all of the actual work; my contribution was stealing credit for it by saying "we" in these notes.)
Here's a quick visual summary of roughly what to expect from the changes (although each application looks a little bit different):
| Before | After |
|---|---|
 |  |
Some aspects of this design will undergo further changes, but the general idea is that actions and common properties (like subscriptions, projects, and tokens) are moving a few pixels to a separate panel in the right column. This isn't a major departure from the existing design, but improves aesthetics and flexibility.
In particular, this new design gives us more flexibility to layout content for objects, especially when objects have unusual content or a lot of actions. Prior to this change, objects with many actions and few properties developed a yawning vastness of empty space underneath the properties, and this approach allows us to start the content earlier instead.
The new layout will also let us specialize and refine the "Subscribers" and "Tokens" sections, and likely move token/subscribe interactions into the new dedicated sections so we can generally present fewer, more relevant actions in the primary list.
These changes are live on this install, so you can poke around to get a better sense of them if you'd like.
Event Timeline
The new two columns layout is really neat! Any plan on having the second column move along as one scrolls down?
+1 for having the second column position:fixed
As it stands currently I am not fond of moving projects down to the side on maniphest tasks. Maybe I'll get used to it though.
@epriestley @chad [This comment is not specific to the above-mentioned changes, but rather general.]
I'm wondering about what is the point of having so much white space to the left and to the right of a comment text area at the expense of the said area. Unless I'm missing something, it doesn't make any sense to me... Could one of you two clarify?
We have one form display library and it powers all forms. Sometimes we build bespoke forms, but not often. Some future explorations in M1461
@chad Thank you for the clarification and the link. That mockup looks pretty good to me (though I couldn't decode the implied functionality of the "+" icon in the left top corner of the area (to the left of "Add Action"). Also, I'm not sure that forcing people to select the preview tab is the optimal choice - not only it's an extra click each time, but also doesn't give the user an idea about the fit / layout of the text in a horizontal dimension. Just my two cents.
Also, I'm not sure that forcing people to select the preview tab is the optimal choice.
See M1461#7049
@20after4 : I did the same remark in D15396#177349 but according to chad answer, content are just splited, and upstream have not actually designed side bar and main coulmn yet so things will change.
This indeed looks fresh and cleaner, good job.
Just like the above comment, I'll wait a little before giving feedback, other than the below 3 initial reactions I polled internally:
- restricting the width (and thus line legth) in any body of text over 2-3 lines makes it more readable, kudos for that
- however, restricting this much the text editor's width itself makes it feel slightly cramped, and going full screen means losing context and an extra click every time
- it would be great to have the indespensible to us Dependency Graph found in https://secure.phabricator.com/P1094 continue to work in the 2 column design.
I plan to address timeline / commenting separately after most/all layouts are converted.
When managing our task-load the first things I scope out to get "the lay of the land" for a task are:
- Author
- Assignee
- Status
- Tags
- Created Date
I've been poking at the tasks on this install a little and having Author/Assignee/Tags in the bottom right of the page continues to feel a little jarring. Our internal task tool puts this content in the top/left near where the "Before" layout was, so I've likely been conditioned to look there first. This also may be that I regularly need to review incoming/version tasks in order to prioritize and assign appropriately, so those fields are more relevant when I'm glancing vs. when I'm focused on completing the task.
We've talked internally about several other solutions, but we haven't settled on anything specific yet. It's helpful to know in general how often and what people get from this information. I can find it if I need it, but I only look for it maybe 1-2 times a month here, and only ever for curiosity. I don't tend to treat tasks differently because of the date.
There are 3 choices.
- Put in the subheader like on Ponder, Paste.
- Put the date in the sidebar with Author somehow.
- Make the first transaction in Timeline never hide.
Curious which people prefer overall. This would be consistently rolled out in most apps, like Differential/Maniphest/Ponder, etc.
I miss the create date being easily visible. I opened a feature request for this, but was directed here for commenting. The question posted there was "What do I do differently knowing the create date?"
In our organization, the same thing as seeing who created it. For example, let's say it's a key user who is already overworked. We may give that task higher priority than normal, based on seeing who it came from.
With create date, if we see we just have not gotten to this task yet, it's a minor inconvenience but they have dealt with it for a month now, we may bump it up in priority. Initially in the triage, we may not have intended for it to go outstanding for this long, but it has. We really need to get it taken care of, just due to the age. With the new change, we have to go digging for the create date, thus the age.
Maybe this data could be combined, Authored By "John Doe on Mar 1, 16" or something.
I miss the create date being easily visible.
Can you walk us through what you mean? The availability of this information has not changed. If anything, it is now more visible because it appears higher on the page and is more likely to be above the fold.
Here's stable (pre-change):
Here's master (post-change):
The information is visible earlier on the page in master (new design) than in stable (old design). It was not a top-level property in the old design. Am I misunderstanding?
Here are two screen shots
This one you'll see getting at the create date requires some browsing/clicking.
and this one requires scrolling.
The later one is from automated bug submission, but we have many users who do a fantastic job creating detailed reports. Maybe 50% of the time do we have a task like the ones you linked to. More than not, they are like these two.
Sorry, I'm still not understanding what specific change you're concerned about. Isn't the information in the same place -- with the same behavior -- as it was before?
Specifically, how was the information more visible on these tasks before the change? From your screenshots, I don't understand how it was easier to find or what has changed.
Oh! And I'm not saying that this change caused this issue. It has existed for quite some time, we just now are getting around to posting here for discussion.
We cross posted... My initial feature request was not due to this change. It has always been difficult to come by the create date in Phabricator for us. With this change and prior to. With this change, however, it may open an opportunity to put create date on the right column.
Knowing created date helps to understand how stale a task is which is good to know in some cases
- Certain tasks with a given status/tag need addressed in a timely manner (like customer complaints)
- Tasks which have made it to a version but are ancient are likely no longer relevant/important
- Possibly other case that aren't coming to mind
We have means/views/communications for determining & handling these situations already so it's purely convenience, not trying to base decisions around a single date field.
This hasn't changed between master and stable, I was trying to think about how I look at task forms and why I found the new layout out of comfort.
@chad wrote:
There are 3 choices.
- Put in the subheader like on Ponder, Paste.
- Put the date in the sidebar with Author somehow.
- Make the first transaction in Timeline never hide.
I look for the date often, but that's because https://phabricator.wikimedia.org has imported our very long history of bugzilla bugs into maniphest. But probably the most common case for looking at the date is when it's a bug report against phabricator it's self, and after an update I need to check if it was filed before or after the update deployment.
From the 3 choices above, I would be happy with 3. Options 1 or 2 might be marginally better but any of the three would be fine solutions.
I really will miss seeing the projects at the top, personally, but I suppose I will eventually get used to the new location.
The create date is now added to the "Authored By" field. I'll maybe give it a better treatment after we land Differential.
For some reason, I now look for a "quick edit" button on each of the fields in the right pane (like "Projects"). Maybe because they look bigger now?
Maybe that's how GitHub works. There is some discussion on D15432 on why that's not likely easy for us. I do want to clean that up and get a "Claim/Unclaim" action built for Maniphest though.
You know, I just noticed the way that Differential shows created date... Not suggesting a change, just offering it up as a potential place for consistency?
I think the owner of a task is the person assigned. The owner of a revision is the author.
We certainly prefer consistency if possible, but I'm not opposed to being inconsistent if it's better for that individual product (ie, many installs only use Differential). But not sure the 'subheader' layout is going to be it. We'll get everything converted and live with it and see. There may be other options too, but at some point I need to move on.