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