5

I'm working on iOS app and part of what I'm making is an advanced search interface. The default iOS search components allow for text entry and for a "scope bar". That is, a bar which allows you to choose which property (or properties) of your "target object" you want to match. If we were designing a books search app, here's what might look like:

Scope Bar

This works well, however there are two limitations here.

  1. The user has no preset search terms to choose from. While this is not bad, I'm looking for something a little different. I want to show the user a list of all existing authors and let them choose from the list.

  2. Only one property can be searched against at a time, unless you explicitly provide an "all" button. But even, then, it's all or nothing. What if I want to search Title and Author, but not Content?

How would you design such a search control? Instead o a scope bar, I was thinking along the lines of a scope "chart" where the user taps a button and is shown a list of options. In the list, they can choose from an option, or, optionally, a custom keyword.

Scope "Chart" mockup

Is this a bad idea for user experience? How would you create this visually, to match iOS conventions?

1
  • I'd be inclined to allow the user to search either "Title and Author" or "All".
    – ICR
    Commented Aug 12, 2011 at 20:35

4 Answers 4

1

I think the whole concept of "Advanced Search" is a bit contrary to the design goals of iOS and most good iOS apps. With a little extra programming work, you can make the results of a simple search just as useful as those of an advanced search, without all the visual and cognitive complexity it would add.

You want to be able to search by Title, Author, or Body. Most titles are not people's names, and those that are are rarely names of authors. Text from a title might be in the body of something else, but if you pick that phrase as your search query, you are almost certainly more interested in the title match.

So when someone types something in, prioritize the results based on what they expect. Title matches are clearly most important, followed closely by Author matches, with Body matches at the bottom. Works with more Body occurrences of the search query might add a small amount to that item's priority.

There may be rare edge cases where the intended result is not at the top of the list, but even then, the chances of the user having to scroll past more than one or two unintended results is vanishingly small. The most frequent and annoying such edge case might be if someone wants to see books that mention an author, rather than those by that author. For this case, I would be sure to include the author's name under the title of each work in the results list. This way, users can quickly visually confirm when they've scrolled past the Author matches and have reached the Body matches.

2

"I want to show the user a list of all existing authors and let them choose from the list."

That sounds more like navigation/filtering than actual searching.

I'd have the home screen be:

BROWSE:
By Title >
By Author >
By Content >

Each secondary screen could then have:

Search by keyword: [             ]
or browse:
term >
term >
term >
term >
term >
1
  • This answer does not address the question: How to build a user interface for performing a query across multiple categories/attributes. Your answer is for a query within a single category/attribute. Commented Dec 24, 2012 at 6:02
0

How about using a modified version of the search tokens Apple added to OS X with Lion?

You could put a '+' button to the right of the search field. When users tap it, it would take them to a screen where they can select from a list of search tokens (Title, Author, Content, etc.) Tapping on a list item would bring up a screen with a text field near the top, where they enter the actual keyword ("Harry Potter," or "Mark Twain,").

This screen would initially be populated with a list of preset search terms for the user to browse through. As the user typed, these would be replaced with a list of matching suggestions.

Once the user selected a search term, it would appear as a "lozenge" on the main search screen. Instead of appearing in the main search field as in Lion, it could be put in a separate, horizontally-scrolling bar beneath the field (like the tab bar in your first picture). Tapping on a "lozenge" would bring up an action sheet with options to 'edit' or 'delete' it.

0

Think about the most powerful search functionality used by most of your users - Google itself. The UI is simple, but provides filtering after the fact.

Instead of having a complex UI for starting the search, how about having more features for controlling the results afterwards.

You could, perhaps, have toggling buttons at the bottom of the search results window, allowing users to turn on/off matches.

Taking your books search app example,

[Title Match (45)] [Author Match (4)] [Body Match(95)]

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.