From: Karl Kurbjun <kkurbjun_at_gmail.com>
Date: Mon, 12 Jan 2009 22:34:49 -0700

On Mon, Jan 12, 2009 at 2:14 PM, Dominik Riebeling <
dominik.riebeling_at_gmail.com> wrote:

> On Mon, Jan 12, 2009 at 7:58 PM, Karl Kurbjun <kkurbjun_at_gmail.com> wrote:
> > The the ability to configure the fade in/fade out delays to the detail
> that
> > the PWM code has on the supported targets is not possible on every device
> > due to hardware implementation limitations. The Gigabeat F/X is an
> example
>
> we already have lots of differences between targets depending on their
> hardware capabilities.



> > Removing some of the configurabilty would be a benefit in terms of cross
> > device option consistency while keeping the penalty to performance low.
>
> but why is there a need to remove options from targets that can
> support them without penalties? This feels somewhat like removing
> headphone detection from devices that support it just to not have
> additional options on those players compared to others. I really can't
> see a benefit in removing those options.
>

I do not have a strong feeling that the options /should/ be removed, but in
order to be fair with the discussion I think we should stick to analogies
that apply.

Removing a feature completely versus removing/changing functionality are two
different things in my mind. Removing the feature for headphone detection
is single and isolated. Yes, not all devices support it, but on the devices
that do the options and functionality are equivalent in my understanding.
This makes the user experience consistent for the supported feature,
headphone detection, across all devices that are capable.

This feature and discussion, backlight fading, on the other hand is not
about completely removing a feature. It is about making the functionality
and options consistent for a feature. If a user sees that the device
supports backlight fading, they might assume that the use will be the same
regardless of which player they choose which is not true in this case.
Generally I would not consider this feature core to Rockbox's appeal or
device decision when purchasing, but I think it comes down to:

Is the added functionality really necessary and would most, if not all,
users even notice if there was not an option to change the backlight fade
settings.

I would venture a guess that most users would not notice in any way at the
loss of fine tuning the fade and for the few that look to enable/disable
fading they would have an option to do so that is consistent. I have not
heard so much as a mumble from users, developers purposefully excluded ;),
on the configuration options (or lack of) for the Gigabeat backlight
fading. I might have missed that though.

Again, I do not have a strong feeling that it should be removed mainly
because I personally am unlikely to do the work and it does not have much of
an effect on my personal use. I do feel that there is a case worth
considering though based on the user experience and, from what I remember
when I was working on it, the mess of the backlight fading code between the
different devices.

As an idea it would be interesting if we had web statistics on number of
page views from the FS#'s in the bug tracker. I am not aware of a bug filed
on the backlight fading functionality of the Gigabeat, but it could
potentially give some interesting statistics on what users care about, or
issues that they run into commonly when discussions like this (add/remove
configurability) come up.


> - Dominik
>
> (oh, and a reminder: please don't top-post to this list. Thanks)
>

Thanks for the reminder.

-Karl
Received on 2009-01-13