Wikimedia monthly activities meetings/Quarterly reviews/Multimedia/October 2014

The following are notes from the Quarterly Review meeting with the Wikimedia Foundation's Multimedia team, October 23, 2014, 10AM - 11:30AM PDT.

Present:

Rachel diCerbo - community engagement director
Fabrice Florin - product manager
Howie Fung - product development director
Rob Lanphier - platform engineering director
Erik Moeller - vp product
Toby Negrin - analytics director
Damon Sicore - vp engineering
Lila Tretikov - executive director
Jared Zimmerman - design director
Tilman Bayer (taking minutes)

Participating remotely:

Gilles Dubuc - engineering team lead
Pau Giner - UX/UI interaction designer
Mark Holmquist - frontend engineer
Guillaume Paumier - product analyst
Keegan Peterzell - community liaison
Gergo Tisza - backend engineer

Please keep in mind that these minutes are mostly a rough transcript of what was said at the meeting, rather than a source of authoritative information. Consider referring to the presentation slides, blog posts, press releases and other official material

[slide 2]

Agenda:

10:00 am - Last 6 months
10:45 am - This quarter
11:15 am - Next steps
11:30 am - Meeting ends

All times above are Pacific time (UTC-8)

[slide 3]

Fabrice:
multimedia a great way to bring people into the movement
mission: ...

[slide 4]

structured data: really important for coming year

Last 6 months

slide 6

[slide 6]

MV: work that was not planned, took extra time

slide 7

[slide 7]

plan vs. actual
UX: always planned to do technical work (debt) first before designs

Media Viewer

slide 9

[slide 9]

slide 10

[slide 10]

slide 11

[slide 11]

(demo of new MV version on beta.wmflabs.org:)
we separated share and download panels
removed some stuff (displayed on first view) below the fold
worked on disabling/reenabling function
concept now clarified: MV is a preview function
plan to show caption below the image (if no caption, show description, if no description, show file name)

slide 12

[slide 12]

Improvements

slide 13

[slide 13]

Must-haves that we promised to the community based on the consultation in August/September:
almost all done, except:
still in dev: caption/description below image
metadata cleanup drive in progress

slide 14

[slide 14]

did research with Abby, Pau[?] which was very beneficial

slide 15

[slide 15]

clickthroughs to original image increased
Lila: did we see decreases too?
Fabrice: no
Erik: also, there was consolidation - previously there were two buttons

slide 16

[slide 16]

Damon: ...
Toby: what was the goal of the improvements? drive clicks to..?
Erik: we had identified several serious issues with the existing media viewer experience through user testing
team decided to not make image clickable, I think that was wrong, now being reconsidered
to measure success of feature as a whole, would want to capture image usage across a whole user session
people accessing images they would not have before
Damon: when I stumbled upon MV, I used cursor keys instead of clicking on arrows. do we track key presses too? not distinguished from mouse clicks, all rolled up
RobLa: problem: huge area of screen became clickable; not surprising this had a huge effect
Damon: ....
Lila: are ...clicks going up?
Erik: we did not expect a change there
Lila: total number of image views before/after MV ?
Erik: don't have solid data for that, some ballpark numbers
Fabrice: saw drastic decline in disabling right after deploying these improvements
might go up again once we introduce a more prominent disable button
Damon: so if disabling already possible, why did we do further work on it?
Erik: was hard to find (had to scroll down...)
Damon: what's the #1 complaint?
Fabrice: existing users happy with their workflow, for them it's an extra click (but: can bypass via e.g. shift-click, people getting to know they can do this)
Damon: biggest problem I see with MV is performance (dithering..). 4-6 sec on my machine at home
Fabrice: working on server-side improvements[?]
Lila: previous load times?
Erik: best available numbers show it loads faster than file description page
Fabrice: ...
Damon: preemptively caching how many images?
Jared: 1
Damon: difference: with file description page, image appears immediately
Erik, Fabrice: But that page needs to load first
Erik: also, image is significantly larger, which will take longer
Damon: pre-cache then
Erik: thumbnails are pre-generated now (by the scalers) for new uploads, high cache hit rate for old ones
a lot of this work has alreeady happened
left: standardize bucket sizes
Damon: but pre-generated thumbnails already marked as done in the list?
Gilles: it's actually done as of this week
Lila: what is the data [about impact on perf]?
Gilles: merged only 2 days ago, will have the data next week
Lila: should have a target for things like this
and items like "pre-render thumbnails" should be grouped under that [as means to that end]
Fabrice: be aware target will vary by connection speed
Lila: ...
also, think about graceful degradation for slow connections
Damon: this is the most data driven qr of the 5-6 I've seen so far
you only get pushback from me because you show good information ;)

slide 17

[slide 17]

(Fabrice:)
Community and Research
and want to find additional ways to engage users (e.g. just went to Germany, talked to community members there)

slide 18

[slide 18]

...

UploadWizard

slide 20

[slide 20]

slide 21

[slide 21]

Pau provided design vision for future

slide 22

[slide 22]

Upload funnel analysis

slide 23

[slide 23]

Error messages
Damon: 30% drop in what?
Erik: (explains UW funnel - initial click, tutorial = 100, 70% click through to next stop)
introduced 3-4 years ago, huge improvements, increased uploads
let's avoid anecdata
longstanding API issues we need to fix for Commons, will not only benefit UW (this is what the "Error messages" slide is about)
Lila: dropoff when exactly? (basically, is it a software problem or usability issue?)
Gergo: lost on file screen
Erik: need to define these better in the chart
Howie: should include UI elements in the funnel chart to make it clearer
Erik and others: need baseline
RobLa: generate a pie chart of dropoff causes
Erik: and then can start on a regression policy
RobLa: this analysis will involve a substantial amount of engineering work
Fabrice: bear in mind that team is only just starting on this
Guillaume: come ask me to show you the horrors of upload workflow before UW ;)
for the chart, it would be helpful to display entire 0-1 scale

slide 25

[slide 25]

(and following slides:) design ideas
Fabrice:
design (Pau's vision) - postponed while working on tech debt

slide 28

[slide 28]

next steps:
upload directly from Wikipedia and other non-Commons sites
also from Flow, VE
Erik: be realistic, with ongoing work on metadata
Toby: getting baselines first is important

This quarter

Gilles:

slide 30

[slide 30]

Q2 projects
MV: deploy improvements, then reduce involvement - just bugfixes
structured data: working with WMDE's Wikidata team
tech debt: overlaps with all other projects

slide 31

[slide 31]

UW: now have data, start with tech work
structured data: more than originally planned
MV took more room than planned

slide 32

[slide 32]

this Q roadmap
at the moment, don't have good error logging tools
structured data: Pau working on design prototypes

slide 34

[slide 34]

Tasks:
ID metrics to be able to define targets, hope to get full clarity on this this q

slide 35

[slide 35]

Key metrics
this slide is just to get people thinking
Lila: track amount of reverts or deletes, at least
Erik: mobile team already tracked deletions of mobile uploads, informed their decision to temporarily disable mobile upload
Lila: should track deletes, but need other measures too
Howie: #images used in articles
Fabrice: ...

slide 37

[slide 37]

Gilles:
we are also responsible for lots of other projects, maintenance

slide 38

[slide 38]

on TMH, losing team member (student) now. Brion also did spare time work on this
important and worthwhile tasks, but sometime hard to keep on top of them

Structured Data

slide 40

[slide 40]

Purpose
use Wikibase (built by WMDE for Wikidata) for media data
many goals, likely to take several years

slide 41

[slide 41]

many different uses
current search on Commons is terrible - has to rely on fulltext
viewing: a lot of MV criticism was that the image information shown was inaccurate/incomplete
Guillaume is working on that with the cleanup drive
structured data will help a lot with that too

slide 42

[slide 42]

will support GLAMs
internationalization

slide 43

[slide 43]

these are some quick mockups made in Berlin (nothing final)

slide 44

[slide 44]

File page vs. Data section
[figure out the distinct purposes]

slide 49

[slide 49]

Key concepts
Wikidata always in flux
API as a stable interface, also for 3rd party users

slide 50

[slide 50]

API class diagram

slide 51

[slide 51]

Workflows
already discussed with interested community members
migration easier to figure out for us than new [workflows]
Lila: how will structured and unstructured data be kept in sync?
Gilles: aim to make structured version good enough so people will want to primarily refer to that
already example: Wikidata links, e.g. Mona Lisa image -> Leonardo
Erik: can't cover this in the remaining 5 minutes, suggest separate introduction meeting
let's look at measures of success

slide 53

[slide 53]

biggest issue now: English-only categories, descriptions in few/1 language
leverage Wikidata translation layer
this will enable many more users to cat/tag
users across projects will find images more easily to use on their projects
problem: detached media repository
categorization is difficult, have to know system, not like on Flickr where one just types in some words as tags
need to get success measures in place as early as possible
can use usage numbers
also, UX tests
this is a big project, WMDE has committed to it, we have committed to some support work
RobLa: also, from Wikigrok conversations: there is lots of other work (e.g. perf) we'd like Wikidata to do

slide 59

[slide 59]

Fabrice; need to consider resources
Erik: need to decide about prioritization of this project (considerate of our commitments in partnership)
it's on the roadmap now, but so far planning only
MV, UW goals are fixed
Lila: first thing: be clear of what user will get this q
Erik: OK, can spell that out for UW and MW
RobLa: these are longstanding bugs, need significant research effort to figure out how to solve

Lila: appreciate team's work on hairy issues