Foldable toolbar - questionable usability

[Lee Olson]

Attached is a mockup of an idea that I came up with to simplify the playlist
toolbar. The user would click the "Manage Playlist" button, which would
provide a menu of playlist functions. The user would scroll through the
functions using the mouse or arrow keys. Comments, suggestions?

- Lee

On Mon, Jun 29, 2009 at 8:13 AM, Leo Franchi <lfranchi at kde.org> wrote:

>
> On Jun 29, 2009, at 6:23 AM, Nikolaj Hald Nielsen wrote:
>
> > I went over it again and tested a bit around and I am even less
> > convinced about the real usability of your addition today.
> >
> > Which is fair, I am still trying to make up my own mind as well! :-)
> >
> > 1. It adds unnecessary complexion to the existing Amarok. Especially
> > with the "symmetry" you added, we find ourselves with arrows that do
> > precisely nothing on the left and which are not intuitive on the right
> > neither.
> >
> > Yes. That was the very last thing I added. Again just to try stuff
> > out.
> >
> > 2. It is just plain ugly, sorry to be that blunt, but those green
> > arrows have always been ugly, wherever they were.
> >
> > Sorry, but I am not even going to argue against this. The green
> > arrows was just the only icons I could find at the time ( had no
> > Internet access when I created this stuff ) that sort of illustrated
> > the point. I have no special love of these and would happily replace
> > them with something else, perhaps something similar to the "more"
> > icon used in the bracrumb...
> >
>
> If the issue here is the design of the arrows themselves, it might
> make some sense to talk to nuno or lee about designing different ones?
> Rather than just tossing out the whole feature due to some arrow design.
>
> > 3. Adding those arrows everywhere for the sake of symmetry means also
> > we will have to add a function to all the existing arrows, and this
> > adds again more unnecessary complexity and we will have to invent new
> > items to add, just because there are folding arrows? Come on, this
> > makes absolutely no sense.
> >
> > No, the idea was that an arrow could be disabled (but still visible)
> > when there was no items. But when browsing through the categories
> > this would allow items to be there or not without changing the
> > layout and hence the symmetry. At least that was the though I wanted
> > to try out.
> >
> > I strongly vote against these folding arrows and suggest to remove
> > those everywhere, including the context view. I am sure we can find an
> > alternative way to add applets
> >
> > In the context view? Oh, the scrolling list has them... I am not
> > taking responsibility for those! :-P
>
> It is very easy to rail against something that no one has
>
> a) made any comments to me about
> b) had any ideas for improvements
> c) provided any sort of alternative artwork
>
> (note that we have used those arrows since January, and there has been
> little to no feedback about them).
>
> >
> > I am quite disappointed, Amarok started to look nice and now it begins
> > to suck again, complexity everywhere just because we listen to every
> > fart the users come up with, and no, I am not sorry about the wording.
> > Already the playlist options are too many, and the realisation doesn't
> > fit in the general aspect, as we have now non less than 5 different
> > menus, dropdown selectors, option choosers and tool boxes for the
> > playlist alone!
> >
> > Sorry, I think you are on a wrong path here, please, make it easier,
> > not more complex. I think we need an extensive discussion about the
> > playlist in Gran Canaria before you even add more stuff, consensus
> > first!
> >
> > Ok, now we are getting to the meat of the issue.
> >
> > We are currently miles away from any kind of a release and this is
> > exactly the time to try out new stuff. I have no issue discussing
> > and even removing any of this stuff is that is the consensus, but I
> > don't want to do this discussions in a vacuum, without having an
> > actual prototype to play with, hence I committed it. I hate trying
> > to figure out what will work and what will not as a pure though
> > experiment, hence I always prototype stuff and accept the bruises if
> > people tell me that it's pure crap. (contrary to legend, I am not
> > always right... :-)
> >
> > In the course of developing 2.0.0 we tried out a lot of stuff that
> > never made it into the final 2.0.0, but we learned a lot about what
> > worked and what did not in the process. This is the only sane way to
> > do development of something as complex as amarok in my oppinion.
> > Come feature freeze we should have decided what works and what does
> > not and the experimentation should be over. As you yourself say,
> > your oppinion changes as you play with it, something that would not
> > happen if we just discussed it as a theoretical change on a
> > blackboard.
>
> I totally agree with Nikolaj here. It is impossible to achieve
> consensus on a "new feature" via mailing-list or IRC before beginning
> to code. Putting aside the fact that maybe about 50% (if even) of
> interested parties actually respond to any given email, consensus
> requires much time AND a willingness to hunt down people for a
> response (i have unfortunately done way too much of this in the last 8
> months).
>
> Playing around with Amarok in svn, given that we have many months
> before release, is an effective way of sharing an idea and soliciting
> comments. As we have just seen, it immediately starts a conversation
> when people feel strongly about it---and that to me seems to be
> exactly the point.
>
> Our upcoming meeting in GC is a perfect way to leap forward in terms
> of future plans/layouts/etc, like in Berlin, but I strongly disagree
> with putting off changes until we have a chance to talk them over all
> together. Way less would get done, and it would simply be demotivating
> imho.
>
> cheers,
> leo
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/amarok-devel/attachments/20090630/57d5b293/attachment-0001.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: playlist1-mockup.png
Type: image/png
Size: 222766 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/amarok-devel/attachments/20090630/57d5b293/attachment-0001.png