Extension:GettingStarted/Architecture discussion

HTML and CSS relationship
Right now, the CSS is.

But the HTML uses MediaWiki:gettingstarted-msg, and the default value of that is 'An administrator on should customize this message by editing    :gettingstarted-msg.'.

Basically, the CSS is implicitly depending on HTML outside of the extension, with the default message being a placeholder. This has lead to inconsistencies, where the interface appears broken due to the on-wiki HTML being out of sync with the CSS in the extension.

With Munaf's latest styling (43982 in progress), it should be possible to have default chrome HTML (everything outside the three columns), with a transclusion to another page. In English Wikipedia's case, that include would be the Copyediting/Spelling & grammar/Add links columns, populated by SuggestBot initially.

Does it make sense to put that outer HTML with an include as the default message?
 * Not yet. The feature of GettingStarted on its own is it makes the end of account creation a free-standing named page that users can return to. Let's leave it up to each wiki how they use the feature, maybe they'll build a new user dashboard or a "What's up for new users" that is nothing to do with presenting tasks to new users. -- S Page (WMF) (talk) 23:12, 27 January 2013 (UTC)
 * I probably wasn't clear. In practical terms (with the current HTML), I mean everything outside onboarding-tasks (both HTML and CSS) should be out-of-the-box, while the rest is wiki-specific MW messages.  I think this will make it easier to vary the purpose. Superm401 - Talk 08:25, 30 January 2013 (UTC)
 * I think Matt's suggestion ("everything outside onboarding-tasks (both HTML and CSS) should be out-of-the-box, while the rest is wiki-specific MW messages") is the sane solution here. Keep in mind that soon we hope to get rid of the dependency on SuggestBot and content delivered from an on-wiki template. Steven Walling (WMF) &bull; talk   19:23, 13 February 2013 (UTC)

On-wiki JS CSS
CSS that's specific to the inner wiki-specific part, should probably go in a CSS page in the MediaWiki namespace. This can use essentially the same mechanism as GuidedTour uses for wiki-specific CSS.

On the JS side, this could include loading tours for wikis that choose to use them.

Loose dependencies
For testing and stability, the less dependencies the better. For external users, we just need the code to work if some of E3Experiments, EventLogging, and GuidedTour aren't loaded. For WMF wikis, we may need explicit global variables as well.

Decouple from Extension:GuidedTour
GettingStarted may be useful on wikis that don't deploy GuidedTour, so add a global config variable or maybe detect if GuidedTour is loaded before requiring it.
 * In the browser
 * in ext.gettingStarted.js, simply


 * On the server
 * I (spage) don't know how an Extension can adjust a $wgResourceModule's dependencies according to whether another extension can provide a module. Maybe by declaring the dependencies in an onSetup handler or onResourceLoaderRegisterModules (mail sent)

If a wiki has GuidedTour available but no guiders for its GS help, it should modify the HTML to remove class.


 * I'm now leaning towards this (making GuidedTour an optional dependency). See above re wiki-specific JS, which would allow wikis to load the tour of their choice (plus do other stuff). Superm401 - Talk 08:33, 30 January 2013 (UTC)

Leave decoupled from E3Experiments
Note the openTask tracking and logging for GettingStarted happens in Extension:E3Experiments code (/experiments/openTask.js). This is confusing, but it means you can deploy GettingStarted without E3Experiments (and without EventLogging).

(BTW GuidedTour invokes mw.eventLog.logEvent, it should test first for if mw.eventLog and mw.eventLog.logEvent before setting gt.pingServer.)

Logging
The logging for GettingStarted should be moved from Extension:E3Experiments to Extension:GettingStarted