Original stuff works now, but I think we should let you choose new labels for the icons and colors too (e.g., relabel "An Umbrella" as "Miscellaneous"), or "Red" as "Security" or whatever. Possibly we should adjust some of the default labels ("An Umbrella", "The Cloud") now that they're exposed more prominently in the UI, too. Maybe:

• Briefcase -> Default?
• Garbage -> Cleanup
• An Umbrella -> Miscellaneous
• The Cloud -> uhhh "Services"? I guess?

Relabelling, etc. would be a nice addition. A couple of those references would not have occurred to me without a little prompting.

Even nicer, though, would be the ability for administrators to easily extend/replace the image set.

We're unlikely to let you change the icons. Are there specific icons you'd like to see added/removed? You can see all the icons available here:

https://secure.phabricator.com/uiexample/view/PHUIIconExample/

Well, if I could select from that icon set, then no problem. Can't do it currently though, unless I've missed something.

Examples of entities other than projects that one might want to represent using icons (at least in :

• Programs (i.e., super-projects or project portfolios; actually, I like for that).
• Sprints (although would probably work for that from the existing set),
• Software components/packages (no idea)
• Support teams (, I guess)
• Process improvement (not sure what would be a good fit, but , or something similar)

No doubt others would make different associations, which is why I think it would be useful to have this at least somewhat customizable.

If I had to work with multiple OS's a lot more than I currently do, I could see the use of the OS icons as well (, , , etc) for quick sorting projects.

We tried to pick icons that are generic, not specific. So teams, not support team, maybe OS not specific OS.

We don't let you select from the entire set because we reserve some icons to identify other types of objects. For example, when you're typing into a "Subscribers" field, you're allowed to add users, mailing lists, or projects.

The icon identifies users, and identifies mailing lists, so we don't want to let you use those for projects because it would create ambiguity.

We have many different teams - Maintenance teams, Support teams, Service teams, Process improvement teams, etc. Marking all of those using a generic team icon isn't really all that helpful.

I can see where the ambiguity argument comes in for regular users, but I don't really see that it applies to the question of allowing site admins to decide which icons are available, which is more what I was thinking of. We hopefully have a pretty good idea of who our users are and what works for them. There is never going to be a specific icon set that will fit everyone, so being able to configure for ourselves which icons our users can employ would give us a lot of much needed flexibility - as opposed to cramming a static set of icons and terms down our users throats that are guaranteed to cause confusion for them.

YMMV, but in my opinion being able to configure these sort of things is important. How people interpret names and images depend a lot upon the corporate culture they come from, and it is a lot easier to get people to accept a tool if its symbology and terms fit (or can be adapted to) what the users are accustomed to.

@michaeloa - where do you work? You've piqued my interest about a company that has many teams, each with a distinct representative icon that each individual in the company can use to discern one from another.

cramming a static set of icons and terms down our users throats that are guaranteed to cause confusion for them

As the upstream, we have to support Phabricator, and doing things like preventing UI ambiguity makes it easier to support because it means users make fewer accidental mistakes. Although you and everyone at your organization might never find this confusing or make a mistake with it, we have a lot of users from different backgrounds and with different skill levels, and many of them do make careless/silly mistakes regularly. Making it more difficult to make silly mistakes makes the product easier to support, so we can spend more time building features.

We have a very small team and provide support for free, so providing support impacts product development directly. This makes it particularly important to reduce support costs.

We haven't seen other feedback that the default set of 16 general purpose icons causes confusion, and overall feedback about this feature has been positive, so it sounds like your organization may be particularly unusual or have specialized needs. We can't reasonably accommodate every special case in the upstream, and we think that pushing back on special cases is a big part of what makes the software good.

If you require an exceptional level of configurability, Phabricator is open source and you can modify it freely. Here's where the icons are defined:

https://secure.phabricator.com/diffusion/P/browse/master/src/applications/project/icon/PhabricatorProjectIcon.php;6669fe9e8a70e368acf6f055fe47953fb671f489$5-25

I can see going to 20 or 25 icons, but we're reserved about that for the time being until more use cases arise.

If there is a specific UI deficiency that has been overlooked, I'd rather talk about that. ie, we have 20 things named "support" and it's difficult to find them in the typeahead. Or, "we have 20 support teams, I want to be able to search for them on /project/".

@btrahan: Government (in this case, MET Norway). Our IT department needs to deal with everything from purchasing super-computers over development to customer support, so we end up with many different kinds of project teams. And although the development department is the primary force driving for adoption of Phabricator, we need to keep in mind the needs of the entire IT organization. If the developers end up using Phabricator as a project/task management tool, we don't want the infrastructure unit using a completely different task management tool covering almost the exact same functionality. That way lies maintenance hell.

@epriestley: Thanks for the code pointer; it'll be useful if we find the icon set too restrictive. But obviously, I'd rather not hack that sort of thing in due to the potential upgrade issues it will cause - I'd rather do the code change properly when I have the time and add configurability if it were of interest upstream.

Also, please don't take this feedback as a sign that we're not positive about this feature. If we're asking for more, it's because we like what we see.

@chad

If there is a specific UI deficiency that has been overlooked, I'd rather talk about that. ie, we have 20 things named "support" and it's difficult to find them in the typeahead. Or, "we have 20 support teams, I want to be able to search for them on /project/".

Perhaps I wasn't clear enough in my description, because the latter case is pretty much why this feature interests me. We'll probably have something like 20+ service teams (we have a lot of different services), maybe 5-10 open-source dev groups, a bunch of support teams, plus miscellany - and that's before we've added in actual projects (and their sprints). Being able to search using icons and color, as suggested in this feature, will be very useful.

Whether there are 16 or 25 icons is not really important to our use case. 16 icons would probably suit us fine, if all of the icons were usable for us. The reason why I'd like to customize the icons is that I'm already sure that a handful of them won't be: e.g., I'm not sure where we would ever get use out of , or in a project context.

Either way, if it becomes annoying enough, we'll just have to hack it, as Eric suggests.

Thanks for your time.

I would like to see more icons for projects (obviously from D10529), as we are using them to tag tasks etc as Features, Bugs, Defects, Enhancements, Design, and then our actual projects as well.

I have read a few places where projects may/should also be used for milestones, not that I really agree with that one, but the current icon set for projects isnt really helpful to label any project.

Having an icon that would match the project was my goal with the commit, I understand it can cause confusion with other aspects of the system, but there is already a cross over with the "All Users" policy, and the "Team" Icon for projects. If its always displayed alongside the project name as well, I cant see any confusion coming in, esp when you have to configure the icon/project name.

Seems like a lot of requests are being pushed onto using projects, but not really enhancing the project app to deal with those issues.

Having an icon that would match the project was my goal with the commit, I understand it can cause confusion with other aspects of the system, but there is already a cross over with the "All Users" policy, and the "Team" Icon for projects. If its always displayed alongside the project name as well, I cant see any confusion coming in, esp when you have to configure the icon/project name.

I would agree that matching icons is best course of action. The moving forward plan then would be to remove the hard-coded image sprites for Project Icons and migrate them with the same set provided in the typeahead from FontAwesome (less resources on the wire, better consistency). If you feel the current icon choices (like team and all-users) are incorrect or could be better, I would file that as a separate task for discussion.

Seems like a lot of requests are being pushed onto using projects, but not really enhancing the project app to deal with those issues.

Is there a specific task that is impeding development at your company? Please ping if so. Things that are fall under 'enhancement' or 'nice to have' obviously are going to have lower priority, see T4778 for specific discussion of task prioritization. Generally, your diff is easy to maintain as a fork or local path. That would be our recommendation if this is important to you.

Agree with @bajb. I feel the problem is that Projects are a bit of a catch-all app at the moment. There aren't really any other alternatives for organizing users, tasks, etc., so it's easy to end up with a lot of different things crammed under the Projects umbrella. This is not necessarily a bad thing, as the concept seems flexible enough to handle it, but it does require a bit of flexibility if that is the case.

That is the intention, for Projects to provide buckets for anything (I think we have some regret at this point not naming them "Tags" instead given their power). Is there something specific you are having issues with?

Nothing beyond stuff that I've already bugged you guys about: i.e., customizable icons and labels would be great, more powerful search capabilities (gather stuff from all projects I belong to, etc)

I do wish you had named them Tags instead too. Would save me from having to include a disclaimer about how "Projects" are not "Projects" every time I introduce someone new to Phabricator. I've ended up having to include a slide in the talk/course I'm doing on Phabricator for our users that specifically addresses this point.

Having said that, I love the flexibility that the mechanism provides by virtue of not being just a "Project" entity.

Yeah, we may be unclear here in the product. Our intent with the typeahead icons is provide a hint at the type of project (team, tag, milestone, company, etc) and not directly describe the project. We could probably present a better UI for guiding that.