Community
Participate
Working Groups
Opening this bug for a separate discussion of how the default e4 styling should use part icons. The original mockups in bug 293481 only show the icon for the selected tab. From bug 293481 comment 8: > - removal of view tab icons except for front tab The mockups look good except for the above one item. I think its better to have icons. Pictures are always quicker and easier to identify the item, rather than reading the characters (one can know the time by having a glimpse at the analog clock rather than the digital clock - the reason why most of the clocks are analog). Its easy to recognize a tab by its icon rather than by reading the title. And also assuming we go without an icon, what happens if the title has two words (Package Explorer, Project Explorer, ...). Won't it appear as if there are two views?
Some comments I've received offline about the view/editor tab icons: - some folks have thought editor icons are intentionally treated different than view editors. This is not the intention in the first mockups. The active stack's active tab is treated differently. - we will add a "multi word" tab to the mockups to investigate the overall issue of how to visually separate the views/editors that have multiple words. The whitespace between "tabs" is much greater than the whitespace between words, but there's no basis for comparison in the mockups - the purpose of view icons and editor icons is different, so perhaps they should be treated differently. View icons help to distinguish the view and also emphasize the graphic used when the view is a fast view in the trim. Also matches the "Show View" graphic and can be helpful in finding the view amongst a bunch of tabs. Editor icons help to indicate what kind of thing is being edited, and their usefulness largely depends on usage patterns - if everything you edit is java, they are less useful, but if you work with a lot of different editors, it's a different story. Regardless of outcome here (it's all under iteration) I expect that the specific case of using icons or not will have to be "dead easy" to change in the stylesheet - ie, a property that is surfaced vs. something that's harder to find/edit.
(In reply to comment #1) > Editor icons help to indicate what kind of thing is being > edited, and their usefulness largely depends on usage patterns - if everything > you edit is java, they are less useful, but if you work with a lot of different > editors, it's a different story Boris also pointed out that the same file might be open in three different editors at once (particularly common when the compare editor and Java editor are open), so using only the name is not enough.
It just goes to show everyone's different, but I find the view icons mostly useless. If you lined up a list of view icons from Eclipse without titles, I probably couldn't tell you which is which. I find this in particular for editors, which only tell you what kind of file it is, which isn't all that useful since the file extension tells me the same thing. Then again, I also never use toolbar buttons, and find it easier to tell time with a digital watch than an analog clock - maybe I'm just a verbal rather than visual person. It could also be because I use a high resolution display, which causes those view icons to be so tiny it's hard to make much sense of them without squinting at them. Some ideas... perhaps it could show the icon on mouse over like we do today with editor tab close buttons. Or, show the icon when there is plenty of space available, but remove it automatically when the tab folder gets crowded. Just to throw out an exception - the JUnit view conveys important information in its view icon, so it would be a definite loss if that went away.
Interesting, I look for the icons first rather than the label... Obe of the main advantages to the icon is that it only takes the space of about 2 characters. This comes in handy for folks that like to have a lot of views open in a stack, limiting the display area for each tab.
I am too in the camp of people who generally don't find icons useful. BUT: icon decorators convey important information, such as warnings or errors in Java files. So, I'd vote for removing icons, but adding decorators to the tabs :-).The type of editor could be included in the tooltip for those rare cases when it is interesting.
Created attachment 156040 [details] Image showing FireFox's use of icons It's interesting that one of the 'new' (ish) features of browsers is the ability to show icons in their tabs. Check out the attached image, note that you can pick out the two non-bugzilla tabs very easily. The icons may also be serving a fairly subtle purpose; they act as separators, ensuring that I see 'n' separate tabs rather then one long string of characters. The more subtle the visual affordance for a tab is the more important the icons are.
+1 for having icons on by default. The icon is an important part of deciphering the identity of an element in the workbench, and is used consistently across views and dialogs (eg, navigator views, open type/resource/task dialogs). This consistency makes the users "chunk" the image+icon information. For example, when using Mylyn, the users gets accustomed to seeing a critical bug they're working on with a red overlay on its icon and will use that to pick it out of the UI, either ignoring the label or only committing the start of the label to memory. If editor tabs are being used to navigate between items, the icon supports the user quickly picking out the item without needing to read a good portion of the label. This is particularly relevant for editors, where the user is switching frequently between a relatively small number of items. I realize that there are exceptions and that some individuals are more verbal than visual. Also, when working with 10 Java files this is not as much of a problem, especially since the start of a Java class is often named in a unique way. However, in the general case, I think that removing the icon will re-introduces additional cognitive load on the user by forcing them to read the label more frequently then the would need to if the image were present.
Quick update on this issue - the use of the icons is related closely to the treatment given to tabs. We've been playing with removing treatment from the tabs, perhaps even the selected tab, and using color/typography to distinguish the selected tab. With all tab treatment gone, it's even more important for the visual distinction between tabs to be more obvious. We're finding that white space isn't enough (as brought up by others), so the use of the icons help to solve the tab boundary problem, in addition to the UX issues folks have pointed out here. So the current mockups are moving back toward "icons all the time" but with a faded look that becomes fully visible on hover and selection. We're also playing with spacing and reserving space for the close box. If you reserve enough space for the close box, it's too much space when the close box is not showing. If you don't reserve it, then you need to reflow the "tabs" when a tab comes forward. So we need to play a bit with how this feels interactively. (Note that we reflow the tabs today in Eclipse, but there is much more visual stuff going on - selected tab color changing, tab shape changing - that makes the reflow only part of a bigger change). We'll post more mockups when we're reasonably happy with tab treatment, spacing, and such, but the current thinking is that the icons will stay and fade back.
+1 for keeping icons. * I often have many editors open. When looking for an editor I use the icon as a visual cue to help me find the editor that I'm interested in. * Icons have overlays (such as warnings/errors) which provide more information about the state of the file. * I sometimes have multiple editors of diferent kinds open on the same file, the icon helps me to discern which editor I want/need. * In general I agree with Susan's original statement about pictures being quicker than words.
(In reply to comment #9) > * In general I agree with Susan's original statement about pictures being > quicker than words. Actually, that was Prakash (I copied his thoughts over from another bug). It seems like most folks find editor icons useful, some find view icons useful. We're additionally finding them useful for solving tab treatment issues. The challenge will be fading them back enough so they don't overpower, without losing their usefulness....that's what we're playing with now.
marking fixed in M4. The e4 CTabFolder renderer always shows the icons. The design mockups show that the icon will be faded out on non-active part stacks, but they will be there. Closing this bug as fixed, since its intention was to discuss and come to a conclusion. (ie, we did not implement a way to turn off the icons in the CSS as originally stated in the bug title, but the result is that we don't need to).
