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
agarrett(a)wikimedia.org
http://werdn.us/