Projects/Usability/HIG/SearchPattern: Difference between revisions

    From KDE TechBase
    < Projects‎ | Usability‎ | HIG
    No edit summary
    Line 35: Line 35:
    ** Show input control only when users start the search.
    ** Show input control only when users start the search.
    ** Hide the control in case the search is not the primary function of the app, but show a small button which indicates clearly the availability of the function.
    ** Hide the control in case the search is not the primary function of the app, but show a small button which indicates clearly the availability of the function.
    ** Active the control and focus it on Ctrl+F or when user clicks the icon.
    ** Do not use search icon anywhere else.
    * ''How to present results'' (Depends on use case?)
    * ''How to present results'' (Depends on use case?)
    ** Highlight search results (KCM mode).
    ** Highlight search results (KCM mode).
    ** Hide non-matching results (Kicker mode).
    ** Hide non-matching results (Kicker mode).
    ** Generate a new list that matches the search pattern  (KRunner mode).
    ** Generate a new list that matches the search pattern  (KRunner mode).
    == Best Practice ==
    == Best Practice ==


    [[Category:Usability]][[Category:Structure]][[Category:Organizational_Model]]
    [[Category:Usability]][[Category:Structure]][[Category:Organizational_Model]]

    Revision as of 15:17, 24 March 2014

     
    Under Construction
    This is a new page, currently under construction!

    Ref's:

    Purpose

    A search function allows to generate a subset out of a big number of items on ground of a user defined pattern. The function is essential to find matching items in case of a extended list or if the position of target(s) is unknown, as well as when bulk operations should be executed.

    More text....

    Guidelines

    • Make the search result persistent. Users must not need to research after selecting or referencing an item.
    • Consider to allow iterative search on result lists.
    • Do not inherit artificial intelligence from users. Search operations have always be clear and comprehensible to users.
    • Follow the guidelines on delayed operations if the search takes longer.
    • Provide paging/scrolling of results.
    • Provide auto complete feature to the input based on previous operations.
    • Start the search process via button or when the user pressed enter.
    • Show the search pattern at the header of the result list (e.g. "Search results for: <Hello World>")
    • Show hints on how to use the search effectively.
    • Do case insensitive search, unless its important.
    • Make the search box large enough to show at least 20 characters (at the moment: KRunner & Kicker = 24, Konqueror = 54, KCM = 33, cf. ).
    • Run a combined AND search when two words have been entered unless the term is quoted (e.g. Hello World vs "Hello World")

    Appearance

    • Search input consists of an icon, a line input to enter the search pattern, and a button to start the search. (VDG could make a proposal how it looks nice)
    • Placement
      • Start search at the upper right area of your dialog (KCM and web style).
      • Start search at the lower left area of your dialog (Kicker and Konqueror style).
      • Show search centered in the upper area of your dialog (Dolphin and KRunner style).
    • To show or not to show:
      • Always show search input. Do not hide the availability from users.
      • Show input control only when users start the search.
      • Hide the control in case the search is not the primary function of the app, but show a small button which indicates clearly the availability of the function.
      • Active the control and focus it on Ctrl+F or when user clicks the icon.
      • Do not use search icon anywhere else.
    • How to present results (Depends on use case?)
      • Highlight search results (KCM mode).
      • Hide non-matching results (Kicker mode).
      • Generate a new list that matches the search pattern (KRunner mode).

    Best Practice