Wikimedia blog

News from the Wikimedia Foundation and about the Wikimedia movement

Posts Tagged ‘design’

Designing for the multilingual web

User testing is essential for designing multilingual interfaces, even though it can be a time-consuming process: it ensures that the community of users are part of the design process. In this article, we share lessons learned by the Language Engineering team while designing features and interfaces that empower users to read and edit Wikipedia and its sister sites in many languages.

Designing user interfaces for the Wikimedia world comes with a lot of responsibility. To achieve our mission, we need to make sure we think of users with varying levels of technological expertise and language skills. While the internet can be a very friendly place for those who understand English, it could be like navigating the Greek Wikipedia to the 4.4 billion people who do not.

While designing the user interface (UI) for language tools like the Universal Language Selector (ULS) and Translate extension, we needed to make sure it could be understood and used by those who use the internet in languages other than English. We had to create early representations of the interface, link them together to create interactive prototypes and test them with users. Each of these steps presents various challenges in a multilingual environment.

Design tools generally have poor support for non-Latin scripts. Moreover, creating screens and prototypes in languages that you don’t speak is hard. But since the world needs these language tools, we can’t wait for our design software to improve, we just need to figure out our own ways to get things done.

Creating multilingual mock-ups

UI designers make layout comps early in the process to illustrate how the interface elements and content will be arranged.

While designing the ULS (that will display a massive list of languages), the only way to understand the effectiveness of the layout was to simulate the end result with all the language names. Common graphic design suites are not optimized to manage large number of text elements and have issues when working with non-Latin fonts.

Our workaround: After some exploration, we realized that the most painless way of creating comps that have multilingual text is to render them outside the design software:

  • Create the UI layout using your design tool;
  • Use a template language like mustache to include placeholder text within the mockup and export them as SVGs;
  • Create a translation text file to replace the placeholder text with strings in your language;
  • Perform a string replace in the SVG and rasterize it with inkscape using a script.

There is a neat illustration of the entire process in this video by Pau Giner. This process allowed us to quickly experiment and test comps in many languages by giving the text file to a translator.

Making interactive prototypes

The best way to understand if a design is effective is to observe a user using it. The fastest way to do this is to make click-through prototypes that simulate a workflow. When our multilingual comps were ready, the next task was to package them and link them by hotspots. Most of the popular tools to do this are not free. After scouting around for free alternatives, we chose a Firefox extension called Pencil because it:

Translate extension prototypes in Malayalam

  • imports raster and vector images, including copy-pasting from other design tools;
  • features master pages and a component library to reuse graphic elements;
  • has rich text support;
  • exports to a single HTML which simulates a web page experience;
  • is free and open-source.

It fulfills our requirements, even though there are a few annoying quirks in the interface which could be improved. Check out this interactive presentation of the ULS that was created using Pencil.

Remote user testing

Once our prototypes are ready, it’s finally time for the real test, with users from parts of the world where the primary language is not English (roughly 95 percent of the world’s population). Planning the logistics and schedule of remote user testing can be tricky, so here are a few key points to keep in mind:

Remote user test

  • Create a pool of volunteer user testers early in the design process. Getting a tester is usually a hit and miss, so it helps to have a volunteer base that can be easily reached when needed.
  • Tell users what the test is about. Most users will not know what happens in a user testing session and may be afraid to volunteer. Who likes to be tested anyway? We created this guide to better communicate what the sessions were about.
  • Schedule the tests initially and ask for a confirmation. We found that testers may not be available at the scheduled time and they often want to reschedule. Stay friendly and accommodating, as these people are providing you with valuable feedback.
  • Observe using a platform that meets your requirements. We found Google+ Hangouts to be the service of choice due to its ease of use across operating systems. As a bonus, it can automatically create a YouTube video of the whole session.
  • Inform the tester beforehand on privacy issues. If you want to share the observations publicly, make sure the tester knows and has agreed to those terms.
  • Have fun. Keeping the mood light with initial introductions will help to make the tester feel comfortable and give more feedback.

If you are curious, you can watch this video from our latest test sessions of the ULS to understand how we do it.

We are designing and developing your software, so keep the feedback coming!

Arun Ganesh and Pau Giner
UI/UX Designers, Language Engineering Team

Wikipedia Mobile gets a new look

Design changes to the Wikipedia mobile site include new navigation and updated typography.

This week you’ll see some changes to the look and feel of Wikipedia on your phone, as the mobile team moves features that were tested on our experimental Beta site onto our mobile gateway. The updated mobile site will include a navigation system that makes it easier to explore our content, as well as visual improvements aimed at increasing the readability of articles.1

The new navigation system is designed to make mobile features and settings more discoverable, paving the way for the addition of new features. In the coming months, the mobile team will continue to experiment with and build contributory features. Whether it’s uploading a photo (as with the Wiki Loves Monuments Android app), watching changes to articles, or even editing, we want anyone to be able to pitch in and help make Wikipedia even better.

If you’re just browsing articles, the first thing you’ll notice is the change to layout and typography. We chose these new fonts for improved device compatibility, ease of scannability and reading, and, more generally, to better fit the high quality standards to which all Wikimedia projects strive.2 Our designers will continue to focus on typography going forward, since text is the primary way readers and editors interact with the site.3

Improving how we serve content on the mobile web is crucial for reaching our goal of 4 billion pageviews per month by June 2013, and for providing Wikipedia to more readers in countries where mobile is the primary form of Internet access.

But we’re not done improving the mobile experience—please help us by providing feedback on the new look of the mobile site! You can also become a Wikipedia Beta tester by signing up to receive updates and test new experimental features before they go live.

Maryana Pinchuk, Associate Product Manager

1. The most recent set of updates will be available for users of our mobile website (such as the English Wikipedia on mobile).

2. Studies have shown that certain fonts can influence the perception of content in terms of quality and reliability.

3. The current set of changes are for Latin scripts. Readability improvements for non-Latin scripts will be carried out in cooperation with our localization team.

Wikipedia Mobile gets a face lift

A growing number of visitors access the mobile site of Wikipedia and it is an area the engineering team is keen to improve. To do this, we are offering a more functional and polished experience adapted for mobile users, who operate in a much more confined world compared to those on the desktop.

This week we pushed several new and updated design changes to our beta. We hope these changes will provide a more professional look and a better experience for you. These include changes to the footer, a cleaner design for revealing and hiding sections, and a revamped full-screen search experience. The mechanism for toggling between desktop and mobile has also moved from the footer to the top navigation menu to the left of search to allow users to switch more effortlessly.

References can now be read in place

Full screen search

In addition to this we have also pushed an experimental feature which makes it easier to refer to references on articles without having to plunge to the bottom of the page. Now clicking on a reference will load an overlay which readers can consult without losing their place in the article.

We are keen to gather feedback to stabilise these additions and make these changes available by default to a much larger audience. In particular and as always, we are interested in any device-specific issues being brought to our attention as well as feedback on the new design. Let us know how you find the experience – good and bad and also the quirks that you discover.

We are also experimenting with animations when revealing references and would appreciate thoughts from the community on which is felt to work best. By default, references are revealed by a fade in/out effect but we would appreciate thoughts on whether a slide animation or no animation would be preferable.

Opt in to our beta and try them out today. We look forward to your feedback which can be provided either here or by your involvement in the design process.

– Jon Robson, Software Developer Mobile

UI Design Experiments

In 2009 the Wikipedia Usability Initiative performed research on how to improve the usability of MediaWiki by watching users as they performed various tasks on Wikipedia. Each of the problems that were identified were then matched with potential solutions which were then filtered by technical complexity and user impact. During the development process, yet more features were filtered out because of resource limitations, many of which had even been designed, but never finished.

In a joint effort between members of the Wikimedia Foundation’s community and engineering departments, many of these ideas, as well as some new ones based on ongoing research are being developed and deployed as a series of brief experiments.

Comparison of section edit link designsThe first of these experiments is a redesign of how section edit links are displayed. The current design displays the section edit link on the opposite side of the heading text. During research, users often became confused about which section the link was related to, sometimes associating it with the section above rather than below. Other users did not find the links easily, or in some cases at all. The proposed design was to move the links to be displayed together with the heading text, and to add a small pencil icon to draw attention to the link. This feature was designed but never finished. At the same time as this research was being conducted, Wikia designed and deployed a very similar change to their sites, and reported a measurable increase in the use of section edit links on their wikis as a result of the change.

The experiment is scheduled to be conducted on English Wikipedia from March 9th, 2011 to March 16th 2011, during which time a small fraction of users will be randomly selected to participate in the experiment. During the experiment anonymous statistics will be collected using the ClickTracking extension. Data collected will be used to improve the user experience of Wikipedia and other sites running on MediaWiki. If you would like to abstain from participating in this and other experiments in the future, you can select the “Exclude me from feature experiments” option in your user preferences.

Trevor Parscal, Lead Features Engineer

Usability: Why Did We Move The Search Box?

On May 13th, we changed the default appearance of the English Wikipedia to use the new look developed as part of the Wikimedia Usability Initiative. On June 9th, we unveiled the new look in the remaining top 9 languages (by access volume). Other languages will follow in the coming weeks.

The key elements of the new design had been in public beta testing for many months, and hundreds of thousands of users had already adopted the new look. But, nothing compares to the real thing, and we tried to make the switch as painless as possible — by offering a quick way back to the old layout, by explaining our reasoning, observing and listening to comments carefully, fixing bugs and implementing changes quickly.

The single most frequently expressed concern about the changes we’ve made is the relocation of the search box from the left sidebar to the top right corner. This blog post will give an extended explanation of why we made the change, the other changes we made to the search, and what we’re planning to do next.

The old search box location

The default location of the search box in MediaWiki, the software used by Wikipedia, is below the “navigation” box in the top left corner. This was also the location in the English language Wikipedia, as well as many other language editions. Some language editions, including the German one, had customized the location of the search box, and moved it directly below the logo.

What do we know about search usability?

There are essentially three factors that influenced our decision to relocate the search box:

  • common user expectations regarding the placement of the search box on web pages, as determined by the preexisting body of usability research;
  • usability research regarding ideal search box width, and implications for the search box placement in our layout;
  • ability of our test subjects to locate and use the Wikipedia search box, as determined by Wikimedia usability tests in a research lab.

There are several scientific studies that have examined the ideal placement of common objects on web pages. One early study by Michael Bernard conducted in 2001 by surveying participants regarding the expected placement of web objects such as internal links, external links, and search found that both new and experienced web users “generally expected internal search engines to be located in the upper and bottom-center of a web page. A smaller number expected it to be located at the top right of the page.”

This study was followed up five years later by A. Dawn Shaikh and Keisi Lenz (”Where’s the Search? Re-examining User Expectations of Web Objects”) in a survey of 142 participants. The study found that expectations had changed significantly, especially regarding the placement of the site search engine. The figure below illustrates the areas where participants expected the search to be found:

Expected location of site search engine

As the authors speculate and as seems intuitively plausible, early expectations of the placement of the search box were likely driven by the fact that search was commonly associated only with search engines of the time like AltaVista, not with site-specific searches. As more and more sites developed internal search functions, those were increasingly placed in slightly less exclusive screen real estate than the top center, shifting users’ expectations to look for search features in the top right corner.

Another factor that may have influenced user expectations is the common placement of search engine features in the top right corner of the web browser window.

There are practical advantages of positioning the search in the top right. As summarized in this research paper, several usability studies have pointed out a key advantage of navigational elements being placed on the right: it gives immediate access to the browser scrollbar. This is particularly valuable when a) scrolling up and down a list of search results, b) scrolling up and down an article you’ve just called up for information.

Search box width, and placement implications

 

A separate body of research examines the question what width makes a search box user-friendly. A search box that is too narrow obscures the user’s query while typing, inhibiting their ability to complete their search quickly. Usability luminary Jakob Nielsen recommends an ideal width of 27 characters.

The old search box is approximately 20 characters wide, the new search box accommodates 24 characters. More importantly, due to the placement of the old search box in the sidebar of the layout, widening the search was impossible without either relocating it or widening the sidebar.

The search box placement in the top right allows us to maintain a fixed standard width from one page to the next, while giving us maximum flexibility as to what that width should be. To make it even easier for users, we are experimenting with an expandable search, which is currently deployed in our sandbox 3. When you click the box, it will expand significantly to the left.  We may or may not end up deploying this feature as we continue to look at ways to make search more accessible and user-friendly.

Our own research

In the course of the usability and user experience work since last year, we have so far completed a total of three usability studies, all of which are documented on the usability wiki:

These studies included both remote and San Francisco based participants. While the primary focus of our studies were obstacles people encountered when editing, finding search in the navigation was clearly one of them, and our test subjects tended to resort to common web search engines to navigate Wikipedia instead of using the site’s own search. With the new search box placement, users’ ability to find and use the site search was markedly improved.  One user intuitively used the search box in its new location and then consciously realized that it had been moved.  To see videos of the other subjects finding and using the search box with ease, please see here.

For those unfamiliar with usability testing, it’s important to note that small samples and agile, iterative tests are commonly understood to be an effective method for discovering most key user interface issues. Our sample sizes were actually larger than strictly necessary, and more diverse than typical due to our use of remote testing methods.

With that said, we didn’t test the English Wikipedia against other languages which had placed the search box directly below the logo, and we recognize that this alternative placement is already an improvement to match user expectations. However, based on the cited research above, as well as the design reasons for moving the search box to the top right, we still believe that the overall case for moving the search is compelling even for those languages, if slightly less so.

So .. why did you move the search box? I liked it where it was!

In sum, we moved the search box to a) match web practices and user expectations, b) make it possible to widen it consistent with common usability recommendations, c) in response to actual observed problems of test subjects when using the old search.

We also recognize that millions of Wikipedia users had adjusted to the old placement, and will now have to re-adjust to the new placement. However, Wikipedia’s global audience grows by tens of millions of users every year (it is currently at 375 million unique visitors/month world-wide), and we hope to grow it by hundreds of millions in this decade. That will require that we adapt to common user expectations, rather than expecting every new user to adapt to us.

This will unfortunately inconvenience those who have adapted to the old placement. Do we absolutely know that to be the correct decision? No, but the fact that existing users are temporarily inconvenienced by it is not at all indicative that it is not.

Other search changes we made

It’s worth noting that the search box placement isn’t the only thing we changed about the search function. Perhaps most notably, the old search had two buttons (”Go” and “Search” in English). If you asked even an experienced user what the difference between those buttons was, you would get wildly different answers, and bug 577 had been open since 2004 because of this.

To answer the mystery: the “Go” button attempts to find an article with the same title as the entered search term and, if it fails, runs a full-text search of all articles.  “Search” will always run the full-text search.  “Search” is necessary where you want to search for a word instead of displaying the article of that title (say, you want to search for instances of “George W. Bush” all across Wikipedia).

In the new design, the less common case (search all across Wikipedia for a phrase, regardless of exact match) can be accessed using the “containing …” option in the drop-down menu. We believe this is both a more discoverable implementation, and it reduces overall clutter and complexity of the search.

Measures and coming changes

We are monitoring overall search volume. In the first week since the deployment, we have observed neither a statistically significant increase nor a decrease in search volume, but it’s too early to draw conclusions. There are also confounding variables. As noted above, the search box has changed not just in placement, but also in appearance and behavior. Finally, search volume isn’t the only interesting metric: search convenience (how long does it take users to, on average, find the search) is another one.

We’ll try to get our hands on solid metrics, but we’ll also continue to look for ways to make search more user-friendly (such as the auto-expansion), fix bugs, and so forth. In continuing our efforts to improve the user experience of all our projects, both for new and experienced users,  we’ll try to share our thoughts with you frequently, and work with you to figure out the right answer. And, if you just can’t get used to the new search — you can always switch back to the old layout, which will continue to be there for you.

Warmly,

The User Experience Team

Design students tackle WP

Over at his fine blog, Jakob Voss has highlighted some neat work by design students at Texas State University.

http://farm3.static.flickr.com/2085/2453226990_7230a728db.jpg?v=0From Jakob’s blog:

Mike Perez, design student at Texas State University, and his fellow students Mark Decker and Jacob Brubaker have created a wonderful campaign for Wikipedia in their design class. The posters or ads each show a straight view of an everyday person as an expert on a specific subject and a mind map of their thought process. This are the best ads for Wikipedia that I have seen since the Wikipedia promotion images that André created back in 2005 for the German Wikipedia. Just have a look (photos at flickr only because of copyright restrictions) and enjoy if you like Wikipedia as much as I do!

Nice work! Let us know if you’ve seen any other creative treatments…

Jay Walsh, Head of Communications