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

List:       kde-usability
Subject:    Re: powerful tooltips,	behaviour dependent and clearer toolbars
From:       solo turn <soloturn99 () yahoo ! com>
Date:       2003-11-15 11:22:23
[Download RAW message or body]

> Date: Fri, 14 Nov 2003 06:00:53 -0800 (PST)
> From: cintyram <cintyram@yahoo.com>
> B>]. for that matter if tool bars also become a two click affair, they
> might as well become part of menus, ie. simply add an icon to each menu
> entry along with its text, that way, some place can be saved on the
> tool bar;
no, you have the "default" (one click), and the other options on clicking the error or clicking
longer. btw, i would like it with menus too (click selects the default, longer or arrow opens it).
it also would be consistent with object left click (selects default), and object right click
(opens context menu).

> C>]. From a useability perspective, there are different stages of use
> of any application, tooltips and the like are useful only in the
> initial stages, as we get used to an application we find ourselves
if you use tooltips for more, this is not true any more. this area is easily reachable, and its a
sin to use it only for explaining text. and it is easy configurable (switch off, on, timouts).

the rest of your points i fully agree (microsoft fullscreen does not forbid task-bar. you cannot
see it, but it comes up if you go down with mouse). and this distinguishes full-screen from kiosk
mode.

> Date: Fri, 14 Nov 2003 09:12:04 -0700
> From: "Aaron J. Seigo" <aseigo@kde.org>
> 
> > it wuold be great if there would be a possibility to go to the 
> tooltip with
> > the keyboard and also leave it again via keyboard (esc, timeout, ?)
> 
> i don't know if we really have (m)any global keyboard combox left. then 
> there's the issue of giving focus via the keyboard to a toolbar items 
> w/out 
> selecting it, which would probably be tricky enough to be not so useful 
> and 
> probably rather dreadful as far as speed and clarity of action.

it should be just a matter of reaching the toolbar, than arrow left,
arrow right should do the job.

> > 2. display buttons, menu entries depending on users behaviour
> > ----------
> > microsoft uses this strategy to simplify menus. menus have to modes:
> > "standard" and "extended/full". clicking on a menu opens the standard menu
> > with a minimal set of entries, and an arrow icon. staying with the mouse on
> > the arrow, or clicking the arrow opens the full menu. choosing a menu entry
> > includes it in the standard display the next time. not choosing it for a
> > long time removes it again from the standard display.
> 
> this is one of the worst possible ideas. it hides options, makes 
> getting to 
> them longer, prevents learning from taking place due to spacial, 
> textual and 
> contextual interface changes, etc...

if you do not like it, just switch it off. this thing does NOT prevent
thinking about icons, texts or menu entries. you need that in any case.

> 
> > 4. do not distinguish between menu bar, and tool bar
> >     ...
> menus and toolbars are not the same. they do not work
> the same, they duplicate actions, 
 
this is true. this is not about contents of the two, but operation,
i.e. widgets. they can contain the same things, and there is no obvious
reason for not float a menu bar, or not use arrow keys in tool bars.
or not place menu and tool bar side by side. or not display a tool-bar
with texts instead of icons (like netscape offers it for years).




__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
http://antispam.yahoo.com/whatsnewfree
_______________________________________________
kde-usability mailing list
kde-usability@mail.kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]