Wikidata Bridge/Research

Edit Wikidata’s data directly from your infobox

Current prototype

edit


 
Screenshot from the current prototype. The user will have to indicate if the former value was wrong or outdated.
 
Screenshot from the current prototype.

You can access the current prototype here (version 4.0)

This is the current state of the prototype. Please note that it is a screenshot prototype, not a fully working feature: you will be guided to go from a screen to another and you won't be able to click on all links and buttons that you see on the screen. This is not the final state of the feature but a work in progress. This prototype will regularly evolve, based on our research and user's feedback.

Feel free to test it and give us your feedback on this thread!

What’s the need? What’s the problem to solve?

edit

There are quite a few advantages to use Wikidata in infoboxes, for example:

  • Less outdated data in infoboxes
  • Less (unintentionally) conflicting data between infoboxes in different projects
  • More high quality data on Wikidata
  • More data for readers on all wikis (especially smaller ones)
  • Less data overall to maintain per editor on the Wikimedia projects
  • Wikidata feels less distant for editors from other Wikimedia projects

But unfortunately the way it is currently done is not convenient for most editors, especially those who are not yet familiar with Wikidata and its data structure.

We want to make easier to use Wikidata’s data in the other Wikimedia projects by making possible to edit the data directly from there, therefore giving editors a sense of agency and connectedness with Wikidata. It’s important that this should not lead in an increase in vandalism or bad edits done it good faith to Wikidata.

How do we work?

edit

We follow a user-centered design approach which means that we base our decisions on what we think will give the people using the feature in the end the best user experience.

To find out what the users need, we define personas and conduct research.

  • We usually do this by conducting interviews with people that will likely use the feature or will be affected by it in some way. We ask about their current workflows that will be affected by the changes as well as things that work well for them currently and problems they’re facing. Overall our goal is to get a good understanding of how we can best improve the situation for them so they can have a more efficient and satisfactory editing experience. For the exact research we conducted for Wikidata Bridge please see the feedback loop section below.
  • From this research we also develop personas which means we create fictional representatives of the user groups that we encountered during the interviews. This helps us to keep the focus of who we are making this product for and try and make design decisions in their best interest.
  • Based on the information we gather from the interviews we come up with a concrete design and interaction that integrates well into the existing UI and solves the problem in the best way.

Unfortunately what we imagine does not always end up being developed exactly as envisioned because there are usually technical constraints and resource constraints that we need to take into account. This means that we will be in discussion with the product team and the engineering team to figure out the best way we can make this work. For more information on how we ended up with the current version please see the feedback loop section below.

We then start thinking about user journeys. What are the things that the personas would like to be able to do and how should this journey look. We will then define these journeys and settle on a few main ones that we want to tackle first.

We will start out small with what we call MVP (minimal viable product). This means we don’t make the full cruise ship right away, but start of with a small paddle boat to see whether we have the right idea on how to approach the feature. The reason for this is, this way we can include many iterations and feedback loops to ensure that we are on the right path and are actually solving the problem we set out to solve. Starting with a product that from the start includes all extra features will take a lot of time and we’d run the risk of finding out too late, after a lot of resources have already been put into building it, that this is actually not the right approach to the issue.

 
User journey for the first minimal viable product
Personas and user journeys

For this project, we mostly work with two personas:

Our minimal viable product contains the following user journeys:

  • Changing the value of a simple statement (e.g. date or number of inhabitants, not a value that links to another Item)
  • Updating the value of a simple statement

Our minimal viable product has the following scope:

  • Has to work independently of the Visual Editor
  • We focus only on items connected via sitelink
  • Only for the fields that are using wikidata

On further iterations, we plan to work on:

  • Reference adding and editing
  • Adding statements

Everything else is not planned for now and will have to be discussed again in the future.

Past research

edit
Past feedback loops
Things that already exist
Previous prototypes
  • Prototype developed in 2017 and 2018, based on the feedback loops (English, German)

Why did we move away from this prototype? This prototype was developed as part of a thesis where engineering expertise and resources had not been considered yet. Most of the features seen in the prototype are still things that we would like to do along the line but are not part of the first iteration. This is explained in more detail in the “how we work” section above.

List of all the onwiki discussions about Wikidata on Wikipedias

Feel free to add the ones that are missing, or to create one on your home wiki!