SoK idea: Improve krunner result displaying and navigation.

Wed May 4 12:54:09 CEST 2011

Hi again.

So, based on this list, I made a 12 week plan for the project based on the
12 week scheme used in GSoC:

Week 1/2: Tweak Nepomuk runner
Week 2/3: Tweak File search runner
Week 3: Tweak Google runner
Weeks 4 to 5 (or 6?): Put result querying in a different thread
Week 6: Polish what has been done so far

Week 7: Get user feedback better (Tell when searching and when nothing was
found, some helping message at start)
Week 8: Separate results in groups, allow user to define the priority of
each runner (or allow developer to define the priority each one of their
runner's commands can set it)
Week 9: Make results fit on only one krunner screen, shrink less relevant
results, hide lesser relevant results on main krunner screen
Week 10: Expanding/unexpanding search groups
Week 11: Extra actions for each item of the results, depending on its type
Week 12: Polish and get everything ready to go

What do you think?

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

> 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

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