Reading/Multimedia/Meetings/Quarterly Review Q3 2013-14
< Reading | Multimedia
MULTIMEDIA QUARTERLY REVIEW - Q3 Meeting Notes March 21, 2014
A Multimedia Quarterly Review Meeting for Q3 2013-14 was held by the Wikimedia Foundation's multimedia team on March 21, 2014 in San Francisco. Here are our notes, prepared collaboratively on this shared notepad.
Participants
[edit]- Gilles Dubuc - engineering team lead
- Fabrice Florin - product manager, host
- Howie Fung - product development director
- Pau Giner - designer
- Rob Lanphier - platform engineering director
- Erik Moeller - vp engineering & product
- Keegan Peterzell - community liaison
- Gergo Terza - engineer
- Jared Zimmerman - design director
Agenda
[edit]- 09:30 am - Q3 Projects
- 10:00 am - Q4 Projects
- 10:35 pm - Next steps
- 11:00 am - Meeting ends
- All times above are Pacific time (UTC-8)
See these Meeting Slides to see what we discussed.
Overview
[edit]Fabrice gave an overview of the multimedia team's mission and goals.
Mission
[edit]- engage users through multimedia
- encourage media collaborations
- provide a seamless experience
- address technical debt
Goals
[edit]- improve the viewing experience
- enable seamless contributions
- support structured data
- develop feedback tools
- help editors use media on articles
- engage users in media campaigns
Q3 Projects
[edit]Fabrice: Our main project this quarter was the Media Viewer, which aim to improve the multimedia viewing experience. We focused on completing this initiative as a team, rather than diluting our resources by taking on multiple tasks.
Q3 Projects - Accomplished
[edit]- Media Viewer 0.2
- better UI
- faster image load
- more metadata
- use this file
- Media Viewer 0.3 Designs
- video/audio support
- slides, collections
- zoom
- GLAM Toolset (batch uploads)
- Community Engagement
- 2016 Vision
- MP4 RfC
- Wiki discussions
- IRC chats
Q3 Projects - Plan vs. Actual
[edit]- Expand Media Viewer
- improve performance - done
- play video/audio files, PDF slides - designs only
- support plugins - not done
- Improve the Upload Pipeline
- bug fixes, code refactoring - not done
- UX improvements - designs only
- Deploy GW Toolset - done
- Discuss Video Formats with community - done
- Implement File Notifications - not done
Media Viewer 0.2
[edit]New features
[edit]Fabrice: Here are some of the Media Viewer features we completed this quarter. (Shows a quick demo of new features, focusing on 'Use this file' and the meta-data panel.)
- Faster image load
- Full screen
- Next/previous
- Meta-data panel
- Use this file
- Jared: for the Embed HTML, I recommend wrapping the text in a CSS style so that the blog owner can add to their style sheet to style this text consistantly on their own blog. And/or provide some very basic css to make embeded images look good already, e.g. make image 100% width of parent container, wrap text to image width, control text size, leading, etc with in-line overridable styles. Seehttp://www.gettyimages.com/creative/frontdoor/embed for example style and herarchy of information for text
- Fabrice: 'Use this file' took longer than anticipated (5 weeks with multiple developers).
- Gilles: The feature was large, we underestimated its scope, tried to do everything at once.
- Fabrice: We are trying a different approach for 'Download', with more rapid prototyping and quick iterations.
In development
[edit]- Opt-out preference
- Robla: Preference for turning it off. We have many places to get straight to the commons page so that we minimize the temptation to turn it off.
- Howie: Should we give a first time guider to Media Viewer, with a tip on how to turn it off?
- Jared: Not sure it's necessary to have a first-time invitation to disable this feature.
- Fabrice: We also plan to have links to that preference in the Media Viewer and the Help page
- Edit this file (see slides)
- Robla: The edit icon needs some thought - Pau and Fabrice to work out alternative.
- Jared: Recomend we either go directly to edit state on commons ot change icongraphy to be "go to source" rather than edit (e.g. Commons icon)
- Pau: The "go to source" metaphor could work (there is a risk of being mistaken with "embed" but we could try it).
- Pau: the main issue is that we don't want to convey "getting more details" because that is what the panel does and that would become a confusing decision.
- User feedback
- Jared: Not in love with the icon, a little too complex, metaphor is fine but a simpler version of the icon might be ok or literally just show "Give feedback"
- Pau: Icon is from UX repo https://www.dropbox.com/s/9d7pdkrfw8yc1xi/horn_grey.svg I'll talk with May
- Robla: goes to SurveyMonkey
- Jared: make sure its VERY obvious that you are going to and giving feedback on a 3rd party site
- Site configuration
- Metrics
Stats
[edit]- See these slides.
- Jared: Can we also capture keyboard actions separately? (next/prev/escape)
Close Options
[edit]- Erik: Need to capture the different ways to exit, since there may be an argument that people get confused and get in without getting out.
- Howie: Should we close the viewer if the user clicks in the black area?
- Gilles: We considered that, but there were concerned about accidental clicks when using next/previous
- Fabrice: Best practices are that clicking outside of a panel closes it, but not clicking inside the panel, and we take the whole browser window
- Erik: Let's also have a usability study on Enwiki
- Jared: Consider allowing black space to exit fullscreen, but make the action targets larger than they are visually, to reduce accidental exits
- Jared: discoverability of X to close for user testing could have been affected by the UI of usertesting.com (Pau: It was.)
- Jared: Consider default (HTML/WIKITEXT) to be based on logged in vs logged out, e.g. logged out gets HTML, logged in gets wikitext.
- Pau: Good point, I added this as a comment for card #148
- Erik: Consider usability test on production site like enwiki, working through complete workflows for editors
- Jared:(next image function pulls in non-article images like template, footer, and in-line support images)
Feedback
[edit]- What users like:
- see images more clearly
- no need to jump away
- interface more intuitive
- easy access to images and data
- What users dislike:
- images take too long to load
- insufficient licensing and attribution
- interferes with editing workflows
- still missing some key features
- See Discussion:
https://www.mediawiki.org/wiki/Talk:Multimedia/About_Media_Viewer/Archive02
- Licensing Comments:
- Erik: How serious are the concerns about licensing?
- Fabrice: Not as many concerns as we used to have, as we now cover a lot more use cases, showing not only more license details, but also special permissions in Media Viewer.
- Erik: If community is concerned that some use cases are not covered for special templates, we could respond with a call to action to help clean up the meta-data on Commons, which is a requirement for other projects as well, like Structured Data.
- Keegan: I am hearing fewer concerns about licensing, many experienced editors and administrators think it's fine now.
- Image Load Comments:
- Fabrice: Our main concern right now is image load time, which could be pretty slow in low-bandwith environments. Gilles is starting some tests to get a better sense of how long it takes to load an image, but we won’t know for sure until we try out the tool by default on entire sites like Hungarian and Catalan Wikipedias.
- Gilles: We've been working with Ops to increase Varnish hard drive capacity. They have some disks on order, but don't feel comfortable taking this on until the hardware is in place.
- Howie: Can you give projections for ops, so they know how much additional bandwith they need to support? For example, the prev/next buttons could dramatically increase the number of images delivered -- could even be on the order of 10x or more?
Usability
[edit]- Works well for these actions:
- use display controls
- access metadata
- identify authors
- find 'use this file'
- Not so well for these actions:
- find more data on description page
- come back from description page
- understand what is a license
- know how to 'use this file'
- See Study:
Process
[edit]- Agile Development
- Mingle tools / scrum practice
- Sprint planning / retrospectives
- Cycles of 6 weekly sprints
- Stats
- Last cycle velocity: 164 points (8 weeks/4 engineers)
- Net sprint velocity: 13.5 points/week (for features/bugs)
- Total sprint velocity: 20.5 pts (inc. scope increase, meets)
- Net cycle capacity: 72 points total (12pts./sprint)
- Comments:
- Fabrice: Team is getting discipline around using Scrum process, which is really helpful.
- Rob: Gilles is scrummaster, with a lot of help from Aaron.
- Gilles: I think we are well resourced for continuing this Scrum process, from a team standpoint.
Q4 Projects
[edit]Q4 Projects
[edit]Fabrice: We propose to devote our first 6-week cycle this quarter to completing Media Viewer v0.2. We would then like to devote much of the next 6-week cycle to starting Upload Wizard and Structured Data, while fixing bugs or key issues for Media Viewer.
Here are key projects we plan to work on next quarter (Apr.-Jun. 2014):
- Media Viewer 0.2
- pilot releases
- wide release
- bug fixes
- Upload Wizard
- metrics, planning
- bug fixes
- code refactoring
- UI improvements
- Structured Data (planning, research, prototype)
- File Notifications (as time allows)
Fabrice: Note that we are dividing each quarter into two 6-week development cycles. We have estimated the first cycle, but not the second cycle. We will estimate and plan that second cycle next month, based on team capacity.
See also previous team planning meeting notes about our next development cycles: http://etherpad.wikimedia.org/p/multimedia-planning-meeting-2014-03-12
- Comments:
- Erik: Want to make sure we address important community concerns for Media Viewer right after launch, which may mean a bit more than just fixing bugs.
- Jared: You could devote 1-2 sprints to addressing Media Viewer issues, after your first 6-week sprint focused on Upload Wizard.
- Gilles: It takes time to synthesize what the community wants. We don't want to change the product too quickly.
- Rob: We can’t be just the Media Viewer team, we have other responsibilities.
- Erik: I Iike the idea of a 2-week sprint for Media Viewer, but we may need to extend it longer, up to 6 weeks, based on response.
Q4 Projects - Plan vs. Forecast
[edit]- Improve the Upload Pipeline
- bug fixes - planned
- code refactoring - planned
- UX improvements - planned
- Discuss plans for structured data on Commons - planned
- Start File Feedback experiment - postponed
- Support new video and audio formats per RfC - postponed
- More bug fixes and Commons improvements - planned
Media Viewer
[edit]- gradual release of Media Viewer 0.2
- pilot releases start in April 2014:
- MediaWiki.org
- small pilot sites (e.g. Hungarian)
- large pilot sites (e.g. French)
- full release on all wikis: May 2014
- fix bugs - no feature development
- postpone next version v0.3 until later
- Comments:
- Keegan: We will collect feedback from dedicated Media Viewer talk pages on MediaWiki.org, as well as some of the top projects.
Upload Wizard
[edit]- Purpose:
- Provide a smoother upload experience
- Engage more users to contribute
- Users:
- Logged-in users
- Tasks:
- Collect feedback, metrics
- Develop project plan
- Fix high priority bugs
- Incremental refactoring
- Improve user experience (see next slides)
- Support video uploads (with Internet Archive)
- Designs
- See these slides for early design mockups
- Pau: Here's our initial UX analysis (and "radical redesign" ideas): http://etherpad.wikimedia.org/p/design-multimedia-uploader
- Comments:
- Rob: Work on the upload pipeline will be modest at first.
- Erik: An important question is how will the upload experience for Commons integrate with Wikipedia?
- Jared: Usability studies we did with 15+ users suggest that they want the upload to take place during the edit process.
- Pau: We want users to be able to describe the image while the upload is in progress.
- Erik: How would you support the upload of multiple files in this context? What’s the logical path for uploading 30 or 40 files at a time?
- Pau: The design mockups show affordances for multiple file support on the right corner of the proposed Upload Wizard upgrade.
- Fabrice: Note these are early mockups, we don’t know yet how many of these design ideas can be implemented in coming months. The upload wizard’s code base also needs to be incrementally improved.
Structured Data
[edit]- Purpose:
- Store media file info as structured data on Commons
- Make it easier to view, search, upload, edit, curate and use media
- Users:
- All users and developers
- Q4 Tasks:
- Develop project plan with Wikidata
- Review Wikidata code (e.g. WikiBase)
- Create mock interfaces (e.g. UploadWizard)
- Discuss data migration with community
- Comments:
- Erik: how do you propose to store the data?
- Fabrice: Daniel Kintzer at Wikidata has proposed storing structured data in a special sub-page of a file-description page.
- Erik: Not sure if that’s the best way to do it. We need to re-think what a file page is and what it may mean to users - media viewer could become the front-end for this data.
- Fabrice: We don’t need to figure this out now, we will schedule a separate planning discussion for Structured Data.
- Keegan: The good news is that the community wants this project to happen.
- See Mingle cards:
- #307 Plan for Structured Data on Commons
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/307
- #309 Prepare for Wikidata Integration
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/309
File Notifications
[edit]- Purpose:
- Inform file creators when something happens to their files
- Engage users to contribute more files
- Users:
- All Commons contributors or curators
- Features:
- File was Used in Article - Q4?
- File Upload Complete - Q4?
- File was Rated/Featured
- File was Edited
- File was Marked for Deletion
- File was Deleted
- See Mingle card:
- #170 Notification: Your file was used
https://wikimedia.mingle.thoughtworks.com/projects/multimedia/cards/170
Fabrice: Note that all these Q4 proposals are for discussion purposes only, they are not prescriptive. We have only planned the first 6-week cycle that ends in April. Before we can reach a decision about the next cycle, we will want to have a planning meeting to identify and estimate tasks, then prioritize them as a team.
Next Steps
[edit]2014-15 Projects - High Priority
[edit]We are considering one or more of these projects as high priorities for next year:
- Upload Pipeline
- Structured Data
- File Notifications
- Media Viewer 0.3
2014-15 Projects - Lower Priority
[edit]- File Feedback
- Better Search
- Campaign Tools
These options will be discussed in upcoming planning meeting for 2014-15.
2014-15 Ongoing Responsibilities
[edit]The team has maintenance obligations, technical debt and code review to clean up for the following projects:
- Timed Media Handler
- Upload pipeline
- Image scaling
- PDF handling
- Media storage
- Score
- GW Toolset
Metrics
[edit]Here are key metrics we're considering to track the impact of our work:
- 17k uploaders / month (1)
- 288k uploads / month (1)
- 8.0M files used in articles (39% of all files) (2)
- 105k image views / month in Media Viewer Beta (3)
(1) Commons uploaders / uploads in Dec. 2013. Source: Wikimedia Foundation (2) GlobalFileUsage stats on Mar. 21, 2014. Source: Wikimedia Foundation (3) Media Viewer Beta image use dashboards for Mar. 2014. Source: Wikimedia Foundation
We will continue this discussion in our next planning meetings, to identify a few key metrics that can measure overall multimedia usage, as well as our progress i supporting our users with new features and infrastructure upgrades.