Where specifically is this?

While editing a task:

People use icons and colors to differentiate types of projects. Sounds like people have a demand for better differentiation between projects that represent a group of people and projects that represent something else. In the UI, I'd rank group projects higher for fields which are more related to people.

OK, I assumed this would have been completed with T4420, but it was either missed or I can't find the precise task.

Well, we're not doing tag colors at least, the icon is correct.

We could add the colors but I want to wait until after T4100 since that might be a stronger argument for use of color.

I'd like to emphasize that the ideal would be Project differentiation. In my phab instance, we're using prefixes. E.g. [G] SomePeople to name the group of people, [T] MyTag, [L] LibBar, etc.

That is why icons and colors are provided, so each install can make their own tool. Are you wanting another layer on top of project creation that does icon/color for you automatically?

"Project Templates" or something?

So, the icon shows up, but the color doesn't.

And yes, a bit differentiating projects might be useful. In fields "Visible to" and "Editible by" I'd like to get list of people ranked higher. In the "Projects" field, I'd like to get list of tags ranked higher.

The specific issue with color is that, after T4100, I want it to be clear when you've selected a parameter/variable in a typeahead, like "My Projects", "Members of Project X", "Me", etc. These values will resolve dynamically at runtime.

If we colorize the tokens now, we may need to adjust the colorization after T4100 if we can't find a way to clearly communicate which tokens are variables vs normal tokens without visual ambiguity. This could be confusing, since the tokens would colorize in one way and then later change to colorize in a different way.

Basically just a UI question: how do we show both "variable" tokens and project tokens in a way that they each stand out unambiguously? Something like a different border style or different tag shape might work, or a different font style or weight, or just colorizing only the icons for projects, or something else, but I'm hesitant to colorize project tokens until we have a path forward here that we're happy with.

The solution may include Indigo.

In T5746#26, @igorgatis wrote:

I'd like to emphasize that the ideal would be Project differentiation. In my phab instance, we're using prefixes. E.g. [G] SomePeople to name the group of people, [T] MyTag, [L] LibBar, etc.

This is essentially the same that we have ended up doing, but it's an ugly solution.

I'd say that there are actually two needs that we have in this respect, neither of which is unfortunately fulfilled with the icon/color thing.

• Sorting/grouping projects according to the "type" of project.
• Querying according to the "type" of the project. If I want to find a specific team, I do not also want to browse through miscellaneous tags, administrative units and other projects - I just want to see the teams.

Having explicit differentiation isn't the only way to handle this, but it does seem to be the most straightforward approach.

Where do you want this additional sorting, on /project/ page itself? I could see adding icon/color to the list of options to query/group on in ApplicationSearch.

Yeah, doing so from the /projects/ page would seem to make sense. At least that's my go-to place when I need to find projects.

Adding search on icon and color would solve at least part of the issue.

I'd like sorting in the "Visible to", "Editable by" and "Projects" fields in task edition pages.

See T4136.

Added T5819 for additional queries around icon and color as a starting place. T4011 is a more general task for building a new /project/ home.

In T5746#69560, @epriestley wrote:

If we colorize the tokens now, we may need to adjust the colorization after T4100 if we can't find a way to clearly communicate which tokens are variables vs normal tokens without visual ambiguity.

In terms of UX priorities, I think the first priority is that whatever exists today is consistent. A red token is a red token, and if it shows blue somewhere, they you are colorizing it already. For no good reason (today).

Yes, variables need to look different, but maybe you can do that simply by reserving an icon and a color only available for them.

We're still looking at possibly tweaking things a bit here (e.g., see T7858) but project tokens/tags now have consistent coloring.