Wikidata Bridge/Research

What’s the need? What’s the problem to solve?
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?
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, or as we call them personas need, we 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.

Our MVP contains the following user journeys: Our MVP has the following scope:
 * So what is it that we ended up with?
 * Changing the value of a simple statement
 * Updating the value of a simple statement
 * Has to work independently of the Visual Editor
 * We focus only on items connected via sitelink
 * Only for the fields that are using wikidata


 * What we plan to do should further iterations confirm this:
 * 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

 * Past feedback loops
 * First feedback loop on October 2015
 * Feedback loop on Wikidata, May-June 2017
 * Feedback loop on German Wikipedia, February-March 2018
 * Plus various interviews and discussions during events (Wikimania, WikiCon, hackathons...)


 * Things that already exist:
 * WE-Framework: infobox editing tool on Russian Wikipedia
 * Infoboxes on various wikis already having an "edit Wikidata" link or icon: examples on Catalan, Spanish, French


 * 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.

Feel free to add the ones that are missing, or to create one on your home wiki!
 * List of all the onwiki discussions about Wikidata on Wikipedias:
 * Wikipedia:Wikidata on English Wikipedia
 * Infobox RfC on English Wikipedia
 * Wikipédia:Wikidata on French Wikipedia
 * List of all the Wikidata projects