About Amarok's interface design

Dan Meltzer parallelgrapefruit at gmail.com
Wed Nov 19 15:37:50 CET 2008


On Wed, Nov 19, 2008 at 2:13 AM, Big O <illogical1 at gmail.com> wrote:
> On Wed, Nov 19, 2008 at 12:08 AM, Dan Meltzer
> <parallelgrapefruit at gmail.com> wrote:
>> On Tue, Nov 18, 2008 at 11:51 PM, Casey Link <unnamedrambler at gmail.com> wrote:
>>> On Tue, Nov 18, 2008 at 11:26 PM, Big O <illogical1 at gmail.com> wrote:
>>>>>> The seekbar could also be shorter and in the same line as the volume
>>>>>> bar as you said, as vertical space is becoming very precious on
>>>>>> today's widescreen displays.
>>>> I concur!
>>> Of this list, this is what I most strongly agree with. +1
>>
>> As this seems to be getting lots of support.. it looks like it's time
>> to shoot it down.
> I was thinking "shoot it down." meant you'd take care of it. Then I
> got to the end of your mail :-(
>
>>
>> One of the major reasons behind the top bar being designed the way it
>> was is due to the progress slider.  The small progress bar (amarok 1.4
>> style) is not big enough to allow for accurate seeking.  The large one
>> does allow for this.
> So if folks want more accurate seeking they can just increase the width right?
> What bothers me most about the volume on top and the seekbar below is
> that it just looks off.
> See http://illogic-al.org/images/screenshots/interface_niggles.png
>
> That and the gaping "holes" in the window when nothing is being played
> make it somewhat unpleasant to stare at.
> See http://illogic-al.org/images/screenshots/lets_laugh_at_the_retarded_kid.png
>
> I was going to use words but I decided to test out the new Pixelmator
> update instead. Here's a mockup of the window wasting less space.
> See http://illogic-al.org/images/screenshots/at_least_we_used_up_the_space.png

I agree that it doesn't line up perfectly as is, and thats something
to look at (it should balance itself out better once we have the
analyzers back, at least in theory... but that mockup would be a
horrible regression.

There is no visual connection between those tab buttons and what they
control, this would confuse the hell out of users.  Compressing things
because it makes it better is one thing.. compressing things just for
the sake of taking up less space is not.
>
> The idea is that the sidetabs are hidden (is it possible to hide just
> the tabs) and whenever a button up top is clicked, that section shows
> up in the sidebar.
> I suppose if it's possible to hide the tab widget and the sidebar
> separately we could just hook the buttons up top to a signal which
> causes the switch on the side. The buttons would need work of course.
> Yes, yes, if it's possible then something to do post 2.0 and all that jazz.
>>
>> As it stands it's not as utilized as it is going to be in the future.
>> I still have plans of bookmarking support post 2.0 (and bookmarks on a
>> small seekbar would... suck).  Throwing it randomly in line with the
>> volume (but stretching the full remaining width of the screen) Would
>> not really solve much, as the control icons would still require the
>> same amount of vertical space.  I don't think it would be wise to
>> shrink these icons down to a one line height, as they are important
>> and should be large enough to click easily.
>>
>> I think it makes more sense to keep it where it is, as there is no
>> benefit to moving it elsewhere/shrinking it down.
>>> _______________________________________________
>>> Amarok-devel mailing list
>>> Amarok-devel at kde.org
>>> https://mail.kde.org/mailman/listinfo/amarok-devel
>>>
>> _______________________________________________
>> Amarok-devel mailing list
>> Amarok-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/amarok-devel
>>
>
>
>
> --
> All your gmail are belong to us.
> _______________________________________________
> Amarok-devel mailing list
> Amarok-devel at kde.org
> https://mail.kde.org/mailman/listinfo/amarok-devel
>


More information about the Amarok-devel mailing list