Guide your users through a tour of your app

I'm part of a team that has been looking at using Shepherd (and ember-shepherd) within one of our externally-facing Ember sites, however we've noticed that the accessibility support is fairly minimal - there are no ARIA attributes on any Shepherd elements and the semantic markup could be improved (no nav tag around the navigation buttons, for example).

I know there was an issue #26 raised along these lines but it was closed without explanation late last year.

I realize that this is a period of transition in terms of the stewardship of Shepherd but I was wondering if any efforts were being planned in this regard.

The README.md states that Shepherd still supports IE11, but the dist and demo (latest beta) give JavaScript errors. So Shepherd doesn't work with IE11 right now.

Is there a way to fix these issues or build Shepherd with IE11 support? There are still a lot of IE11 users on our platform (> 10%).

The lambda's are definitely breaking for IE11, see following example:

// returns true if 'el' should be allowed to receive touchmove events
  const allowTouchMove = el => locks.some(lock => {
    if (lock.options.allowTouchMove && lock.options.allowTouchMove(el)) {
      return true;
    }

    return false;
  });

Is a progress indicator planned? Something like a set of dots denoting each step, and clicking a dot can take you to steps back.

Current step and total steps can currently be had as you suggested here: https://github.com/shipshapecode/shepherd/issues/427

There are few addStep I used, however, after step four, the overlay doesn't create an opening around my remaining target element (next step till the end).

Does anyone know how to solve this problem? Please help :( Thank you in advance!

Hi, first of all thank you for maintaining this module. I am trying to upgrade from tether-shepard and lots of things have changed.

I have tried both with 2-beta.14 and 2-beta.15 and get two different errors depending on the version.

in 2-beta.14 i get an error TypeError: __WEBPACK_IMPORTED_MODULE_1_shepherd_js___default.a.Tour is not a constructor importing it like this:

import Shepherd from 'shepherd.js';
import Popper from 'popper.js';
window.Popper = Popper;
window.Shepherd = Shepherd;

export function initTour() {
  return new Shepherd.Tour({
    defaults: {
      classes: 'shepherd-theme-default',
      scrollTo: true,
      showCancelLink: true,
    },
  });
}

in 2-beta.15 i get the error: TypeError: Popper is not a constructor

In node_modules/shepherd.js/dist/js/shepherd.js:430 at this.popper = new Popper(opts.element, this.el, popperOpts);

Any idea on what I am missing? Does Shepherd work when it is used within an es6 module?

Some advice would be greatly appreciated!

On the GitHub demo page, shouldn't I be disallowed from clicking on buttons outside of the tour unless I exit the tour or the tour specifically tells me to press a button?

When a tour is hidden because the target is not visible on the page (e.g. because of a media query), it is blocking/masking the content behind it. This is because it's still rendered (always in the top-left corner of the document) with just opacity: 0;.

Is this a known problem?

Demo

https://codepen.io/snap/pen/yLYXQmG

Possible fix

.shepherd-element[data-popper-reference-hidden]:not(.shepherd-centered) {
  opacity: 0;
  pointer-events: none; /* <- added */
}

Reduced Test Case Fiddle

https://jsfiddle.net/h8gwus79/

Version: whatever version https://shipshapecode.github.io is using right now

// never started 
const unused = new Shepherd.Tour({
  defaultStepOptions: {
    classes: 'shadow-md bg-purple-dark',
    scrollTo: true
  },
  useModalOverlay: true
});

// we start this one
const tour = new Shepherd.Tour({
  defaultStepOptions: {
    classes: 'shadow-md bg-purple-dark',
    scrollTo: true
  },
  useModalOverlay: true
});

tour.addStep('example', {
  title: 'Example Shepherd',
  text: 'Creating a Shepherd is easy too! Just create ...',
  attachTo: '#someImg',
  advanceOn: '.docs-link click'
});

tour.start();

<img src="https://img.kizuna.austinpray.com/images/879bf634e1ea4e63928dc36c4ac3add1.jpg" id="someImg" />

Current Behavior

Active step is not highlighted

note the duplicate shepherdModalOverlayContainers

Expected Behavior

Active step is highlighted

Comments

1. I would expect shepherd to not touch the dom at all until tour.start()
2. The insertion of the svg overlay should be idempotent

Hi,

I want to attach a step to an element with fixed width & height, this element has a div child (a dropdown content) positioned with the "absolute" css property.

When i configure the attachTo; element: '.parent-element'. the opac layer cover the entire screen, except my element, but the child element is not visible and covered by the opac layer.

Do you have any solution to not cover the parent element and his child ? or a way to specify multiple highlighted elements ?

Thanks

I'm using shepherd-react and I'm getting a strange behavior with the highlighted div, only the visible part on the screen is highlighted while the other part is not, and it stills like that after scrolling

I'm using a basic config four the tour and the steps, unfortunately I can't attach the code because it's a large react app here is a screenshot of the problem

Unless I'm missing something, it seems that Shepherd only supports "top, bottom, left, right" as options within the attachTo option.

It would be nice to add the ability to position items using "top left" or "bottom middle", etc.

http://github.hubspot.com/tether/#attachment

Adding an example use case of shepherd to Read Me

It's a plugin for an open source application called Budibase. The plugin allows you to easily create interactive walkthroughs.

demo

Promise function:

// TypeScript
{
  ...
  confirmCancel: () => {
    return new Promise<boolean>((resolve) => {
      // my dialog component
      dialog
        .open(
          "Are you sure you want to stop the tour?",
          "You can watch it again in setting paddle"
        )
        .then((res: boolean) => {
          resolve(res);
        });
    });
  },
  ...
}

https://github.com/shipshapecode/shepherd/blob/1076b0c37465cb48968b5f7159e08033cceaab20/test/unit/tour.spec.js#L295-L335 Unit tests have been passed.

I've installed shepherd.js as a node module using npm (version 10.0.1), and I'm getting this message when attempting to create a tour:

Uncaught ReferenceError: must call super constructor before using 'this' in derived class constructor

My code is the following:

import Shepherd from 'shepherd.js';

        this.tour = new Shepherd.Tour({
            useModalOverlay: false,
            defaultStepOptions: {
                classes: 'shadow-md bg-purple-dark',
                scrollTo: {behavior: 'smooth', block: 'center'},
            },
        });

The debugger points to this line of code:

class Tour extends Evented {
          /** ... **/
	  constructor(options) {
	    var this$1 = this;   // <----  This is where the exception is raised

	    if (options === void 0) {
	      options = {};
	    }

	    super(options);    // <--- complains this should have already been called?

When I download and included the file from the releases page manually in my app, it doesn't raise the exception. I'm a little confused as to why it works that way but not when I use the version from npm?

To add on to this closed issue, would it be possible to specify a direction bias for the auto property?

Something like auto-left auto-left-end etc.

Currently Shepherd seems to have a bias for the right side in auto mode when there is enough space for it to be anywhere.

Here's the CodePen I used for the screenshot. https://codepen.io/RazeiXello/pen/ExRjyLW

Hey there!

I'd like to "re-discuss" #1588 - I have the same use case, in which I would like to keep an input in the highlighted app part focused, and not have the step popup take focus away. Currently, you use floating-ui to focus the step element after 300ms timeout (see here).

I understand that this is something where you would like to figure out a general strategy around a11y. In my case, I would however rather disable this behavior entirely via some step option autoFocus = false or something like that. Would you accept a PR that introduces this ability, or you would not like to have such changes until you have a clearer position on this topic overall?