Multimedia March 2015

multimedia@lists.wikimedia.org

16 participants
9 discussions

State of the Wizard, March 2015
by Mark Holmquist 30 Mar '15

30 Mar '15

Hi, all. As a summary of what I've been spending my time on lately, and as a neat reference for any future work, I thought I would explain where I see us in UploadWizard land, from a technical point of view, from a UX point of view, and from whatever other perspective I can provide. == Technical == UploadWizard is still a bit of a mish-mash. It has about three different design methodologies still in use today, though one has become dominant over the past few months of refactoring work. I've tried very hard to make UploadWizard a mostly-JavaScript, MVC-driven, OOJS-centered piece of software. There are bits remaining on the backend - mostly initial interface construction and configuration, some of which makes sense - and there are still lots of non-OOJS bits and spaghetti code laying around, too. The grand future that I saw in January of this year was that each step in the wizard should be a "class" (insomuch as that's a thing in JS), and that they should receive and emit arrays of uploads instead of relying on the parent UploadWizard class to keep track of global state. That dream is very nearly a reality, however one major thing stands in the way: The metadata copying functionality. This feature uses the global upload list in a way that I cannot easily circumvent, and in order to fix it, there must be a significant change in the implementation and UX of that feature - see https://phabricator.wikimedia.org/T90741 which is no small feat. Other areas that need improvement include the upload objects, which are still poorly defined and barely tested. A similar MVC framework for them would be nice, though it could be less strictly separated in this case. There's also a WIP patch for https://phabricator.wikimedia.org/T89356 - namely https://gerrit.wikimedia.org/r/192809 - which makes the "add files" functionality a lot cleaner in the code. This particular change was not necessary to complete the refactoring goals for this quarter. And of course, there's OOUI. The new design for the metadata copy feature will use it, because new features always should, but the road to OOUI- fication of UploadWizard is a long one. rmoen was kind enough to do a big patch for it once upon a time, but the rebase process for that patch would almost certainly take longer than the patch itself did. If anyone is looking to take this on, I suggest small patches for one or two controls at a time, like I did in https://gerrit.wikimedia.org/r/187238 and https://gerrit.wikimedia.org/r/187415 == UX == UploadWizard is often touted as the more friendly upload process, but its design is hardly as friendly as it could be. OOUI is a good step in the right direction, but realistically, we need to rethink parts of the process entirely. The most basic improvement we could make would be to add "remove" buttons on every step. This issue has been open for some time, but was blocked due to issues with the global upload list being difficult to maintain. Since the global upload list is nearly gone, we could probably reopen the WIP patch, or write a new patch, and get this done. Another relatively simple change would be to upload files in the background, and allow the user to add descriptions, licenses, etc. while that process finishes. Then, at the end of the wizard, the final "finish uploads" step could wait for all of the processes to be complete before allowing them to continue to another batch. == Testing == We always need more testing, of course. The new browser tests that the multimedia team wrote over the past few months are a great start, but we didn't cover everything, and the unit tests are still imperfect, too. Further refactoring may be necessary to make the latter problem solvable, but browser tests are getting easier and easier to write. == Extensibility == This has always been in the back of my mind. I would love to see UploadWizard built up to the point where you could add or modify steps from the gadget interface. I would also love to see all of the Commons- specific cruft that has built up over the years put into gadgets. But this is a very-long-term goal, and it's superseded by other priorities. If you love the idea, please feel free to run with it. The mw.hook and related interfaces should be able to do the trick. == Flickr == An ongoing concern is the security and completeness of our implementation of Flickr imports. bawolff and I are planning on working on this in Lyon, and hopefully we'll get something useful off the ground there. My remaining issues include verification on the backend, addition of license text on the backend, and better-separated and -tested code for the Flickr uploads on the frontend. == Reuse == And finally, reuse. Embeddable UploadWizard has been a wishlist item for longer than I have worked on the project. We want to upload files from other wikis, so users aren't confused by the domain change. We want to do it from inside the editor, so it's more like other editors. We want to do it from inside of VisualEditor, because it's even more jarring to not see this basic feature in such a modern interface. Well, this is still a ways away. We cannot dump UW into a new environment without cleaning up at least some of the above issues, and after that, there are still potential problems with CORS support, the interface being built on the backend, building a sane dependency tree, and so on. That said, I would love nothing more than to see embedded UW. Anyway, sorry about the brain-dump. I felt I needed to write this up so it would be on-record exactly where we are and where we should go. Thanks, all. It's been a great run. I'm sure you'll still see patches of mine in mediawiki/extensions/UploadWizard from time to time :) -- Mark Holmquist Software Engineer, Multimedia Wikimedia Foundation mtraceur(a)member.fsf.org https://wikimediafoundation.org/wiki/User:MHolmquist

1 0

Fwd: [Wikitech-l] Org changes in WMF's Platform Engineering group
by bawolff 27 Mar '15

27 Mar '15

I'm taking the liberty of forwarding this to the multimedia mailing list, as the list has a lot of interested parties (from the "community") on it who I think would be keenly interested in how the team structure of WMF affects multimedia, and probably don't read wikitech-l. For full context, read the quoted email from robla at the bottom first. --bawolff ---------- Forwarded message ---------- From: Gilles Dubuc <gilles(a)wikimedia.org> Date: Wed, Mar 25, 2015 at 1:18 PM Subject: Re: [Wikitech-l] Org changes in WMF's Platform Engineering group To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org> > > Does this mean there will no longer be a multimedia team/nobody responsible > or working on what the multimedia team was working on previously? > We'll keep supporting the extensions that multimedia used to cover, in terms of addressing emergencies. This will probably be done by *the people formerly known as multimedia*, because for now there isn't any better pick than people who've worked with those extensions as first responders on breaking issues. That might change when a reactor team is formed and staffed later down the line. As far as active development goes, some things are still in the pipeline, like addressing technical issues that affect UploadWizard's funnel. This is assigned to the API team but isn't the top priority for the coming quarter (I think it's 3rd in the list, but someone might know better). More ambitious projects like structured data on commons will need a dedicated team. Resourcing for such projects will depend on organization-wide priorities. My humble opinion is that it's a good thing to have less catch-all teams like "core" and "multimedia" and rather have teams focused on narrower, well-understood scopes. Multimedia was a vague term and it made us spread ourselves thin across many unrelated extensions and projects. It also gave the illusion that we were going to take care of everything, but we were really too small to undertake ambitious things like bringing video support into the modern era or making commons data structured. As much as it must feel disappointing that these projects are on the backburner, they already were, because of how small the multimedia team was. Maintaining the illusion wasn't a good thing, I think. On Wed, Mar 25, 2015 at 12:26 PM, Brian Wolff <bawolff(a)gmail.com> wrote: > On Mar 24, 2015 10:45 PM, "Rob Lanphier" <robla(a)wikimedia.org> wrote: > > > > Hi folks, > > > > First things first: I'm not burying the lede in this email, so if you > > aren't interested in the inner workings of WMF's Platform Engineering > team, > > feel free to ignore the rest of this. :-) > > > > We're making a few changes effective in April for Platform Engineering, > > which you all care deeply about because you're still reading. > > > > We're looking to give the teams a little more clarity of scope. > > Previously, among other teams in Platform Engineering, we had a large > > MediaWiki Core team, and a smaller Multimedia team. We played a big game > > of musical chairs, and everyone from those teams is part of a new team. > > Additionally, the Parsoid team got into the fun, getting a new member as > a > > result. > > > > > > - > > > > Performance - This team is shooting for all page views in under 1000ms > > < > > https://docs.google.com/presentation/d/1MtDBNTH1g7CZzhwlJ1raEJagA8qM3uoV7ta… > >. > > The team plans to establish key frontend and backend performance > metrics > > and assume responsibility for their curation and upkeep, and get a > handle > > on web page rendering performance. Right now, it's all about > VisualEditor, > > but over time, this is going to be a more generalized function. > > - > > > > Members: Ori Livneh, Gilles Dubuc (soon!), now hiring! > > - > > > > Availability - Make MediaWiki backend failures diminishingly > infrequent, > > and prevent end users from noticing the ones that do by making > recovery as > > easy and automated as possible. This team does ops facing work that > > contributes to the overall stability and maintainability of the > system. > > Things like multi-datacenter support, and migrating off of outdated > > technology to newer, more reliable tech. > > - > > > > Members: Aaron Schulz and Gilles Dubuc (for now, until he wraps up > > work on multi datacenter) > > - > > > > MediaWiki API - This team's goal wil be make user interface > > innovation+evolution easier and make life easier for our sites' robot > > overlords by making all business logic for MediaWiki available via > well > > specified API. Some APIs will be in PHP and some external over HTTP > > depending on the needs of other teams. > > - > > > > Members: Brad Jorsch, Kunal Mehta, Gergo Tisza, Mark Holmquist. > Stas > > Malyshev plans to join this team when his work on Wikidata Query > > wraps up. Bryan > > Davis plans to join as soon as his role as interim Product Manager > for > > Platform wraps up. > > - > > > > Search - Provide unique and highly relevant search results on > Wikimedia > > sites, increasing the value of our content to readers and providing > tools > > that help editors make our content better. The team will continue > working > > on existing backlog of the CirrusSearch/Elasticsearch bugs and > > improvements, plus Wikidata Query > > - > > > > Members: Nik Everett, Stas Malyshev (for now...), James Douglas, > also > > now hiring! > > - > > > > Security - making life hard for the people that want to do harm to our > > sites or the people that use them. > > - > > > > Members: Chris Steipp, also now hiring! > > - > > > > Programs support - support our non-tech programs with tools that > delight > > our users and maintain the privacy and security of our community, > providing > > infrastructure for things like Wikimania scholarships, grant program > > applications, and ContactForm. > > - > > > > Members: Niharika Kohli, Bryan Davis(20%) > > - > > > > Parsing (renamed from "Parsoid") - There are a number of changes to > our > > PHP parser that would make things easier for VisualEditor and Parsoid, > > while at the same time offering a more powerful and easy-to-use > authoring > > environment for our editors (even those using wikitext). Having Tim > on a > > rebranded “Parsing” team gives that team agency to start evolving > wikitext > > again, in a way that is supported by Parsoid HTML from day one. > > - > > > > Members: Existing Parsoid team (Subbu Sastry, Marc Ordinas i > Llopis, > > Arlo Brenault, and C. Scott Ananian), plus (new) Tim Starling > > > > > > You'll notice that some of these teams are pretty small, especially given > > their scope. This is likely to be at least a little fluid for a while as > > we make sure we have the balance of work right and as we figure out the > FY > > 2015-16 budget. > > > > Let us know if you have any questions about this. I say "us" because > I'll > > actually be traveling shortly. Feel free to ask the individual members > of > > the teams what's up, or if you don't know who to go to, Bryan Davis will > be > > filling in for my duties while I'm out. > > > > Thanks > > Rob > > _______________________________________________ > > Wikitech-l mailing list > > Wikitech-l(a)lists.wikimedia.org > > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > > Thanks for sending this, its always good to be able to figure out who is > working on what. > > Does this mean there will no longer be a multimedia team/nobody responsible > or working on what the multimedia team was working on previously? > > --bawolff > _______________________________________________ > Wikitech-l mailing list > Wikitech-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

1 0

Text-to-speech mobile app for wiki
by Dmitry Talisman 26 Mar '15

26 Mar '15

Hi, I’m working on mobile application that reads wikipedia articles using IOS Siri voice. It downloads text extract, breaks it to chapters and reads, allowing to skip to the next chapter. Siri voice is still quite annoying, but it is getting better every year. This app could be useful for people who want to listen to wikipedia content while on the move: driving or walking , or visually impaired. It is much more convenient than the out-of-the box text to speech feature that allows you to listen to selected text. The app allows to search articles by geolocation or by title. See attached screenshots. I would like to ask for your advice and opinion on a few issues. 1. Are there any license limitations for wikipedia content that would put restriction on how such app can function ? 2. Do you know if this was tried before? If yes, it probably failed because I don’t see any app of these kind in the app store. Any recommendations how to make it work and reach out to the maximum number of users who may find it useful ? 3. Any features you would recommend that may be useful in such application? 4. Who can help me with the question regarding Wikipedia logo/mobile icon trademark reuse ? If trademark allows , I would consider replicating Wikipedia mobile app icon with the word “audio” beneath W. Any help greatly appreciated! Thank you, Dmitry Talisman.

1 0

Structured data on Commons update
by Keegan Peterzell 23 Mar '15

23 Mar '15

Greetings, After a delay in updates to the Structured data on Commons[1] project, I wanted to catch you up with what has been going on over the past three months. In short: The project is on hold, but that doesn't mean nothing is happening. The meeting in Berlin[2] in October provided the engineering teams with a lot to start on. Unfortunately the Structured Data on Commons project was put on hold not too long after this meeting. Development of the actual Structured data system for Commons will not begin until more resources can be allocated to it. The Wikimedia Foundation and Wikimedia Germany have been working to improve the Wikidata query process on the back-end. This is designed to be a production-grade replacement of WikidataQuery integrated with search. The full project is described at Mediawiki.org[3].This will benefit the structured data project greatly since developing a high-level search for Commons is a desired goal of this project. The Wikidata development team is working on the arbitrary access feature. Currently it's only possible to access items that are connected to the current page. So for example on Vincent van Gogh you can access the statements on Q5582, but you can't access these statements on Commons at Category:Vincent van Gogh or Creator:Vincent van Gogh. With arbitrary access enabled on Commons we no longer have this limitation. This opens up the possibility to use Wikidata data on Creator, Institution, Authority control and other templates instead of duplicating the data (what we do now). This will greatly enhance the usefulness of Wikidata for Commons. To use the full potential of arbitrary access the Commons community needs to reimplement several templates in LUA. In LUA it's possible to use the local fields and fallback to Wikidata if it's not locally available. Help with this conversion is greatly appreciated. The different tasks are tracked in Phabricator[4]. Volunteers are continuing to add data about artworks to Wikidata. Sometimes an institution website is used and sometimes data is being transfered from Commons to Wikidata. Wikidata now has almost 35.000 items about paintings. This is done as part of the Wikidata WikiProject "Sum of All Paintings"[5]. This helps us to learn how to refine metadata structure about artworks. Experience that will of course be very useful for Commons too. Additionally, the metadata cleanup drive continues to produce results[6]. The drive, which is intended to identify files missing {{information}} or the like structured data fields and to add such fields when absent, has reduced the number of files missing information by almost 100,000 on Commons. You can help by looking for files[7] with similarly-formatted description pages, and listing them at Commons:Bots/Work requests[8] so that a bot can add the {{information}} template on them. At the Amsterdam Hackathon in November 2014, a couple of different models were developed about how artwork can be viewed on the web using structured data from Wikidata. You can browse two examples[9][10]. These examples can give you an idea of the kind of data that file pages have the potential to display on-wiki in the future. The Structured Data project is a long-term one, and the volunteers and staff will continue working together to provide the structure and support in the back-end toward front-end development. There are still many things to do to help advance the project, and I hope to have more news for you in the near future. Contact me any time with questions, comments, concerns. 1. https://commons.wikimedia.org/wiki/Commons:Structured_data 2. https://commons.wikimedia.org/wiki/Commons:Structured_data/Berlin_bootcamp 3. https://www.mediawiki.org/wiki/Wikibase/Indexing 4. https://phabricator.wikimedia.org/T89594 5. https://www.wikidata.org/wiki/Wikidata:WikiProject_sum_of_all_paintings 6. https://meta.wikimedia.org/wiki/File_metadata_cleanup_drive 7. https://tools.wmflabs.org/mrmetadata/commons/commons/index.html 8. https://commons.wikimedia.org/wiki/Commons:Bots/Work_requests 9. http://www.zone47.com/crotos/?p=1&p276=190804&y1=1600&y2=2014 10. http://sum.bykr.org/432253 -- Keegan Peterzell Community Liaison, Product Wikimedia Foundation

3 2

UploadWizard Turn off license, default description language
by Marcel Hamade 16 Mar '15

16 Mar '15

Dear all, I'm planning to use UploadWizard in our small corporate wiki. I have a few questions * Can I turn off the "Choose license" part completely? I want an easy quick upload * Can I turn off the Flickr-Button? * Can I switch the default description language to german? Kind regards Marcel

3 3

Editor training for VisualEditor
by Pine W 15 Mar '15

15 Mar '15

Hi all, As mentioned on the Education mailing list, some thematic organizations have already, or will soon, produce training materials for VisualEditor in a variety of languages. Cascadia Wikimedians needs at least a lesson plan for our workshops in April, so I/we will produce materials in English, probably in video form that includes two major sections: about Wikipedia and its sister projects, and how to edit Wikipedia with VisualEditor. My hope is to produce a 30 to 60 minute video that can get new editors to a basic level of Wikipedia competence in one hour including competence with talk pages, notability, copyright, plagarism, conflict of interest, and deletion discussions. I also hope that new editors will feel excited to participate in the community when they finish watching the video. Stay tuned for further developments. If other English speaking Wikimedians are interested in helping with the production then please email me off list. Thanks, Pine

4 5

Upload images from VisualEditor
by Marcel Hamade 12 Mar '15

12 Mar '15

Hi everyone, I've read that the VisualEditor team is planning to integrate an upload-image feature but that this "requires some significant preparatory work from the Multimedia team; VIsualEditor-en work mostly done". Any plans when it could be possible that I can upload images directly from VIsualEditor instead of going through a separate upload process. Regards Marcel

2 1

TimedMediaHandler ogv.js patch status check
by Brion Vibber 04 Mar '15

04 Mar '15

I've done an update pass on the patch to TimedMediaHandler adding my ogv.js JavaScript Ogg Theora/Vorbis playback engine for IE 10/11 and Safari 6.1+ users: https://phabricator.wikimedia.org/T63823 It now comes in two parts: * https://gerrit.wikimedia.org/r/#/c/165477/ - libraries only * https://gerrit.wikimedia.org/r/#/c/165478/ - TMH modifications for desktop only (I wasn't happy with the mobile video overlay in the third patch and have abandoned it for now, will rewrite it soon but want to sync up with mobile web team on integration issues.) This version should pretty much "just work" on desktops/laptops, including seeking, and the JS console spam should be gone now. If folks have strong preferences on my plugin code, do let me know and I will tweak further. :) I have a live wiki running at http://ogvjs-testing.wmflabs.org/ -- note that thumbnail images of some videos there are broken due to some kind of InstantCommons issue but the actual video plays through. -- brion

2 3

Media Viewer 2014 Reports
by Fabrice Florin 02 Mar '15

02 Mar '15

Hi folks, The multimedia team completed a review of Media Viewer in recent weeks, and we'd like to share a few highlights of what we learned from this project in 2014. 1. Research Here are some key findings from our research about this product: • Media Viewer serves a lot more images than before (17M intentional views/day) • Most users keep Media Viewer enabled (99.5% enabled) • Media Viewer key features were found easy to use • Media Viewer is more useful for readers than active editors More information can be found in this Media Viewer Research 2014 report: https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Research_2014 <https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Research_2014> See also these companion slides for a visual presentation of more findings: https://commons.wikimedia.org/wiki/File:Media_Viewer_Research_-_2014_Slides… <https://commons.wikimedia.org/wiki/File:Media_Viewer_Research_-_2014_Slides…> 2. Retrospective The multimedia team also discussed lessons learned from this project in 2014, identifying what worked and what didn’t work, in order to inform future product development. Here are some highlights of that team review. The Media Viewer project ran from July 2013 to November 2014 and was more challenging than expected. While the product received favorable or neutral feedback on most Wikimedia sites, it was met with negative reactions from many contributors on the English and German Wikipedias, as well as on Wikimedia Commons. This caused the team to work longer than planned, to improve features based on user feedback. What worked well: • Detailed activity and performance metrics. • Design research -- before and after implementing a feature. • Working with community champions in different projects. • Agile development process and tools. • Unit tests to improve the code. What didn't work well: • Many community discussions did not effectively inform product development. • Surveys were not representative, because they were optional. • We lacked the tools to get productive feedback from different user groups. • Juggling feature and platform development at the same time was hard. • Scope creep; the workload kept growing beyond available resources. • No clear success metric; we couldn't tell if we had met our goal. More findings can be found in this Media Viewer Retrospective summary: https://www.mediawiki.org/wiki/Multimedia/Media_Viewer/Retrospective Please let us know if you have any questions about this research or retrospective. You’re also welcome to add your feedback on the Media Viewer talk page: https://www.mediawiki.org/wiki/Extension_talk:Media_Viewer/About#Media_View… I'm grateful to all the team members who worked on these documents, especially Gergő and Gilles. These findings can help us better understand how Media Viewer serves our users — and how we can improve not only this product but also our development and release process. This will be my last post on behalf of the multimedia team, as I have now transitioned into a new role at the Wikimedia Foundation, working as Movement Communications Manager. Senior engineer Gilles Dubuc is now leading the multimedia team and can answer questions related to upcoming projects. I’d like to thank all the community members who worked closely with us on this project, as well as my colleagues on the multimedia and product teams. We learned a lot together, and I really enjoyed creating a better product with you all. I look forward to more collaborations in coming years. Regards as ever, Fabrice _______________________________ Fabrice Florin Movement Communications Manager Wikimedia Foundation https://en.wikipedia.org/wiki/User:Fabrice_Florin_(WMF)

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

Multimedia March 2015