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

List:       kde-usability
Subject:    Re: Kicker find as you type
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2005-05-06 16:48:40
Message-ID: 200505061048.41597.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Thursday 05 May 2005 04:35, Thomas Zander wrote:
> On Thursday 05 May 2005 23:32, Aaron J. Seigo wrote:
> > On Thursday 05 May 2005 02:55, Thomas Zander wrote:
> > > As another poster said; you are mixing concepts which will give
> > > inconsistencies however hard you try.
> >
> > yes, and i'm asking what those inconsistencies are.
>
> Clicking outside the kmenu will totally remove all your text and
> selections. For one thing.

you've just described how menus work. i don't see the problem here. it's not 
like what is in that text box need to be saved for later use, for instance.

> But I already mentioned that in my previous post 
> :) If I press 'ALT' the normal behavior is _very_ different from the kmenu
> one (the kmenu disappears totally)

i don't see the need to use the ALT key, nor do i see how this would relate to 
having a text box in the kmenu.

> The KMenu does not visually take focus away from other applications (they
> still have the 'active' kwin decoration) but you still have focus in the
> kmenu.  -> confusing.

the kmenu not jumping up and down and saying "i've got focus!" is has been the 
current situation for years now. adding a textbox doesn't alter this "weak 
focus" model one bit. if you think that this is a problem, then it's a probem 
that has existed for years and yet nobody has ever found it troublesome to 
use.

probably because when someone uses the kmenu they don't expect it to behave 
exactly like a menu in an application window and their focus is 100% in that 
menu and so any theoretical inconsistency is completely unnoticed and 
therefore unimportant.

> Thats 3, Need I go on?

yes please go on, because none of them are thus far meaningful.

> You can say that those are not important, and I think you will :)  But then
> what is the usage of all these gui-concepts we have been sweating over to
> get consistent???

the kmenu is a unique element on the desktop that is already rather different 
than other menus in various ways, ranging from editability to DnD. 

i suppose what i'm really uncomfortable with in this discussion about why a 
line edit is bad is that it's talking about possible problems that just don't 
seem to map to the kmenu very well at all.

i'm not really sure that your average user will find the search box useful. 
that's my personal concern here. all talk of "focus issues" seems to be 
highly missing the point: will users find this useful or will they ignore it, 
avoid it, and perhaps even get bothered by it?

> > > And having to learn an extra concept to use the k-menu
> > > is just making it harder to use.
> >
> > something that allows people to find things ... makes it hard to use.
> > hrm.
>
> Making people grok the search-in-a-menu concept next to the normal usage of
> the kmenu makes it harder to use on the whole.  Due to a steeper learning
> curve.  As I explained in my last mail.

here are the three possibilities i see:

a) the user sees the box, doesn't understand what it's for, ignores it.
b) the user sees the box, tries it out, understands what it's doing.
c) the user sees the box, tries it out, doesn't understand what it's doing.
d) the user sees the box, doesn't understand what it's there for and freezes 
not sure what to do

(a) and (b) are not particularly worrisome (though (a) would denote that the 
concept is weak). (c) would be a Bad Thing and would make the feature not 
useful. (d) would be the worst thing possible, but seems highly unrealistic. 
people tend to ignore what they don't understand.

which will most users do when confronted with a kmenu with this box in it? 
will they use it to find things, and will finding items in the kmenu be 
faster or less frustrating for the user with or without the search box?

that is what matters to me. not theoretically measuring the learning curve. 
i'm sorry if i don't have much of a stomach for "guestimation" usability, but 
i've watched that lead to numerous bad decisions. if it's a factual item 
(e.g. "the human mind can deal with 7 plus minus two things at once") then 
fine; if it's a matter of "above a certain limit, things are bad" then it's 
useful to measure where we are against that limit. merely stating there is a 
limit is not good enough.

> > i understand the whole "OMFG this is a MENU! this is a MENU! don't put
> > anything in it but MENU ITEMS!" thinking, but i also think it may be
> > useful to step out of that box for a bit.
>
> Well; in all my years doing usability in KDE and in companies and all that
> I learned that consistency rules;  stepping out of the box is great, just
> keep yourself in check please :)

yes, consistency is king. there are also exceptions to this guideline. the up 
arrow in konqueror versus the up arrow in the file dialog is one example.

the first thing we need to do is identify what the kmenu is. comparing it to 
menus that appear in an application window, for instance, is daft.

> In short; I don't want to address the kmenu scalability inside the kmenu. I
> feel it has to be done outside it.  Not because I really really want to;
> but because I have not found a good way of doing it. (please don't hesitate
> to surprise me!)

i'd like to see the "in menu" method at least tested on users before we throw 
it out as a possibility. i am sceptical that people will travel very far to 
launch applications. if an "in menu" search doesn't work, then the kmenu will 
probably have to be radically redesigned or thrown away altogether (in the 
default setup).

in which case making the "launch applications" UI look more like a real 
application may be the way to go. i imagine it will still be available in 
some form from the panel, however.

i wonder how MacOS X users find using the Finder for application launching?

-- 
Aaron J. Seigo
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

[Attachment #5 (application/pgp-signature)]

_______________________________________________
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]