Show HN: Build a JS-only interactive product walk-through for your landing page
github.com
github.com
The knowledge gained by sitting through the demo (and more) could be had in less time by simply using the software. I prefer to learn by doing, not watching.
We iterate on onboarding constantly. There's a few concepts that users need to understand to get to grips with using Trevor. E.g. that queries are made up of steps.
I'd prefer to use my time clicking around the site than clicking to close tooltips and modals.
I think introductory tutorials are better served by:
1. Scrollable documentation w/ images and an easily navigable sidebar that allows you to jump to specific topics that draw your attention.
2. In the case of something truly complex I like to watch videos for a more holistic perspective. Note that this is the slow and "relaxing" way of getting information. I do this primarily at night and never if I plan on using a product that same day.
I'd probably recommend a video for conveying a workflow (is the fact that queries are made up of steps best categorized as a workflow?), but make it short and focused; and support it with text so that I can quickly decide whether that video is worth clicking or not. Most of what's in the video should be readable in text on the same page as the video.
Will run this by the team tomorrow.
I looked at the repo again in more detail; and I must admit that I got distracted by the comments and missed out on the intent behind your demo.
While I am not a fan of the interactive demo before you can start using an app, I think that what you've shared is: 1. not that and 2. looks excellent for presentations and landing pages.
My feedback still stands, but I was imagining a much different use case which may not align closely with your product.
Random thought: it may be cool to see this implemented in a "picture-in-picture" fashion on a documentation site where the documentation scrolls to the relevant area as you navigate the app in the pip window.
"confused about how to upload your portfolio? click here for an interactive demo"
There are free solutions too (e.g. http://bootstraptour.com/ )
(But, I would prefer text-based documentation. You can still have videos or animations too if wanted, though.)
I guess a video would do the trick though
This is an optional walk-through on the landing page, for those who prefer that over signing up and trying it themselves.
Not the op, but I didn't interpret the comment as being restricted to certain types.
I particularly dislike any walkthrough. An optional one still needs user-interaction to dismiss. Sometimes multiple interactions.
A few specifics:
- As a first-time visitor to a product, I have usually joined the product with an initial particular motivating intent. Walkthroughs can't typically know this intent (and optimising multiple walkthroughs for many intents would be a challenge), so you're just putting extra clicks in the way of me getting to the thing I joined for.
- If walkthrough experiences were genuinely of use, they'd be integrated as a permanent product feature. Examples of things like this are Instagram / Facebook / Twitter's "discover" features. These are slightly different as they're about discovering users, not features, but the general idea is the same: a user wants guidance.
If it's "click here to dismiss this walkthrough we just started", yes. If it's "click here to view a walkthrough", then... no? User interaction is required to start. That would be optional.
If you're thinking it's the "we auto started something and you can optionally stop it" then yeah, I agree, those are often annoying.
It's essentially the ux equivalent of an ad or newsletter popup.
Imagine that these exist _alongside_ step-by-step documentation reachable by specific searches "How do I download in CSV?".
How in the world am I supposed to know what does what without clicking on them? Even then I'd forget. They were pretty unique icons, too :/
Please don't do that. Tooltips save lives :)
I looked at your pricing and your free tier is enough for unlimited basic usage. I personally use Metabase for this, though you guys have a much nicer UI/UX in my opinion.
Also, one nitpick: The widget on the page showing off a dashboard usage is not an "interactive demo", it's a slideshow. I was really hoping there would be a sandboxed dashboard I could poke around in.
Hmmm... not sure what to do about that one
I can't see a "choose a workflow" section.
var steps = [
['/img/flow/click-users.png', [1, 280]],
['/img/flow/click-header.png', [765, 155]],
Where the array is x,y coords in pixels? Why would you not use percentages instead for the top and left offsets? I see your adjusted function is getting the correct offset for the screen aspect ratio, but wouldn't you get the same result on percentages?Then did the adjusted function when we decided we were actually going to use it, and it needed to work on mobile.
Subtly guiding the user is like slicing a watermelon with a katana, and this was more of a sledgehammer.
Any suggestions we could do instead, to draw their attention to the clickable circle?
I'm not particularly motion sensitive but agree that the animation was really jarring and threw off my focus every time it happened, which is probably the opposite of what's intended.
[EDIT] particularly, on revisiting it, I think the problem is that the animation doesn't flow from one point of focus to another, but effectively resets the user's eye every time it happens by coming in from "outside" of the screen. Fading out what's not currently important/interactive, or, if you must have an animation, making it move less-loudly from one point of focus to another would be an improvement. I think the former's both more elegant and more effective but either'd be better.
Couple thoughts:
- You should let the user know the goal of the demo before they start it, for example, "Let's build a query of Users by Country and Export it to Google Docs" and indicate their progress through the demo (eg, Step 1 of 5) with a caption of the action they are taking at the bottom of the screen that reinforces the previous bubble. Like:
- Step 1: Let's build a query of Users by Country
- Step 2: Here our Users by Country is shown as a bar graph. Let's change it to a Table View
- Step 3: We have 14 users in the UK. Let's check the underlying results
- Step 4: Let's export the results to Google Docs
- Step 5: Here's our result exported to Google Docs
- The flying/pulsing circle is fast and distracting - and it shouldn't move the label attached to itProgress (e.g. 2 of 5) would also be very satisfying for users.
Thanks for this suggestion.
Marketing wise this landing page[1] is not great either. It's assuming the visitor understands what a query builder is, how it works, what problems it solves, how is this query builder better than others, etc.
IMO the only useful part of it is the "A better way of getting answers" which still needs a lot more explaining about the product. Sure, great support and nice dashboards should be mentioned but as much smaller points after the core of the product and what it solves has been explained and made super obvious to the visitor.
Also this demo thing, regardless of how useful it is, should be way lower. Most users do not want to make the effort to start clicking stuff and much less see a black box that has no meaning at all.
If you have any examples of pages you particularly like to hand, I'd love to take a look.
In theory one could also put up a YouTube video of screenshots annotated on Photoshop, but this does seem more elegant.
I do like the idea of it being interactive though.
Feel free to fork if you need something similar for your site.
Is pure javascript (with jquery animations).
I'm sympathetic to jQuery users and I think it's a phenomenal artifact in the history of the early web but unless you need to accommodate IE9 I don't know why you'd want to use it for a widget like this.
It might be possible to port most stuff over to ES6 and use CSS animations; however, the code is concise and readable.
I've used jQuery recently because I had to target older browsers, but if you don't it's almost always cleaner and lighter weight to use modern J's.
I think the tradeoff is if you want to delegate everything (animations and DOM manipulation) to one language using a single library or split things up into two languages with no libraries. I prefer splitting things between JS and CSS, but I'm impressed with how clever, concise, and expressive using jQuery can be.
All the more surprising - I've been building frontend UIs from the late 90s, starting with plain JS, to prototype, to jQuery and onwards. I'm kinda amazed over how my perception of 'what is normal/acceptable in JS' has slowly but steadily changed over time.
The React library is usable "with" idiomatic plain javascript, rather than instead of (sure chained jQuery api calls are technically JS, but they're more akin to another language/convention within. Angular html directives are a whole nuther thing). The React library itself is small (~7kb to jQuery's ~30kb), and simple. So conceptually simple in fact that it lends itself to reimplementations like preact. The added weight of the somewhat over engineered react-dom renderer needed for browser rendering is regrettable, but still the modular approach is elegant in its simplicity and there's no reason you couldn't swap out the renderer.
What I'm getting at here is: I much prefer using plain vanilla JS as I did when I started in the early 00s, but even when it does makes sense to jump on the library bandwagon, it's possible to take a critical approach and avoid unnecessary extra complexity. jQuery has never been that. At any point.
* Important to clarify I'm referring to the React library, not React's ecosystem
I'm somewhat wary of React because I feel like it pushes developers to work with non-standard tools rather than the HTML + CSS + JS that browsers handle just fine.
I agree wholeheartedly on the ecosystem. I think global state stores will have a reckoning in the next 10 years where we collectively realize that maintaining a large amount of client-side state is not required for 90% of sites.
That said, Typescript got me (maybe a little too) comfortable with having a preprocessor: I still use JSX-less React but in Typescript I've actually started using React-less JSX...
CSS-in-JS is silly. I put that idea into the same bucket as a lot of other nonsense in the React ecosystem. Don't.
I tried out React a while ago, didn't like the idea of JSX, then saw the complexity of the React ecosystem, and then decided "nope, too much complexity."
I ended up using Vue, although from that I'm seeing, Vue is going down the "let's add complexity" route with Vue 3.
I'll look at React again and reassess in this new light.