CategoryUser Interfaces

UI ideas which deserve attention

PediaX: Wikipedia 2.0 (BETA; NOT FOR CHILDREN UNDER 3)

Is it a toothpaste for children? Is it a midget superhero? No, Pediax is a mirror of Wikipedia with some added features. The main added value seems to be:

  • Google Suggest style autocompletion on searches
  • Floating navigation sidebar (left) and table of contents / information sidebar (right)
  • Information sidebar shows collected usage data (most popular pages as well as incoming / outgoing user tracking)
  • Auto-magnification when you mouse over images (load a typical Wikipedia article to test it)
  • Full Google Maps integration for geocoding information
  • Pre-loading of article intros in a pop-up when you hover over links

Overall, my impression is mixed. The entire site doesn’t work properly in Konqueror, so cross-browser compatibility appears to not have been a consideration. Autocompletion is definitely useful; we already support it through the OpenSearch API, e.g., you can add Wikipedia as a search engine to Firefox 2.0 and it will autocomplete the search as you type. There’s also an AJAX autocompletion feature in MediaWiki Subversion.

MediaWiki used to have a floating sidebar feature before we switched to the current MonoBook skin. It’s certainly helpful to have the navigation links permanently accessible. For some reason or other, PediaX seems to lose focus on the main content area quite often, which means I have to click in the middle column to be able to scroll. It also doesn’t handle pages with lots of interlanguage links in the sidebar well; links below the visible screen area appear to be simply inaccessible.

I think more than one floating sidebar is overkill, but being able to “pin” the left-hand bar would be useful together with an expandable or scrollable interlanguage link list. There appears to be a user script hack which does exactly that, but it kills the logo.

I don’t like the auto-magnification; I consider it bad UI design to shove large things in people’s faces when they move their mouse around. Zocky’s Picture Popups user script seems like a better solution to me; it simply shows nice, draggable previews when you click an image. I’ve been using it on the English Wikipedia for a while; the main problem is that it loads licensing information into the picture area from time to time.

Google Maps integration is interesting, though Wikimedia takes a non-discriminatory approach to external services. We’ve been using Magnus Manske’s “GeoHack” script for a while now to show links to various online mapping resources about a particular set of coordinates (example). If something were to be embedded into Wikipedia itself, it should be freely licensed, not proprietary information controlled by Google. Support for OpenStreetMap would be interesting, for example.

The pop-up preloading is a matter of taste. Again, there is a user script which implements this: Lupin’s navigation pop-ups, which also include a bunch of useful editing tools and image previews and can be customized in numerous ways.

It’s nice to see some systematic usability and feature work happening in one place. Those who think that PediaX exemplifies that Wikipedia uses “outdated” technology and is not hip enough to adopt all the cool Web 2.0 toys ought to consider, though, that implementing changes recklessly would easily break the site for a large portion of our users. Our existing innovation model includes the ability for users to write and activate their own user JavaScript and stylesheets, and this has led to many exciting Tools. The best ones, if they degrade gracefully on browsers with insufficient capabilities, should be considered for inclusion in the default view. For the others, we mainly ought to make it easier to select and activate them.

Website Time Lapse

The history of AltaVista, Yahoo! and Google visualized as GIF animations. Would be even cooler with a slider.

OpenUsability reviews German Wikipedia and MediaWiki

OpenUsability has published an interesting report on the usability of the German Wikipedia and, implicitly, the underlying MediaWiki software. They confronted 7 “newbies” with Wikipedia and gave them navigation-oriented tasks.

The problem analysis is reasonable; the recommended solutions are often a bit off the mark. It’s important to note that newbies, regulars and experts all work with essentially the same interface in Wikipedia. Suddenly removing elements from the interface can obviously cause large problems with the latter two groups. Ignoring this shared dependency and focusing on just one user group when proposing solutions is inherently flawed.

I find this to be the most glaring in the suggestion to make the German Wikipedia Main Page less “information heavy” because newbies were a bit disoriented at first. This may be so, but I think keeping the “daily visit” value of the Main Page high is of at least equal importance. I do agree that the editability of Wikipedia should be made clearer; I like this help page from the German Wikipedia, which is sadly no longer linked from the Main Page. An eye-catching image like this one might also be good as a permanent fixture on the Main Page. And, oh yes, image description pages suck. The concept has always sucked and is utterly counter-intuitive.

Another problem they point out are the confusing search button labels. Ever since I added the “Go” button to MediaWiki, Wikipedia has had two buttons to find articles, “Go” and “Search”. “Go” looks for a page with the exact title given (as well as some minor variations in case), and only displays it if a match can be found. Otherwise it runs a full-text search. “Search” immediately runs the full-text search, ignoring any direct title matches. This is, of course, not immediately intuitive, and the participants in the study even found it difficult to distinguish the two after trying them. The authors recommend abandoning the “Search” button. Instead, they suggest that there should be a link on every page that performs a full-text search with the title as a phrase.

While I agree with the assessment of the problem, I find the solution even more awkward than the current implementation. Not only does it remove some functionality (namely, running the full-text search on arbitrary search terms in one click), it moves search functionality into a separate, highly atypical link with a confusing title. What is the right solution? I believe that perhaps Everything2’s implementaiton is ideal: an “ignore exact” checkbox next to the search box. (To be more intuitive, it should perhaps be “ignore exact match”.)

Whether or not an exact match should be shown is a parameter to the search, and parameters are frequently displayed as checkboxes in search interfaces. So this strikes me as the most natural implementation.

The authors also suggest to make the “visited link” color more obvious. With a link heavy site like Wikipedia, anything that is very obvious easily gets very annoying. But I do agree that some tweaking might be in order.

There are, of course, many improvements that could be made beyond the ones suggested by the authors. Autocompletion for search (in the style of Wikiwax) has been frequently proposed. An AJAX-based dynamic category browser and a link mapper (anyone remember The Brain?) would also be valuable tools. The largest usability deficits, however, will be found when the actual process of editing is examined: messy HTML/wiki syntax mixtures, complicated templates, difficult to understand conflict resolution, and so forth. Due to its ties to huge projects and huge communities, MediaWiki development has lost some of its initial agility, and it will be interesting to see what solutions the smaller wiki engines come up with to deal with the same problem sets.

UI idea: Paint selections

Drag and drop is so ubiquitous that we sometimes forget that mouse movements can be meaningful. Mouse gestures have revealed the true power of mouse movements to many users, though lack of standardization and wide integration still limit their usefulness.

In spite of Bayesian spam filtering, I have daily supply of spam and email worms to look through. Usually, I can already tell by the subject lines that it is spam. Nevertheless, my email client (Novell Evolution) requires me to click around a lot in order to select and delete all relevant messages. One typical pattern for interrupted multi-selection in lists is the Ctrl+clck pattern, but it quickly becomes cumbersome, especially because a single false click can destroy your selection instantly.

How about simply painting over the messages I don’t want?

Ctrl+click+mouse-move could switch into “paint mode”. By simply clicking+drawing over the unwanted nonsense, it would get selected. It would be ideal if the selection would change in real-time, rather than after I finish drawing (as the above mock-up might suggest) — then painting over selected items again would unselect them. The paint lines could also disappear as soon as they have taken effect to avoid obscuring the screen.

A similar pattern could be very useful when dealing with rows of checkboxes and might eliminate the need for “Check all” buttons.

No wiki page yet for this idea, but feel free to [[edit:Paint selection|create one]]. Has this already been done in a common office application?

UI pattern: Hover and Switch

I’m sure others have already found a better label for this, but there’s an interesting UI pattern which I call [[Hover and Switch]]. An active area of the client window (e.g. a tab bar) controls the content of the client window (e.g. a browser window). But instead of having to click on an item in the active area, hovering over it for a certain duration of time (e.g. 100 ms) causes the client area to change. Now that the switch has been triggered, simply moving your mouse in the client area causes further switches without any delay. (A similar mechanism is used for showing info bubbles or “speed tips” in many applications.)

This UI pattern is used, for example, by the Tabbrowser Preferences extension to ease browser tab navigation in Firefox: no more clicking required. I can see few reasons not to apply it to taskbar navigation, console tab navigation, preferences navigation, and many similar situations. A problem is, of course, that you may sometimes accidentally cause the switch to trigger. So this kind of pattern can only be used where an accidental switch can never be problematic. In any case, the reduced amount of mouse clickery in my opinion more than compensates for the occasional accidental switch, the likelihood of which is greatly reduced with the time delay.

In fact, after enabling this extension, I found myself hovering over console tabs and taskbar buttons in the expectations that they would switch in the same way. When a user interface is so effective that it changes your expectations in other applications, it deserves a closer look.

One seemingly related idea is to use the scrollwheel to navigate the active area. KDE does this for many of its tabs and task switchers (try it in Konqueror or in the tasklist). The scrollwheel navigation is useful when you want to quickly view the content of a large subset of possible client areas, e.g. cycle through all browser windows. The Hover and Switch approach also allows this – simply move the mouse to the left left or right – while at the same time making it possible to precisely select the client area you wish to view.