Proposal: Last.fm UI Changes

[Trever Fischer]

On Monday 08 December 2008 08:01:16 am you wrote:
> Hey Guys,
>
> I was going to wait until 2.0 was officially released to send this
> out, but since Trever has expressed interest in improving the lastfm
> service I thought I'd shoot it over to him.
>
> This is a proposal for some major lastfm ui refactoring:
> http://amarok.kde.org/wiki/Proposals/Last_FM_UI_Redesign:2.0
> Also I've attached a gimped mockup of the proposal.
>
> In short here are the changes I want to make:
>
> * Remove the Love/Ban/Skip buttons
>     They already exist in the tool bar, and are pretty useless in that
>     window.
> * Move the "Play Artist Radio" field to the top, above the tree.
>     The field is at the bottom of the panel, far out of reach of the cursor
>     and the eye. Ever since we moved the toolbar to the top of the ui,
>     we have been more top centric. This will also increase the visual
>     similarity of the last.fm service with all our other services: there is 
>     usually a query/filter field in that position.
My attached reworked patch does that. However, I think it looks worse with the 
search at the top and the play field sorta just hanging out there, looking all 
awkward like. I thought up a second suggestion, and that would be to eliminate 
the whole bit and use the search field. When someone searches for something, 
the service uses last.fm's search API to pull up some tag, artist, album, and 
user entries, while at the same time adding 3 braindead entries to it before 
the search finishes, each with a different url. The first would be 
lastfm://artist/%s, the second would be the tag url, and the third would be 
the username.
> * Make the "Play Artist Radio" field also support arbitrary tags and users
>     This is a major last.fm feature we're missing out on.
> * Re-organize the tree (see mockup)
>     My proposed version provides cohesiveness between all the
> different elements.
>     For every user mentioned in the tree, it is possible to play their
> 3 stations that
>     exist.
Organizing the tree like that makes more sense. I can see why the current tree 
is laid out like it is now though, with 'personal radio', 'neighbor's loved', 
etc being seen as genres.
>
> I didn't mention the "Global Tags" parent item, but I think it can stay.
>
> Thoughts, comments? Make sure and use "Reply All" when replying to this
> email.
FWIW, I've been subscribed to the amarok list for quite some time :)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: tag-radio.diff
Type: text/x-patch
Size: 3778 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/amarok/attachments/20081208/1737cdf9/attachment.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/amarok/attachments/20081208/1737cdf9/attachment.sig>