[Kaffeine-user] Re: A first cut of a new full screen interface for Kaffeine.

[John M. <jw...@es...>]

On Thu, 27 May 2004 00:45, Mikolaj Machowski wrote:
>  Dnia =B6roda, 26 maja 2004 04:08, John Morton napisa=B3:

>  But it will trigger only where menu/taskbar is.=20

That's good. That's where you'll be. And if the most frequently used button=
 is=20
on the corner of the toolbar, that's the corner people will usually aim for=
=2E=20

>  Users will move pointer  to the side. Also triggering by corner isn't ve=
ry
>  intuitive.

It's not unfortunately, though kicker uses it, which means KDE desktop user=
s=20
will understand that it exists as a target. But it's ok, as it's not the on=
ly=20
means to pop up the controls, as you can use the left mouse button, enter, =
or=20
some other action key, which is the first thing they're likely to try. But =
if=20
they bother to read the tool tips (and I think I can say everything that=20
needs to be said about basic full screen interface usage in one tool tip),=
=20
then they'll know that the corners work, too, and that kicker won't pop up =
if=20
they go there.

>  Most hidden =20
>  controls in desktops are turned on by moving to the side.

But this is not the desktop, it's full screen mode in a media player,=20
therefore users want to look at the whole screen and not look at the pointe=
r,=20
or have it cluttered with controls - hence they'll tend to flick the pointe=
r=20
to the edge. If the controls appear on the edge most likely to contain blac=
k=20
bands, then there's nowhere to go but leave the pointer in the middle of th=
e=20
picture - especially if the controls don't time out and disappear if the=20
pointer is over them!

>  Teleporting is also done when Alt-Tabbing through windows. This is not
>  so uncommon. With good feedback indicating cursor was moved it shouldn't
>  be problem.

Perhaps, but a moot point if we have right mouse do pause. Then there's no=
=20
rush to move the pointer about.=20

>  > It's probably a good idea to have the controls appear when the pause
>  > hotkey is clicked, too.
>
>  Depends on hotkey.

Right mouse button, space or some second action button, in this case. Popin=
g=20
up controls for pause is good, because your next action is probably to togg=
le=20
some setting or move about in the stream, or you're off doing something awa=
y=20
from the screen and don't care. I wouldn't pop up the controls for most oth=
er=20
actions - especially not mouse wheel controled volume :-)

>  > But do usabililty testing for the default :-)
>
>  Behaviour should default to other elements of desktop. Kicker is IMO the
>  best to follow: Keep visible when pointer is on it, hide after timeout,
>  when not.

Possibly, but full screen isn't the desktop. On the desktop, it's ok to lea=
ve=20
kicker up indefinitely when the pointer is over it because it's the natural=
=20
thing to do to move the pointer to somewhere else when you've finished usin=
g=20
it, and at that point you're off doing something else in some other=20
application. In a full screen mode, there's nowhere else you want to move t=
he=20
pointer to except away from the controls and out of the way of the picture.=
=20

Now, whether we go for 'controls are always up when the pointer is over the=
m',=20
or 'controls disappear after a long timer, when the pointer is stationary=20
over them' in part depends on whether we go for 'edge of screen pixels pop =
up=20
the controls'.=20

 If we go for both of your preferences, the consequences are that the user=
=20
must move the pointer away from the controls to make them disappear, but th=
ey=20
can't move it to the remaining edge, as that will cause it to pop up again,=
=20
so they're stuck with moving to the middle to have it hover over the pictur=
e=20
like a fly on the screen for three or four seconds. And the moment the mous=
e=20
registers enough movement to move the pointer by a single pixel, up it=20
appears again. We could make the edges that don't have controls adjacent to=
=20
them not activate the popup, but they will tend to be the edges with pictur=
e,=20
as the controls will tend to be on the edges with black bands.=20

Conversely, the only reason not to have a long timeout on the controls is t=
hat=20
the user manages to hover the pointer, dead stationary, over the controls f=
or=20
longer than the timeout when they still wanted to do something. If we can=20
find a timeout period long enough that 95% of the users never experience=20
that, because they've managed to get on with it and do their thing in time=
=20
without feeling any presure to keep moving, it's going to be a win.=20

>  > >  Not sure here. Maybe treat last element as ten elements. If cursor
>  > >  key
>  > >  will be pressed down for some time it will jump to first/last
>  > > element?
>  >
>  > Possibly, but I expect that holding the opposite key down will get you
>  > back just as fast, but without the unexpected behaviour of  holding the
>  > key down a bit too long suddenly sending you to the other side.
>
>  After few times it will be known. OTOH I knew some completely
>  untrainable users :/. OK, maybe without wrap is good solution.

Ha! That's exactly what I've just said about corner targets :-)

In this case, we're talking about five to ten items on the tool bar, and le=
ss=20
on the menu bar, so having a 10 step 'punch through' to the other side woul=
d=20
actually be a bit slower than just holding down the other key, but it would=
=20
surprise someone who wasn't expecting it, and that would cause them to slow=
=20
down their button navigation, which is not something we want to discourage.=
=20

But the same effect on a playlist, or some other listing that can have tens=
 to=20
hundreds of entries - that would be a win.

John