Rockbox Development > Feature Ideas

Binary Skip Part 2

(1/1)

seani:
A while ago (last November I'm horrified to realise) I floated the idea of  Binary Skip Mode, partly on the basis that it might have some use for users navigating through large files where there is little feedback from the progress bar.


I tried a patch ( FS#10766 ) with a few revisions and AlexW was kind enough to act as a guinea pig for that and a few other test enhancements aimed at blind users.

There have been some questions on the mailing list so I thought I'd update here with and answer a few of those at the same time.


The patch is aimed primarily at allowing blind users to navigate with relative ease to a specific point in a file. In the version Alex has been testing, this also involves announcing the current track position when it has changed in this way.



1) As it stands, as per the original discussion, when this option is set, navigating within 5 seconds performs a binary skip in the chosen direction; the original post or flyspray spells out the mechanics. As suggested on the mailing list, this is to allow time for the announcement to take place and still decide if you need to sklp again.


2) After 5 seconds the current binary skip times out and a new one can be started.


3) Enabling it replaces "skip track" -  but this is no different from enabling the other fixed skip-length options


4) That said, in the current version, if binary skip is enabled and you skip twice within one second, a skip-track is performed. One second seems a bit slow to me, perhaps 0.5 or less makes more sense.


5) The behaviour doesn't affect the long-press fast forward and reverse behaviour.


6) It think 6 somewhat addresses the concerns about waiting for the timeout to mature to begin a new skip, if  you accidentally overshoot. I think other options to solve this would overcomplicate matters.



I can't really say, ultimately, if it's useful or not; my use cases are pretty specific which was why I asked if Alex would give some feedback.



My intention would be:


1) Fix the potential bug pointed out with the patch on flyspray

2) Add a persistent setting to allow the track position to be optionally voiced.

3) Tune the double-click behaviour down to 0.5 second.

Llorean:
#5 doesn't seem like it'd help at all on long files. If I have an 18 hour audiobook, and I skip forward 9 hours, then accidentally forward another 4.5, the fact that I now need to rewind 13.5 hours of audiobook is probably going to take about as long as the 5 second timeout.

seani:

--- Quote from: Llorean on August 13, 2010, 11:25:02 AM ---#5 doesn't seem like it'd help at all on long files. If I have an 18 hour audiobook, and I skip forward 9 hours, then accidentally forward another 4.5, the fact that I now need to rewind 13.5 hours of audiobook is probably going to take about as long as the 5 second timeout.

--- End quote ---

Well, that's why I say "somewhat". It all depends on what "long" is in a given circumstance.

If you're aiming for a particular *known* spot, you're right, if you get your second skip incorrect in a 9 hour file, you're faced with a five second wait to correct it. But remember you also get 5 seconds at a time to make the "right" decision.

I worked through a few scenarios (in practice and theory) and there are of course some pathological cases where you're worse off if you have a bit of finger trouble.


In practice, I haven't personally found it an issue. I think it needs to be physically tried out to get a feel for it.

What I did find is that if I missed the mark in this way, I doubt If I could even quantify the effect in lost time, but the level of irritation at getting it wrong was a bit disproportionate :-)

Llorean:
So what's the problem with having a pause/unpause make the release immediate instead of 5 seconds (leaving the 5 second release also in place)?

What's the likelihood of someone skipping correctly, accidentally pausing and unpausing, and then being frustrated by the ability to continue with their binary search?

Or maybe make seeking immediately release, so that a new binary search can be started after a quick seek?


I guess what I don't understand is that you haven't really given any reason why allowing the user to force a "release" through some means is bad.

seani:

--- Quote from: Llorean on August 13, 2010, 12:00:53 PM ---So what's the problem with having a pause/unpause make the release immediate instead of 5 seconds (leaving the 5 second release also in place)?

What's the likelihood of someone skipping correctly, accidentally pausing and unpausing, and then being frustrated by the ability to continue with their binary search?

Or maybe make seeking immediately release, so that a new binary search can be started after a quick seek?


I guess what I don't understand is that you haven't really given any reason why allowing the user to force a "release" through some means is bad.

--- End quote ---


I'm not saying it's "bad", just stating my opinion that, having used it for a while, that problem doesn't crop up enough to warrant the complication.


That said, I'd say that if you seek, you're implicitly indicating an intention not to continue binary skipping anyway, so resetting whenever that happens in either direction seems like a win.

Navigation

[0] Message Index