Re: [Muine] Groups revisited
- From: Jorn Baayen <jbaayen gnome org>
- To: Lee Willis <lee leewillis co uk>
- Cc: muine-list gnome org
- Subject: Re: [Muine] Groups revisited
- Date: Sun, 11 Apr 2004 14:49:22 +0200
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]