[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: New panel layout
From:       David Laban <alsuren () gmail ! com>
Date:       2005-08-29 21:15:15
Message-ID: 200508292215.15807.alsuren () gmail ! com
[Download RAW message or body]

On Monday 29 August 2005 20:01, Uno Engborg wrote:
> Huh!?  A long thin button, at the edge of the screen is much easier to
> hit than a short
> one (like in the current situation). It doesn't matter much how many
> pixels wide it is as you can't overshoot
> a button at the screen edge.

Sorry, I wasn't being clear. If you have a "hide" button running along the 
edge of the screen, Fitts' law doesn't work for the *rest* of the bar, and 
the motive that started off the thread was using Fitts' law for the task bar 
etc. 

For the record, I don't think the "screen edges" element of Fitts' law is 
really all that important, as I'm used to being accurate with the mouse. 
Also, I would pay attention to the variables "A" (distance from start to 
target centre) and "a" (a regression coefficient possibly dependant on 
thinking time) in "MT = a + b log(A/W)" [1] if we want to create a usable 
desktop environment

[1] taken from < http://ei.cs.vt.edu/~cs5724/g1/glance.html >

"A" is reduced by placing things close together (well implemented in the quick 
launcher applet in the monolithic panel, which (on my system) is placed at 
the bottom of the screen (next to the K menu) so that all new programs are 
launched from an area that's 200x50 pixels(assuming your mouse instinctively 
flicks to the bottom left before you're even done thinking what you want to 
open, that gives you a maximum "A" of 207 pixels))

"a" is reduced by:
o     using pictures instead of text, so you don't have to waste time reading 
(implemented well in the kasbar, (even if it is ugly as hell) and the apple 
task bar (that includes screenshots of all windows)) 
o     placing things in a consistant place (which is possible with virtual 
desktops on Linux, but very hard to do with windows on the task bar, as there 
are often a random number of them open)(this is also an advantage of the OSX 
style "file" menu at the top of the screen)

Sorry for going off into a monologue, but people seem to be using "fitts' law" 
as a buzz word to sell their idea, and I feel that pushing everything to the 
screen edges "because of Fitts' law" is a BAD philosophy. Especially if we're 
not looking at alternatives first.
>
> >>it would not be covered by other panels. The hide button could remain as
> >>it is except for the direction of the arrow.
> >>This problem with hidden hide buttons should probably be fixed
> >>regardless if we chose to change the default
> >>panel layout.
> >>
> >>    
> >
> >I can't reproduce that bug using the kicker from subversion, so I think
> > it's probably safe to assume that it's fixed. Whoever is responsible for
> > kicker is doing a great job this release. It's pretty impressive
> >  
>
> Where does your unhide button for a hidden  side panel show up?

ah.... I didn't try hiding the panel, because I'd removed the hide buttons, 
but if the panel *is* showing, an external task bar will hide quite nicely to 
a little arrow, no matter where it is (imagine the edge of the panel becomes 
the new edge of the screen, and that's how it behaves)
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability

[prev in list] [next in list] [prev in thread] [next in thread]