SoK idea: Improve krunner result displaying and navigation.

Sun May 1 09:06:26 CEST 2011

Ah, this is not a definitive list. We can add/remove stuff from it.

Em 1 de maio de 2011 04:04, Luiz Romário Santana Rios <luizromario at gmail.com
> escreveu:

> Take a look at this and see if it's OK:
>
> Improve krunner result displaying brainstorm:
> + Tweak runners result rating
>   * Nepomuk runner
>    ~ Remove over and over repeated results
>   * File search runner
>    Priority criteria
>    ~ Exact match: for "photos", priorize "Photos" over "Photos -
> september", for example
>    ~ Priorize folders over files
>    ~ Folders that contain several folders or files that match the query,
> probably showing them as "subresults"
>   * Google runner
>    ~ Show a list of actual results from the search (Is this possible?)
> + Change krunner result displaying
>   * Group each runner results into its own category
>   * Allow user to change the categories' priorities (For example: first,
> commands, then, files, then, nepomuk, etc....).
>   * Show as many results as it fits in krunner, shrinking the less relevant
> ones. (configurable)
>   * If there are results from more than a runner, give the user an option
> to expand one category and show only its results.
>    ~ Show further results in the associated application
>   * Show extra actions for each item
>   * Give the option of using a compact layout
>   * Mockup:
> https://picasaweb.google.com/luizromario/Mockups#5601639496208873426
> + Fine-tune krunner
>   * Popup some helping text if user waits too long
>   * Tell the user when krunner is searching and when it found nothing
>   * Put query in a different thread so krunner doesn't freeze while the
> user is typing something (if it still isn't).
>
> And I think the KSysGuard part it uses needs some care too.
>
> Anyway, sorry for taking so long, I got stuck sometimes when doing this.
>
> 2011/4/30 Aaron J. Seigo <aseigo at kde.org>
>
>  On Friday, April 29, 2011 23:57:57 Luiz Romário Santana Rios wrote:
>> > 2011/4/29 Aaron J. Seigo <aseigo at kde.org>
>> >
>> > > On Friday, April 29, 2011 00:21:11 Luiz Romário Santana Rios wrote:
>> > > > 2011/4/28 Aaron J. Seigo <aseigo at kde.org>
>> > > >
>> > > > > On Thursday, April 28, 2011 09:15:08 Luiz Romário Santana Rios
>> wrote:
>> > > > > > Currently, when we type something in, krunner displays the
>> > > > > > results
>> > > > > > as it finds it, without giving a feedback of whether it is
>> > > > > > searching or just didn't find anything.
>> > > > >
>> > > > > that would be a nice addition.
>> > > > >
>> > > > > > It also does not separate the results into its different
>> > > > > > categories
>> > > > >
>> > > > > that's because they are organized by relevance. if they are
>> > > > > sorted into categories, and if there are 4 categories that
>> > > > > match and 5 items in
>> > >
>> > > each
>> > >
>> > > > > category then the best match from the 4th category will be the
>> > > > > 16th
>> > >
>> > > item
>> > >
>> > > > > in the list(!) even though it is more likely to be what the user
>> > > > > wants than most
>> > > > > of the items above it.
>> > > > >
>> > > > > i have yet to see a solution for this problem, but am open to
>> > > > > such a
>> > > > > solution
>> > > > > being offered.
>> > > >
>> > > > Well, I thought about showing only the most relevant results for
>> > > > each
>> > > > category and priorizing the category with the most relevant results.
>> > > > If a
>> > >
>> > > which is almost always going to be the nepomuk search ;)
>> > >
>> > > > user want to see more results for that category, they would just
>> > > > need to expand it. I'll do some mockups for that and will post
>> > > > here.
>> > >
>> > > sounds good; mockups always help.
>> >
>> > Here's one:
>> >
>> http://lh5.googleusercontent.com/_V8ZPvFyTxNc/Tbty2kU7CII/AAAAAAAAARs/v_Ut1J
>> > 8P4DQ/01%20-%20Expand%20and%20Shrink%20less%20relevant%20results.png
>> >
>> > It's bad, I know, I suck at making mockups, but it gives part of the
>> idea of
>> > what I mean.
>>
>> wire frame mockups like that one are just fine. they let one concentrate
>> on
>> the structure rather than get distracted by shiny things ;)
>>
>> > Notice that I show two different ways of expanding the results
>> > in it. I think the button is better, but it takes too much space, so I'm
>>
>> and what would be the workflow to expand / collapse / run?
>
>
>> an important part of krunner is being able to very quickly type and
>> execute.
>> the UI is not fancy, but it is designed for speed.
>>
>
> See mockup in the beginning of the message. But, basically, running
> anything by just typing and hitting enter wouldn't change much.
>
>
>>
>> > > then the Nepomuk runner needs tweaking in how it rates results.
>> >
>> > So this is the first thing we should do, I guess.
>>
>> it's definitely a good starting point. :)
>>
>> > What I meant was that I think it's better to wait one or two seconds
>> after
>> > the user stops typing so that krunner doesn't start querying with an
>> > incomplete string.
>>
>> that would probably ruin one of the main features of krunner: match as you
>> type.
>>
>
> Yeah, you're right.
>
>
>>
>> > I also think it would give focus to the main result, if
>> > there's one, but I may be wrong.
>>
>> it already does.
>>
>> > Weird. Should it work if I just type in something and then press the
>> down
>> > arrow?
>>
>> yes...
>>
>> > Well, I will stop and think over this project and get back with better
>> > summarized idead and more mockups tomorrow.
>>
>> :)
>>
>
> See above. :)
>
>
>>
>> --
>>
>> Aaron J. Seigo
>> humru othro a kohnu se
>> GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43
>>
>> KDE core developer sponsored by Qt Development Frameworks
>>
>> _______________________________________________
>> Plasma-devel mailing list
>> Plasma-devel at kde.org
>> https://mail.kde.org/mailman/listinfo/plasma-devel
>>
>> --
> Luiz Romário Santana Rios
>

-- 
Luiz Romário Santana Rios
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/plasma-devel/attachments/20110501/776832e6/attachment.htm 