Page MenuHomePhabricator

Provide UI hints about task subtypes

Authored by epriestley on Mar 2 2017, 1:09 PM.
Referenced Files
Unknown Object (File)
Wed, Nov 23, 8:26 PM
Unknown Object (File)
Wed, Nov 23, 8:26 PM
Unknown Object (File)
Wed, Nov 23, 8:25 PM
Unknown Object (File)
Wed, Nov 23, 8:25 PM
Unknown Object (File)
Mon, Nov 14, 12:43 PM
Unknown Object (File)
Fri, Nov 11, 11:27 PM
Unknown Object (File)
Fri, Nov 11, 1:45 PM
Unknown Object (File)
Fri, Nov 11, 1:03 PM
"Love" token, awarded by benwick.



Ref T12314. Open to counterdiffs / iterating / suggestions / skipping most or all of this, mostly just throwing this out there as a maybe-reasonable first pass.

When a task has a subtype (like "Plant" or "Animal"), provide some hints on the task list, workboards, and task detail.

To make these hints more useful, allow subtypes to have icons and colors.

Also use these icons and colors in the typeahead tokens.

The current rule is that we show the subtype if it's not the default subtype. Another rule we could use is "show the subtype if there's more than one subtype defined", but my guess is that most installs will mostly have something like "normal task" as the default subtype.

Test Plan

The interfaces this affects are: task detail view, task list view, workboard cards, subtype typeahead.

Screen Shot 2017-03-02 at 5.01.13 AM.png (430×388 px, 22 KB)

Screen Shot 2017-03-02 at 5.01.20 AM.png (564×569 px, 47 KB)

Screen Shot 2017-03-02 at 4.48.09 AM.png (176×416 px, 19 KB)

Screen Shot 2017-03-02 at 4.47.57 AM.png (232×474 px, 22 KB)

Diff Detail

rP Phabricator
Lint Not Applicable
Tests Not Applicable

Event Timeline

I'm not totally sure we actually need any of this -- it might always be fairly obvious which subtype a task is, in practice -- but I'd guess at least some of these hints are useful. But we could drop some and wait for feedback.

Some other ideas I had, which could complement or replace these approaches:

  • On the detail view, we could put this information in the curtain instead of the header.
  • On the detail view, we could swap the name of the "Edit Task" action for an optionally customizable "Edit Animal" action (e.g., add a string.edit key to config or something).
120–122 ↗(On Diff #41959)

This is old and has no CSS associated with it, per grep.

yeah, I'm not sure we need this yet. I wouldn't mind some sort of shortname/callsign for tasks, that way they could be inline with the task ID or title.


I'd worry that may be confusing because T1234, T1234-FR and T1234-BUG are all the same object, and all but one of reference are just wrong (and which reference is right might change over time, if the subtype of the object changes -- which is very rare today, but possible, and maybe more common in the future).

That is, if we show users that the monogram is T1234-BUG in the UI, I'd worry it will teach them that the object monogram is T1234-BUG, but it isn't (and shouldn't be).

Anyway, I'll just hold this for feedback from installs.

That is what I'm suggesting - allow monograms to be extended with additional meaning and enforcement, even if it's just an alias.

What would the behavior be if you type T1234-BUG but that task is actually a feature request?

What if you just type T1234?

What if you type T1234-BUG, and the task is later changed into a feature request?

It seems to me like that just adds a lot of ways to get things wrong or confuse things? I'm not sure what we gain by requiring you to know the task subtype in order to reference it.

We could do these things:

  • Make T1234 in remarkup generate a tag with a subtype icon if the task has a subtype.
  • Make {T1234} do something similar (or just this form, if the icon in all cases is a little heavy).
  • Add subtype information on hovercards.

But all of these just make it easier to find subtype information, and maybe you're trying to accomplish some other goal?

That is, when users type T1234, we're free to render T1234-FR (the correct value) in Remarkup, but I think that's worse than rendering (little leaf icon) T1234.

There isn't any path I see to using icon/tooltip to denote what a task is. We already do that with projects and I think adding a new treatment confuses the layout further (especially with points). I also don't believe it scales as well. That is, some icons are obvious, like bug, but leaf is not. I'd have to hover. And Font Awesome is great, but I have to think some install is going to subtype 100's... I think text scales there meaningfully, longer.

I simple scenario might be, I go to KDE's project board for Konquerer. I see tasks with "bug-icon, leaf-icon, sun-icon". I'm going to have to hover to understand. Mixed with project icons, it's unclear as a new user what one or the other means. If we separate the UI into (monogram or space, etc), it pulls it out with a different meaning. Even if not perfect, I think most people seeing "BUG, FEAT, IDEA, SPRT", should be able to more quickly understand the context of the task.

I think all the issues possibly with monograms could be resolved, but I've only given it like 5 minutes of thought. Nothing stands out as too hard to figure out.

I'm not specifically tied to using Monogram, I just think it had enough promise to explore / discuss. I think the structure we've built supports exploring the UI in a context of like crumbs. [Space] [Object] [Subobject]

We can just give these "short text" and put that everywhere, and installs can pick "BUG" if they want.

I think "BUG" is more clear for first-time users, but I don't think "FEAT" is very clear, and I'd guess that most installs will have very few subtypes. As an experienced user, I'd rather see and with color cues than "FEAT" and "BUG".

I don't think we should conflate this with monograms. There's no reason cards, titles, lists, etc., can't say "BUG T123 Lorem ipsum..." or "T123 BUG Lorem ipsum..." but I think we purely lose clarity and gain nothing by writing "BUG-" instead of "BUG<space>".

I think "BUG" is more clear for first-time users, but I don't think "FEAT" is very clear, and I'd guess that most installs will have very few subtypes. As an experienced user, I'd rather see and with color cues than "FEAT" and "BUG".

People in general will always have more experience reading [language] over translating iconography. There also looks to be plenty of UX research on this topic as well with similar findings.

Regardless of learning a handful of well chosen and frequently used icons, I think there is too much capability here to make really bad user choices that affect Phabricator's perception as a whole. I think we do need to be mindful how our UI scales just like engineering scales.

Locking icons to a IconSet I think helps a lot.

Does it have to be exclusively icon or monogram hints? We use the new subtype feature very intense - but only with four subtypes. Icon hints would suffice and after one or two days the user would adapt and exactly know what is what. With more subtypes, a monogram could be a better choice. Just let the administrator decide between these two hint types via configuration?

This feature is blocked on design as supporting multiple options increases our costs quite significantly, as each new option is a new path we need to develop, document, test, and maintain for life. Spending time upfront reduces long term costs for us. It does also mean it needs to wait until resources are free. You can obviously patch this diff locally if you just want to use it.

Well, that wasn't so obvious to me 😉 But now patched and happy. Still, there is one suggestion for the future if you will go for forward with this: I really don't understand why the default task has no icon and color. If an phabricator instance is using the subtype feature it just doesn't make any sense to give the default type no hint. When using subtypes the default type then is just like any other subtype... Disabling the possiblity to configure the hint of the default subtype could break consistent representation of the subtypes and perplex the user.

It does indeed look better than the icons. And it is clear and comprehensible. ❤

In D17451#217988, @chad wrote:

subtype_v1.png (686×1 px, 89 KB)

This is beautiful! I Mean - icons can be vague, but red "BUG" and blue "FEATURE" is really better in context. In the long term it can really help with adoption.

Looks good to me, do you want to give PHUITagView a mode for it and I'll rebase this on top of that?

An optional hint for the default subtype (reasoning here) would still be appreciated.

  • Use new outline tags.
  • By default, use the subtype name, but allow users to override it (for example, subtype "Bug Report" can have tag text "BUG" instead of the default, "BUG REPORT").
  • By default, the "default subtype" gets no tag, but you can add one explicitly if you prefer.
  • Icons can still be configured, but are only used in the typeahead.

Screen Shot 2017-05-26 at 1.38.15 PM.png (106×278 px, 12 KB)

Screen Shot 2017-05-26 at 1.33.33 PM.png (136×337 px, 12 KB)

This revision is now accepted and ready to land.May 26 2017, 8:44 PM
This revision was automatically updated to reflect the committed changes.