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

Tue Apr 1 16:47:36 UTC 2014

>From a user perspective I think I can see some functional differences
between search versus filtering, even in the same folder.

So let's say Jane has Dolphin open in her Documents folder. Let's say Jane
has ~100 miscellaneous files there that have built up over the years. Jane
also has under Documents several more structured folders with oodles of
files as well for different projects over the years, travel expense reports
and receipts.
Jane thinks that the file she's looking for is one of those ~100
miscellaneous files because that where she typically put documents that
aren't project or travel expense related. She thinks the filename starts
with "sta"  but isn't sure. So she opens the filter function on Dolphin and
types "sta". What she expects is that out of ~100 files Dolphin shows in
the Documents folder, some subset will be displayed with filenames starting
with or containing "sta". She just wants to reduce the set of data that was
already *visible* in Dolphin. She chose filter instead of search because
she doesn't care about the 200 or so files in the Documents/Littlesburg
Train Station project folder and its subfolders with "sta" in their
filename, .

She's essentially just restricting her search to what is currently
*visible* and not trying to recursively search the contents of the
currently displayed Documents folder. She's still conceptually searching.
But how she's searching, even in the current folder, is quite different. I
do think we can still unify the presentation of say the search/filter text
field. But we may need a way to offer the "just restrict my search to what
is currently visible, without recursion" functionality that filter
provides. Perhaps a search mode toggle of some sort. It might also
ameliorate any understandable developer concerns about unifying search and
filtering.

Separately, perhaps it might be worth distinguishing this pattern from a
word/item-highlight search where the content isn't altered but the found
items are simply highlighted and you can walk through each search "hit".

P.S. I do think we should consider my sidebar search suggestion as a
separate, maybe experimental, pattern to revisit at a later date after
we've sorted out this basic search pattern.

On Sun, Mar 30, 2014 at 11:07 AM, Thomas Pfeiffer <colomar at autistici.org>wrote:

> On Sunday 30 March 2014 19:36:30 Philipp Stefan wrote:
> > On 30.03.2014 00:18, Heiko Tietze wrote:
> > > On Tuesday 25 March 2014, 20:38:05 Andrew Lake wrote:
> > >> http://wstaw.org/m/2014/03/26/Category_search_pattern.png
> > >
> > > I think the position is good in case of some preselection is done
> > > left-hand. But if we have navigational content it absolutely makes no
> > > sense to place a search field there that affects the content only. For
> > > instance a file browser with folders on the left and files at the
> client
> > > area.
> > >
> > > All else looks nice to me except the missing main menu and the missing
> > > scrollbar arrows. :-)
> > > _______________________________________________
> > > kde-guidelines mailing list
> > > kde-guidelines at kde.org
> > > https://mail.kde.org/mailman/listinfo/kde-guidelines
> >
> > I think so, too. I think the search field should be placed in the menu
> > bar when the search will be performed in a global manner / lots of
> > different directories that can't be accessed via the sidebar. Dolphin
> > and I guess  Kmail would also fit in this category.
> > Apps that use the sidebar to navigate the applications/ between
> > different grouping options of the data should place the search field in
> > the sidebar. A music player or a social media application would fall
> > into this second category.
> >
> > In these second applications the search function is just a simple filter
> > functions. And based on that I'm going to claim that the difference
> > between search and filter is actually pretty meaningless in most use
> cases.
> >
> > Let's imagine a music player:
> >
> >     The applications currently is displays the album view. The user
> >     opens the search dialogue and attempts to search for a specific
> >     song, because the search function actually is filter here the
> >     application will display the album which contains the target song.
> >     The user now has two choices:
> >     1) Click on the album and then navigate the the song
> >     2) Click on "songs" in the sidebar and then directly navigate to the
> >     song in question
> >     This way no additional options for the search is needed - the
> >     different options in the sidebar become the search controls.
> >
> > Let's imagine a application with a complicated structure like a file
> > browser:
> >
> >     1)The application currently displays a random directory. The user
> >     wants to find a file and has no idea where it resides. He calls the
> >     search function and the search field appear in the menu bar along
> >     with the option to display more settings. The search then returns
> >     the wished results and the user will proceed with whatever they had
> >     in mind.
> >
> >     2)The user currently navigates a directory with lets say over 100
> >     files. The user then calls the filter function via a shortcut or a
> >     menu entry. The search field appears in the menu bar along with a
> >     option to display more settings. In these setting the option to only
> >     search the current directory is toggled. The filter will return the
> >     desired results and the user continues with what they were doing.
> >
> > With this in mind I propose to always demand an instant search. If the
> > search takes a bit longer an indicator that the query is still being
> > processed can be shown. We can also get rid of the difference between
> > the filter and the search functionality. The search field and the filter
> > field are the same entity with the different predefined settings. They
> > reside in the same area and use the same label and icon.
> >
> > The different shortcuts will then only be a quick way to change between
> > different parameters of the search function.
> >
> > 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. I think the user generally doesn't really care about the
> > technical differences, and those who do can simply change them in the
> > search settings.
> >
> > What do you think?
> >
> > Phil
>
> I think unifying search and filter mechanism makes a lot of sense from a
> user
> perspective. It might be difficult to convince developers because they
> seem to
> usually prefer to present things in a technically precise manner (Jens'
> "precise vs. correct" comes to mind once again), but for users a filter
> and a
> search in the current folder is presumable the same.
> _______________________________________________
> kde-guidelines mailing list
> kde-guidelines at kde.org
> https://mail.kde.org/mailman/listinfo/kde-guidelines
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-guidelines/attachments/20140401/a1e72e35/attachment.html>