On Wed, Sep 16, 2009 at 12:34 PM, Andrew Garrett <agarr...@wikimedia.org> wrote: >> * Heavy icon use means a lot of extra HTTP requests. > > Non-issue, I think. If we think that icons enhance usability, and we > have appropriate placeholders in place, then we're willing to buy the > extra servers.
It's not just server load, it's also latency that's visible to the user. Both in loading the images, and any subsequent files. Browsers don't load things in parallel very aggressively. >> * Icons noticeably disrupt page load, since the browser has to request >> each separately, and usually it's rendered the empty spot where the >> image should be before it actually loads the image. This results in >> the page changing as it loads, with some empty space appearing and >> then getting filled in. > > With appropriate caching this is generally not a significant issue, > provided, again, that we have placeholders. In practice, caching is not effective enough to moot this concern, especially since on most setups you'll at least have to round-trip for a 304 (which for a small icon is probably no faster than actually retrieving it). I don't know what you mean by "placeholders". > The reply icon (in variations) is standard in most e-mail software. It's still less much comprehensible than the word "reply". Gmail, for one, has both the arrow and the word. In fact there are very few things in Gmail, or any other Google apps I can think of, that are accessible only using icons (i.e., with no text). Needless to say, we could do a lot worse by our UI than emulating Google. :) > I agree, however, that in most cases, icons should be in some way > accompanied by text. Frequently-used icons should have a text > description adjacent to them, and other icons should have a tooltip. > This way, if an icon cannot be immediately understood, the user can at > least figure out what's going on, and know next time. I think icons, by themselves, would usually be worse than text, by itself, maybe in a drop-down menu to save space. For instance, I think the link and edit buttons on LQT threads right now would be better off merged into the drop-down menu. (Actually, the edit link already seems to be duplicated there . . .) This has the advantage of reducing clutter even more than if you use icons. Of course, if clutter is a concern, the first solution should be to cut out UI altogether, not to try making it less obtrusive. > I accept, however, that tooltips are not especially accessible — many > users barely know that they exist. I just did a quick tour of > websites, and it appears that many (such as Facebook) have their own > custom tooltips that appear when one mouses over the appropriate icon. > Perhaps this would be appropriate? I'd be interested in some hard data on how many users actually use tooltips effectively. I suspect it's a significant minority, but a minority all the same. I can't say whether I think Facebook is a good model for UI, since I've never used it. On my current Gmail page, there are four icons I can find with no accompanying text: "open menu", "open reply in new window", "Google Labs enabled", and the star. Only the third has a tooltip. In Google Reader, a quick look finds only one icon with no accompanying text, the star, again with no tooltip. In Chrome, interestingly, there are relatively many icons (although almost all are the standard browser back/forward/etc. icons), and almost all have tooltips. > It's standard in most word processing and web authoring software. > However, as above, accompanying text (tooltips now exist for the > example you present) is usually appropriate. I'm inclined to believe that tooltips aren't enough unless the icon is extremely recognizable (like VCR buttons, the standard browser controls, some standard text editor controls, etc.) or obvious (like a little plus sign to add something to a list, or an X right next to an item to remove it, etc.). > I'm aware that you're also referring to the labour cost of actually > regenerating the individual icons. I think that if there is a > usability benefit You didn't finish this sentence, but I can guess at the end. *If* there is a demonstrated usability benefit -- then sure. Is there? I've seen no data yet. > I think icons help in decluttering interfaces and keeping them > minimalistic. Icons are much easier to find (if they're done properly, > of course) than text. > > The problems you suggest are, in my opinion, examples of poor usage of > icons, rather than problems inherent in icon use. I agree that there are legitimate uses for icons. The edit toolbar right now isn't very good, but it would be a lot harder to find "Bold" and "Italic" and so on if they were words instead of icons. Toolbars in general are cases where you tend to have a *lot* of functions, which (if you designed well) should all be used very commonly, so icons with tooltips is about as good as you can get. Text would take up too much space. But before you get to that point, you should see if they really all are used often enough that they can't be ditched or put in a submenu as text. The only place I can think of where MW currently *needs* icons without accompanying text is the edit toolbar. > Generally, I think users drown in the number of links splattered about > MediaWiki pages. Try finding the "Printable Version" link, and then > try again when a "Print" icon is placed next to it. People tend to > skim, looking for cues, and I think icons are a good way of > facilitating that. I agree that icons are likely to be beneficial in many cases *if* they have accompanying text (tooltips don't count). In these cases most of my concerns are addressed -- latency isn't an issue because the page will be totally usable without the icons, and you don't have to guess even briefly at what the icon means. (Styling is still an issue, but oh well.) My main objection is to icons with no accompanying text, including icons with only tooltips. I don't think we should go overboard trying to make up icons for things with no common/standard icon, though, even if there's accompanying text. "Print" has a very standard icon, and so do a few other things, but let's not try to figure out what a good icon would be for "Permanent link" or "Special pages" or anything. I don't think you could come up with anything helpful in those cases. I do recognize that all of my views here are based mainly on anecdotal evidence, and not much of that. I'm very willing to revise them in light of better data, including both actual studies, and examination of the practices or recommendations of organizations that do good UI (like Google or Apple). On Wed, Sep 16, 2009 at 12:53 PM, Erik Moeller <e...@wikimedia.org> wrote: > Some good discussion about good/bad icons here: > http://usability.wikimedia.org/wiki/Opinion_Icons Interesting, but it mostly seems very specific to the actual icons under discussion there. > Some relevant discussion from another context: > http://library.gnome.org/devel/hig-book/stable/icons.html.en I wouldn't fully trust GNOME to be the best at usability, but this is interesting regardless. This page is particularly relevant: http://library.gnome.org/devel/hig-book/stable/icons-design.html.en "Rule of Thumb for Icon Metaphors "If you have to think about an icon to 'get it', the metaphor is too complex"" Unfortunately, there's not any recommendation I can see on whether to have accompanying text or tooltips, or when icons should be used at all. > I think the Apple HIG have a lot of icon-related guidelines as well, > but can't download the 27MB PDF right now to check :-) > http://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGIntro/XHIGIntro.html Here's a page on icons: http://developer.apple.com/mac/library/documentation/UserExperience/Conceptual/AppleHIGuidelines/XHIGIcons/XHIGIcons.html I didn't find anything very relevant to the current discussion, though. _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
