[kde-guidelines] HIG for search needed (?)

Thomas Pfeiffer colomar at autistici.org
Thu Mar 6 20:17:46 UTC 2014


On Thursday 06 March 2014 16:19:45 Heiko Tietze wrote:
> On Thursday 06 March 2014, 15:23:06 Thomas Pfeiffer wrote:
> > Do you guys agree that such an HIG is necessary? If so, I think we
> > should first decide whether KDE should stick to always visible search
> > fields or switch to hidden ones, then I can start writing the guideline
> > (unless Heiko would like to step up to do it ;) ).
> 
> Yes, of course it is part of the HIG. Actually there are some placeholders
> below organizational model yet: Central configuration, Notification
> mechanism, Minimize to tray, Processing of passwords.

Okay :)
 
> I would call this "search" a filter because the result list is completely
> known and becomes limited by the operation. I use "search" in case of
> generating a potentially huge list on ground of some strings or the like.

Actually in the new Kickoff, the search uses KRunner underneath, so it does 
indeed more than just filter the application list, so search makes sense in 
this case.

> Visible or not can be extended to "highlighted" (as in the KCM), and sorted
> or separated or selected, to be creative, Personally, I like the
> highlighting, but it works not well for trees and hidden stuff like menus.
> Dolphin search works like kickoff and switches from standard view to some
> result list, kmail and konqueror selects the first occurrence on search. So
> an answer is not that easy.

Yes, the way the results are presented is another aspect that should be 
covered in the guidelines.
However, while the presentation of results can be different depending on the 
usecase, I think the visibility of the search field itself should be 
consistent. I'd say either we make search/filter fields everywhere always 
visible, or we hide them by default and only show them when users start 
typing. What's your take on this?


More information about the kde-guidelines mailing list