Requests for comment/UploadWizard: scale to sister projects

This request for comment is about UploadWizard software which the Multimedia Team (WMF) is about to embrace and take over starting within next weeks and processing it during 2014, per the text on the software page.

Proposed change
What I would like to propose is to restructure the UploadWizard software to make the following functionality available to contributors:
 * Edit text of each wizard screen on-wiki.
 * Edit the flow of the wizard (which buttons exist on a screen, where they take) on-wiki.

Context
This request is based on the following observations:
 * English and Russian Wikipedia's article creation wizards appear to be entirely markup-based, with no JS. Contributors have the flexibilities mentioned above, but lack some nice flexible things JS would let them do, such as choosing a next wizard screen depending on multiple previous choices, or entering partial data to be carried forward from page to page.
 * A product which has the flexibilities mentioned above would have the potential to be deployed across all sister projects.
 * Such a product would also have the potential to work a bit gadget-like, to address use-cases I call “interactive templates”, to aid in daily editing routine and make it more intuitive.
 * A JS-based product of this kind is under development on English Wikinews.
 * Multimedia Team mention they would start working “in the coming weeks”, making feedback pertinent earlier better than later.
 * Editing on-wiki is more collaborative than querying editing files (like ones in an Extension) would be.
 * Markup should also be less-prone to security risks.

Amount of complexity involved
I'm not sure you fully appreciate the complexity involved in a project like this.

UploadWizard itself has thousands and thousands of lines of JavaScript code that deals with step navigation, different upload methods, error checking, interfaces for different choices along the upload path, and various API calls to save all of that information on the wiki. Putting all of that in a gadget *might* be possible, but putting most of it into wikitext is not.

And even if it's possible to shunt the backend UW code into core, and put all of the frontend code into a gadget, we would lose a lot of the benefits we get from having UploadWizard be an extension: It gets proper code review, it can be configured (and the configuration also gets code review), it can be distributed to third party sites, and so on.

I would be adamantly against pushing UploadWizard more on-wiki.

However, I would be very much in favour of sticking more client-side hooks into UploadWizard. You can already edit most of the text of the wizard through MediaWiki namespace message pages, so allowing gadgets to play with the workflow and the interface is IMO the only remaining task. Let's focus our attention on accomplishing a more extensible interface instead of totally rewriting it in a new language, and screwing with the established structure of the tool. --MarkTraceur (talk) 21:18, 10 February 2014 (UTC)
 * Yeah I would say that it is important to slowly rework the wizard where possible in more subcomponents that can be reused and hooked into, instead of a monolithic and intertwined blob. That is much more important then making everything editable. TheDJ (talk) 10:27, 11 February 2014 (UTC)

UploadWizard isn't going to be as much wizard-like as it currently is
I think the main issue with this RfC/discussion is that it's not distinguishing the current UploadWizard experience vs the one that's been collectively agreed on for the next version. They differ greatly, the new way of doing things doesn't rely on steps.

Having several steps to enter information is actually a weakness that we're about to get rid of. There is a big UX benefit to letting people enter the information while the content is being uploaded, as such most of the new experience will be happening on a single page. In order to make a compelling UI, this will need to be made in a traditional fashion, with JS running the show. As Mark described above, this is a level of complexity that goes way beyond what wikitext can do, there are too many moving parts. The history of the web is littered with attempts at making websites simple to write without knowing how to write code, but as soon as you delve into very technical sides like upload, it just gets too complex to do anything more than letting people bringing in a self-contained upload component that just handles everything.

Reuse is a big focus of the work we're about to do, at the javascript level. We intend to make UploadWizard very modular, which it currently isn't. So while the end-user experience will turn into a single dynamic page, the actual code that makes UploadWizard will be as modular as possible, to allow other extensions and projects to leverage upload ability with a different UI, to reuse components of the UploadWizard UI, etc. We always try to keep in mind the "amateur developer" experience when we organize the code like this, avoiding techniques that would be too complex and constantly improving the organization of the code, which benefits developers of all levels.

All of that being said, I can see the benefit in having wiki-specific preliminary wizard steps leading up to the new UploadWizard, similar to the current customizable "step 1" text. I'm unfamiliar with the current techniques that could be used for local wikis to achieve this, although I imagine that it's already possible.

Similarly, there could be benefit in building a general-purpose wizard system that could hook into anything, not just UploadWizard, that would display speech bubbles on top of specific elements, introducing how the UI works, step by step. Again, I'm unfamiliar with what's currently available (I think I recall something kind of like this when I created a wikipedia account recently), maybe there are similar things already out there that can do that. That I could imagine being fully definable in wikitext, by specifying pages to open, CSS selectors to target, etc. With options such as selecting a field for the user (keyboard focus), fading/hiding parts of the UI and so on. That would be a wizard as a layer on top of an actual extension/page, not a wizard that's part of the extension itself.

Bottom line is, if you want to customize the UI of the UploadWizard itself (where the fields are placed, which ones are required, etc.), CSS/JS seems unavoidable to me.--GDubuc (WMF) (talk) 10:50, 11 February 2014 (UTC)

which wizard are we talking about?
the page title and intro talk about "upload wizard". however, the "context" paragraph seem to be about the "article creation wizards". these are two wildly different discussions that, at least at first glance, seem to be hopelessly conflated. it's not at all clear from the discussion which wizard is being discussed here. please clarify. thanks, peace - קיפודנחש (talk) 23:21, 10 February 2014 (UTC)
 * קיפודנחש, that's right. The title says: "scale upload wizard to sister projects", meaning "scale upload wizard for all wizard needs of sister projects". Gryllida 02:38, 11 February 2014 (UTC)
 * Oh right, that really wasn't clear to me (and I suspect others). "Scale" doesn't seem the right word to use. Perhaps "Wizard framework" would be a more appropriate title, if that's what is being proposed? the wub "?!"  12:14, 11 February 2014 (UTC)