Kicker find as you type
ellen.reitmayr at relevantive.de
Mon May 9 09:29:30 BST 2005
-----BEGIN PGP SIGNED MESSAGE-----
Just as Jan (see mail below), I like the idea of search for the kmenu,
and i think it's a very important feature. Me personally, I also like
the idea of a quick search within the kmenu - possibly in addition to a
more detailed search window (see Jan's mail). But these are opinions only...
In an important interface element like the KMenu, major changes like
that should not be implemented based on opinions. As far as I'm
concerened, there are no usability studies on similar topics, that means
1) decision bases are missing
2) we need to do the user testing ourselves.
If you [ the developers :) ] send me the patch, Jan and me can do some
user testing with the current implementation. We will try to answer the
- - Do users make use of the Quick Search?
- - Do they have problems handling it (input field in a menu)?
- - What do they enter (app name vs keywords vs both?)
- - Do they have problems initiating the search by clicking . or /? Is it
necessary to have those search initiators at all?
- - Do they expect the results to be consistent or volatile after
re-opening the menu?
- - Are the results sufficient (for applications they do not know: do they
need more information such as descriptions/further context? -> see Jan's
- - Do they accept it?
- - Do they appreciate it?
If you would like us to do the testing, please let us know.
Jan Muehlig wrote:
> I like the idea of a search inside of kmenu, and it came immediately to
> my mind when scott talked about (now called) tenor at akademy.
> I don't want to stick too much on the micro usability issues, since I am
> sure they can be solved. If we can't decide by intuition or experience,
> we must test it with users. This should be no problem. I am willing to
> do testing of different versions.
> A quick overview of how WinXP and MacosX do it can be found here:
> www.userbrain.de/kmenue.html .
> But the discussion about a search inside of kmenu does not make sense if
> we do not think about how results are displayed. and this leads back to
> some mails about the difference between search and minicli (or alt-f2),
> and also the integration of tenor.
> As a rough draft, the results could be shown in a new pane with:
> - launch application (s) (button)
> - show location of application (button)
> - describe application
> - show application in kmenu or put it there
> - configure application
> - perhaps: look for newer versions
> - later: show documents created/connected with this application
> Spotlight (OSX Tiger) does something similar:
> For all keyboard freaks, we may have a prefix in the search field, like
> run [application] or r [application]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the kde-core-devel