Pau Giner

Keep & Share: exploring concepts for the future of Wikipedia

Mon, 19 Feb 2024 23:58:35 +0100

Learning is a journey. Currently, Wikipedia is a great resource to support you in your learning journey. In this exploration, I illustrated how Wikipedia could support people through more parts of this journey.

The ideas presented in the video below were discussed and prototyped in unconference sessions at two consecutive recent events in Nairobi and San Francisco (and some airports in between).

Some key ideas illustrated in the video are detailed below:

Responding to different learning needs. Different people at different moments may follow a different learning process. From looking for a specific answer on Wikipedia, to getting immersed into the story from beginning to end (possibly with some rabbit holes in between).
Smaller and richer knowledge units. We can think of a Wikipedia article as an assembly of smaller information pieces that can be accessed and manipulated both as a whole or independently. This notion provides flexibility to support new possibilities. A visual overview can be provided with key information about the topic in a way that individuals and communities can customize it. For example, an individual can include an interactive map as they explore multiple articles on animals to understand their habitat. This can be useful for that user or proposed to be part of the default view of the article.
Explore and collect. Keeping all the great things people learned from Wikipedia at hand can be quite powerful to build a “second brain”. Not only to find them again, but also to keep track of updates, and contextualize them. Putting information in context helps to build an understanding. The elevation of Nairobi is just a number, comparing it to other cities of Kenya or your own city helps you to get a better idea.
Remix and share with traceability. Relevant pieces of knowledge can be reassembled by people for different purposes: a slide deck for school, a video for social media, an interactive graph to be embedded on a news site. This helps Wikipedia knowledge to reach where people are. More importantly, contents can be connected with the original pieces of information. In this way, people can verify where the information comes from, and check any updates or inconsistencies in the future.
Support active readers. Providing ways for readers to participate more blurs the lines between readers and editors. Active readers can participate in collecting the information they are interested in, following the updates on such information, and providing useful signals. Some example signals: indicate that they learned something new to surface a particularly relevant piece of information, flag content that lacks references (“citation needed”) to signal it may not be trustworthy, or propose possible changes as a lower bar into editing. This can be useful to distribute a bit of the load from editors to the larger reader group, as well as making readers more aware and familiar with participation to encourage them to try more active editing too.

The way the ideas are presented in the video is one possible way to execute the ideas for illustration purposes. With a quick prototype that skips over many details. This is not part of any ongoing project. The intention is to inspire others.

It’s been a while

Wed, 15 Mar 2023 13:11:24 +0100

Meeting people in person after a long time. After these last pandemic years of travel restrictions, I’ve been able to meet in person with the different people I collaborate with. Including the Design team in Paris, the Language team in Hyderabad and the San Francisco colleagues in the office.

Design team offsite in Paris

The Design team was meeting in Paris and it was the first time meeting in person for half of the team. The offsite was great to connect and re-connect.

Wikimedia Technology Summit in Hyderabad

The Language team was meeting in India. Dates were selected right before the Wikimedia Technology Summit in Hyderabad. In this way we could combine team meetings with the participation in the event. In addition to the official program where the team presented and took part of several panels, it was great to interact with the conference attendees which included people from the industry, academia and Wikimedia movement.

Back to the San Francisco office

As part of annual planning exercises I had the chance to be back to San Francisco after four years and work a few days from the office. More about the annual planning work will be shared soon.

A blog post about the Wikimedia Design style guide was recently published.

Sat, 12 Sep 2020 08:20:12 +0200

A blog post about the Wikimedia Design style guide was recently published.

The origin was a conversation with David Golberg about the construction of open participatory design systems and some parallelisms with architecture.

Content Translation: impact beyond numbers

Thu, 02 Mar 2017 21:03:39 +0100

In the past I wrote about the design process of Content Translation and how the tool was born. The tool has been growing since then. While still in beta, it is showing a positive impact already as it was highlighted in the recent Wikimedia Foundation annual report.

Last summer the project crossed the milestone of one hundred thousand articles translated. This video celebrates the achievement:

It is really great to see that the tool is frequently used by translators. However, the biggest impact of a tool is not always captured just by numbers.

I was excited to hear that the Medical Translation Task Force was interested in trying our tool. They are a group of users devoted to reduce the language barriers for health knowledge. Having access to essential health information, such as vaccines, can make a big difference on many people’s life.

After a trial, it was amazing to read that they boosted their productivity by 17% by using the Content Translation tool. This means more people will have access to essential information in the language they understand.

Translating articles about vaccines is something I could not have contributed much directly. So it is really great to see how through design you can help others to do so and contribute a bit on relevant but unexpected areas.

Another less known aspect about Content Translation is that by using it you are also contributing for translation services to get better in the future. As you create a translation, your contribution is published as a collection of translation examples (technically known as parallel corpora). This information is publicly exposed through an API and is very useful for researchers and developers of machine translation services in order to improve their approaches or create new services.

Spreading the word

We want to help as many people as possible to break language barriers in their different areas of interest. The possibilities of the Content Translation tool have been discussed in different venues and we are always interested to spread the word more.

Last June we organised an event for the San Francisco design week. I had the opportunity to talk with people from the Google team that worked on the Google Translation toolkit. We had an interesting discussion about the design principles that aligned our tool with the way people translate on Wikipedia.

Santhosh, a member of the Wikimedia Foundation Language team, presented the tool at the Unicode Conference where attendees were interested in the technical challenges the tool solves. Content Translation was also presented to a very different audience at “Translating for EU" an event organised by the Directorate-General for Translation of the European Commission.

The tool has been also used in many other workshops, editathons and university courses around the world. We love to hear your stories about your experience using the tool, so feel free to ping us.

Next steps

As the tool becomes more mature we are improving several technical aspects but we wanted also to polish different aspects to make the tool more consistent with the evolving Wikimedia design guidelines.

These design improvements include the evolution of the visual design of the tool as well as improvements in some of the workflows such as making the process of starting a new translation more fluent. You can read more about this initial design refresh on the Wikimedia blog.

Another area where the tool has been evolving is in template support. Wikipedia uses templates to format content in a consistent way. the infoboxes (tables with quick facts that you can find at the beginning of many articles are just one example).

Initially the tool didn’t provide support for templates because of their complexity. After several explorations we came with a concept based on the same principles we applied to the rest of the tool: supporting translation in a visual way, making it possible to translate as much as you need and getting the support of translation services when available.

Initial research based on a prototype showed it was a promising approach and we added initial support in the tool. There is still a long way to go in this front, but we are happy to have improved already the support of a frequently requested aspect.

In February 2016, I gave a talk in a TEDx event organised by my...

Wed, 09 Mar 2016 20:17:09 +0100

In February 2016, I gave a talk in a TEDx event organised by my university in Valencia (TEDxUPValència). The talk (in Spanish with subtitles available in other languages) explored the potential of global collaboration tools and the challenges in their design.

It has been a real pleasure to participate with a great group of speakers and an amazing organisation. You can check the videos for all the talks.

The design of Content Translation

Thu, 16 Apr 2015 07:52:17 +0200

Content Translation is a tool that facilitates the translation of Wikipedia articles. The initial beta version was launched for several languages and it has been used already to create more than one thousand articles.

Designing this new translation experience has been an exciting journey, but before going into the details you can check how the tool works in the video below.

The translation process with Content Translation is quite simple: click on a paragraph to get an initial automatic translation, improve it, and repeat for the next paragraph until you are ready to publish your new article. The tool feels natural to our users and saves them time:

I can now translate a 20-line article in less than 5 minutes, saving lots of time.

However, not so long ago, when I started the design process, a translation tool for Wikipedia was just a blurry idea full of interesting challenges.

The problem to solve: translate the sum of all human knowledge

Translating Wikipedia articles was not a new concept. Multilingual users currently make about 30% of Wikipedia edits. However, little support was provided in the software for the process of translation. As a result, users had to take care of many boring aspects that prevented them from focusing just on crafting great content.

There have been previous attempts to improve this process by big names in the tech industry. Tools such as Google Translator Toolkit or Microsoft Research Wikibhasha are interesting tools in this area, but they didn’t get a wider adoption. As it is detailed next, we think the reason is that these tools were probably too rigid to fit in “the wiki way” of translating.

Design principles: translating the wiki way

What is “the wiki way” of translating? What means to translate in the Wikipedia context? what is different from translating other kinds of content such as technical documentation or user interface messages?

The project started with many unanswered questions, but we relied on the design process to lead the path to clarity. The support and appreciation for design by all the members of the Language Team was key to figure out the right answers. Simplifying the experience for users often means to move the complexity from the user to the software, which the engineers at the Language team always perceived as a challenge worth taking.

During the project we collected a lot of information from many different sources: conversations with experts from the Language team, existing documentation on community conventions and recommendations for translation, research on multilingual users behaviour, and interactions with different members of the community with different expertise in translation (below you can see a screenshot from our round table with some of the early adopters of our tool).

We identified three different user profiles for the tool: the casual translator (a multilingual editor not always confident about the proper way to translate some words or sentences), the advanced translator (focused on increasing the language coverage and expecting a fluent process that does not get in the way), and the new editor (for which translation could be a simpler route to start contributing than starting from scratch). Casual translators represented our main target audience but we wanted to keep a balance between the simplicity new users needed and the shortcuts to speed up the process for advanced translators.

We organised periodic user research sessions to better understand the different user needs during the existing translation process, and to validate new ideas on how to improve this process. We recruited participants through a survey and organised 17 research sessions. Most of the sessions were conducted remotely using Google Hangouts with participants from all around the world.

As the project evolved, we learnt more about the current process of translation, and several ideas were explored on how to improve it. As a consequence, a greater percentage of each session was devoted to the testing of more detailed prototypes. Once the initial implementation for Content Translation was available, it was also included as part of the sessions.

The research sessions were instrumental to understand the particularities of translating in the Wikipedia context, and guided the design of the translation experience. Below you can find some of the principles we applied in the design of Content Translation.

Freedom of translation. There is a significant diversity in Wikipedia content across languages. On average, two articles from different languages on the same topic have just 41% of common content. In contrast to other kinds of content, such as software user interface strings or technical documentation, Wikipedia articles in different languages are not intended to be exact translations that are always kept in sync.

In order to support that content diversity, Content Translation does not force users to translate the full article. Users can add one paragraph at a time to the translation, deciding how much to translate. When a paragraph is added, an initial automatic translation is provided (if it is available for the language), and users are free to correct words, rearrange sentences or start with the source text or an empty paragraph if that is preferred.

Provide context information. In Content Translation, the original article and the translation are shown side-by-side. In addition, each paragraph is dynamically aligned vertically with the corresponding translated paragraph, regardless of the difference in length. This allows users to quickly have an overview of what has already been translated and what has not (with just a single scrollbar). This is one one of those details most users will not even notice because it just feels natural.

Contextual information is provided at different levels to reduce the need for the user to navigate and reorient. When working on a sentence in the translation, the tool will highlight the corresponding sentence in the original document to allow translators to easily check the original context. In addition, when manipulating the content, options such as exploring linked articles (in both languages) are provided to anticipate the user’s next steps in order to make the experience more fluent.

Focus on the translation. During user observations we identified steps in the translation process that could be automated. Users spend time making sure each link they translated points to the correct article in the target Wikipedia, recreating the text formatting that was lost when using an external translation service. They also look for categories available in the target Wikipedia to properly classify the translated article, and save constantly during the process to avoid losing their work.

Content Translation deals with those aspects automatically. When adding a paragraph, the initial translation preserves the text format and links point to the right articles if existing. In a similar way, existing categories are added to the article and user modifications to the translated content are saved automatically.

In addition to removing distractions for the user, it was important to focus on the scenarios the tool was intended to solve, and more importantly, those it was not. Working closely with the product manager we decided to focus on the creation of new articles by a single user. Other scenarios we identified initially (such as multiple users editing in real time the same translation, or extending existing articles) had to wait. Focusing in one scenario allowed the team to iterate faster, provide value to our users early, and learn from the actual use of the tool to inform future steps.

Quality is key. One of the concerns raised early by the participants was about machine translation quality. Several users were concerned about the potential proliferation of low quality content in Wikipedia articles if the translation process was made so easy and machine translation was into the mix.

In order to respond to that concern, Content Translation keeps track of the amount of text that is added using machine translation without further modification by the users. When the amount of text exceeds a given threshold, the users are provided with a warning message. This message is intended to educate the users about the purpose of the tool and to encourage them to focus on quality more than quantity. Finally, if a user publishes an article with a high level of automatically-generated content, the resulting article can be marked for the community to review. So far we have not received complaints on the quality of the articles produced with the tool. After three months of launching only two articles got deleted form 708 translations published.

Exploring solutions: iterate, iterate, and iterate

The above principles and solutions were the result of many iterations. We explored multiple options for several aspects from the content layout to how to show multiple translation suggestions. For those explorations I like to apply quick sketching techniques such as 6-8-5, where you timebox yourself to quickly explore as many different design directions as possible. Below is an example of 6 different ways to show language information for the translation content.

Once we had some promising candidate ideas, I prepared some mockups at a higher fidelity level and illustrated how they would work in a video. The video, which was useful to frame the conversations with the Language team, is shown below.

In order to test our ideas with users, we build several prototypes at different fidelity levels (and using different tools). From basic clickable prototypes made with Pencil, to an advanced HTML prototype where users can have rich interactions with the content (e.g., typing and applying different language tools on the content). The later went under 40 revisions to simulate new features based on the testing sessions (including the translations to test with users in different languages). Finally, some small prototypes made with Hype with a very specific focus were created to test aspects such as the card-based layout for language tools or how to add links using text auto-completion.

As the tool was taking shape, the design team at the Wikimedia Foundation was also growing. This resulted in feedback from all my great colleagues that was very useful to improve the tool, review the testing process, and make the designs better aligned with the general design direction for Wikimedia projects.

More details on the design of Content translation can be found at the project page and on this research paper.

Next steps

Content translation has the potential to reduce the language barriers in Wikipedia. Currently the amount of knowledge you can access depends heavily on the languages you are able to speak. Although it has been a great start, there are many pending steps in this road.

For the initial stage of the process, covered in this post, the main focus was to create a translation editor that made translation easier and faster for our users. Our results show that once users start a translation with the editor they are able to complete it successfully and users are happy with it.

The goal for the next stage is to bring new users to the translation process and keep them translating by helping them to find interesting content to translate. Some of this work has already started with the great help of Nirzar Pangarkar and is showing already an increase in the number of translators using the tool, but there are many questions yet to be answered.

You can get the latest news about Content Translation through this twitter account, and if you are around Mexico this summer we can discuss more details about the design of the tool during my talk at Wikimania 2015.

Interaction 2015: talks and beyond

Thu, 12 Mar 2015 10:10:32 +0100

Last month I attended the IxDA’s Interaction conference with other members of the Wikimedia Design team. We organised a workshop as part of the event, and attended many talks. In a nutshell: three days of listening and talking to lots of designers in different settings.

The talks on stage

Videos of the talks are available so those unable to attend the conference can check them out. From the top of my head I can remember many great talks, but I recall these four especially:

Matt Jones talked about communicating the potential of projects from the beginning. In addition to performing one of the greatest presentation intros ever, Matt emphasised the need to project the future when communicating design ideas and provided examples of interesting projects (including the Project Ara, Google modular phone).

Leah Bulley presented an an interesting survey on UX role in across different organisations which was really useful to set the coordinates of where we are and where we want to go.

Mike Monteiro introduced the common mistakes designers make when presenting their work. In addition to being quite fun to watch, this talk will challenge some of your habits and help you to be a better designer (or a better professional in general).

Ayah Bdeir talked about the challenge of simplifying the language of electronics. In addition to introduce the history of LittleBits and the need to learn and experiment on how things work, she walked us through her story on what meant for her to be a designer or not.

I’m sure you can find more talks worth watching, and I’m going to check again to see what I missed due to parallel sessions.

Beyond the stage

Many talks were great, but the most interesting part of the whole event was to find yourself in casual conversations with other designers. From a designer you read his book about ten years ago, to the designers solving the interaction challenges of self-driving cars of tomorrow. From designers well-know today to the young designers that will be well-known tomorrow.

One of the recurring topics in different conversations and talks was about the responsibility of designers to contribute to a better world. Different people set the line at different points (superfluous social networks, banks, companies building weapons…). In those conversations I felt lucky to work for the Wikimedia Foundation where our work helps people around the world, and as designers we can focus on just serving our user needs without any obscure hidden intention.

The workshop

In our workshop we introduced the challenges of designing for Wikipedia (considering design implications of user diversity, accessibility, social interactions, etc.) and explored with the participants (using the 6-8-5 approach) new ways to consume and contribute knowledge, and new kinds of content that they imagined for the encyclopedia of the future. You can check the slides to get a general idea.

The participants provided great ideas (consuming content in smaller chunks such as article highlights and podcasts, making knowledge more contextual with geo-location and virtual reality, or surfacing better questions and discussions are just some examples).

As a group we evaluated evaluated the different ideas based on the challenges we introduced earlier. We could get really interesting perspectives on how Wikipedia is perceived by different people in different contexts, and it was also a good opportunity to invite designers to participate in an open project.

Autonym: a lightweight font to improve multi-language content discoverability

Mon, 28 Oct 2013 19:44:11 +0100

The Autonym font was announced in the Wikimedia blog. The Autonym font is a font that contains only the glyphs that are absolutely necessary for display a list of languages. This small font solves an interesting conflict between UX and performance when dealing with lists of languages.

The problem of discoverability

When content is provided in several languages, you can find a list of languages somewhere. If you support languages for which users may lack their fonts, you have to decide when to deliver those fonts to them or not.

For a page mostly written in Thai, it makes sense to deliver a Thai font to users. However, if the page contains a language list, should you deliver all the fonts necessary to display all languages in that list?

Deliver fonts impacts bandwidth. On the one hand, if we want all users to be aware that content is available in their language, we had to load a lot of fonts to make sure they display properly. This has a severe impact on bandwidth in a very inefficient way since users are downloading a whole font just to display each language name (e.g., a thai font is downloaded just to display “ไทย”).
Not delivering fonts harms discoverability. On the other hand, if you don’t deliver fonts to the users for the list of languages, you generate a problem of discoverability. Users lacking local fonts will not be able to discover that behind a link like “□□□□□” there is a version of the content in their language (a version they can display and read once they reach the content thanks to webfonts, but is undiscoverable for them). This problem is illustrated below:

Autonym solves the above problem by including only the glyphs needed to display language names, so language lists can be displayed properly with minimal bandwidth impact. This font will be used in language lists such as the one shown at the Universal Language Selector, or those you find at the sidebar of your favourite Wikipedia articles.

It’s free to use

The font has been created by the Language Engineering team from the Wikimedia Foundation, and you are totally welcome to use it in your own website.

The Autonym font weights about 50KB in size, and provides support for nearly 95% of the 400 supported languages in Wikipedia software. You can use it for free and contribute to its open source repository.

New language tools are arriving to your closest Wikipedia

Sun, 28 Jul 2013 21:14:25 +0200

When I am using a computer which is not mine, sometimes I have a hard time to find some “special” characters used in Catalan or Spanish such as “ç” and “ñ”. Then, I imagine what would happen if all my characters were “special”, and even my own computer’s keyboard was not prepared for them. This is the situation for many languages around the world.

But typing is not a problem at all if your computer is not even able to display text in your script. If you visit this page about the Javanese language you may get the impression that Javanese is an original language based on a single character: the square. Unfortunately, squares are what your computer uses to indicate that it lacks fonts for a specific script.

Language is our vehicle to communicate knowledge. Allowing users to read and write in their own languages is essential for projects such as Wikipedia. To help users to achieve this goal, new language tools have been added recently.

The Universal Language Selector

The Universal Language Selector is being deployed to Wikimedia projects, and provides the following tools and settings:

Input methods allow users to type in a language their keyboard is not prepared for. For example, when the Greek input method is enabled, users can type “π” by pressing “p” in a non-Greek keyboard.
Web fonts. For languages with poor font support, fonts are delivered to the user automatically, so that the content is properly displayed.
Change menu language. You can change the language in which menus are displayed.

These tools are essential for many language communities but will also help in other scenarios as well. For example, as Amir Aharoni explains, now Akkadian cuneiform is properly displayed when reading about the Tower of Babel in English Wikipedia (where mixed-language content is quite common). In addition, readers with dyslexia will also benefit from the inclusion of Open Dyslexic font as a choice for users.

Design considerations

Many design considerations were made while designing these language tools, some are summarised below:

Different languages are supported to different degrees. Some users do not need language tools, while other users need them for the most basic activities. Thus, you need the right balance in order to make tools easy to find for those users that need them, but avoid disturbing the users that do not.
Users speak a small number of languages. Despite the high number of languages supported by Wikipedia, each user is interested on a very small subset of those languages. Thus, providing the full list of all languages each time the user needs language support is sub-optimal. Different design patterns were applied in our designs to make language selection easier such as anticipation (show a small list of the likely languages according to previous selections and user context), forgiving input (allowing the user to search a language in different languages, even with typos), and undo (allowing to quickly revert if the user choice may led the user to a foreign language UI).
Repetitive use needs to be properly supported. Most language related actions do not happen in isolation. For context where switching between languages can be repetitive such as typing, it make sense to avoid extra steps and provide the tools at hand. For example, when selecting input methods, we allow the user to select previous languages right from the typing context, and by selecting a language the last input method used for this language is used avoiding an additional selection most of the time.

If you are interested on more aspects of the design and you are attending Wikimania 2013 at Hong Kong, you can attend my talk: Improving the user experience of language tools.

An open project

While reading this post you may have tried to use the new language tools for your language. If you found they are useful we have good news: you can take these tools to your own website. Input methods, web fonts and language selection tools are available as jQuery components that can be used for any web projects.

On the other hand, if you found that there is something missing, we have also good news. The catalog of fonts and input methods provided by these tools is open for contribution, so you can help us to improve it. This tutorial on how to create a new input method may be a good first step.

Iconathon with the Noun Project

Wed, 17 Apr 2013 23:06:42 +0200

Last April 6, I attended the Iconathon organised by the Noun Project and the Wikimedia Foundation. We proposed some concepts related to Wikipedia such as “neutral point of view”, “No original research” or “Encyclopedia worthy” and participants explored with sketches possible representations for such concepts.

It was great to interact with the Noun Project team, other designers, and members from the Wikimedia community in a collaborative design session. Each one added a different perspective that added to the experience. You can see some pictures of the event at Wikimedia Commons, but final vectorised icons will be created in a later stage.

The Noun Project goal of “building a global visual language that everyone can understand” is not only challenging but also well aligned with our idea of sharing the sum of human knowledge. So I was really happy to contribute to, and I hope that more interactions happen between both projects in the future.

My talk at the Iconathon

I had also the opportunity to gave a talk at the Iconathon about internationalisation issues to consider when creating icons (the slides are available). The talk was appreciated by the audience since these issues, although easy to solve are sometimes hard to identify. Working with people around the world on a daily basis helps a lot in this process, so all my co-workers deserve most of the credit for this talk.

If you are interested in design internationalisation and are planning to attend Wikimania 2013 in Hong Kong, you may find interesting the talk proposal I submitted.