PDA

View Full Version : Squeezebox alarm



2004-02-25, 15:58
Sorry, didn't mean to sound abrupt. Just an observation really.

I guess it could be a feature request, but it's not a problem now that I
know it works like that.

Aynsley

kdf <slim-mail (AT) deane-freeman (DOT) com> wrote on 25.02.2004, 23:46:24:
> Quoting aynsley (AT) vicandaynsley (DOT) com:
>
> >
> > On a related note...
> >
> >
> > Why are there three different volume control scales? On the player
> > interface it goes from 0-40, on the Web Interface, it goes 0-11 (V. Cool
> > BTW), and when you set the alarm volume from the web interface, it goes
> > from 0-100!
> >
> >
> > Just something I noticed the other day when I nearly didn't wake up to
> > my new SB after setting the alarm volume in the web interface to 30
> > (thinking it was 30/40) when it should have been set to 75.
>
> so is this a bug report, a feature request...or just fuming?
> -kdf
>

kdf
2004-02-25, 16:14
Quoting aynsley (AT) vicandaynsley (DOT) com:

>
> Sorry, didn't mean to sound abrupt. Just an observation really.
>
> I guess it could be a feature request, but it's not a problem now that I
> know it works like that.
>
> Aynsley
>

ok :)
Web Interface: 11, is a joke. Spinal Tap reference, but still fairly obvious
what max and min is. Other skins show things linek 1-10 or a graphic scale.

Player Interface: Its a 40 character display, so makes sense to handle it as
0-40. Again, pretty clear what is max and min.

Alarm: Using the remote, is also 40, but web interface allows a value from
0-maxVolume (a server hardcoded value)

Server: in the background, the volume is always handled as 0-100, or in fact can
be negative for mute (stores the previous volume that way)

So, one problem is clearly that while the alarm input on the web interface is
the most direct correlation, its confusing because of all the other cases of
obfuscation.

Having fallen victim to this hole in user information, what would you think to
be the best way to have prevented that from happening:

1) Alarm setting in web interface, having a note saying max 100.

2) Alarm setting assuming all users understand 0-40 is range and process the
value accordingly. Bit of extra code needed, and still probably need a not to
say 0-40

3) Have the player report 0-100 (clearly sitll in 40 steps). This gets a little
odd as every step woudl be 2.5, or would step by 2 then 3 alternately.

Is there another way to do this that you would like to see?

cheers,
kdf

4)

Andrew W. Donoho
2004-02-25, 16:53
On Feb 25, 2004, at 17:14, kdf wrote:
> Having fallen victim to this hole in user information, what would you
> think to
> be the best way to have prevented that from happening:
>
> 1) Alarm setting in web interface, having a note saying max 100.
>
> 2) Alarm setting assuming all users understand 0-40 is range and
> process the
> value accordingly. Bit of extra code needed, and still probably need a
> not to
> say 0-40
>
> 3) Have the player report 0-100 (clearly sitll in 40 steps). This
> gets a little
> odd as every step woudl be 2.5, or would step by 2 then 3 alternately.
>
> Is there another way to do this that you would like to see?
>


Using the user interface principle of least surprise, would lead me to
ask you to standardize around 0 - 100 throughout the interface. 0 - 100
intuitively maps into 0 - 10 (11 ;-). The full progress bar maps
intuitively to 100 even though it is only 40 segments wide (only you
engineers are counting.) This is a consumer device (or at least you
want to sell it in consumer quantities). Therefore, simplify your
support load by having as few areas for multiple interpretation as
possible. Interface variance equals cost of support delivering little
real user value.

Andrew
____________________________________
Andrew W. Donoho
awd (AT) DDG (DOT) com, PGP Key ID: 0x81D0F250
+1 (512) 453-6652 (o), +1 (512) 750-7596 (m)