Extension:GuidedTour/Shared tour instructions

A series of steps
First, you have to consider when and how your tour should start.

The tour itself is a sequence of dialog windows that appear on the page, called steps. (It is possible to have a single-step tour that operates as a fancy tooltip, and to jump into the tour at different points.)

Each step can optionally have a next button, a back button, or both. You can also have the tour automatically move (transition) from one step to another in response to a user action (for instance, when the user makes their first change to an open VisualEditor window). You define the tour in a JavaScript function, calling API methods to construct and link the steps together.

The extension keeps track of the current step in each tour in a browser cookie. By default, a tour will continue across multiple web pages.

Implementation

 * 1) Consult the design recommendations and the API documentation.
 * 2) Choose a tour name.  This and   (if applicable) should be set when constructing the   (see example tours below).
 * 3) If you want to log certain events with Schema:GuidedTour, add:
 * 4) For each step in your tour:
 * 5) Choose title and description text.
 * 6) Then, choose whether the step will have an attachment or a central overlay:
 * 7) * Attachment positions a step near a page element such as the Edit tab, a link, or the save button. You identify the page element using a selector.  Any jQuery selector can be used.  In general, this includes all CSS selectors.  This example positions near the Edit tab using an id selector:
 * For attachments, you must choose an attachment position. The choices are topLeft, top, topRight, rightTop, right, rightBottom, bottomRight, bottom, bottomLeft, leftBottom, left, leftTop.  You can experiment with these values, and may want to test in a skin beside your primary one (using the useskin parameter).  For on-wiki tours, you should test in the wiki's site direction (which does not vary by user or according to uselang).  If you're not sure what this is, you can check in a JavaScript console with:
 * Extension-defined tours should always be written left-to-right. In either case (on-wiki or extension tours), if the user is using another direction (for example, they are browsing English Wikipedia but have their interface language set to Hebrew in preferences), steps will automatically flip horizontally.
 * 1) * By default (if you do not choose one of the directions above) the step shows in the center of the screen. This allows you to explain something without attaching to an element.  In this case, it is recommended that you use an overlay to draw focus to the step:
 * 2) To link steps together, you can use Next and Back buttons.  These will automatically be added if you tell the tour how to find the Next and Back steps.  For example:
 * 3) * For Next:
 * 4) * For Back:
 * Both Next and Back can be used on the same step. Also, more powerful behavior is available (such as choosing a different next or back step depending on context); see the 'next' and 'back' methods in the API documentation.
 * 1) Choose any further button actions you want to add to the step.  If you want the user to click something (such as the edit tab), you can provide no explicit buttons (an Okay button that dismisses the step will still show).   If you only want Next and/or Back buttons, you do not need to specify anything here (see above).  Otherwise, you will want to specify one or more.  You can specify arbitrary button actions.  However, there are helpers included for common button behaviors.  For   and , no custom button text is necessary.  For the others, use   or   (see below sections):
 * 2) *  - Shows as an Okay button.  Will run the specified function when the button is clicked.
 * 3) *  - Shows as an Okay button.  Will end the tour when clicked.
 * 4) *  - Shows as a textual button.  Will go to the specified wiki page when clicked.
 * 5) *  - Shows as a textual button.  Will go the specified external web site when clicked.
 * 6) * For any of the buttons, you can specify the type of button as,  ,  ,  , or  .  See the Living Style Guide for an explanation of the meanings. For example:
 * 7) By default, the step will close when they click outside it.  In some cases, such as on the edit page, you may want to disable this by including:
 * 8) Decide if you want transition behavior.  In some cases, you will want to automatically transition to another step when an event (including page load) occurs.  For example, if you have a step asking the user to click Edit, you may want to transition to a step pointing to the Preview button (  in this example) once they're on the edit page.  For more information about transitions, see the API documentation on the 'transition' method.
 * 1) *  - Shows as an Okay button.  Will run the specified function when the button is clicked.
 * 2) *  - Shows as an Okay button.  Will end the tour when clicked.
 * 3) *  - Shows as a textual button.  Will go to the specified wiki page when clicked.
 * 4) *  - Shows as a textual button.  Will go the specified external web site when clicked.
 * 5) * For any of the buttons, you can specify the type of button as,  ,  ,  , or  .  See the Living Style Guide for an explanation of the meanings. For example:
 * 6) By default, the step will close when they click outside it.  In some cases, such as on the edit page, you may want to disable this by including:
 * 7) Decide if you want transition behavior.  In some cases, you will want to automatically transition to another step when an event (including page load) occurs.  For example, if you have a step asking the user to click Edit, you may want to transition to a step pointing to the Preview button (  in this example) once they're on the edit page.  For more information about transitions, see the API documentation on the 'transition' method.
 * 1) * For any of the buttons, you can specify the type of button as,  ,  ,  , or  .  See the Living Style Guide for an explanation of the meanings. For example:
 * 2) By default, the step will close when they click outside it.  In some cases, such as on the edit page, you may want to disable this by including:
 * 3) Decide if you want transition behavior.  In some cases, you will want to automatically transition to another step when an event (including page load) occurs.  For example, if you have a step asking the user to click Edit, you may want to transition to a step pointing to the Preview button (  in this example) once they're on the edit page.  For more information about transitions, see the API documentation on the 'transition' method.
 * 1) By default, the step will close when they click outside it.  In some cases, such as on the edit page, you may want to disable this by including:
 * 2) Decide if you want transition behavior.  In some cases, you will want to automatically transition to another step when an event (including page load) occurs.  For example, if you have a step asking the user to click Edit, you may want to transition to a step pointing to the Preview button (  in this example) once they're on the edit page.  For more information about transitions, see the API documentation on the 'transition' method.
 * 1) Decide if you want transition behavior.  In some cases, you will want to automatically transition to another step when an event (including page load) occurs.  For example, if you have a step asking the user to click Edit, you may want to transition to a step pointing to the Preview button (  in this example) once they're on the edit page.  For more information about transitions, see the API documentation on the 'transition' method.

Note that if a step doesn't have a button to take them somewhere, you'll generally want to implement a  function for the current step that allows them to go somewhere. Otherwise the tour will "stall" on it — every time the user reloads the page or visits any page that loads your tour, the current step will reappear until the user exits the tour.

Tips

 * Use debug mode while developing your tours.
 * Inspect the tour cookie (named wgCookiePrefix-mw-tour) to see what step your tour is on.
 * Even when writing an on-wiki tour, use a JavaScript checker such as jshint to check for errors in your tour definition.
 * When stepping through your code in a browser debugger, the  function in guiders.js is one of the most useful functions in which to set a breakpoint.