The default blue color is always shown regardless of the specific project settings.
|Resolved||epriestley||T5746 Phabricator does not show project color in Projects Typeahead field|
|Resolved||None||T4420 Modernize typeahead datasources|
|Restricted Maniphest Task|
|Resolved||epriestley||T5750 Implement typeahead browse mode|
|Resolved||epriestley||T7688 Move token rendering into TypeaheadDatasource|
|Resolved||epriestley||T7689 Load handles just-in-time|
|Wontfix||epriestley||T7803 Implement a composite query which unifies cursor paging across subqueries|
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.
This doesn't reproduce on this install. For example, I edited this task (though I didn't save it) and added two more projects that have customized icons:
I think the issue might be confusion about the profile picture versus the icon. For example, on this install, Aphlict has a pretty profile picture but the standard icon. It is showing correctly on this install. Note on the first screenshot the "looks like" UI:
...and here's the edit screen for kicks
AFAIK we don't have plans to let these typeahead icons get too crazy (unlike the infinitely customizable profile pictures), and instead be a standard colors / formats.
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.
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.
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.
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.
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.