Commons:Structured data/Archive/2014/Development/Design

This page is presently inactive and retained primarily for historical interest. For up-to-date information, check the current info pages about Structured Commons. You can leave comments on the talk page there.

This page will collect the design efforts to understand the issues, propose solutions and validate them about the Structured Data project. We need your help for each of these, so feel free to provide feedback on the talk page.

Users and scenarios

Structured data about media files will have both a direct and indirect impact to many different users. Some users will find the files they are looking for more easily thanks to new filtering options that are not possible today. Other users will be manipulating structured information directly to fix some piece of information.

In order to identify the needs of different kinds of users, we created some user profiles and scenarios.

User profiles

• Wikipedia reader. A user consuming content from Wikipedia (or other Wikimedia project where multimedia content from Commons is available).
• Wikipedia editor. A user contributing content to a Wikimedia sites that adds and manipulates media files that are relevant to the topic at hand.
• Commons curator. Reviews media files and makes sure that multimedia is properly organised.
• Commons contributor. Contributes new files and looks for media files to remix.
• Site editor. Adds images to a third-party site.
• Partner in a museum. Contributes a big (or really huge) set of media files and organises them.
• Bot creator. Helps to organise files by setting automatic rules.

Scenarios

For the current stage of the process we are going to focus on the scenarios related to the Commons curator user profile. We decided to focus on Commons curators because their expertise in managing file information will help us to iterate on how to present and edit information for all kinds of media files. In addition, activities from other users depend on structured data to exist and being editable. Allowing search based on structured data (as a great improvement as it is) has little value if files lack structured data, and advanced editing (provide information as you upload, or manage a high amount of files) will build on the solutions for the more basic editing needs.

A compete list of the scenarios explored is available. For Commons curators we have identified the following ones:

1. Classification. the user goes through a list of recent uploads and classifies them by adding and correcting their topics/categories.
2. Review copyright status. the user checks that licenses and copyright is correct for a file. If needed, the user indicates that the license for a file is not correct, add additional information, or mark the file as a copyright violation.
3. Add multilingual information. The user goes through a list of recent uploads and adds file descriptions in different languages when some of the user native languages are missing.
4. Add location information. The user provides missing geographic coordinates for pictures of monuments that lack such information from a list of recent uploads.
5. Complement information of a collection. After a museum uploaded many paintings by Van Gogh from the same museum, the user wants to add specific information to each of them: a more detailed description, topics, and license information.
6. Look for missing information. Search a museum collection of cubist paintings that have the author information missing, and adds their author.
7. Topic creation. The user creates a new topic about a conference for which images are expected and shares it with the conference organisers so that participants can upload pictures to it.

Relationship between structured and unstructured data

Currently information about media files is lives "hardcoded" inside templates. Although the goal is to better structure that information, the migration will take a while. This means that new structured data and the current unstructured information will coexist. Some ideas are discussed on the relationship between these two kinds of information in order to avoid user confusion, reduce duplication and facilitate the migration.

Some ideas to explore:

Integrate structured data in the current File Pages

Instead of presenting a completely separate page with similar information, provide a "data view" on the existing File Pages where structured data can be viewed and manipulate. the data view can be a new section in the page, a separate sidebar panel floating over the current file page.

• Benefits:
  • There is a single entry point for each file with the information about it. We avoid having two separate pages about "the starry night" with a different subset of information about the same file.
  • Opportunities to facilitate the migration process. Being in the same context, the migration of information from unstructured to structured could be facilitated (e.g., easily moving from structured to unstructured data in order to check or copy information).
• Possible issues:
  • This can crowd current file pages. We need to explore UI patterns to avoid it.
  • By presenting all the information in the "data view" there may not be a clear connection between a specific field on a template and where it is located in the data view.

Support structured data as template editing

Provide a template editing UI that presents in an integrated way both unstructured and structured data.

Approaches to view and edit structured data

Design examples for editing media structured data

This section explores ideas about presenting and editing structured data about media files. The patters proposed in this section are generic (e.g., multilingual text strings can be used in many different fields when describing a file). How to deal with specific pieces of information is dealt in a different section.

Information complexity and progressive disclosure

Media files can have lots of complex information. Presenting all the information at the same time will crowd the UI and make information hard to find. By applying "progressive disclosure" users can get the information they need when it is most relevant. Some ideas to apply this approach:

• Use separate views for more detail. Separate the main file information from additional information on related items. The second view would be contextual showing information about the selected element on the main panel. For example, the main panel can indicate that a file has an author, and by clicking on it, the second panel would provide additional details such as the OTRS ticket that verifies that user as the real author.
• Compact information. A complex piece of information can be presented as a single unit and be decomposed when it needs to be edited. In the example above, the presence of an OTRS ticked can be surfaced with a tick icon next to the "own work" indicator in order to inform that the author was verified.
• Use smart defaults. Simple cases should remain simple despite the support for the complex ones. For example, when providing rights information, most files consist a single work, and although it should be possible to specify the rights information for different aspects of the work (the painting vs. the scan or photograph of the painting), the default use should be straightforward.

• Possible issues:
  • Hiding lacking information makes it hard to be completed. We need to be careful with hiding information: for top-level items we may want to explicitly show the empty items, other more compact indicators (such as icons or a summarised version) can be used to highlight when there is (or is not) some information available.
  • Some advanced users may want to have all information available all the time. Users dealing with a very specific piece of information, or those exhaustively filling all possible details of very complex files, may consider an added effort to reach the desired field to fill the information.

Referencing entities

Auto-complete and suggestion list make it easy to reference existing entities based on user input. Some aspects to consider:

• Basic manipulation mechanisms (add, remove, edit) supported with both touch and keyboard-based input.
• Integrate multiple sources. When information from different sources is modified, the users should be aware that they are contributing to different places.

Rich multilingual information

Information such as descriptions is multilingual, and support is needed to viewing and contributing information in different languages. In addition, that kind of information tends to include more than just plain text, so it will need rich text editing support.

Language fallbacks add some complexity when editing (since content may be provided in a different language than the one the user is editing).

Flexible types

For some values we need to allow users to specify different kinds of information. For example, a work can be represented by a Wikidata item, a commons image, or an external URL.

Ideally, flexible fields should be able to detect automatically the kind of information (e.g., detecting a URL) and providing feedback to let the user know that the information provided is correct.

Navigation structures

Given the possible amount of structured data, we may need to allow users to access a specific pieces or groups of information quickly using some navigation structures (filters, groups...).

Getting started with a simple edit

In order to facilitate the migration process to get started, users can get a simplified UI asking to confirm some small piece of structured data for a file (similar to the WikiGrok experiment). That would help users to discover the data view and encourage them to start the migration process.

Considerations for specific pieces of information

Rights

Icons as those used for trademark and insignia templates can be useful to make the information easier to get at a glance.

About (categories and topics)

The about field of an image is useful for users to later find images about one or more topics. Categories are used here as a shortcut for a set f topics. Categories can be described using topics. In this way, the category Churches in the Netherlands will represent the set of topics "church" and "the Netherlands". Users will be able to add categories and individual topics.

Benefits:

• Categories are useful as a convenient way to add topics for users describing images (e.g., adding the category "Churches in the Netherlands" instead of the individual topics it represents).
• Users can keep using categories as they are now and enhance them with topics to better describe their content.

Challenges:

• We need to communicate which topics categories represent, so that it is clear for the user how are they describing the image.
• We may want to facilitate the migration of items from generic topics to other more specific fields (e.g., a user adds "paris" to the "about" section, and another user moves it to the location field).
• Mechanisms are needed to adding topics to categories.

Design process and how to participate

We propose an iterative design process that includes these steps:

• planning: identify first workflows we need to support (migrate, view and edit data)
• design: prepare first mockups to explore possible design solutions
• research: test mockups with users, to validate designs
• iterate: rince and repeat, as needed

One practical way to plan this effort is to start with the research goals and back out from there.

Planning

In a first design iteration, we plan to develop mockups, slides and/or a design prototype to simulate how to view and edit structured data on a sample file page, so we can test them with sample users and learn from their feedback.

The workflows supported by these mockups or prototype would include:

• migrate unstructured data to structured format
• view structured data (integrated with unstructured data at top of page)
• edit structured data (using a simple editor tool)

Design / Development

Prepare design examples of how a users could migrate, view and/or edit structured data on a sample file page.

The mockups, slides or prototype would include:

• a file page with hybrid information (both structured and unstructured)
• a data section at the end of the file page (showing structured data properties for that file)
• a visual cue when a data property has been structured
• a prompt to migrate or edit data in structured format
• an edit button (for opening an editor for a structured data property)
• an editor panel (for editing a structured data property)

Some of the mockups would illustrate a first-time user experience, showing how the user would be cued and prompted to view or edit structured data. Other mockups would show how advanced users might editing structured data for typical workflows like adding a category, updating a description, etc.

See proposed research questions below to guide this work.

See Mingle card #954 for this work.

Research

Here are some proposed research questions and tasks for this design work, for discussion purposes.

Research questions
Here are some questions we might ask users in our first research studies:

• Do you understand what structured data means and what its benefits are?
• Can you tell when a data property on a file page has been structured?
• Can you find the structured data section on the file page?
• Can you find the information you need in this data section?
• Can you find which fields need to be edited?
• Can you tell how to edit structured data?
• Can you tell how to migrate data in structured format?

Research tasks

• Define goals and scope of user research this quarter
• Identify user groups to test (readers, casual editors, active editors)
• Discuss research questions we want to answer with design mockups and/or prototype.
• Prioritize those questions and prepare a research plan
• Write guidelines for mockups and prototype development
• Recruit and schedule participants for user studies
• Discuss designs with participants, ask questions
• Analyze responses and report on research findings

See Mingle card #969 for this work.