This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 178124 - [firstboot] playing a sound is "too hard" during firstboot
[firstboot] playing a sound is "too hard" during firstboot
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: system-config-soundcard (Show other bugs)
5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Martin Stransky
:
: 113793 (view as bug list)
Depends On:
Blocks: FC5Target
  Show dependency treegraph
 
Reported: 2006-01-17 16:25 EST by Christopher Aillon
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-21 09:37:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
new look (51.04 KB, image/png)
2006-01-26 08:35 EST, Martin Stransky
no flags Details
test play widget (10.88 KB, image/png)
2006-01-26 15:44 EST, Bryan W Clark
no flags Details
system-config-soundcard with helixplayer'ish controls (18.94 KB, image/jpeg)
2006-02-14 16:34 EST, Rowan Kerr
no flags Details

  None (edit)
Description Christopher Aillon 2006-01-17 16:25:11 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
Comment 1 Martin Stransky 2006-01-18 08:08:44 EST
> 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

Good idea.
Comment 2 Christopher Aillon 2006-01-18 13:35:27 EST
(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.
Comment 3 Wade Mealing 2006-01-24 02:02:12 EST
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.

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.

2) Troubleshooting.

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.


Comment 4 Christopher Aillon 2006-01-24 02:36:27 EST
(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 ;-)
Comment 5 Martin Stransky 2006-01-26 08:35:44 EST
Created attachment 123713 [details]
new look

Okay, there is my proposal...
Comment 6 Bryan W Clark 2006-01-26 15:38:39 EST
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...
Comment 7 Bryan W Clark 2006-01-26 15:44:48 EST
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.
Comment 8 Martin Stransky 2006-01-27 05:08:44 EST
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...
Comment 9 Bryan W Clark 2006-01-27 16:38:01 EST
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.
Comment 10 Martin Stransky 2006-01-30 08:04:19 EST
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?
Comment 11 Wade Mealing 2006-02-04 23:04:42 EST
Martin, 

I would assume the speaker icons are part of rhythmbox.

Comment 12 Martin Stransky 2006-02-07 07:56:45 EST
The new version is in CVS/devel.
Comment 13 Rowan Kerr 2006-02-14 16:34:09 EST
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.
Comment 14 Martin Stransky 2006-02-21 03:28:25 EST
*** Bug 113793 has been marked as a duplicate of this bug. ***
Comment 15 Martin Stransky 2006-03-21 09:37:05 EST
Fixed in FC5/rawhide. Please reopen if you have any other comments/suggestions...

Note You need to log in before you can comment on or make changes to this bug.