Re: [Muine] Groups revisited



On Sun, 2004-04-11 at 10:23 +0100, Lee Willis wrote:

> On Sat, 2004-04-10 at 17:13 +0200, Jorn Baayen wrote:
> 
> > Hi,
> > 
> > I've been working a bit on creating a concrete groups and random
> > playback proposal. The proposal can be found here: http://huizen.dds.nl/
> > ~jbaayen/proposal.html.
> > 
> > Comments greatly appreciated.
> 
> Sorry, evolution sent the last mail before I finished :(  Full text
> below!
> 
> OK - from the bottom :)
> 
> Playlist filling
> ----------------
> The way I'd evisioned this working was as follows:
> 
> Addition of an "Autoplay" button on the main playlist window.
> 
> This would pop-open a list of defined "Autoplay groups". This would
> have:
>    (a) A list of previously defined groups (We can ship with some nice
> defaults)
>    (b) a method to tick one or more of these pre-defined groups
>    (c) The ability to create a new group
> 
> Creating a new group would allow you to define criteria (Think of the
> filter-creation type tool that you'd use for email) that the group would
> select. Since the explicit filter control may get a bit complicated I
> think we probably need a "wizard" approach to make it nice and simple.
> This would allow, as examples:
> 
> - Music by Radiohead
> - Music from 1980-1989
> - Rock, or Prog-rock music
> - Rock music from 1990-1999 by Radiohead
> 
> We should also allow criteria such as "newness" (Not played yet?),
> popularness (Hardly ever played, sometimes played, often played), and
> some form of ratings system so I could define such groups as:
> 
> - New dance music
> - Often played trance music
> 
> Your mock-ups don't indicate that sort of level of control (You seem to
> have limited it to genres??).

This is almost what I had in mind:

We allow the user to create groups of music, in two different ways:
- Manual grouping, the user manually groups albums and songs together
  (Also see the new infodialog proposal)
- "Automatic" groups, providing a set of critera, for example:
  1980 < Song.Year < 1989 && Song.Genre == "Rock"
  We could indeed use a wizard or whatever, something easy anyway to
  create these groups.

I only included genres in my mockup because I didn't feel like spending
hours in the gimp adding in all possible examples. :)

Because creating and managing groups is something that would probably
only happen in a few spurts of music management, I think including group
editing functionality in the "group playback"/"playlist filling" dialog
would only bloat that interface. Therefore the proposal containts two
different dialogs; one for purely editing, and one for purely selecting
groups to playback from. I think the latter needs easier access from the
main interface though..

> 
> Once you play a group we need to look at the main UI a little in terms
> of:
> 
> - How we title the playlist (Could get complicated to assemble a nice
> string automatically from multiple criteria, I think we should just
> allow a user to "name" their group, and use that

Yea, we'll have the user name their groups of course- otherwise they
won't have a way to select groups either.

> - The playlist length remaining could either be blank, or the time until
> all music matching the criteria have been played

We won't need to include playlist length, because the program will keep
playing forever: it can play the same song twice.

> - Do we randomize everything at the start, and just fill the playlist,
> or do we just show say, the next five items, and keep filling as time
> goes on?

I'd say keep filling- this allows us to use "smart random"; i.e. playing
popular songs more. If we could only add each song once, that wouldn't
be possible ..

> - What happens if some has selected an auto-play group, then a few songs
> in, clicks "Add-album", and clicks "Queue"? Do we queue it to start when
> the whole selection has expired, or just when the "x" items that are
> shown in the playlist have finished?

I'd say just put it at the end of the playlist like always- so that is,
after the 5 automatically queued songs. And when there are only 4 songs
of the album remaining, automatic takes over again.

> OK - now that that's explained - how does it fit with the rest of your
> proposal. Well, the play album, and play songs dialog would remain as
> you proposed it, although the group restriction is now more powerful
> since we have finer control over the critera. I don't really udnerstand
> the "Group Editor" dialog, what is the user actually doing at this
> point? Over-riding the criteria you set for the group by explicitly
> adding/removing items? That sounds complicated. The group editor in my
> view would take you back to the criteria "wizard" in edit mode so that
> you can change the criteria.

The group editor dialog is shown editing a "manual" group in the mockup.
For "automatic" groups, this would basically just show the contents- the
"add/remove" buttons would be disabled. In the case of genre groups
though, clicking add/remove would be enabled, allowing the user to add/
remove songs from a certain genre. The "automatic" functionality would
be hidden in the menus, since this is not something a regular user would
touch anyway- we'll include a couple of automatic groups by default, for
the genres, and something like "never played/new songs".

> 
> How does all of this address the use cases?
> 
>     1.  The user wants to play random songs
> The user would hit "Auto-play", tick the "All music" pre-defined group,
> and hit play.

Yeap.

> 
>      2. The user wants to play random albums
> The user would hit "Auto-play", tick the "All music" pre-defined group,
> and hit play. Is this different from (1)? Do people actually
> differentiate between songs from albums, and songs not from albums?

Yea, it's different from (1) in the sense that this would choose an
album to play, isntead of a song: meaning, when one song is finished,
going to the next song of the album, and when done, choosing a new
album. I personally think this is very useful: tracks are played in the
order they are intented to be played. But (1) is useful too, when I just
want to hear anything.

> 
>      3. The user wants to play random songs of a certain kind
> The user would hit "Auto-play", tick one, or more of the groups and hit
> play. If a group didn't exist then he'd click on "New group", select the
> criteria, input a group title, and click "Add". The group would appear
> in the group-list, ticked, and he'd hit "Play".

Yea, except that groups will need to be created only once, and that I
therefore think editing functionality would bloat the purely "play"
dialog. Also, clicking "play" in the autoplay dialog wont be as easy,
since there needs to be a "toggle" somewhere- otherwise the user wont be
able to escape from autoplay mode.

> 
>      4. The user wants to play random albums of a certain kind
> Same as 3. See comments on (2)
> 
>      5. The user wants to see all single songs, recently added songs,
>         never played songs, most popular songs, etc
> Hmm - not really covered by my comments, although maybe an extra button
> in the auto-play dialog that was "View music", that just displayed the
> music matched by the critera?

This would work like this:
Opening "Play album/song", and then selecting "New songs" or whatever
from the groups dropdown.

> 
>      6. The user wants to browse music by genre
> Not covered, but see comments on (5)

See (5) :)

> 
>      7. The user wants to randomize the current playlist
> We need to add a random item just below shuffle to the main menu, not
> covered explicitly by my comments, but sort of covered since "auto-play"
> would add the tracks randomly when it is used to add music.

Yea. This is mentioned in the very bottom of the proposal..

>      8. The user wants to be able to manually categorise their music
> Not sure I actually understand this?. Perhaps we should auto-generate an
> auto-play group for every genre that the user's collection contains?
> Would that cover it?

For example, I'd like to group all my music from Estonia together .. 


Thanks,

Jorn




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]