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

List:       kde-usability
Subject:    Re: [another PATCH]: Kicker find as you type
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2005-05-05 21:32:02
Message-ID: 200505051532.04637.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Thursday 05 May 2005 02:55, Thomas Zander wrote:
> On Wednesday 04 May 2005 17:43, Aaron J. Seigo wrote:
> > > I like the idea behind that but placing such widget inside of K-Menu is
> > > weird.
> >
> > why? besides the fact that we haven't done it before =)
>
> * The 'select through typing' that we have currently is very nice, but I
> doubt will work with a search box.

of course it will. the search box wouldn't have keyboard focus until selected.

> * The KMenu is not a dialog, its a menu and there are all sorts of modality
> and focus issues that will come up if you try to put too much of an

seeing as i've actually done this before and dealt with the modality and focus 
issues, i happen to know it's possible. and it's not even that hard =) you 
just have to handle the up arrow, down arrow, tab key, enter/return ... 

> 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.

> I'll just repeat that this thing should be done in the minicli.  Its like

i think that would be a fine idea ... as well.

> you saying we should improve the dir listing of konqueror since you might
> find things too hard to find.  Well, no; we create things like locate:/ or
> the find dialog.

both of which operate on the dir listing. i don't think this is a valid 
comparison.

it's more like the search line in kmail, juk and elsewhere.

> As you are very well aware; adding a new widget to the top-level choice has
> a negative effect of adding an extra choice that the user must understand
> to use the whole.

it would be self documenting with that greyed out "this is a search box" text. 
this is a brand new idea, it's one found all over kde.

> 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. 

have you tried the patch? (i haven't either, but having done similar things 
i'm able to imagine it a bit at least ;)

> This may not be immidiately obvious; so 
> I'll give a related example.  Consider we have the normal file menu with
> quit and close and all that.   Now we want to add close-all as a menu.
> When the user wants to close his document he has to chose between close and
> close-all forcing him to consider what both are in order to make an
> informed choice.  This is counter productive and in usability normally is
> called the negative effect of adding more top-level choices.

this isn't even remotely similar to what we're talking about. i too can up 
with things that would be bad additions to menus. we aren't talking about 
application menus, we aren't talking about new action entries.. this is a 
search line in the kmenu.

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.

the kmenu has scalability issues. how do we address that?

> So either remove the k-menu altogether (well, please don't :) or put the
> search thingy outside of the k-menu itself.

putting it outside of the kmenu makes it nigh useless because the place people 
need help is when using the kmenu.

and there is always: 3) replace the kmenu with something better

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