'Re: Kicker find as you type'

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

List:       kde-usability
Subject:    Re: Kicker find as you type
From:       Dominik Seichter <domseichter () web ! de>
Date:       2005-05-09 13:00:16
Message-ID: 200505091500.20425.domseichter () web ! de
[Download RAW message or body]

[Attachment #2 (multipart/signed)]

Hi,

It would be great to get some real user testing on the topic and I am gald 
that you volunteer to do so. 

Our current progress can be found in subversion under 
branches/kicker/kmenu_search/ . I think it is the easiest way if you just 
check out kdebase from trunk and switch the kicker directory to the branch 
mentioned above. Is this ok with you or do you prefer patches? Using 
subversion has the advantage that changes you propose can be integrated 
quickly and you can get the results almost immediately.

To give you an impression of what it looks right now:
http://krename.sourceforge.net/screenshots/kicker_05.png

We show immediate search results sorted by most recent usage in the MRU area 
of the menu and we disable non matching items in the KMenu, so that the user 
is able to learn where the application sits in the menu. 

> > For all keyboard freaks, we may have a prefix in the search field, like
> > run [application] or r [application]
I think it would be enough, if the search field would just work like minicli. 
Typing xcalc and pressing enter will start xcalc. Isn't that easier than a 
prefix? Also one could use webshortcuts like "gg:Kicker find as you type" to 
google in the search field if it worked like kicker.

> - 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?
Currently we decided to give the search line the initial focus, after it is 
lost once (for example because of using the up/down arrows) one can access it 
fast using SHIFT+/ or using SPACE. This is still up for discussion, though.

> - 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
> mail below)
> - Do they accept it?
> - Do they appreciate it?

It would be great if we could get answers on all this topics. I hope the users 
will use and appreciate it in your tests!

Thanks for your help!

CU Dom

Am Monday, 9. May 2005 10:29 schrieben Sie:
> 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
> following questions:
>
> - 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
> mail below)
> - Do they accept it?
> - Do they appreciate it?
>
> etc.
>
> If you would like us to do the testing, please let us know.
>
> LG
> /el
>
> 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:
> > www.userbrain.de/spotlight.png
> >
> > For all keyboard freaks, we may have a prefix in the search field, like
> > run [application] or r [application]

-- 
**********************************************************************
Dominik Seichter - domseichter@web.de
KRename  - http://www.krename.net  - Powerful batch renamer for KDE
KBarcode - http://www.kbarcode.net - Barcode and label printing
KDE Mass Mailer - http://www.kmassmailer.net - Mass mailing for KDE
SchafKopf - http://schafkopf.berlios.de - Schafkopf, a card game,  for KDE
**********************************************************************

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