-
Notifications
You must be signed in to change notification settings - Fork 38
Icons for common MIME Types available in Data Registry #62
Comments
My Musts:
|
I found a resource that has a TON of mime type icons. It's not perfect in terms of following Material Design Guidelines, but there are a lot of very communicative icons in this set. |
I would move away from their color usage, but some of the folder based icons could really make sense for nested/database datasets. It's also pretty cool that so many mime types are represented here. |
Also, this list isn't all mimetype but many of these could be helpful. https://github.com/file-icons/DevOpicons/blob/master/charmap.md And this list is more mimetype focussed: |
Also you probably want icons that are pixel perfect at the same scales as the other jupyterlab icons. |
VSCode icons might be useful? ...maybe not mime-type related though. |
So I looked around for icons that we might be able to use. Feedback? |
I think the ones we use currently are:
Often a dataset will have multiple of these, so we can set up a priority of them so we just show the first mimetype that matches. |
As a quick catch up here to the work we've been doing in Figma here's an explanation of the current state of work. We wanted to develop a set of icons based on rules that would allow us to generate future mimetype icons on an as-needed basis with as little overhead as possible. @tonyfast , @koliphan2 , and I worked on an alphabet we could use within the contraints of the Material Design Icon Specifications. The original alphabet we developed is here: We wanted to explore more with this so we made a set of constraints, and went about exploring existing fonts we could use for this. The constraints:
Using these I went through appropriate fonts on Google Fonts, working with only open source free fonts. The explorations to date: As shown above we have narrowed the options down to 6 fonts. I'll make individual posts below about the state of each font for further discussion, in the meantime the 'final 6' fonts we're iterating on are: More to come. |
@ellisonbg , @telamonian , @tonyfast , Here are the 'final six' font's we're looking at. Please take a look over these (They aren't showing in the correct size, you'll have to click on each one for it to render in the size. There are a couple things to note: Some of the larger letters overalp finishing the letter with negative space, do you like this look or not? There's two styles here, one with overlapping letters, one with separate letters. I think the separate letters are more readable, but the overlapping letters are quicker to find while scanning if you're used to them, as they register in your brain as both shapes and letters. Please comment on your preference. Some fonts that look good in dark mode don't look great in light mode and vice versa. None of these are final, a little pixel-pushing will be required for each font. Let me know which you think we should throw out, and why. Thanks! |
Anton isn't particularly legible, specifically the N's look a bit like chunk H's I say we can cross that one out. |
Here are the meeting minutes from our call about the final Icons: Font DiscussionNotesIssues to discuss
Fonts
|
@ellisonbg that image didn't render on my end. |
👍 for semi-bold and the slight reduction in (though not elimination of) chunkiness |
But Teko is not monospaced, so all of this will entirely depend on the
letters being used. I don't see any way to get px perfect boundaries with a
variable width typeface.
…On Wed, Oct 30, 2019 at 3:56 PM T. George ***@***.***> wrote:
Ah, thanks.
So we did look at the semibold during our final video call about this, the
reasons we went away from semi-bold are mostly due to how the size fits the
edge of a pixel when rendered on lower resolution monitors. It's less of a
problem on Retina displays as you get 1/2 pixel renders. I've blown up the
icons, with my assessment of which fits 'within' the pixels better. Bear in
mind, text rendered as text will render differently than text rendered as
an image.
Here are the relevant icons. This isn't an exhaustive list, but it's a
place to start. For each of these the top is Teko Bold 12.5, and the bottom
is Teko Semibold 13, so compare each icon with the one below it, looking
for how much of the boundary regions are covering a fraction of a pixel:
[image: Frame 5]
<https://user-images.githubusercontent.com/22109376/67905084-8d0c3b80-fb2d-11e9-9968-e75ec88e3ef0.png>
[image: Frame 6]
<https://user-images.githubusercontent.com/22109376/67905085-8d0c3b80-fb2d-11e9-8e7c-59f311df6f54.png>
[image: Frame 7]
<https://user-images.githubusercontent.com/22109376/67905086-8d0c3b80-fb2d-11e9-89f0-419183eaa3e4.png>
[image: Frame 8]
<https://user-images.githubusercontent.com/22109376/67905087-8da4d200-fb2d-11e9-829c-9345fab5b10e.png>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#62?email_source=notifications&email_token=AAAGXUGYP6VBR6FGA2UTGBLQRIGJDA5CNFSM4IKVOKWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECWA7NQ#issuecomment-548147126>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAAGXUDQJHEPOFBL43M53ELQRIGJDANCNFSM4IKVOKWA>
.
--
Brian E. Granger
Principal Technical Program Manager, AWS AI Platform ([email protected])
On Leave - Professor of Physics and Data Science, Cal Poly
@ellisonbg on GitHub
|
An aside - I think this typeface at this size works well in the square icon
but in the other 2 cases (in the folder icon shape, the NB with the other
stuff) it starts to be too cramped.
…On Thu, Oct 31, 2019 at 11:22 AM Brian Granger ***@***.***> wrote:
I have two monitors - a Retina resolution MacBook Pro and an external
monitor that is higher than 1080p, but still lower that Retina. I also
tried with my normal and computer glasses on. Overall the semi-bold is more
legible. However, with my computer glasses on, the bold is "legible
enough". With my normal glasses I am right at 20/20.
On Thu, Oct 31, 2019 at 11:11 AM T. George ***@***.***>
wrote:
> I don't think anybody here was claiming this was a pixel-perfect
> boundary, let's take a look:
>
> [image: csv-trial]
> <https://user-images.githubusercontent.com/22109376/67973522-e330bb80-fbcd-11e9-9683-b497c070e123.png>
> [image: csv]
> <https://user-images.githubusercontent.com/22109376/67973523-e330bb80-fbcd-11e9-98a3-a571e5cbb57c.png>
>
> [image: tsv-trial]
> <https://user-images.githubusercontent.com/22109376/67973537-e4fa7f00-fbcd-11e9-9c59-4ab4124f769e.png>
> [image: tsv]
> <https://user-images.githubusercontent.com/22109376/67973539-e4fa7f00-fbcd-11e9-9134-e09df2691cc2.png>
>
> [image: notebookcelloutput-trial]
> <https://user-images.githubusercontent.com/22109376/67973531-e461e880-fbcd-11e9-9e51-d7f6ba62f7be.png>
> [image: notebookcelloutput]
> <https://user-images.githubusercontent.com/22109376/67973532-e461e880-fbcd-11e9-8620-3b1780f37499.png>
>
> [image: pdf--trial]
> <https://user-images.githubusercontent.com/22109376/67973533-e461e880-fbcd-11e9-830d-09df83093a9b.png>
> [image: pdf]
> <https://user-images.githubusercontent.com/22109376/67973534-e461e880-fbcd-11e9-8571-06120b1b1d7f.png>
>
> [image: rdf-trial]
> <https://user-images.githubusercontent.com/22109376/67973535-e461e880-fbcd-11e9-9baf-ac64e1791c99.png>
> [image: rdf]
> <https://user-images.githubusercontent.com/22109376/67973536-e4fa7f00-fbcd-11e9-9a3e-5e4dafb6a133.png>
>
> [image: hdf5-trial]
> <https://user-images.githubusercontent.com/22109376/67973524-e330bb80-fbcd-11e9-8992-ea2e51beef88.png>
> [image: hdf5]
> <https://user-images.githubusercontent.com/22109376/67973525-e330bb80-fbcd-11e9-8600-34a1fb840a1f.png>
>
> [image: hdf5group-trial]
> <https://user-images.githubusercontent.com/22109376/67973526-e3c95200-fbcd-11e9-87bd-f3bab3db0b59.png>
> [image: hdf5group]
> <https://user-images.githubusercontent.com/22109376/67973527-e3c95200-fbcd-11e9-9e70-5d37cfc7df1f.png>
>
> [image: notebookcell-trial]
> <https://user-images.githubusercontent.com/22109376/67973528-e3c95200-fbcd-11e9-893a-2edb5d622cf1.png>
> [image: notebookcell]
> <https://user-images.githubusercontent.com/22109376/67973529-e3c95200-fbcd-11e9-87f7-dc742e418a5f.png>
>
> Which of these do you find more legible, tops or bottoms?
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub
> <#62?email_source=notifications&email_token=AAAGXUBKTKMUAVFQUXN4AVDQRMNUNA5CNFSM4IKVOKWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOECYXVWQ#issuecomment-548502234>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAAGXUGY2MFV7NUVMPXVXHLQRMNUNANCNFSM4IKVOKWA>
> .
>
--
Brian E. Granger
Principal Technical Program Manager, AWS AI Platform ***@***.***)
On Leave - Professor of Physics and Data Science, Cal Poly
@ellisonbg on GitHub
--
Brian E. Granger
Principal Technical Program Manager, AWS AI Platform ([email protected])
On Leave - Professor of Physics and Data Science, Cal Poly
@ellisonbg on GitHub
|
The bottom is more legible to me. I don't mind mind the folder crampedness. |
I take preference to the bottom style:
|
I'm looking to make a list of common MIME types we'll need icons for.
Do we have any need to represent data or video files at this point? Do any of those in the not make sense to include for now? Are there any obvious types missing?
I don't have a good feel for what MIME types will be considered 'common' in this use case, please help me populate this list.
The text was updated successfully, but these errors were encountered: