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