On 12/15/2010 1:31 PM, David Hall wrote:
> If the test for inclusion includes "can a user abuse the freedoms
> Rockbox grants to do stupid things?" shop might as well be packed up, IMHO.
I think though that this isn't quite the same. There's a difference
between allowing a user to explicitly do stupid things, and having an
automated system for doing stupid things. Basically, what I'm arguing
for is that "once playback has started, playback position should
progress linearly forward without skipping unless the user presses
There's a difference (to me) between resuming playback when you start a
playlist, and then progressing through it from that point on, and
attempting to resume every entry in a playlist. Many audiobooks are
broken into multiple chapters, and spare resume points left sitting
around could impede a listening attempt.
I just think that we're basically creating a situation in which playback
attempts to control itself rather than waiting on user input to help the
least common use case, rather than the most common use case. I may be
wrong,but I'm just really having a hard time believing the most common
case for a queue of long files is *incomplete* podcasts rather than
podcasts a user hasn't listened to yet, or chapters of sequential audio
of some sort.
As far as I can tell, the only harm from dropping most of the
configurability is this one use case, which to me is an edge case, while
doing so could (from my perspective) significantly improve the ease of
use and decrease the likelihood of Rockbox performing somewhat
unexpected behaviour. It would also remove the requirement of
identifying which files should be resumed by filters or genre or
location. Attempt to resume when starting playback, but not when
playback automatically moves between files.
I admit it's less flexible, but I feel it's not *much* less flexible. If
someone wants to resume one podcast, then resume the next, they just
have to play one and when it stops, play the next.
Another option might be to offer a "queue and resume" option in the
insert menu, so that people can explicitly mark additional songs in a
playlist to be resumed (presumably you wouldn't want to insert and resume).
I just feel the feature can be in some ways drastically simplified both
in terms of options offered (and needing understanding of) and
unexpected behaviour without reducing its usefulness significantly to
the majority of Rockbox users, and want to move discussion in the
direction of "what do we want our goals for this feature to be - what
use cases are we trying to address?"
Received on 2010-12-15