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).

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.

BUG-T1234
FR-T24115

T12345-BUG
T12346-FR
T12347-IDEA

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).

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>".

In D17451#208787, @epriestley wrote:

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:

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.