Page MenuHomePhabricator

Edit interface should be nicer
Open, Needs TriagePublic

Description

Make the edit interface something like this:

  1. On new annotation, show a list of options
    1. Text/Wikitext
    2. Thing (Wikipedia/Wikidata item)
    3. Commons Category
    4. Picture
  2. Switch to ProcessDialog frame with tabs for each type - this is where the edit interface starts
    1. Text/wikitext is existing form
    2. Thing is search on WP/WD for a title
    3. Commons Category is search on Commons for category name
    4. Picture is media search (cf. VE?)
  3. Obviously save/cancel as usual

Not necessary for beta release, let's test in a real environment and then move on to editing things more conveniently.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptSep 22 2016, 6:05 PM
cscott added a subscriber: cscott.May 6 2017, 8:10 PM

Here's a contribution from Wesley Lindamood (Interaction Designer at NPR) at I Annotate 17 for an annotation edit workflow.


First frame shows a "toggle annotations" button in lieu of mouseover (which doesn't work on mobile).
Second frame shows how each annotation has a "edit" icon attached to the corner, which provides a minimum target size, even if the annotated area is very small.
Third and fourth frame show "free text" input box, which autocompletes with Wikidata items (like the search box on wikidata).
If a wikidata item is shown, a second drop down box shows up, prefilled with the property type describing the relationship between the image region and the wikidata item. A default relation (P18, "image of") is selected, but you could drill down and be more precise. For example, a link to Q42 Douglas Adams may in fact be P1442 an image of his grave (not an image of the person). This relationship dropdown is populated from the "see also" property of P18.

To link an image to an image, the user types File:.... naming the image (yeah, this isn't wonderful). The property dropdown then gets filled with properties appropriate for relationships between images.

Prtksxna added a comment.EditedJun 5 2017, 3:31 AM

If a wikidata item is shown, a second drop down box shows up, prefilled with the property type describing the relationship between the image region and the wikidata item. A default relation (P18, "image of") is selected, but you could drill down and be more precise. For example, a link to Q42 Douglas Adams may in fact be P1442 an image of his grave (not an image of the person). This relationship dropdown is populated from the "see also" property of P18.

This is very interesting. Using Wikidata not just to populate search results but also editing it to save parts of the information. I have two queries here:

  1. In images with a lot of elements, a group photograph of politicians for example, its quite normal to annotate each person. For such cases, in my view, using P18 or any of the related images properties might not make sense. Have I understood P18 incorrectly here? Does the wikidata policy want us to add every image of an entity as its P18?
  1. So the annotation will be between a segment of the image [1] and a particular statement on the wikidata entity [2]? Does each wikidata statement have a URI?

[1] Example 4: IRIs with Fragment Components in Section 3.2.3
[2] Both body and target as Web Resources, like Example 2: External Web Resources in Section 3.2.1


See also:

  1. T151846: Adding FileAnnotations (on images)
  2. T153296: Moderated usability testing for FileAnnotations prototypes - Adding prototype
cscott added a comment.Jun 5 2017, 9:57 PM
  1. Yes, the annotation is specifically saying "this subregion of the image is a P18 of Douglas Adams", "this other subregion is P18 of Ford Prefect", etc. I believe those are all appropriate triples. You could also say "this entire image is P18 of Arthur Dent", or "this entire image is P18 of NATO leaders" or some such.
  2. Each annotation has a URI, according to the W3C specs. Those URIs can be pointed to by the resource, in a standard way.

I'm not certain whether the backing storage would be wikidata (in which case the annotations would be full-fledged wikidata statements) or separate (in which case we'd have an "annotation storage API" which referenced wikidata properties). It appears that part of the commons project work on wikidata may involve creating first class wikidata items for every image on commons. But for the first option you'd need to go further and create first class wikidata items for each *annotation region* of the image. I think the second option would be easier in the short-term, and it would use MCR for backend storage.

Understood, that makes sense. Thanks for the explanation @cscott .

Restricted Application added a subscriber: PokestarFan. · View Herald TranscriptAug 7 2017, 5:38 PM
Restricted Application added a project: Wikidata. · View Herald TranscriptNov 28 2017, 9:06 PM
Ramsey-WMF moved this task from Untriaged to Prototyping on the Multimedia board.Nov 28 2017, 9:07 PM
Lydia_Pintscher moved this task from incoming to monitoring on the Wikidata board.Dec 18 2017, 3:03 PM

I want to preserve this for the awesome chatter, but the description of the task is no longer particularly relevant given T216565 which will mean no longer allowing annotations of different types, instead only Wikidata items will be used.