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

[Andrew Lake]

Oh sure Thomas, I should have thought of that. I'm always the one saying
preach with the pixels not the words! Sorry. :-)

Bangarang:
http://bangarangkde.files.wordpress.com/2010/11/app-korn.png?w=740&h=547

A couple mockups I shared with the VDG (in the mockup toolkit) for a file
manager:
http://wstaw.org/m/2014/03/24/fm.png

and a music player:
http://wstaw.org/m/2014/03/24/mp.png

In these particular mockups, the search is exposed in the UI with a simple
search icon rather than a text field, but that less important. The word
"Search" could accompany the icon to make it a bit more
discoverable. Search could also be the first entry in the list if it is
more appropriate. But, the number of interaction steps would be exactly the
same:
1. Click to focus/activate
2. Type
3. Enter (only necessary if the interaction pattern is search-on-enter vs
search-as-you-type).

In all these cases, category selection (including search) is on the left
and content corresponding to that selection is on the right. The behavioral
model is consistent whether you select a category or search: Content on the
right reflects actions taken on the left AND selections on the left are
mutually exclusive.

I've also used this pattern in a few Android applications with good
results. Of course, while this is a design pattern I've found quite useful
in practice, there's always the possibility that you folks may identify
some downsides with this approach. I certainly welcome the feedback. :-)

Hope this helps,
Andrew

P.S.  In the case of Bangarang, *filtering* was exposed in the content
window where the content corresponding to any category selection on the
left, including search, could be filtered.



On Mon, Mar 24, 2014 at 12:45 PM, Thomas Pfeiffer <colomar at autistici.org>wrote:

> On Monday 24 March 2014 12:22:10 Andrew Lake wrote:
> > I've followed this conversation to try to absrob the viewpoints so far,
> > before rudely jumping in and sharing my thoughts. :-)
> >
> > Is it possible to distill our consideration of search into something a
> > little less exceptional? Should search always be treated differently than
> > any other content selection/alteration model?
> >
> > In many cases where search is present there is often some other basic
> > content selection model. For a music player, there is a Artist, Album,
> > Genre content selection model. For system settings there is usually a
> > Hardware, Appearance, Admin, etc. content selection. For Kickoff there's
> > Favorites, Applications, Computer, etc. For some reason search is often
> > visually treated as a something completely different - usually by putting
> > the search field in a completely different location than the other
> content
> > selection mechanisms.
> >
> > The consequence can sometimes get messy. If you have Artist selected and
> > you do a search that displays songs in the search result, the UI ends up
> in
> > this inconsistent state where the search field is highlighted and songs
> are
> > being displayed but Artist is still selected. If the designer is careful,
> > they'll deselect Artist (leaving a useless category selection pane with
> > nothing selected), or hide the category selection all-together (like
> > Kickoff does).
> >
> > My question is why? If other forms of content selection are available,
> why
> > treat search as a completely different form of content selection? When
> you
> > select Artist in a music player, the content changes to show artists.
> When
> > you select your Document folder in the places panel in dolphin, the
> content
> > changes to show the files in your Documents folder. When you search, the
> > content changes to reflect what you're searching for. Why not use the
> same
> > space and interaction model in the UI for search as other category
> > selection mechanism? Sure you have to type but is that really the only
> > thing that really compels a completely different location for the search
> > field?
> >
> > If I have a simple two panel layout with category selection on the left
> and
> > content on the right, then search goes on the left with all the other
> > categories. The upside being that it cleans up the UI because I didn't
> have
> > to find a whole other place to put search. I've had the opportunity to
> use
> > this in several application designs across several platforms and have not
> > observed any degradation in user search experience. I'm not saying there
> > are never good reasons to elevate the search field to a primary, distinct
> > point of focus for any UI design - Unity does it well I think. Rather, I
> > think it should be the exception rather than the rule/guideline.
> >
> > *Filtering* of existing content, on the other hand, really should go into
> > the content view. The category selection doesn't change as a result of
> > filtering. And with search as just another form of category selection,
> you
> > can conceivably filter search results - very useful.
> >
> > Sorry for rambling but I hope this is helpful!
> > Andrew
>
> Hi Andrew,
> while this idea sounds reasonable on an abstract level, I must admit that I
> can't really picture how it works in practice. Could you point us to some
> screenshots/mockups of applications were this was/will be implemented?
> Maybe
> then we can judge whether it would work for the majority of cases.
> Thanks,
> Thomas
>
>
> _______________________________________________
> 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/20140324/d4f2c28c/attachment.html>