simple-icons-website
simple-icons-website copied to clipboard
simple-icons
[Suggestion] Add "Icon detail" view
:information_source: If you're interested in this feature, please leave comment or add a :+1:
Kind of issue
- [x] Feature
- [ ] Bug
- [ ] Design
- [ ] Other, namely:
Description
As per this comment, add an "icon detail view". This would display a particular icon at a larger size and potentially give download options such as #31, #32, #33 for that particular icon, as seen in this example mockup.
I'm not sure how useful this is. The larger icon can be nice, but if that is the only benefit I'm not sure something like the mockup below is suitable. The icon-specific download options can be nice, but I would expect that everyone would nearly always want the same download option for all icons.
What it may allow us to do is things like:
- Show everything that is already in the card (the SVG, color, brand guidelines URL, license name & URL)
- Show aliases (https://github.com/simple-icons/simple-icons/issues/4797)
- Show the SVG source URL
- Show the brand website URL
- Option to copy the brand name
- Option to copy the brand slug
- Option to copy the font class
- Option to copy the font code point
- Option to copy the entire SVG (even though that is already possible)
- Option to copy the path data
- Option to copy code to use in NPM
- Download svgs in the brand color (https://github.com/simple-icons/simple-icons-website/issues/32)
- Show the icon in a variety of sizes (https://github.com/simple-icons/simple-icons-website/issues/40)
- More? (Suggestions are welcome)
I'm working on a project wich basically is a list of links, and it uses Simple Icons if one for the link is available. Because of that I sometimes just scroll through your icon list to look for inspiration for more useful links. When doing so I sometimes find logos I don't know. Then I wish there was a link to the website of that product or company to find more information. Would that be a good idea?
Thanks for the suggestion @alinnert, that is something we could include in this view, yes!
However, getting this data (the homepage of the brand for each brand) is not that straightforward as the main project doesn't track it (more on this below) so I'm not quite sure how we would go about implementing it.
For completeness, I believe we shouldn't keep track of this data. Every data point we track adds to the size of the project and ideally it is as small as possible. Storing the URL of a brand that is, by the definition of simple icons, popular seems illogical to me; it's popular so you should be able to find it just by searching its name.
In that regard, the redesign is actually already an improvement on the original. The new website allows you to select and copy the name, whereas the old one doesn't (at least not nicely) because it's part of a download link.
I just realized the array already includes a source property that's almost what I was asking for. I also didn't expect this to be part of the main project after what you've said. But I'd say including this information is close enough, maybe?
With "as small as possible" do you mean the overall collected data and time to manage all that? Or from a performance perspective because the array and space requirements grow bigger?
If it's the latter: In principle it would be possible to add more data per icon in the website project (that's similar to what I do in my project, just with a subset of the icons). Or a build step could map the array to a more basic version (that includes only title and hex). The latter is easier to manage I guess, but the size of the project itself grows again.
it's popular so you should be able to find it just by searching its name.
I don't think that's true for all names. Especially searching for names like bit, byte, RTL (If you don't know it: right-to-left?), Julia, Jasmine, Go (yes, no results about golang on the first page of Google results!), Ghost, Gitter (means grid or lattice in German), HERE, Hey, Highly, and other common words or names probably won't give you the desired results. Then I have to search for (just an example) "Gitter service" in hope that it is some kind of service and not a company or a code library or framework. Do you see what I mean?
I just realized the array already includes a source property that's almost what I was asking for. I also didn't expect this to be part of the main project after what you've said. But I'd say including this information is close enough, maybe?
Though it often lines up with what you're looking for, it is explicitly not indented for that (see the Contributing Guidelines) - it's just that many companies don't have branding guidelines and often their homepage is the best place to find an SVG of their logo. That said, it is definitely something I think we should include in whatever comes out of this issue :slightly_smiling_face:
With "as small as possible" do you mean the overall collected data and time to manage all that? Or from a performance perspective because the array and space requirements grow bigger?
If it's the latter: In principle it would be possible to add more data per icon in the website project (that's similar to what I do in my project, just with a subset of the icons). Or a build step could map the array to a more basic version (that includes only title and hex). The latter is easier to manage I guess, but the size of the project itself grows again.
Both (i.e. reduce "management" and space requirements). Of course we can map that data out if we want, in fact any extra data that appears in the data file - including the new guidelines field - is not published to NPM (as JavaScript, the datafile itself is publisehed in any case, but we don't advice importing that directly).
I do think we can add it, but I'm still personally still against it for the reason that the brands are supposed to popular (regardless of your last argument). I can give two reasons for this, but I don't think they are particularly satisfactory. The first is that I think we should keep to scope of this open source project limited, and making simple-icons a "discovery" tool is not something we should invest our time in. The second is that I don't see any value in the data field for anything other than this website (and other website with the same goal).
That said, this is just my point of view. If you still believe we should add this information to the project, or if you just want to open the discussion to a broader audience, do feel free to open an issue on this topic in the main project :slightly_smiling_face:
I don't think that's true for all names. Especially searching for names like bit, byte, RTL (If you don't know it: right-to-left?), Julia, Jasmine, Go (yes, no results about golang on the first page of Google results!), Ghost, Gitter (means grid or lattice in German), HERE, Hey, Highly, and other common words or names probably won't give you the desired results. Then I have to search for (just an example) "Gitter service" in hope that it is some kind of service and not a company or a code library or framework. Do you see what I mean?
Fair enough, can't say anything against that really. But, as per what I said before, I don't think this project is intended for "discovery" so it doesn't seem to big a problem to me personally.
Alright. Then I'm also for the inclusion of the source and guideline fields in the detail view. Even if it's not intended for discovery, it's still a very helpful starting point. (btw: to me personally the original website is not important, I just wanted a hint in the right direction so I know what a logo or name is referring to. I didn't plan to use that url in my project because I add even more data than that and it's not always a 1:1 match.) On the other hand those guidelines sure are also of potential interest for other users of Simple Icons.
On the other hand those guidelines sure are also of potential interest for other users of Simple Icons.
Agreed, see https://github.com/simple-icons/simple-icons/issues/4900 :+1:
I think this is becoming increasingly necessary with all we're planning to add to the project and packages; trying to display everything on the cards is going to cause too much clutter. We could, as one example, show the slug here and/or the code to retrieve the icon through NPM. Another feature could be providing more options for for copying - see the sidebar on https://petershaggynoble.github.io/MDI-Sandbox/ for some possible examples.
I think this is becoming increasingly necessary with all we're planning to add to the project and packages; trying to display everything on the cards is going to cause too much clutter.
So far, i.e. with only guidelines and licenses, it is still manageable I think.
With the addition of custom slugs and https://github.com/simple-icons/simple-icons/pull/5002, including slugs in the card may get a bit messy.
Regarding aliases, I think it depends what we want to do with those. My take (despite what is in the issue description) would be that it shouldn't affect the design of the cards much. Namely:
- Duplicates: can be displayed as separate card, just with the same SVG.
- Localisation: can be a global option, if your localisation matches for an icon, than we can display the localised name (admittedly, this may cause confusion w.r.t. the slug, so we should definitely display that on the website if we choose to do this)
- akas: should be limited to search and hidden from the user.
- Old: should either be ignored altogether or limited to search and hidden from the user.
Any other things we're planning to add that I'm forgetting here?
or the code to retrieve the icon through NPM. Another feature could be providing more options for for copying - see the sidebar on https://petershaggynoble.github.io/MDI-Sandbox/ for some possible examples.
Those are some interesting ideas, nice :+1:
Is this supppaes to be a separate page or a modal? And what's the trigger, a click on the icon? I suppose that does away with the copy button. Or should both buttons be kept?
We are going to need design suggestions here to proceed to coding this feature. @PeterShaggyNoble @ericcornelissen @adamrusted @mondeja @sachinraja
I like the sidebar design in https://github.com/simple-icons/simple-icons/issues/980#issuecomment-547591284 and I think that would be a great way to proceed. I think we can do away with the copy button and instead include that next to the download options.
I like the sidebar design in simple-icons/simple-icons#980 (comment) and I think that would be a great way to proceed. I think we can do away with the copy button and instead include that next to the download options.
a sidebar that moves the layout of the tickets, or that slides out on top of the page?
Or a fixed sidebar? I don't think I like it if it is fixed.
I think one that slides out on top of the page would be fine. Layout shift is not ideal.
I think one that slides out on top of the page would be fine. Layout shift is not ideal.
agreed. Thank you