Home of the Squeezebox™ & Transporter® network music players.
Results 1 to 3 of 3
  1. #1
    Guest

    Squeezebox alarm

    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
    >

  2. #2
    NOT a Slim Devices Employee kdf's Avatar
    Join Date
    Apr 2005
    Posts
    9,493

    Squeezebox alarm

    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)

  3. #3
    Andrew W. Donoho
    Guest

    Squeezebox alarm

    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)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •