Breeze and differentiation of file types
Tags:
None
Registered Member 
|
Uri, I am sorry if I made you angry. This was not my intention, neither is it this time. However, as you may have guessed, English is not my native language. Finding the right words is already difficult in French, so my English may have been bad.
Nowhere in my post I was trying to make suggestions. What I did is stating a few problems I have, and trying to understand why Breeze is failing where others succeed. That doesn't mean I want Breeze to look like [any name here].
Previews only work for a few formats. I can't think of a good way to preview databases, executables or XML files. Having to switch away from Breeze is a failure of the theme.
I'm using 48px icons because I think they are the best compromise between clarity and density. At 48px I can see 60 files, at 64px only 48 (25% difference). Anyway, the colour is still much easier to look at than the symbol. (I can see the colour even if I blur the icons, but the symbol disappears. Said otherwise: I can only see one symbol at a time, but I can see the colour of all visible files at once.)
This is not essential, but see this screenshot if you want to understand what I meant. What I call the "folder block" is the visually coherent set formed by folders at the top. The Desktop icon is user-desktop, found in the "Places" category of the icon selection dialog. I'm using it at 48px, but there is a small version too.
As I said, what I was doing is trying to understand why Breeze is failing at a use case very common to me (finding a specific file in a folder containing inhomogeneous content), while other icon themes work great. These lists' intent was to highlight a difference : while in most icon themes file types are very visible, they are much less visible in Breeze.
The small icon set is in fact at 16px, but Dolphin ends up scaling them when 22px icons I requested. The point here it that these icons don't have the same problem: the file type stands out much better.
That's a very low-level vision of what a file is. But this was off-topic anyway, so let's stop here. Louis |
|
Registered Member
|
Is there any chance to see the usability issue described here addressed ?
|
Registered Member
|
Hi Louis,
mimetype small I think that mimetype small icons are very recognizsable because here the symbols are in the focus AND only the color of the symbol show you something special. So first you see picture and than you can separate between png, raw for example. In my opinion the small icons are really good, better than in other icon sets because of the simplification. folders I sometimes thing why the blue standard folder icon looks so "unshiny". The mimetypes are very color intensiv the standard folders aren't. Instead of the colored folders they have more the look and feel of mimetypes. The desktop icon is realy special maybe to special it doesn't fit to the other folders. mimetype large for me the colors of the mimetype are good and useful to separate between the same mimetype block (for example pictures). In difference to the small icons at the large mimetype the color is the first visual information and after that the user recognize the file type (picture, zip, ...). Result For me the small mimetype icons look and work better than in all other icon sets I know, because the focus is on the file type and than on the color. For the large mimetype the focus is reverse. So you look at the color and think zip but it could also be a picture. So maybe we can change the focus to the type. Do you think the same? or I'm not a representiv user? |
|
Registered Member
|
That's exactly what I was trying to say, but in a much less concise way. Maybe using the small icons (maybe rescaled) on top of a more neutral background would work. Louis |
|
Registered Member
|
Ok here we go.
    Result First Screenshot smalle 16x16 px icons works fine, second Screenshot first standard icon size (maybe 22x22 px), third "standard" icon size (I think it is default 64x64 px) and fourth icons "old style". With additional contrast the icons are better readable and recognizable. At small icon size (22x22 px, maybe 32x32 px) the small mimetypes should be used. And there is to much green. The combination 4 will be used for zip, xls, ! jpg !, bak, C, svg, ... |
|
Registered Member
|
Wow. That's impressive what a small colour change can do. This makes the mimetype much more visible, even if I don't think the focus order has changed. Green is also used for Makefiles, INSTALL files, ics, x-executable, svg and odg, and both ods, csv and xls. Some other colours are under-used, like the .djvu green, the .pdf red (as this is a very common format, that's ok), .sqlite and .tex purple. As for icon sizes in Dolphin : the first few are 16, 22, 32, 48, 64, 80, 96, … When a size is not available, the nearest icon (in terms of the small/big ratio) is scaled. So to force the use of the small variant at 32px, providing renders at that size should work. Rendering the 16px icons at twice their size would be a quick workaround, they can be reworked afterwards. |
|
Registered Member
|
Uri, I'm going to overlook the general tone of your response, as it brings nothing good to this discussion, and right now, after reading for third time your first post i'm trying really hard to only be constructive and to concentrate in the subject. I think that my post wasn't disrespectful to get you angry so easily.
Maybe i am misunderstanding you, but after read this statement i have the feeling that this screenshot was made in a synthetic way, with the purpose to illustrate my point in regards of the actual use of the colors on the Breeze icon theme. If this is was you are trying to say, then i must say that this screenshot has nothing special at all. In fact, it is a random capture of my downloads folder. I was programming something and i had to download some files with example code, some of them in tar.gz and other in .zip (or other format, i don't remember). I also have some png and jpg images and a cpp file related with the task i was doing. In the end of the task, i wanted to delete only the compressed files, but i had to read each filename extension to do that simple task because the colors, that is the primary aspect of this icon theme at that icon size, seems to be used in a random way so it's really hard to differentiate between files at first glance (that must be the purporse of a usable icon set, by the way).
Please, we need to focus on the subject. And this is an icon theme issue. This is the main reason for what i did not include file names, status area and side panel information. If the user needs additional information (or to do additional actions, as activate the preview in the file manager) to differentiate between files at first glance, then this is a serious defect of the icon theme. Remember that all these icons share the same form (a document), so the primary aspect of differentiation is the color. The second is the actual file type depicted as a simplified shape inside the document. But this secondary aspect is not enough because it is eclipsed by the the first one. The color is a more strong hint for grouping in this case. |
Registered Member
|
Let me weigh in as someone neutral to this discussion. I will try not to pick sides here, my intention is just to help people provide feedback in a way that is more likely (though not guaranteed) to elicit a positive response. A few hints on how to increase your chances of getting a constructive reply: 1. Avoid expressions such as "this is plain wrong from a usability point of view". Even if you are referring only to a specific aspect of a designer's work, that designer is likely to perceive it as "you are plain wrong from a usability point of view", which is very harsh criticism. This was not what you intended, but designers are humans, too, and may still feel offended even if you never intended to offend them. And believe me, I've worked with enough designers to tell that this reaction is not specific to Uri. 2. Make sure to focus on describing the specific problem you had in your specific usecase. Don't say "this simplification is breaking usability in the most basic function of an icon theme", which is a general criticism. louis does this pretty well here (though at other points in his post, he - probably inadvertently - over-generalizes a bit as well):
This is a subjective description of a real problem. If I received a description such as this, I would say "Thank you for telling us about the problem you have. Now let's see how we can solve this". Talking about a problem clearly from your perspective makes it easier to accept it, because its message is "Aha, this user has a problem with our product" instead of "Our product is bad". This does not make it any less relevant, of course. We don't want our users to have problems. But it allows the designer to address the problem without feeling like they did a bad job. 3. You may suggest solutions to the problem, but try to be as open as possible to other suggestions. What's important first is that we understand the specific problem, so we can all work together on a solution to it. Now to the actual topic: It seems like at least for louis, the problem would be reduced a lot with the contrast tweak that Andreas proposed. Would that modification help you as well, or do you think the problem would stay the same for you even with more prominent glyphs? Let's please bury the hatchet, let's say we understand your problem, now let's find a solution to it. Together. Thanks, Thomas |
|
Core problem: different scenario consideration.
- Uri focuses on the case where you've a dir with many similar files (eg. *.jpg and *.png or *.zip and *.rar) and worries on how to quickly distiguish those. - The concern in this thread focuses on the case where you've a dir with many different files (*.jpg and *.zip - the typical download grabbag  Design restriction: mime icons have one dominant attribute (their color) I'll now just ignore your requests and lecture around ;-P The secondary attribute (symbol) is low contrastred and of equal or lower saturation than the primary attribute (color of the sheet) - this makes them very hard to be seen and, sorry, close to worthless. There's a reason why paper is usually white and GUI background some sort of gray. Also see eg. https://books.google.de/books?id=Q3Xp_A ... CDoQ6AEwCQ https://books.google.de/books?id=qFmS95 ... CDQQ6AEwBw on GUI theory. So my personal suggestion would be to largely desaturate the sheet colors and saturate the symbols to have them stick out. If one keeps the hues sufficiently apart, one can even use a common (low saturation) color per group and keep different (high saturation) colors per type (ie. eg. all images have a sheet of #D5E7F3, but jpegs have a foreground of #11D116, pngs #1D99F3 etc.) I'm however not interested in pointless argues here. It's Uri's theme and if ppl. don't like it, they just don't have to use it - changing an icon theme is no rocket science =) |
|
Registered Member
|
Andreas' suggested modification (see his previous post) goes in that direction (saturating the symbols). Do you think that is already effective, or would the contrast have to be further improved by also desaturating the background? |
|
Registered Member
|
You are right, colomar. Thank you for the hints.
When i wrote the post, i was trying to describe this usability problem as if it was a bug report, as a concise report to get into the track quickly and to focus on the problem without distractions. This is the main reason for what the tone of Uri's responses surprised me. I wasn't intending to insult him, i was just pointing a basic mistake from the perspective of usability, assuming (wrongly) that all people on the VDG team have a background training on usability theory in UX design. There is nothing wrong with this, as a UX team must be multidisciplinary, but from time to time, the work must be supervised by someone with experience and a background in usability theory, to avoid basic mistakes in the final product like the one that i was trying to report in this thread.
With this tweak is a bit better, but i'm afraid that is not enough to differentiate between them clearly at first glance.
I think that with the changes suggested by luebking the problem can be greatly reduced, if not resolved completely. Good work! 
|
|
Registered Member
|
Sorry, but you're doing it again: You imply that our icon designers have no usability training and that this is a "usability bug". However, you might have noticed that the current design makes sense from Uri's perspective: It was optimized for folders that contain files of the same group (like the default setup of ~/Documents, ~/Videos and ~/Pictures), in which indeed the specific file type (e.g. jpg vs. png) is more important information than the general type. However, it turns out that for at least some of our users (you being among them), folders with different general file types in them are a more common case, and for that case the current design works less well. This problem could have been caught beforehand if we had tested the iconset with a representative group of users. This has not happened because we currently a) don't have access to such a representative sample of users b) lack the resources to conduct such tests Yes, this isn't an optimal situation, but for the moment we have to live with it. If designers with usability training could easily put themselves into all their user's shoes when designing, user research and usability testing would not be necessary. However, that is not the case. So please, try to not imply a lack of skill on the part of our designers. The only effect that will have is demotivating them, and with the huge amount of work they're facing, we cannot afford that.
Well, let's see how we can further improve the situation, then.
We are currently thinking about how to improve the situation further, and are considering this idea as well. |
|
Registered Member
|
I'm sorry, colomar, but i have to disagree. All I'll explain in this post is a clarification of why I think that way from a purely engineering perspective, in a constructive way. I do not pretend, under any circumstances, that this post is interpreted as an attack on anyone in particular. Peace. I didn't wrote that the icon designers have no usability training. I wrote that i was assuming (wrongly) that all people on the VDG team have a background training on usability theory in UX design. This doesn't imply a lack of skills on the designers. This implies that maybe some of them can't understand my first post in the way i wrote it (as a bug report) because they didn't have the knowledge to understand it in that way. And i wrote too that this is not a wrong thing per se, because an UX team ussually is multidisciplinary. That's all. Now, why i think this way. Before I could answer that I have to describe a part of the methodology used in engineering to design user interfaces. The design of a usable user interface adds three new activities to the software engineering process:
Analysis and design. The analysis activity has as main objective to obtain a series of documents that we will use later to do prototyping and usability evaluations. At this activity, we create an user profile for each significant category of users. For the task of icons creation, we could have two user categories:
Profile 1: to differentiate each file type easily. Profile 2: to differentiate each group easily. Note: These requirements may seem contradictory at first glance, but they are not at all when you think about it carefully. After this, other documents are made, although i think that these ones are more related to software engineering that for icon design. For curious people: documents of persons, scenarios and tasks analysis. The last document to be performed in the first activity is the usability goals document. These goals must be measurable and must have a scale,so we can test it later using the prototypes if they have been achieved or not. For example, in our case, this could be a possible a goal: Average time taken for a new user to find a particular group of three icons of the same type in the same group within a set of 10 icons, all shown on screen at once so the user does not have to perform scroll. Prototyping. Once we have the above documents, the prototypes are made and they are tested with the users in a iterative process. The look of the prototypes will be driven by the overall look and feel that artists want to give them, but they must meet usability requirements continuously. During this activity some principles are used. I'll describe, in my opinion the most influential ones for the task we are analyzing: the icons design. The principles of human perception that artists have studied but the rest of us can ignore. The principles of Gestalt:
Then there are the design principles: alignment, balance, visual noise, etc. but these are more related to graphical interface design than to icon design. Other design documents that are made in this activity are: navigation paths, dialogue sequences, etc. but this also are more related to the design of graphical interfaces.  Ok, the bored stuff is over. Now, i'll explain the reason i think that way about VGD team. If the creation process had followed a similar path that the one i described (taking into account the available resources, which I know are few and also volunteers), then the requirements of the most common user profiles would have been considered from the first stage, and then they might route the icon design to satisfy these requeriments. But they are not. They only satisfy the requeriments of one user profile, throwing out the other requeriments of another common user profile, and thus, generating bad usability for it. Furthermore, by not considering one of the most common user profiles, the color used for the types of icons goes against the strongest of the principles of the Gestalt, the similarity, so files of different groups are grouping together and causing confusion to the recognition of the files in the same group. Hence i was asserting that not all VDG team have the knowledge that I have expressed previously, as if they had, all these things would have been detected in the analysis and design phases, so that the final version of Breeze theme would not have the problem that we are discussing in this thread. And I repeat it again, my intention is not upset anyone, not to insult or belittle the team and its work. They have done an excellent job, but there are some little things to improve. And that is the only purpose for which I write all this. Also, take into account that english is not my mother language, and some expressions may seems rude or misleading. If they are, i apologized for that too. Cheers, and keep the good job. |
|
Registered Member
|
Here is the pull request for changing the contrast. the lightness was changed to 15%. https://github.com/NitruxSA/plasma-next-icons/pull/123
About the icon layout I would discuss something here. We have now the document style for the background and the file type in the middle. the document style is always the same (redundant) only the symbol change. Would it be a good idea to make different background styles for (audio, zip, image, video and documents). Than we have the document style, document color and symbol to separate the files. a raw draft 
|
|
Registered Member
|
You are right in that no human-centered design methods were applied in the creation of these icons, and that had they been applied, this problem would probably have been caught during the design phase. That does not necessarily mean that our designers are not aware of these methods. We'd have to ask Uri and Andreas about that, I simply do not know. I know that I have a strong background in human-centered design theory, principles and methods ("user" has been part of my job title for about four years, and I've spent another > 3 years at an institute of ergonomics), but I was not involved in the icon design. I do not have the skills nor time to do the design myself, and since our designers are volunteers, I have no right to tell them how to do what they do.
If it sounded like I implied you were upsetting Uri on purpose, then I'm sorry for that. I never had the feeling you were doing this on purpose. I merely meant to give you a few hints on how to lower the chance of upsetting designers with feedback on their design, based on my experience from working with designers. As a usability professional, communicating your insights in a way that does not upset the designers is almost as important as gaining those insights. You say you're an engineer, so perhaps giving usability feedback to designers isn't an important task in your job. Maybe it is, and you were just lucky to so far only have met designers which are not easily offended. I don't know.
I guess kver is the only native English speaker in this thread so far 
|
Bookmarks
Who is online
Registered users: Bing [Bot], daret, Google [Bot], Sogou [Bot]
