On Wed, Sep 16, 2009 at 12:34 PM, Andrew Garrett <agarrett(a)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 <erik(a)wikimedia.org> wrote:
Interesting, but it mostly seems very specific to the actual icons
under discussion there.
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/Concept…
Here's a page on icons:
http://developer.apple.com/mac/library/documentation/UserExperience/Concept…
I didn't find anything very relevant to the current discussion, though.