OZtree
OZtree copied to clipboard
OneZoom
Behaviour of the back button in tours is not as expected - it doesn't always go back
It was previously noted that
the front page tour does not permit the back button to be pressed - I think probably because the moment it's pressed in advances to the waiting state so pressing back again just resets the timer rather than going back to the previous 'main' tour stop. It also seems to be hard to press the "forward" button when the tour is paused (it should just skip to the next stop)
This refers to the tour back button rather than the browser back button (making it pretty much a duplicate of #207), yes?
Having a poke around, one clear bug is you can't go back past African apes. I'm guessing this is because it's the start and can't wrap around to the end.
But generally interacting with the prev/next buttons isn't very satisfying. It's easy to hit the back button as the flight to the next stop is about to start, especially as there's a delay between the tour advancing to the next stop and the flight starting. As a result seemingly nothing happens. The next button triggering a flight rather than going straight to a node makes the interface feel very laggy, since the flight takes a while to start it looks like it's not responding.
Getting this right really isn't easy. Personally I'd be very tempted to just ditch the prev/next buttons at least for now. They don't add enough to the experience versus the amount of heartache they will cause.
I think more feedback is needed, and one way of achieving this would be for the prev/next buttons to slide the old view to the left/right to reveal the new location. You could do this roughly by:
- Overlay an image of the current canvas
- Wipe treeview canvas, move to new location. Point being that if rendering is slow for whatever reason, you see nothing (which will be a clear change from the previous state) vs. seeing the old location (which makes it look unresponsive).
- Slide overlay image away to reveal new treeview
Hooking this into mobile swipes would be an obvious neat thing to do too.
You still have the "CD player problem" of deciding when the user wanted to go back to the start of the flight, and when they wanted to go to the previous stop, but there's less demand (IMO) to get this right since at least something will be obviously happening.
Hi @lentinj: yes, this is the "tour back" button. It would be nice to solve "properly" rather than overlaying views, not for the front page, but for tours in general. For example, have a play with the "tutorial" by going to life_MDmouse.html and clicking on the "How to use" button on the toolbar. You can see the general purpose we might use these sorts of "tours" for. Anything to improve the general navigation around the tours would be a huge advance for us, but it may be too much of a rabbit-hole for you! Incremental improvements welcome, however.
We have a rough sketch of the way that we are hoping the tour stops work, here:
but it might take a bit of explaining! The idea is basically to be able to define a number of tourstops and then to be able to chain them together in an arbitrary order, and for the visiting of places to make sense.
I wasn't suggesting the above as a homepage-specific solution. The way to do it would probably to add the transition into the tree viewer, so you can jump-to, fly-to or slide-to (the above) a location. The tours code can then use that when a skip button is pressed, for more obvious feedback that you're skipping. A simpler option would be clear-and-jump-to, less swish but would achieve similar. All this said, this isn't a problem in the same way on the "How to use" tour, as the various overlaid slides are obviously different, unlike the home page. And either way isn't a quick thing to solve, so file my waffle somewhere and forget about it for now.
The "loop backwards from start to end" bug is possibly a smaller thing to fix though, and may be worth looking at.
The "loop backwards from start to end" bug is possibly a smaller thing to fix though, and may be worth looking at.
I'll look at that.
I've noticed that this is actually fixed by incorporating a non zero wait time on each stop. I suspect the reason is that when you go back to the beginning of a transition you have a moment to press back again and go to the previous stop before the transition restarts. Whilst it could be considered a bug, provided that we write the tours in the right way we won't have the problem. I'd advise that all tours have a 1s wait on stops and this problem will go
I've relabelled for tours project as the change of tour JSON on the front page means this issue doesn't occur any more.
I've noticed that this is actually fixed by incorporating a non zero wait time on each stop.
Yes, that's working around the "CD player problem" in my comment. Given a second delay, you now have an initial period where back goes further back than it would do during the flight. The other solution would be to pretend the flight hasn't started for the first second, but adding a delay seems a lot neater and easier.
I guess the only other thing to consider is whether we should enforce at least a 1s delay? I don't think we should though, since if there's a reason in the future for having no delay, it'll be tricky to then remove this enforcement without breaking lots of tours.
We can't rely on wait = back to previous, as videos will need more subtle behaviour.
A video will (generally) be playing in a wait state, and it's progress basically tied to the wait state. i.e. first 3 seconds of video goes back to previous tourstop, after that it reverses to start of video.
The above case keeps working, since it's wait is shorter than 3s so is always for returning to previous tourstop.
I'm not sure what else is to be done in this issue, if anything. I think we should close it and open new more directed issues for back-button-bugs.