Search design

Status Notes from first brainstorm on Search. August 3, 2004

Use cases (with example workflows for Ted)

• Who (regardless of From, To, CC BCC).
  • e.g. Search for items related to a person "John Smith".
  • This searches the From, To, CC, BCC attributes for all Processing Items
  • The search term used is not just the text string "John Smith". We also determine if a Contact matches the string "John Smith". If so, John Smith's email address is searched through all emailed items in the repository. In the future, as we add other item transports, John Smith's corresondending user address for that transport will also be searched. e.g. John Smith's JabberID^? will be searched through Jabber Items.
• Keyword (single term or string)
  • e.g. Search for keywords "OSCon Presentation"
  • This searches all attributes of all Processing Items for the keywords "OSCon Presentation"
  • More work needs to be done to figure out criteria for search relevance
  • Also, keywords entered in quotes in the search box indicate results with exact phrase preferred
• Date range (usually done through sorting and scanning)
  • e.g. Return all messages "last week" or "yesterday" or a date range (8/1/04 thru 8/9/04)
• ANDs are used for browsing and searching for a particular item (80% of the use cases)
  • ANDs can combine all 3 search modes above and restrict results that satisfies all conditions
• ORs are used for putting together collections (ie rules)
  • ORs combine all 3 search modes above and return results that satisfies any conditions

Proposal

• Contacts search is separate from Chandler's main search

• Multiple terms typed into the Search bar should limit the search results

• Chandler recognizes attribute values
  • Contact names, nicknames, emails, IM buddy names
  • Headlines (more for event headlines than email subject lines)
  • Collection names
  • Mark-up bar attributes: Triage status, Stamps, Flags, Privacy
  • Dates: Today, Last week, Tuesday, August, August 12th 2004
  • Not necessary for Contacts

• Chandler returns search results in attribute-based clusters
  • Items From Tom
  • Items To Tom
  • Items that mention Tom

Interaction design

• If focus is not in detail view, typing automatically populates search bar
  • Only letters, numbers and shift + letter / number will send the cursor to the search bar
• Search bar parameters restrict Browser
• Safari style auto-complete for recognized attribute values
• Search results come in as user types

• Special prefixes to search on a specific attribute
  • To:
  • From:
  • Collection:
  • Inbox:
  • Foo:
• User can also select prefix from pulldown from Search bar
• Prefix is visually different from normal text

• Support "quotations "
• No support for ANDs and ORs

• User can save search or browser paramenters with the same Save button

Workflows

• Start with a free-text search in Search bar
• Navigate by attribute-based cluster to zoom in on what you want
• Continue to refine search with attribute-based browser
  • [OI^?] How likely is this?
  • The Browser is probably only useful if it is narrowed by the Search bar terms

• Search bar / Browser interaction
  • Search bar parameters limit Browser column options to show: only options that will not result in a null set
  • Search bar parameters bring Browser column options that meet the parameters to the top of each column (ie. Search bar: "Shar" will bring "Shares" and "Sharing" to the top of the Collections column)
  • Users can further refine Search bar parameters will available options in Browser and vice versa
  • Browser selections are reflected in the Search bar as buttons that are deletable but not editable

Questions (mainly for Ted)

• A brief overview of Lucene capabilities will be helpful
  • In particular, what are the variables to tweak that provide the most relevant search results? What are Lucene's idiosyncracies?
• What criteria should we use to decide what attribute is indexed by Lucene and what isn't?
• If an attribute is not indexed by Lucene, what search capabilities can we expect on those attributes? How does it work?
• How do we determine what attributes are searched on and what aren't? Are item clouds the means to specify the relevant attributes?
• Are there issues about date and date range searches to be aware of?
• Can queries be "contacts-aware"?
  • Base case: if query represents "all emails from Mimi", and I have a new email address for Mimi, the query should now include all emails from the new email address
  • More complicated case: Contacts need to have a history of addresses (email, IM, phone#s, etc.)

• What are the challenges in exposing a query language to end-users?
  • How easy is to make it the language so forgiving and permissive to accept most user "mistakes"?

• Can you describe the observable query functionality in more detail?

.5 target

• No UI beyond a text box for search & UI for search results
• Cancel search button (ideally inside search field)
• Save search button creates a new collection in the sidebar
• No corresponding rule builder UI to edit saved searches
• No weighting of attributes
• Search terms apply to currently selected collection and kind filter settings
• Real-time search returns in content area

See Also

• ChandlerQuerySystem

-- MimiYin - 03 Aug 2004