Page MenuHomePhabricator

Point to VE edit button in the GettingStarted tour only after the button is enabled
Closed, ResolvedPublic

Description

Author: swalling

Description:
What is looks like on enwiki now

Currently, GettingStarted's guided tour points to the Save button in VE immediately on page load. This conflicts with the introductory modal VE presents to users, and even when that is not present (it only shows once) the guider is pointing to a disabled button. We should delay loading the guider pointing to the Save button until after the user has made changes and the button is enabled.


Version: unspecified
Severity: enhancement

Attached:

Screen_Shot_2013-08-27_at_10.29.37_PM.png (934×1 px, 298 KB)

Details

Reference
bz53456

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:56 AM
bzimport set Reference to bz53456.

Possible approach:

  • Extend ve.ui.mw.Target class to fire the "sanityCheckComplete" hook
  • Add an awaitHook (?) property to the guider step definition, which indicates that the step should be shown once the hook has been fired
  • Add the property to the third step of the firsteditve tour with the value "sanityCheckComplete"

It seems more direct to put a hook in updateToolbarSaveButtonState (maybe ve.saveButton.stateChanged to match ve.saveDialog.stateChanged). Although sanityCheckComlplete calls updateToolbarSaveButtonState, I consider that more of an implementation detail.

As far as awaitHook, we basically have two choices:

  • Add it as a shouldSkip before doing the non-linear tour refactoring (similar to the VE hooks already there), further cluttering the main library.
  • Have this depend on bug 53143, and implement something like https://www.mediawiki.org/wiki/Extension:GuidedTour/Refactoring_brainstorming . This is a decent chunk of work, but it's already in our sprint. See the part about the listenFor proposal on the MediaWiki.org page.

(In reply to Matthew Flaschen from comment #2)

As far as awaitHook, we basically have two choices:

  • Add it as a shouldSkip before doing the non-linear tour refactoring

(similar to the VE hooks already there), further cluttering the main library.

  • Have this depend on bug 53143, and implement something like

https://www.mediawiki.org/wiki/Extension:GuidedTour/
Refactoring_brainstorming.

Given that this is normal priority, my vote is for the cleaner of the two: fix 53143 first and then return to this (#2).

This is a decent chunk of work, but it's already
in our sprint. See the part about the listenFor proposal on the
MediaWiki.org page.

We can always remove this from the current sprint, taking care to note that it is blocked on 53143.

Change 123171 had a related patch set uploaded by Mattflaschen:
Update firsteditve

https://gerrit.wikimedia.org/r/123171

Change 123171 merged by jenkins-bot:
Update firsteditve

https://gerrit.wikimedia.org/r/123171