Hacker News new | past | comments | ask | show | jobs | submit login
Intro.js – Step-by-step guide and feature introduction for your website (introjs.com)
258 points by afshinmeh on Feb 29, 2016 | hide | past | web | favorite | 50 comments

One problem I have with libs like this is you have to chase the "Ok" and "Next" buttons around. It would be much better IMO to have a fixed footer with the action buttons but have the lightbox w/description move around the page as it does now.

In addition, I would prefer not to have the entire rest of the UI blacked out. Lightboxes don't seem appropriate here since I want to see the "big picture" all the time and just have relevant sections highlighted. This would actually be a much simpler implementation, just fade the background of the div to highlighter-yellow.

This is why the new trend of dismissible pop-over 3-step intros is a wonderful thing, to be frank.

Honestly, there are many problems with an overlay follow-me Intro experience. It's good for certain things and in certain situations, but you should be open to using the best method of introduction for whatever you need people to learn. Sometimes the best way is just a paragraph of text, and there are several things in-between that are simple and highly effective.

To add to your critique, something with which many of us are likely familiar is the Slack intro experience. The intro dissolves into three (and only three) small, subtle bubbles that go hover over important parts of the UI. They're just light enough that you can completely ignore them if you like and get on with your work, but if you're confused they stand out. It's quite a nice compromise that makes this follow-the-UI intro really work.

It would be cool to phase the release of new features with small notifications and upping the amount of call-to UI elements as X time passes without user engagement. Can't work for every site but certainly sites with regular account holders.

Have you seen Desmos's tours? There's no Ok or Next buttons at all, it automatically detects when you've actually interacted with the feature that you're being taught: https://www.desmos.com/calculator?tour=sliders

(Disclaimer or whatever: I helped design and implement them.)

Oh wow!! This is so cool! Where was this tool when I was in high school ;)

Really nice website, This would be very helpful as a teaching aid.

To be fair, you can use the forward / backward arrow keys to navigate around the features, but it isn't clear upon first attempt. It also doesn't solve the issue on mobile, where arrow keys aren't available many times.

If you really want to be fair [1]

[1] https://en.wikipedia.org/wiki/Mystery_meat_navigation

Hey, thanks for the feedbacks. I will try to fix them in the next version. Cheers.

Another similar technology (with slightly less jumpy scroll, but I'm sure you could tease out some bugs if you tried):

Zurb Joyride - http://foundation.zurb.com/sites/docs/v/5.5.3/components/joy...

Last time I looked into building an introductory FTUX with intro.js, I found myself trying to make the choice between these two (intro.js and joyride)

Another good one for the road is HubSpot's Shepherd: http://github.hubspot.com/shepherd/docs/welcome/

Just had a really great experience creating walkthroughs with it.

Thanks. I just opened all the examples mentioned in the comments and this one feels the most elegant.

While this might feel like a great way to introduce people to features in an application, needing it is probably a sign that your UI isn't really working. In my experience learning a UI is a chore, and people hate trying to do it. If the interface is well organised, uncluttered, and laid out in a logic manner that doesn't hide things there's no need to have an intro.

What you're overlooking is the users who type website addresses into google, and compose entire emails in the "subject" field. Some people just require a little hand holding no matter how obvious the UI is to the power users.

Do you really think a 5 step animation is enough to overcome UI problems like navigational searching or a fundamental misunderstanding of how email works?

Those things are examples of the UI failures I'm talking about. Blaming the person using the app for doing something wrong is how "fixes" like putting in an "intro" happen. What we need is to design human-centred experiences that work the way we automatically think they should, not patching things up with instructions that'll be forgotten within 5 minutes.

This library puts the developer first (driven by thinking like "I told my users what's in the app so now they know what's there.") rather than putting the person using the app first (driven by thinking like "The users mustn't be afraid to experiment by clicking on stuff.").

> The users mustn't be afraid to experiment by clicking on stuff.

They shouldn't be, but they are. Nothing is "wrong" with non-technical users, but learning new software, especially complex software, is something they automatically believe they can't do, and so they are afraid to experiment by clicking on stuff.

I feel like Facebook's design is pretty intuitive, but I still have my mom asking how to do simple things that are hidden behind menus (for example, change privacy settings). Nothing's wrong with her, she's just afraid of breaking technology, and it's unlikely anything will change that fundamental belief. However, adding an intro could ease these types of users into the software, and perhaps even lead them to experiment a bit more.

This is a neat project but also replicates the functionality of many libraries (I'm not going to dig it up but there are more than a few of these floating around with varying amounts of maintenance). Anyone needing to use these seriously will quickly end up forking it. Also - I think the goal of EVERY UX designer should be to prevent the need of these kind of things AT ANY COST. It obviously varies by product and industry but any designer worth their salt will do everything they can to make it painfully obvious what a user should do at every step of the way.

There are complex system where something like this is inevitable, because it's complex by nature.

It's certainly a nice enough script for what it does, and I can see it being useful in some instances, but... a lot of this 'feature tour/tutorial' stuff strikes me as more of an excuse to not worry about ease of use. A good site design should be intuitive in of itself, not something that requires a guided tour to figure out.

It's a bit like the modern gaming world to be honest. In the old days, games like Super Mario Bros was designed to teach you through level design, so you'd figure out how things worked without getting a huge info box thrown in your face.

Like this:


On the other hand, games since got obsessed with tutorials detailing every minute thing about the title, leading to such over the top insanity as this 'help DVD' included with Super Mario Galaxy 2:


These tutorials on sites and in mobile apps remind me all too much of the latter. It's like 'we won't use our product to teach people in a natural way, so we'll put in a guide for complete dummies instead'.

Kudos, cool project. However, this behavior is extremely easy to abuse and often leads to a poor user experience. If you want to do something like this, present one tip at a time and specifically when they are most useful. Don't present an entire manual during the onboarding experience.

Further reading: https://www.nngroup.com/articles/mobile-instructional-overla...

While some of the effects are smooth, the scrolling is jumpy and unexpected.

To add to the list of similar/related tools, LinkedIn's Hopscoth: https://github.com/linkedin/hopscotch/blob/master/CONTRIBUTI...

Unfortunately this implementation isn't accessible and doesn't work with screen readers.

I hope websites would stop using "Raleway" for content text. I can't understand half of the letters because they're so thin.

It looks like he's using the Skeleton library and I think its font is set to Raleway by default.

http://bootstraptour.com/ is very similar to this.

Does anyone know of any good research backed studies as to whether these guides improve usability or not?

I use this library on couple of my projects, I love it.

Here's the HN discussion from the original post 3 years ago: https://news.ycombinator.com/item?id=5380056

I've used it too. It's nice and unobtrusive.

I like the idea behind this.. but its kind of jarring. Does anyone have a good wordpress plugin with similar functionality? I want to have an overlay that shows how I'm doing the data collection on my sites.

This is pretty nice! It seems to need some work on mobile though: http://i.imgur.com/6DcJOxu.png

It's a neat little project, but it's been around for 3 years.

I've seen a site completely made with reveal.js (and maybe pandoc).


How does this relate to introjs?

I'm definitely going to look into this to help with on-boarding for my web app. I wish this had existed weeks ago.

Feels misnamed, brought back thoughts of flash intros in 2002. Should be renamed to something like grandtour.js

Done this a year before they've done theirs – https://github.com/oskarkrawczyk/tour.js (never got traction unfortunately, probably because it's MooTools-based and 2012 was the year when everyone who used MooTools started dropping it in favor of jQ).

It is great! I love that it is small, and love the hints feature.

Cool! Yeah the hint feature was added recently.

Adding to the mix, we've also considered Onboard Tips (https://onboardtips.com) because it allows someone non-technical to create in-app tours.

I'd use this... except my interface is in React.

A similar library if you're using jQuery is http://trentrichardson.com/Impromptu/

The step 3 -> 4 is jarring on Chrome 48 OSX.

Extremely so. For one, it actually jumps the scroll position twice in a row when you click. Secondly, the scroll should be performed first, followed by the appearance of the dialog once the scroll is complete. Finally, it would be better to "scrollTo" the position rather than an immediate jump. This way the user has a sense of where the scroll went to relative to their starting position.

I don't believe this format works well with a scrolling page to begin with. It makes a lot more sense on full-screen apps, or on fixed navigation menus. If you really need to show a dialog further down the page, you're better off having the trigger for it be down there - not further up the page.

Most importantly, don't overuse it. Even the most complex situation should not need more than 2-3 of these. Beyond pointing out extremely critical elements to interact with, the page or app shouldn't be that difficult to navigate.

Hmm, I don't have this problem. Are you talking about the introjs.com demo page?


onboardx.com is a similar tool with no coding implementation and segmented guides

While intro.js has some faults, this one is even worse. It doesn't even feel like it tries to fit into the webpage.

Yeah I know the issues with the Introjs but I will release a new version this month, trying to address all existing problems. Cheers.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact