Wikidata:Usability and usefulness/Usability Test 2017-07

Research questions edit

  • How well do our input widgets work?
  • How well does entry creation work for first time users?

Methods and Setup edit

  • Qualitative, lightweight testing
  • small sample size [1]
  • Think aloud while doing a task[2]

Sample edit

  • Externally Recruited
  • 5 people
  • mixed gender, age, job…
  • All with web experience
  • None with Wikipedia Editing experience

Task edit

You saw that there are already some entries for your birth city, some building already have entries but the tv-tower is still missing. Conveniently on the internet page you can find some facts about the tv-tower:

  • Name: Armin Maiwald-Fernsehturm
  • Beschreibung: Fernsehturm in ________ (Neustadt), Deutschland
  • Geographische Koordinaten: -25.344375, 131.034401
  • Höhe: 42,31m
  • Zeitpunkt der Inbetriebnahme: 10. Dezember 1968

Additionally you should save that the building is a tv-tower, so the building will shows up automatically in the list of all tv-towers.

  • Das tust du mit der Angabe: “ist ein(e)”; “Fernsehturm”

Findings edit

The suggested actions are usually coherent with Usability Heuristics, e.g. the ones by Nielsen and Molich [3] or Bruce Tognazzini [4]

People understood add/save semantics edit

 

Participants understood basic semantics of add and save (Our questions were not using similar terms, so it was not too hard)

Name/Bezeichnung (=Label) hard to understand for some edit

 

Finding: Users were not sure what exactly the difference was and what type of information should be inside each one.

Frequency: For about 2-3 people

Pain: Bearable (just wrong data, but some progress)

Action: Use more descriptive words, provide examples instead of repeating the same words again in the field

“Adding statements” confusing for ALL participants. edit

 

Finding: Adding the second property after having added the first one is confusing; people clicked on the wrong “+add”

Frequency: 4-5

Pain: Barely bearable (wrong data, some progress, “something is wrong")

Action:

  • Visual hierarchy changes
  • Specific wording like “add Geocoordinate” vs. “add statement”

Amount-Entry: selecting the unit is confusing edit

 

Finding: When giving the height of the item, people typed something like “12,4m” which was not accepted; save was blocked.

Frequency: 3-4

Pain: Severe: It does not work, so drop this Wikidata thing.

Action:

  • Make it more obvious that the measurement type needs to go in the extra field, e.g. having value and unit side by side.
  • Make that field not optional (rather provide the option “unknown” as a way out than have no information added)
  • Provide a clear error message instead of failing silently and letting the user solve the computer’s problem.

Finding: When typing just “m” into the measurement field “meter” is not suggested

Frequency: 3-4

Pain: Bearable. But confusing.

Action:

  • Have the field the drop down suggest only applicable units in the first place (after the fact constraint warnings are not helpful here)
  • recognize abbreviations that are put in the field

Amount-Entry: selecting the unit is confusing II edit

 

Finding: When entering a property people assumed their input was valid but it was not; Invalid input not recognized, users try to click save; don’t understand blocked button.

Frequency: ???

Pain: Severe: Does not work, drop this Wikidata thing.

Action:

  • Don’t let any input and a valid, selected property (or value) look the same: Semantics!
  • Make it clear that the input could not be recognized

For brand new entries the essential “add statement” is almost the LEAST visible element on the page edit

 

Finding: Often the user thinks they need to add the statements to the boxes of sister projects at the bottom because they visually seem to belong to “Aussagen”.

Severity: 4-5

Pain: OK–bad for users, but bad for us. People walk away.

Action:

  • “+add” button should be more visible
  • “+add” should be placed in a way that it’s associated with the statements.
  • Visually separate from the other projects
  • Give suggestions and guidance in the space where the statements should be

“Fundstelle” is not understood (concerns only German translation of Wikidata UI) edit

Finding: It was not clear what this word means as well as being interpreted as the location of where the item is. This is also not the common word used on DE-WP. The Wikidata-used “Fundstellen”/“Places where this was found” sounds like archeology to many.

Severity: 3-4

Pain: Only slight irritation for the user, but bad for us. Likelihood that they add references low.

Action: renaming that word to “Einzelnachweis”, “Nachweis”, “Quelle” or “Referenz”

“instance of” is seen on another level edit

Finding: Most users wanted to add that statement above the other statements near the description or label since they felt like it’s not on the same level as the other statements since we explained it to them as the MAIN identifier of the item.

Severity: 2-3

Action: We could think of specifically improve selection and design of selectors for “instance of”

“Malformed Value” during data entry confused users edit

 

Finding: Users were confused when a malformed value message came up as they were typing

Frequency: 2-3

Pain: Moderate. New users look to the box as feedback about whether or not they are on the right track if they don’t know what format to enter information in and don’t necessarily get it.

Action:

  • Show some format suggestions so users know what they need to type.
  • Consider showing the "Malformed value" after a more significant delay

Literature edit

  1. https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/
  2. https://www.nngroup.com/articles/thinking-aloud-the-1-usability-tool/
  3. https://www.nngroup.com/articles/ten-usability-heuristics/
  4. http://asktog.com/atc/principles-of-interaction-design/