Red Hat Bugzilla – Bug 178124
[firstboot] playing a sound is "too hard" during firstboot
Last modified: 2007-11-30 17:11:21 EST
Some cleanup items for the dialog:
- We should use the standard Play/Pause buttons instead of "Play test sound".
- The sound should play by default, and loop.
- Additionally, there should be a volume control in the dialog
> We should use the standard Play/Pause buttons instead of "Play test sound".
I'm not comfortable with it.
> The sound should play by default, and loop.
s-c-s can be run as a configuration utility too so I think it isn't so good idea
to play sound immediately after start. Loop could be enabled by some check-box.
> Additionally, there should be a volume control in the dialog
(In reply to comment #1)
> > We should use the standard Play/Pause buttons instead of "Play test sound".
> I'm not comfortable with it.
What are your concerns with it? Anyone that uses the dialog will have to read
the text that says "Play test sound" and process it first. The buttons are
immediately recognizable to anyone without really reading it. Additionally, it
will no longer need to be translated. Since we are playing sounds, it makes
sense to have these controls.
> > The sound should play by default, and loop.
> s-c-s can be run as a configuration utility too so I think it isn't so good idea
> to play sound immediately after start. Loop could be enabled by some check-box.
If users are going to s-c-s, they either are in firstboot and want to make sure
their sound card works fine, or they have a booted system and no sound, so they
want to make sure its working. In both cases, they are going to "play test
sound" first thing. Why make the user click it at all? There could be a small
population of users that doesn't want to do this, but we should not target them.
Right now, a very common use case of this dialog by the desktop user is to
configure systems by clicking the test button, they don't hear anything. They
check the cable to see if they plugged it in the wrong hole in the back of their
soundcard. They click the test button again. They repeat until they hear
sound. We want to make this easier for them. If we keep playing it for them
without them having to do anything, they will be able to know what fixed the
sound for them, and leave it alone. It's very frustrating to do this now.
Chiming in on the usability point of view.
I think it comes down to expected behavior. When I visit a web page, nothing
irks me more than having the web page kick up someones midi file in the
background. It isnt my taste in music, this relates how to s-c-s ?
At a guess, I'd say most users would use this application in two possible ways.
This information is for both s-c-s and firstboot.
A user investigating what things "do", just by clicking around. The user will
see the button "Play test sound" or "play", and expect there to be sound when it
plays, forcing the sound apon them is rude and annoying.
When the user finds out that their ogg player isnt working, this would be the
first place they turn to. In this area I would expect a volume control, a "test
and loop" option while i mess around with the plugs at the back".
It would be nice to have a soft melody loop in the background while messing with
the sound, so that it doesnt startle the user when they have the volume turned
up and they finally get the speakers in the right plug at the rear of the machine.
(In reply to comment #3)
> Chiming in on the usability point of view.
(these suggestions came from bryan clark, our desktop interaction designer with
usability in mind -- i'm just the sap that gets to file them).
> At a guess, I'd say most users would use this application in two possible ways.
> This information is for both s-c-s and firstboot.
> 1) Accidentally.
> A user investigating what things "do", just by clicking around. The user will
> see the button "Play test sound" or "play", and expect there to be sound when it
> plays, forcing the sound apon them is rude and annoying.
There are lots of accidental things the user can do which will play sounds.
This isn't really one of them. They have to go to the System > Administration
menu and click on the thing that says "Soundcard detection". Additionally,
there is a nasty dialog that appears asking users to enter their root password
in order to get to the dialog. That will deter people who don't know what they
are doing. If you get to the s-c-s dialog, you are either: in firstboot, your
soundcard is broken, or you are doing dev/QA work on s-c-s ;-)
Created attachment 123713 [details]
Okay, there is my proposal...
What I was suggesting was using a 'media widget' similar to those that we give
people in our desktop applications. That way there is a famliarity to it and
our positioning is more about showing off than the 'Press this button to see if
sounds explodes' angle we have going.
Playing our music when you first get to the page is another nice thing to do
which makes the interface much less about testing than it is about playing and
checking your sound. Assuming we use some actual music instead of lame test
sounds it won't be so bad.
And the hardwares volume should have been set to a safe low value already so we
won't blow things up. I'll attach something to describe it a little more...
Created attachment 123744 [details]
test play widget
Here's the quick hack of a mockup
The links don't have to be there since we probably don't allow web browsing at
this point. However we can still show the artist and other album information.
I left in a next and previous button because it would be nice to have a few
songs that play, maybe 3. The repeat check box is there, but could be left off
by default. When your sound isn't working you can hit that to have it
continuously play while you fiddle with things.
For songs it seems like we should be able to grab a couple from the CC music
database that we think are nice. Assuming we have a nice song that starts off
a little softly and then gets a little louder the auto-play when you get to the
page won't be a problem. It should be a nice thing to get to this page and
hear some cool music.
I'm sure some of the marketing people have songs we could use or could help us
find songs that would be appropriate.
I'm not against ogg files or some music but I think s-c-s was originally
intended as a simple utility for test sound. In this case I'd have to add some
ogg player, other dependency/files and so on...
Ok great. My main interest is making sure test sounds works just like they will
on the desktop which is why I think if we make it look and act the same as the
desktop does. And even by using the same code paths we'll have better luck
getting peoples sound working the first time.
Where can I get any icons like these small speakers around the volume control
slider? Do you have any idea who is the right person for the music question?
I would assume the speaker icons are part of rhythmbox.
The new version is in CVS/devel.
Created attachment 124642 [details]
system-config-soundcard with helixplayer'ish controls
New version looks like the mockup I did a couple weeks ago (but never got
around to posting) :)
I was going to suggest using the same interface that is in HelixPlayer as users
would possibly be familiar with that layout... and the new version I see now is
pretty close to the HelixPlayer interface.
*** Bug 113793 has been marked as a duplicate of this bug. ***
Fixed in FC5/rawhide. Please reopen if you have any other comments/suggestions...