FileTypes: Use rounded square for audio icon #1111
Conversation
Switches the shape of the audio mimetype icon to more closely resemble the style of other binary mimetypes. This makes the audio mimetype look less like a document.
|
I'm a little torn on this one. I'm almost more inclined to go the other direction and make sure some of the other mimetypes like video, photos, etc are using the document shape. I'd kind of rather use the squares to represent things that are either applications or parts of applications as opposed to files. Right now we have a bit of confusion where some icons are used both to represent an application and a file (like calendars) and I don't think that's helpful |
|
I was a little concerned about it looking too much like an app icon. I was hoping that by using the same gradient style as the other mime icons that it would look enough like a mimetype to not be confused with an app icon. Especially since they are to be seen in context with other mime icons. This is similar to what was done with flatpak and flatpakref icons. It is easy to differentiate between what is text and what is not. I do think that using the document/sheet of paper style and aspect ratio for things that aren't a document or that don't represent a text-based file is a little confusing. The document/paper shape and ratio is a visual cue that I think to most would indicate text, especially when some of them (likely the most common ones) do have text on them. So when you see a document shape with text on it and then a document shape with a music note, it is difficult to understand that when the first one represents something that will open as text-readable that the second one will not do the same. This gets more confusing when there are icons like markdown, vala, etc that do not have text on them but are still text-readable files -- the document/paper shape still indicates that they are text files which is correct. So the fact that they have visuals on them that aren't text is still okay because the icon shape itself still indicates a document. But for audio, video, pictures, packages, etc this doesn't make a lot of sense. Another example would be the subtitle and video file. If they both look like documents, it's difficult to tell that one is text and the other is not. Same with the playlist and audio icons. I think the way you can distinguish between flatpak and flatpakref is a good way to address it. So I think it would be helpful to have a different shape and/or look for binary, non-text-readable icons. |
|
Here were some other styles I played with:
1 - Current document icon Not sure if any of these would be better or still not the right direction. |
|
Another alternative that's used by some other icon sets is to have non-text files use a colored background with a white symbol. That way we always use the same shape to indicate file vs app but we have a way to indicate binary file vs text file |
|
Here's some exploration with different content types:
In the top variation, for some reason totally square corners on non-text files feels weird to me. I'm not sure why. In the middle variation I tried using the same border-radius for everything, but this also feels weird to me for some reason. I'm not a huge fan of it. Maybe it's just a big change from what I'm used to, but I dunno something about it seems odd. In the bottom variation I tried using half the border radius for files and archives vs exectuables. I think I like this one the most tbh. I also wanted to throw in a variation where we always use the same color package for archives. Though maybe it makes sense to have a different background for archives that open in programs other than the archive manager. Thoughts? |
|
@micahilbery thoughts on the above? ^ |
|
The audio one is very similar to the older audio icons, which I always really liked! If it's okay to reintroduce that style I think that's a nice way to do it. For the mockups, I'm torn between row one and three for text and non-text files (although I prefer the executable/package rounding in row 2, I don't like the heavily rounded borders for document and non-text files). Rounded borders of documents in row 3 looks a bit odd to me. But at the same time, sharp borders on non-text files in row 1 also looks a bit odd to me. But like you said, could just be that it's something that takes getting used to. How would you feel about a progressive rounding based on the type of file?
I think this gives good visual clarity. And it would be the most practical to implement as it would minimize the amount of files that needed to be reworked. |
|
I did a few in this style and in different colors to see how it would look once more were added. I do like the idea, my only concern is that they may be a bit loud/distracting and may overshadow other icons. But it could just take some time to adjust. Gonna spend some time living with them. Just thought I'd attach them here in case anyone else wants to try them out.
|
|
I guess another thing to consider is that there are some non-text file icons that use more than one color in their symbolics
|
The audio mimetype icon currently has the look of an icon that would represent a document or text. Most mimetype icons that represent binary files use a different shape (Package, Video, Executable files use a more square shape).
This switches the shape of the audio icon to more closely resemble the style of other binary mimetypes and makes the audio icon look less like a document.
I used the new
image-missingicon and adjusted the gradient, borders, and shadows to match the current audio icon. I think this gives it a mimetype look while the shape differentiates it from a file that represents text.