I did raise a ticket on this but as a more general thing:
What is it with js libraries using data- tags without any kind of "namespacing". For example this library uses data-intro which could easily clash with other things in future.
Would it not be good for everyone to be a good citizen and instead do things like data-ch-intro? Just a few characters from your project name to reduce the chances of clashes.
I think that's an interesting point, and certainly a problem that will grow as data attributes become even more widely used.
Perhaps there's even use for a little database that keeps track of the different data attributes used by different libraries so that authors could easily find out if their name of choice will collide with someone else's, at least as a forewarning to its user about possible incompatibilities.
Some sort of data attribute namespace, which is uniquely identified by a URI, and aliased within the document to shorter version? Might look something like this?
Not necessarily. I do agree that requiring a tour can be an indication that your app is too complex, but sometimes its just a good opportunity to display some light marketing (as in, show stuff behind your app that might be abstracted from the interface in order to avoid cluttering it).
In the use case I built Chardin.js for, I'm using it to display stuff that happens behind the scenes that the user is abstracted for, but I still want the user to know its happening (perception of value is almost as important as value delivered!).
Also, some web apps are power tools for a specific group of employees, rather than a consumer-facing app. In college I worked on a dormitory reservation system that was fairly complex, and was only used by administrators and front desk workers (and they went through brief training for the system). I built a quick little "help mode" overlay system that worked well enough, but something like this would have been a great alternative.
Not at all. Anything sufficiently novel is going to need explanation.
Just look at the tutorials in video games, which get you started. Or for a great example, try out the new Mailbox app -- they do a fantastic job of explaining how the swipes work. In certain cases, a little investment in "training" pays far greater dividends later on.
Of course, there are plenty of apps/sites that aren't novel enough to need this, where everything is straightforward.
Sometimes you don't have any choice. On Android, for example, you have to follow the design guidelines if you want to get featured. However the design guidelines say your actions should be tiny unobtrusive icons in the action bar. Users miss these all the time in user testing in my experience. If you made them big, glossy, 3D looking buttons people would find them, but then you'd violate guidelines. So often we have to put these tutorial overlays up instead with big white arrows over a darkened screen pointing out the actions.
I'm working on an app that has one page that's quite complicated (but in my opinion really easy to use once you've learned how it works). Basically you're outlining the structure of a document, so you have to create a table of contents for the document in a left hand pane (33% width) and then mark corresponding regions on the right hand pane using your mouse, and there are buttons on the left pane to store/load a region corresponding to an entry in your table of contents. As two separate pages the workflow is a little awkward because logically the two steps are related, but when we put the two pages together we found that there was no place to put instructions. I ended up putting in one of those guided tour scripts where you click around to go through it. The thing is once you've used it once it's really obvious what to do and the UI is pretty efficient but you need some way of explaining the interface the first time, and I think something like this is better than wasting a lot of space on instructions.
(I'd link to the app to make it clearer, but it's still a work in progress and at the moment I need to control the number of people using it so we can figure out how it scales before launching it to the world - plus it's really an educational application for instructors so most people wouldn't be interested).
I always feel that such glib attempts at one-upmanship are a good indication of immaturity.
Or perhaps you don't get involved in producing anything with non-trivial functionality? Because anything simple enough not to need instruction is probably too trivial to be worth using.
There is nothing intuitive in life except fear of heights and (possibly) the location of your mother's milk, all else is learnt.
Very well done! I personally like this style of on-boarding versus the "tour" style where you have to click around a bunch of times to see everything. Again, nicely done!
I don't understand why there are some people who doesn't open source their work to help other people, but try to comment on goood things. Open source thing first, comment later, please. Thank you, good people.
I think it would be worth displaying each message one at a time with a delay in between (that way they could function as a sequential tour in addition to coach marks).
Yeah, I contributed some code to that repo and wrote the rails gem for it[0] and I'm a fan of it, this is just a different take that I found works better for some use cases.
Very impressive. It doesn't respond well to resizing the browser but maybe it is just a matter of playing with css "position" or something. Also, great name!
I see that too, and the open again behaviour is flaky in Chrome as well - the label switches to say "See More on Github" but the instructions still tell you that's the toggle button, and the link to "Open it again" (which actually toggles) is covered by the overlay but still active.
What is it with js libraries using data- tags without any kind of "namespacing". For example this library uses data-intro which could easily clash with other things in future.
Would it not be good for everyone to be a good citizen and instead do things like data-ch-intro? Just a few characters from your project name to reduce the chances of clashes.