Material-design-icons: Naming icons for what they represent – not what they are used for

[adamreisnz]

I often find myself searching for icons on the material icons page and being unable to find the icon I am looking for, simply because of inconsistent or strange naming.

I think the biggest problem stems from the fact that some icons are named according to what they are used for, not what they actually represent. And this can make them really a pain to find.

To name a few examples,

Three icons for the same thing. Why not just "clock"?

How about "bag" or "shopping bag"? I knew this icon existed and spent 10 minutes looking for it because searching for "bag" didn't yield any results.

Why not "wrench" or "tool"?

Etcetera, there are many more examples like these.

[adamreisnz]

Here's another one:

Spent another 5 minutes going through the entire page looking for it, because it didn't show up as "puzzle"

[adamreisnz]

"pencil" ?

[mindplay-dk]

My favorite example thus far is icon-star-half and icon-grade - the latter is the whole star.

For a while I couldn't even find the whole star.

It's a mess 🙄

[mindplay-dk]

I really like these icons, it's just a shame they're so poorly organized.

Going through them all and changing the names to describe the pictograms would be quite a big effort - and it's a breaking change, so it wouldn't make sense before there's a major release.

If I'm going to do it, I'd like to know that this is actually something the maintainers are interested in?

(If not, we'll likely just re-map all the icons to new names in our own project, so our devs can find them.)

[adamreisnz]

Agree, they are a good icon set, but very poorly organised and hard to find.

Here's a another example of the redundancy and inconsistency:

How about just envelope, envelope_open and envelope_outline?
Or mail, mail_open, mail_outline?

[adamreisnz]

vs

Why not chevron_up and chevron_down?

Other naming variations of the same icons:

[mindplay-dk]

There are 80-something duplicates in there, I don't think we need to enumerate them all here?

See also this and that.

What I'm really interesting in knowing is, if somebody actually goes through all of this, reorganizes and cleans everything up, is there any interest from the maintainers to merge a PR full of breaking changes?

For internal use, I already have scripts that filter duplicates, but I'd also suggest a better file-hierarchy strategy and a JSON registry of some sort (which would likely include keywords and categories to facilitate search, which I've also implemented a simple Preact-based front-end for) to prevent erosion of the library going forward.

If the maintainers aren't interested, however, I'm not interested in maintaining my own fork, as that would mean manually cleaning up all future erosion, which is what I'd like to avoid.

[qaid]

I agree this would be a useful change to current and future users of this excellent set of icons.

[mindplay-dk]

With so many versions of the files, all checked into source-control, does anyone know, what is the "source of truth"? Which files are the source files and which are "artifacts"? I don't presume every version of these files were created by hand?

If we were to completely reorganize the files, we'd need to know which files are important, and which ones can be regenerated by scripts - then add scripts to build the artifacts consistently. Currently, there's a lot of mismatch between various types and sizes etc.

[SourceCipher]

Totally agree with OP. The naming is way off. They should have multiple names for each icon. Let say clock icon can be found if you would search for the "clock", "watch", "time" etc. I never get the icon I want and have to go through the entire list to find what I need for my projects..

[adamreisnz]

Yes, either multiple names, or using tags or even a plain text description field with keywords for each icon would make it so much easier to find icons... :(

[SourceCipher]

And I don't think its hard to implement it. Only to come up with about 10 names/tags for each icon will be a time consuming task.

Seems like they fetch json file with all of the icon structure and they should add more keywords to it

[mindplay-dk]

Can anybody answer this?

With so many versions of the files, all checked into source-control, does anyone know, what is the "source of truth"? Which files are the source files and which are "artifacts"? I don't presume every version of these files were created by hand?

If we were to completely reorganize the files, we'd need to know which files are important, and which ones can be regenerated by scripts - then add scripts to build the artifacts consistently. Currently, there's a lot of mismatch between various types and sizes etc.

As far as I can tell, the only files that are actually in use, are the /*/svg/production/*_24px.svg files - nothing else appears to be used or required by the build-script?

There's no documentation explaining where the other file sets come from, and there are various inconsistencies - which icons exist, which sizes exist, filenames, etc.

If I was going to work on this task, I'd at least need to know which files are hand-made or machine-made. Ideally, I'd like to start by purging every file set except the one that's actually in use - then add scripts to generate the other files. If for some reason these are hand-made, I'd need to use a different approach.

Without an answer from the project owner/maintainers, this task isn't actionable.

Perhaps they aren't interested?

[mindplay-dk]

I've started repackaging this icon-library with a meta-data registry that redefines the names and adds keywords to improve search. I'm only through about one-third of the icons, but today was mostly spent building a simple graphical user-interface so I can quickly edit the registry, validate against duplicates, etc. - so it's probably another full day of work to complete this.

If you're curious, you can see the work-in-progress here:

https://bitbucket.org/mindplaydk/kodus-icons/src/master/

The registry gets checked into source-control and can be updated with new icons - it's also possible to add custom icons, omitting Google-specific or very ambiguous icons, as well as adding icons from other vendors/packages, if needed. There's also a script that builds a WebFont and CSS file.

I'll post and let you know when it's done :-)

[lsloan]

Adding my 2¢ to keep this issue alive: I simply wanted to search for icons containing question marks. Typing "question" into the search tool is _not_ helpful.

It's easy to find emoji by keyword using various search tools. Finding these icons should be just as easy.

[mindplay-dk]

Meanwhile, I've discovered the noun project, which has boatloads of icons properly indexed with both noun and action keywords. (I don't know if I care to curate a custom index and clean-up of this icon library anymore - it's really simpler to just hand-pick the ones I need and bundle them as needed...)

[adamreisnz]

The problem I find with those kind of libraries (and similar, like Icomoon), is that once you get icons from different sources, they will not match and your app will look bad because every icon has a different style/slightly different sizing.

The hand-pick and bundle as needed approach is one we took for a long while, but if you frequently update and work on your app, you'll spend a lot of time re-picking and re-bundling icons.

Having a library of consistent style icons that are all available to you through an icon font is what made us go with Material icons, so I'd really like the search/discoverability to be improved.

[mindplay-dk]

@adamreisnz there are hundreds of collections listed that follow the Material icon guidelines.

I get what you're saying though - it would definitely be nice if the official library had better keyword indexes. It's a very difficult and time consuming effort though - there duplicates (which I've managed to filter some of) and near-identicals, plus lots of weird, unexplained or proprietary icons for which I can't even come up with a word.

You're welcome to take over :-)