<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
I'm sorry, I forgot about this e-mail, Heiko.<br>
<br>
I like your proposal and I agree that we should move this discussion
back into the forums to get more input. How do you want to do it?
Just a copy-pasta?<br>
<div class="moz-cite-prefix">On 08.04.2014 16:02, Heiko Tietze
wrote:<br>
</div>
<blockquote
cite="mid:f06d0a1596b6280a02340d875c407ef2b08561ea@user-prompt.com"
type="cite">
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<title></title>
<style type="text/css">.felamimail-body-blockquote {margin: 5px 10px 0 3px;padding-left: 10px;border-left: 2px solid #000088;} </style>Am
30.03.2014 19:36:30, schrieb Philipp Stefan:<br>
<blockquote class="felamimail-body-blockquote"> I think this way
the guidelines can be simplified greatly and I think the
behaviour of the whole function become clearer/more consistent
to the user.<br>
</blockquote>
<p>Yes!<br>
</p>
<p><br>
</p>
<p>I was thinking about a better HIG for a while. We have
discussed a lot of options, especially about the position of the
control. Reviewing the current layout I get these results:<br>
</p>
<p><br>
</p>
<p>** Start search at the upper right area of your dialog (KCM and
input for web browser's search engine).<br>
** Start above the content area (Search in Dolphin, KMail -
search within current mail, KSystemLog)<br>
** Start below the content area (Filter in Dolphin, Konqueror /
Rekonq / Browser search within current page in general, KWrite,
Konsole, Okular).<br>
** Start above or below depending on the layout (Kicker, if
started from a top- or bottom-aligned band).<br>
** Make search floating (KRunner style).<br>
** Use an extra (modal) dialog (KMail search for mails,
Krusader).<br>
** Start above the navigation area/category selection to clean
the content on-the-fly (Bangarang).<br>
</p>
<p><br>
</p>
<p>I started with this consideration but most of these operations
might be understood in terms of a filter since it don't generate
something new but jump to the right position! So what's about
the simple advice to use a standard 'filter' and search per
extra dialog. This would affect only Dolphin, but solves the
strange "from here" issue by the way.<br>
</p>
<p><br>
</p>
<p>Therefore I stripped all discussion from the HIG and applied a
different structure (please understand it as proposal not
solution; all changes can be reverted).</p>
<p><br>
</p>
<p><a class="moz-txt-link-freetext" href="http://techbase.kde.org/Projects/Usability/HIG/SearchPattern">http://techbase.kde.org/Projects/Usability/HIG/SearchPattern</a></p>
<p><br>
</p>
<p>--------------------------------</p>
<p><br>
</p>
<h2><span class="mw-headline" id="Purpose">Purpose </span></h2>
<p>A <i>search function</i> 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 to a subset. A
search operation interrupts the 'predefined workflow' and bypass
core functions to a user-defined data set.
</p>
<p>Supplemental to search is the <i>filter function</i> which
rather reduces a given number of items than generating an
output. Filtering should be always instantaneous.
</p>
<table id="collapsibleTable0" class="wikitable collapsible
collapsed" style="border:none">
<tbody>
<tr>
<th><span style="float: right; font-weight: normal;
text-align: right; width: 6em;">[<a
moz-do-not-send="true" id="collapseButton0">show</a>]</span>
Use case for filter vs. search
</th>
</tr>
</tbody>
</table>
<h2><span class="mw-headline" id="Guidelines">Guidelines </span></h2>
<ul>
<li> Provide filter function to shown content by default. Apply
search using an extra dialog.
</li>
</ul>
<h3><span class="editsection"></span> <span class="mw-headline"
id="Filter">Filter </span></h3>
<hr>
<h4><span class="mw-headline" id="Input">Input </span></h4>
<ul>
<li> Perform filter operations always instantaneously.
</li>
<li> Make the operation as simple as possible. For instance, do
not apply multi-dimensional filtering or do not use logical
operators for input.
</li>
<li> Run operation case insensitive, unless it is important.
</li>
<li> Make input control large enough to show at least 20
characters.
</li>
</ul>
<h4><span class="mw-headline" id="Output">Output </span></h4>
<ul>
<li> Make the filter result persistent until it is cleared
explicitly. Users must not need to research after selecting or
referencing an item. </li>
<li> Provide auto complete feature to the input based on
previous operations.
</li>
<li> Highlight matching results and jump to the first
occurrence.
</li>
</ul>
<h4><span class="mw-headline" id="Appearance">Appearance </span></h4>
<ul>
<li> Hide input control until users start the search.
</li>
</ul>
<div class="alert alert-success">
<div style="float:left; valign:top">
<div class="floatleft"><a moz-do-not-send="true"
href="http://techbase.kde.org/File:Note-box-icon.png"
class="image" title="noframe"><img moz-do-not-send="true"
alt="noframe"
src="http://techbase.kde.org/images.userbase/c/c1/Note-box-icon.png"
height="40" width="40"></a></div>
</div>
<div style="width:10px; float:left"> </div>
<table>
<tbody>
<tr>
<th>Note</th>
</tr>
<tr>
<td>I'd prefer to show it always but actually that's not
the current behaviour in general.
<ul>
<li> Hide the input control in case the filter is not
the primary function of the app, but show a small
button which indicates clearly the availability of
the function.</li>
</ul>
</td>
</tr>
</tbody>
</table>
</div>
<ul>
<li> Active the control and focus it on ctrl+F or when user
clicks the icon.
</li>
<li> Place the input control at the bottom of the content area.
</li>
</ul>
<h3><br>
<span class="mw-headline" id="Search"></span></h3>
<h3><span class="mw-headline" id="Search">Search </span></h3>
<hr>
<h4><span class="mw-headline" id="Input_2">Input </span></h4>
<ul>
<li> Do not inherit artificial intelligence from users. Search
operations have always be clear and comprehensible to users.
</li>
<li> Show hints on how to use the search effectively.
</li>
<li> Do fuzzy search by default, if applicable. That means
extend the results by adding a wildcard to the item.
</li>
<li> Run a combined AND search when two words have been entered
unless the term is quoted (e.g. Hello World vs "Hello World")
</li>
</ul>
<h4><span class="mw-headline" id="Output_2">Output </span></h4>
<ul>
<li> Show the search pattern at the header of the result list
(e.g. "Search results for: <Hello World>")
</li>
<li> Follow the guidelines on <a moz-do-not-send="true"
href="http://techbase.kde.org/Projects/Usability/HIG/ProgressIndicator"
title="Projects/Usability/HIG/ProgressIndicator">delayed
operations</a> if the search takes longer.
</li>
<li> Provide paging/scrolling of results.
</li>
</ul>
<h4><span class="mw-headline" id="Appearance_2">Appearance </span></h4>
<ul>
<li> Run search operation within an extra, modal dialog. </li>
</ul>
<h2><span class="mw-headline" id="Best_Practice">Best Practice </span></h2>
<ul>
<li> <a moz-do-not-send="true" rel="nofollow" class="external
text" href="http://i.imgur.com/eL7mi4K.png">Example 1</a>
</li>
<li> <a moz-do-not-send="true" rel="nofollow" class="external
text"
href="http://wstaw.org/m/2014/03/26/Category_search_pattern.png">Example
2</a>
</li>
</ul>
<p><br>
</p>
<p>--------------------------------</p>
<p><br>
</p>
<p>For now, most apps places the filter bar below the content.
That should be used as the state of the art for the HIG but
might be as well a good starting point to improve the layout
with Plasma Next. Because a mailing list is not so good for
discussions I vote for moving back to the forum with all
advanced ideas and to keep the legacy stuff here. (I know it was
me who moved the discussion first to the ML, sorry.)</p>
<p><br>
</p>
<p><br>
</p>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
kde-guidelines mailing list
<a class="moz-txt-link-abbreviated" href="mailto:kde-guidelines@kde.org">kde-guidelines@kde.org</a>
<a class="moz-txt-link-freetext" href="https://mail.kde.org/mailman/listinfo/kde-guidelines">https://mail.kde.org/mailman/listinfo/kde-guidelines</a>
</pre>
</blockquote>
<br>
</body>
</html>