Rockbox mail archiveSubject: Re: Buttons in Hold Mode
Re: Buttons in Hold Mode
From: Paul Louden <paulthenerd_at_gmail.com>
Date: Thu, 22 Oct 2009 03:49:01 -0500
Rob Purchase wrote:
> - Allows in-pocket use on players with limited physical buttons
Using the grid-based screen I was able to use my D2 in my pocket rather
effectively. I wouldn't say "allows" so much as "enhances" or perhaps
"provides an alternate means of."
> - Allows Rockbox to further its goal of being a full firmware
> replacement, by implementing one of the OF's most useful features
This is just a controls issue though. There's been a lot of control
layouts from OFs that aren't duplicated, so I don't see this as
particularly relevant beyond a nodding mention. It's relatively minor.
> - Keeps users happy (there is real demand for this, evidenced by the 3
> separate FS tasks that implement it!)
There is real demand for a lot of things, but the things should be
weighed on their actual merits, not simply "a lot of users want it." If
it's good, it should go in. If it's not, it shouldn't.
Really, it's a relatively minor improvement. I'm not saying it shouldn't
go in, but your advantages really aren't any less minor than the
disadvantages you've listed.
> - Potential for unintended button presses (not an issue on the D2, as
> stated above)
Still an issue on the D2 - while it doesn't happen to you, that doesn't
mean they can't or won't happen.
> - People may start to expect it on other targets (but is this a problem?)
Yes, because several targets have hardware hold switches.
> - I've heard "Support" mentioned as a reason not to implement this,
> but what exactly is the issue? It can be documented like everything
> else, and can be hidden behind an "enable track skipping in hold mode"
> setting, disabled by default if necessary.
Support and more options cruft. How much does this option *really* help?
Is there a way to solve this problem in the existing UI without creating
a new option and making users choose between the ability to hold and the
ability to adjust volume easily? Let's look for alternatives first.
> So, what I want to establish if there are any other objections, or
> whether the above minor disadvantges are enough to keep a useful
> feature out of Rockbox (and if so, why?).
This is a somewhat misleading sentence - in the way you phrase things
here you're attempting to establish that other objections are necessary.
Every feature that improves usability is "useful" but you've not made
any attempt to establish how useful this feature is, just "I use it, and
some people want it."
Let's have a real discussion of why it's necessary or important, rather
than trying to say "the objections against it are trivial, so it should
go in." Even if there weren't objections, it should be justifiable.
Received on 2009-10-22