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
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
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.
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
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
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
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
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
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)