Page MenuHomePhabricator

Adding FileAnnotations (on images)
Closed, DeclinedPublic

Description

When reading about "Stahl House", Henry finds an interesting image of the house where some parts are annotated. Henry discovers that annotations are possible and feels invited to add more. He adds some annotations for testing and is able to quickly remove his own tests without affecting the existign ones. Finally, he annotates a piece of furniture to indicate it was the "tulip chair" by Eero Saarinen. Later, when going back to the article Henry feels he has made a good contribution.


The tasks explores the adding interface for annotations. It doesn't look at where this interface will exist, whether on the File page in Commons, on Wikipedia articles, or as part of an immersive annotation interface.

WARNING: The table below is not really a table, just saving vertical space
1adding.png (364×514 px, 31 KB)
2adding.png (626×344 px, 77 KB)
3adding.png (482×524 px, 28 KB)
4adding.png (318×525 px, 35 KB)
5adding.png (1×698 px, 308 KB)
6adding.png (426×727 px, 29 KB)
7adding.png (286×465 px, 16 KB)
8adding.png (451×814 px, 136 KB)
Blank

Axes

  • Speed of adding annotations vs Information in the form of previews or search result options
  • Guidance in understanding what makes a good annotation vs Control of what kind of annotation is added

Hypotheses

  • People understand basic annotating workflows like the ones seen in Facebook and Flickr.
  • Seeing the interface people understand what a good annotation could be.
  • Users need g

Event Timeline

Prtksxna renamed this task from Adding annotations to Adding FileAnnotations (on images).Nov 29 2016, 7:00 AM
Prtksxna created this task.

I particularly like 4 (or 3), 6, and 8 from technical and look/feel perspectives. The others seem good but not quite right somehow - either too cluttered or not fast enough.

I thought 7 was uncluttered and fast. But I also thought that it hides a lot of information.

That's really what I meant, if it hides the information, then finding that information and acting on it is at least one click removed, hence, slower. But that's just my first-blush opinion of it, so maybe it's a good idea after all and I'm being too critical (or I don't fully understand how it works?)

That's really what I meant, if it hides the information, then finding that information and acting on it is at least one click removed, hence, slower.

It might be the case that the first result is what the user usually picks, and the extra information is really unnecessary. We should do some event logging and check if that is actually the case before limiting the results.

I particularly like 4 (or 3), 6, and 8 from technical and look/feel perspectives.

Is 2 very hard to do? I think that sometimes the user won't know which tab will have the best information. Showing them everything at once might help them make a better decision.

2 wouldn't be difficult to do, no, but the ultra-long div looks weird to me. Maybe in context it wouldn't look so bad.

As commented in previous discussions, I think that allowing to search right away with the minimum number of decisions could help making the experience feel more fluent. Having an option to focus on a specific kind of content makes sense, but can work as a second step. Both approaches can be complementary:

  • Example 3 can include an initial "All" tab that shows all kinds of results initially, and allows for users to focus on a specific tab when looking for a particular kind of content.
  • Example 2 could limit the number of results shown per project in order to keep a relevant overview but still provide an option to view all of them as a way to focus on a specific project.

Another aspect worth considering is how much we want to emphasise types of content over projects or the other way around. That is, do we want to refer to "Media", "Commons" or "Media from Commons"?

dr0ptp4kt changed the task status from Open to Stalled.May 30 2017, 3:20 PM
dr0ptp4kt moved this task from Next up to Triaged on the Multimedia board.
Ramsey-WMF added a subscriber: Ramsey-WMF.

Since the 2016/2017 FileAnnotations prototype work is now quite outdated and both Wikidata and Commons have new features and design plans (like moving new features to Vue.js on Commons), and the extension is not actively under development, the best thing to do is close these tasks and create new ones when/if there's a team available to pick up development on this feature.