unity-design team mailing list archive

["frederik.nnaji@xxxxxxxxx" <frederik.nnaji@xxxxxxxxx>]

On Wed, Nov 3, 2010 at 16:59, Alex Launi <alex.launi@xxxxxxxxxxxxx> wrote:

>  On Wed, 2010-11-03 at 10:15 +0000, Matthew Paul Thomas wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> cmaglothin wrote on 20/10/10 04:43:
> >
> > Why not try this:
> >
> > 1. Instead of having the obscure "copy track data" feature, why not
> > simplify the buttons in indicator-sound to something
> > like http://imgur.com/ueC7X.jpg
>
> Because that's a visual scope error: clicking a button would change
> things both above it (track data) *and* to the left of it (album art).
>
>
> I'm not sure I agree with this reasoning. The buttons there are clearly
> nestled into the warm embrace of the album art and the track metadata. If
> the controls were not clearly associated with both then this could be a
> reasonable argument, but the three are all very tightly coupled visually.
>
>
The Sound Menu as i understand it was made to enable also other music
players to place themselves inside of it. Totem is the default player for
single .mp3 files on every Ubuntu installation i have made so far,
ironically it never appears in the Sound Menu.

To experience the Sound Menu the way it was intended fully, i'm sure it is
critical to have the possiblity to control the DE's default audio file
player first. It doesn't make much sense to have all these pretty controls
in the Sound Menu only if i'm prepared to take the payload of a heavy music
database management application like Rhythmbox.

I think if we use a lean player to test the usability of playback controls
in the Sound Menu, for example Totem, which is system default already, we
run a good chance that we soon will notice how best to usefully display
track metadata.

Just like in the talk about People Metadata, here we should not pull the
metadata from the management application, but rather let the DE handle it.
Rhythmbox may be a management interface to our music library, but it is not
per se the library itself, that's all i'm trying to say. The metadata is
Application independent and should be treated that way. It should also be
represented that way imo.

Representing the metadata per track in a more generic way means to me that
if there is no track data being represented, we should consider using that
space for some other information, too. I suggest indicating playback
position in that field, using saturation. The information (album art, title
and artist) can be overlayed with a progress bar, that's how
Epiphany-browser displays loading progress for example. Is there anything
wrong with overlaying an object's thumb with a progress bar for playback
position?