I'd like to respond separately to the idea of icons. On 16/09/2009, at 5:00 PM, Aryeh Gregor wrote: > I'll chip in that I'm not a big fan of icons. > > * 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. > * 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. > * Icons are often a lot less comprehensible than text. The word > "Reply" in your local language is totally unambiguous -- a little > arrow of some kind is much less clear. The reply icon (in variations) is standard in most e-mail software. 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 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? > Very few icons are so > ubiquitous that they're really as comprehensible as text, IMO > (examples would be the standard "play", "fast forward", and so on). > In LQT I only figured out what one of the icons meant by asking > Werdna. It was apparently meant to be a link from a chain -- which I > didn't even recognize -- and that apparently meant "get a link to this > post" -- which I didn't figure out from the fact that it was a chain, > and which makes no sense in most non-English languages anyway. 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. > * Icons make it a lot harder to reskin the software. You can't even > change the color scheme significantly without all the icons suddenly > clashing. Instead of being able to recolor by adding just a couple of > lines of CSS (which can be obtained from a tutorial or #mediawiki or > whatever if you don't know CSS), you suddenly have to know how to use > Photoshop too. I recolored my wiki (http://www.twcenter.net/wiki) in > a few minutes to match my site's color scheme; I doubt I'll ever end > up recoloring any icons. We don't have a generic mechanism for storing icons and replacing them on a skin-by-skin basis, so most extensions just stick them in the extension directory and refer to them directly. If we were able to implement a generic way of replacing individual icons on a skin-by-skin basis, then I think we'd improve this greatly. 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 > I think the almost icon-free style that the MediaWiki interface has > had to date is the right way to go. 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. 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. -- Andrew Garrett [email protected] http://werdn.us/ _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
