[Amarok] Moved playlist layouts selection menu back to the

[Seb Ruiz]

2009/8/12 Téo Mrnjavac <teo at getamarok.com>:
> On Wed, Aug 12, 2009 at 1:27 PM, Seb Ruiz<ruiz at kde.org> wrote:
>> 2009/8/12 Téo Mrnjavac <teo at getamarok.com>:
>>> On Wed, Aug 12, 2009 at 1:08 PM, Seb Ruiz<ruiz at kde.org> wrote:
>>>> 2009/8/13 Teo Mrnjavac <teo at getamarok.com>:
>>>>> commit 0297885a911708618986f9f4746f711b00a3cc03
>>>>> Author:     Teo Mrnjavac <teo at getamarok.com>
>>>>> AuthorDate: Tue Aug 11 10:57:42 2009 +0200
>>>>> Commit:     Teo Mrnjavac <teo at getamarok.com>
>>>>> CommitDate: Wed Aug 12 12:42:56 2009 +0200
>>>>>
>>>>>    Moved playlist layouts selection menu back to the playlist toolbar.
>>>>
>>>> Why did you do this? We discussed this at length to move it _out_ of
>>>> the toolbar. This is not a feature which can be justified to be in the
>>>> toolbar (as it's not going to be used often enough for enough people).
>>>> Leaving it in the menu bar makes it still accessible without polluting
>>>> the UI.
>>>>
>>>> I call for revert please.
>>>>
>>> We discussed it again yesterday and found that in the playlist menu
>>> it's just too hidden.
>>
>> Just for clarity, can I ask who you spoke about it with please? I'm
>> interested to know who holds these opinions.
>>
> I discussed it with Nikolaj. He agreed that it was a bit too hidden in
> the main menu and we decided to move it back for the time being, at
> least until we can make it accessible through bookmarks.

I'm going to give a dose of Australian frankness here. Let me say that
I think both of you are great programmers and are very creative,
coming up with features that I wouldn't have thought of. This is a
credit to both of you and your partnership during gsoc. There is
absolutely no offence or insult intended here, but both yourself and
Nikolaj don't really have the best track record it comes to usability
and user interfaces. I know this may sound conceited and rude
(especially because I'm no expert), but please stick to your strengths
and keep working on truly kick ass application features.

Going on this - how can you really justify playlist configurations as
a "bookmark"? Bookmarks are locations to data, and shouldn't be
treated as anything else. Please don't justify to yourselves that
configurations which show different information in the playlist are a
type of bookmark - that they just aren't! There is inherent value in
keeping distinct features different and not trying to meld them into
one "monolith feature" where everything starts to get lost in itself.
If you want to improve the discoverability of this feature, then you
certainly shouldn't bury it inside another.

>
>>> Eventually it might return there when we get
>>> sort+layout+grouping bookmarks but until then hiding playlist layouts
>>> hurts the usability of the playlist.
>>
>> No, it does not hurt the usability of the playlist. This is a
>> configuration option, not a method of interacting with the playlist
>> during general usage. Furthermore, an entry in a menu bar is not
>> hiding the option. It is very easy to find.
>>
> I see choosing the layout as an interaction more than a configuration
> option, while modifying layouts is definitely a configuration option.
> And the menu bar isn't hiding it to make it hard to find as much as
> making it long and tedious to hit.

Okay, clearly we're at different ends of the spectrum here. I can
think of one good way to solve this problem to make everyone happy.
Let's make the toolbar configurable like it used to be, and then we
can have this action in the toolbar when the user wants it there.
Sound like a compromise?

>
>> The same way that you couldn't say that moving the collection
>> configuration to a button in the browser would improve usability.
>>
> Collection configuration wouldn't, but if we had collection layouts
> I'd like to have them in a button in the browser.

The closest to this is the collection sort - but this certainly makes sense.

>
>>
>>> I realize that this solution
>>> isn't ideal because it doesn't please everyone, but for now I call for
>>> keeping it as it is at least for a while until bookmarks land in
>>> trunk.
>>
>> What gives you the authority to make this call?
> I haven't made a call and I don't think that I have the authority to
> make a final call for everyone, I don't understand what could give you
> that impression-
> I just committed to trunk something that was discussed with my GSoC
> mentor and can still be changed over 9000 times before a 2.2 freeze.

Unless you can give a good justification as to why it should be
changed, then we shouldn't be engaging in push/pull commit/revert
tactics here - it's not constructive for anyone.

>
>> I don't have a problem
>> with this if the majority is of this mindset, but I find it
>> disconcerting that frequently UI components are moved over the place a
>> few weeks after a discussion has lapsed, as if nobody is going to
>> notice (or when they do, saying "just for a while").
>>
>> I also don't see what playlist layouts have to do with bookmarks
>> (explanation appreciated).
>>
> The plan is to create bookmarks that represent a playlist state and
> combine a sorting scheme with a layout and a grouping category.

It's certainly an interesting idea - and I can't wait to see it.
Consider not embedding them deep within bookmarks and make a parallel
"playlist state" bookmark type ui.


-- 
Seb Ruiz

http://www.sebruiz.net/
http://amarok.kde.org/