You got some valid and some not so valid points here
- It reloads the page 3 times, actually stepping through an edit form,
modifying wikitext with JS, and saving.
Three times? More like two.
- It is 1100 lines of ugly code.
1049 but 'ugly' is a bit over the top.
- It isn't localised.
- It breaks if translations or aliases of the Category namespace are
used.
That is one point (the aliases). Localisation is otherwise irrelevant, as there is nothing to localize.
- It adds random text to the category display, instead of using nice
icons.
Why would you call the + - and +/- links "random text"? And why would icons be "nice"?!
- It doesn't prompt for an edit summary, nor does it provide any sort
of confirmation.
Confirmation should be evedent, as the page reloads with the category list changed. An edit summary is provided automatically
By contrast, my newer version:
- Submits an edit through the API, and selectively reloads the
category section with no user disruption other than a progress spinner.
That is indeed nice.
- Is 300 lines of simple jQuery code.
Also nice. I hope jQuery becomes standard very soon. It was not easily available when hotcat was developed
- Is fully localisable.
Thats nice too, but see above
- Has full support for translations and aliases of the category
namespace.
Good
- Uses icons for the actions.
Not necessarily an improvement
- Prompts for confirmation and an edit summary before making an edit.
Hm, that is somewhat of an inconvenience if you have to change multiple categories, or does your version gather changes and submit them in one edit and one summary?
On Wed, Sep 16, 2009 at 11:37 AM, Daniel Schwen lists@schwen.de wrote:
- It adds random text to the category display, instead of using nice
icons.
Why would you call the + - and +/- links "random text"? And why would icons be "nice"?! ...
- Uses icons for the actions.
Not necessarily an improvement
I'll chip in that I'm not a big fan of icons.
* Heavy icon use means a lot of extra HTTP requests. * 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. * 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. 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. * 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.
I think the almost icon-free style that the MediaWiki interface has had to date is the right way to go. I've noted this before to Werdna more than once, and I've heard other people make the same point, but I don't think I've ever seen a detailed response.
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@wikimedia.org http://werdn.us/
2009/9/16 Andrew Garrett agarrett@wikimedia.org:
The problems you suggest are, in my opinion, examples of poor usage of icons, rather than problems inherent in icon use.
Absolutely agree. I'm personally responsible for some of the most egregious icons in MediaWiki (namely some of the default toolbar icons), which as we've found in our usability study, were utterly confusing to users and didn't help them find key functions. There are well-established visual metaphors for many concepts in MediaWiki, and then there are things which are a lot harder to illustrate, where we may do better without visuals.
Some good discussion about good/bad icons here: http://usability.wikimedia.org/wiki/Opinion_Icons
Some relevant discussion from another context: http://library.gnome.org/devel/hig-book/stable/icons.html.en
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/Conceptu...
On Wed, Sep 16, 2009 at 12:34 PM, Andrew Garrett agarrett@wikimedia.org wrote:
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.
Are you also willing to change the speed of light?
[snip]
I agree, however, that in most cases, icons should be in some way accompanied by text. Frequently-used icons should have a text
[snip]
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.
I think above two snips are not especially consistent with each other.
Icons are symbols. Text are symbols. Each their strengths and weaknesses. Text requires a few bytes to transmit and no horrible speed of light limited round trip. It renders consistently, it better obeys the users scaling requests. It's more frequently non-ambiguous, though it can be ambiguous ... "What does ♻ do?". It can be more accessible and compatible with embedded devices.
Graphical icons can be more attractive, they can take less space, they can be more visually distinctive.
Much of the resistance out there there is a lot of bad design out there that requires the user to comprehend a endless stream of inscrutable glyphs, something much easier to do for experts of the software package in question. ... or when sharp-shooter skills are required to hit the icons made tiny in the name of decluttering. But it doesn't have to be that way.
OTOH, I think + and - characters are absolutely excellent indicators for adding and removing set members. I'm not sure what else you'd use in their place which could be any more clear. All the better that they can be represented a simple characters.
On Wed, Sep 16, 2009 at 12:34 PM, Andrew Garrett agarrett@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@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/Conceptu...
Here's a page on icons:
http://developer.apple.com/mac/library/documentation/UserExperience/Conceptu...
I didn't find anything very relevant to the current discussion, though.
-----Original Message----- From: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] On Behalf Of Aryeh Gregor Sent: 16 September 2009 19:39 To: Wikimedia developers Subject: Re: [Wikitech-l] Usability initiative (HotCatreplacement/improvements etc.)
On Wed, Sep 16, 2009 at 12:34 PM, Andrew Garrett agarrett@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.
Can distribute them across multiple domain names, thereby bypassing the browser/HTTP limits.
Something along the lines of 'c'.(crc32($title) & 3).'.en.wikipedia.org'
Would atleast attempt to download upto 4 times as many things.
Jared
On Wed, Sep 16, 2009 at 5:24 PM, Jared Williams jared.williams1@ntlworld.com wrote:
Can distribute them across multiple domain names, thereby bypassing the browser/HTTP limits.
Something along the lines of 'c'.(crc32($title) & 3).'.en.wikipedia.org'
Would atleast attempt to download upto 4 times as many things.
Right, but it reduces connection reuse. So you end up taking more TCP handshakes and spend more time with a small transmission window. (plus more DNS round-trips; relevant because wikimedia uses low TTLs for GSLB reasons) TNSTAAFL.
-----Original Message----- From: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] On Behalf Of Gregory Maxwell Sent: 16 September 2009 22:35 To: Wikimedia developers Subject: Re: [Wikitech-l] Usability initiative(HotCatreplacement/improvements etc.)
On Wed, Sep 16, 2009 at 5:24 PM, Jared Williams jared.williams1@ntlworld.com wrote:
Can distribute them across multiple domain names, thereby
bypassing
the browser/HTTP limits.
Something along the lines of 'c'.(crc32($title) & 3).'.en.wikipedia.org'
Would atleast attempt to download upto 4 times as many things.
Right, but it reduces connection reuse. So you end up taking more TCP handshakes and spend more time with a small transmission window. (plus more DNS round-trips; relevant because wikimedia uses low TTLs for GSLB reasons) TNSTAAFL.
Indeed, it all rather depends on usage.
There is also that sprite option, combing all the icons into a single image, and using CSS tricks to display each icon. But seems far too much pfaff to keep track of, if want the individual icons as wiki content.
My personal prefered solution would be to have the icons in SVG and embed them directly into the page. But I guess that is not acceptable for the browser agnostic wikipedia audience.
Jared
My personal prefered solution would be to have the icons in SVG and embed them directly into the page. But I guess that is not acceptable for the browser agnostic wikipedia audience.
There are always data: urls, which would also save a roundtrip. But without some serverside support to automatically embed those this would create a maintenance nightmare.
On Wed, Sep 16, 2009 at 6:17 PM, Daniel Schwen lists@schwen.de wrote:
My personal prefered solution would be to have the icons in SVG and embed them directly into the page. But I guess that is not acceptable for the browser agnostic wikipedia audience.
There are always data: urls, which would also save a roundtrip. But without some serverside support to automatically embed those this would create a maintenance nightmare.
These icons are being added to the page by the software, so automatic embedding is no problem. But IE doesn't support data: before version 8. data: with SVG would avoid the extra requests and latency, but then of course you don't get to do caching!
Web development is fun.
-----Original Message----- From: wikitech-l-bounces@lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] On Behalf Of Aryeh Gregor Sent: 17 September 2009 00:46 To: Wikimedia developers Subject: Re: [Wikitech-l] Usabilityinitiative(HotCatreplacement/improvements etc.)
On Wed, Sep 16, 2009 at 6:17 PM, Daniel Schwen lists@schwen.de wrote:
My personal prefered solution would be to have the icons
in SVG and
embed them directly into the page. But I guess that is not
acceptable
for the browser agnostic wikipedia audience.
There are always data: urls, which would also save a roundtrip.
But
without some serverside support to automatically embed those this would create a maintenance nightmare.
These icons are being added to the page by the software, so automatic embedding is no problem. But IE doesn't support data: before version 8. data: with SVG would avoid the extra requests and latency, but then of course you don't get to do
caching!
Caching is still possible, with SDCH compression but only Chromium/Chrome, and possibly IE with Google Toolbar, have implementations.
Web development is fun.
No comment :)
Jared
On Wed, Sep 16, 2009 at 8:25 PM, Jared Williams jared.williams1@ntlworld.com wrote:
Caching is still possible, with SDCH compression but only Chromium/Chrome, and possibly IE with Google Toolbar, have implementations.
In other words it's not possible for what, 95% of our users? But, yes, you're right, SDCH would be useful here. I always forget about because, you know, basically no one supports it.
Actually, does Chrome support stable sdch out-of-the-box these days?
On Thu, Sep 17, 2009 at 1:40 AM, Dmitriy Sintsov questpc@rambler.ru wrote:
Hmm.. just came a thought that it would be neat if the future browsers were able to load small statical content from some kind of resuorce files. Such way css can be grouped into one resource file, icons into another one.
Or both into the same. See a proposal in that vein that Mozilla seems interested in: http://limi.net/articles/resource-packages
Caching is still possible, with SDCH compression but only
In other words it's not possible for what, 95% of our users? But,
And how about HTML5 offline mode cache manifests? That would at best do only one http request to see if the manifest has changed. And would support a considerably larger user base.
These icons are being added to the page by the software, so automatic embedding is no problem. But IE doesn't support data: before version 8. data: with SVG would avoid the extra requests and latency, but then of course you don't get to do caching!
Uhm, SVG and in particular compund document SVG support looks even worse. Nah well, we are getting side-tracked :)
* Jared Williams jared.williams1@ntlworld.com [Wed, 16 Sep 2009 23:07:52 +0100]:
Indeed, it all rather depends on usage.
There is also that sprite option, combing all the icons into a single image, and using CSS tricks to display each icon. But seems far too much pfaff to keep track of, if want the individual icons as wiki content.
My personal prefered solution would be to have the icons in SVG and embed them directly into the page. But I guess that is not acceptable for the browser agnostic wikipedia audience.
Jared
Hmm.. just came a thought that it would be neat if the future browsers were able to load small statical content from some kind of resuorce files. Such way css can be grouped into one resource file, icons into another one. Dmitriy
I'll start by admitting that the way I referred to HotCat was unnecessarily dismissive, and apologizing for this. HotCat was certainly a step in the right direction for usability, and my work extends and improves on the ideas in HotCat.
On 16/09/2009, at 4:37 PM, Daniel Schwen wrote:
- It isn't localised.
- It breaks if translations or aliases of the Category namespace are
used.
That is one point (the aliases). Localisation is otherwise irrelevant, as there is nothing to localize.
- It adds random text to the category display, instead of using nice
icons.
Why would you call the + - and +/- links "random text"? And why would icons be "nice"?!
It isn't really clear what + and - mean in the context, it's much clearer what "Add Category" means (admittedly I've made the same mistake in having a garbage bin as the icon for "remove").
This, of course, needs localisation. I think that if your software has user interaction components, and has nothing to localise, then your interface isn't well-designed.
With that said, there is *one* localisable component of HotCat (the edit summary) that is not localised.
- It doesn't prompt for an edit summary, nor does it provide any sort
of confirmation.
Confirmation should be evedent, as the page reloads with the category list changed. An edit summary is provided automatically
I think it's good to allow people to summarize their edits, and confirm that they want to make them.
- Prompts for confirmation and an edit summary before making an edit.
Hm, that is somewhat of an inconvenience if you have to change multiple categories, or does your version gather changes and submit them in one edit and one summary?
No, but that would certainly be a good idea.
-- Andrew Garrett agarrett@wikimedia.org http://werdn.us/
2009/9/16 Andrew Garrett agarrett@wikimedia.org
With that said, there is *one* localisable component of HotCat (the edit summary) that is not localised.
Although HotCat is not readily localisable and there are some limitations, it can be done with not too much one-time effort by editing the source (e.g. when importing it to a new wiki, as has been done e.g. on huwiki [1]).
Just my 2 cents,
Bence Damokos
wikitech-l@lists.wikimedia.org