Kickoff Meeting for Queries

Attending: TedLeung, AndiVajda, HeikkiToivonen, JohnAnderson, KatieCappsParlante, BrianDouglasSkinner, MimiYin, MitchKapor

Related writeups and notes from the design team

• ItemCollection
• QueryView
• Dashboard view (aka the PPF view)

Notes from the meeting

• We had some discussion of the terms "search" and "query". We are not using the term "search" to mean "a slow way of finding what you want". The line is perhaps blurred, but for end users, a "search" is an interface for asking for a set of items, based on some criteria. A "collection" in the interface is a set of items, which may be created explicitly by the user choosing each item in the collection, or implicitly by creating a sort of rule (similar to the search) for which items are included in the collection, or some combination of the two. "Searches" and "collections" in the user interface may be unified in the implementation with queries.

• Ted proposed an "item collection" abstraction, which results in a set of items. We might have different types of such item collections. One type of item collection might be built out of other item collections (union or intersection, for example). There was general agreement for this concept in principle.

• We had some discussion about whether or not the "declaration" of a query would be built up as a string, or if there would be an api for creating/modifying the query declaration. We agreed there were situations when one or the other was preferrable. Perhaps there is an elegant way to allow both.

• We had some discussion about how results are returned from the query: iterator or generator, etc. Can the client ask for the size of the query's result set?

• There was some discussion about whether or not we might have a separate "collection" item and "query" item, or if these should be merged into the same kind of item. The discussion was somewhat clouded by confusion over terminology. One of the key issues here is how we want to model the content model. Do we have a "collection" kind as a superkind to groups, projects, etc.? Do we use a query item for this purpose? Are "collections" of objects, the contents of views, (e.g. an email inbox, a project view of tasks and contacts) modeled as items with bidirectional relationships, modeled as queries, etc.?

Tasks noted at the end of the meeting

• Ted will come up with a proposal for an API for queries, the client model for how to use queries
• Katie will provide use cases to help Ted, with help from design team if necessary

A few use cases

• A user's email inbox: all mail marked as being in the inbox
  • All inbox email items that have been marked up as being in the Foo project
  • All inbox email items that were sent in the last month/day/week
  • All inbox email items that were sent by a particular person
  • All inbox email items with the word "Bar" in the body
  • All inbox email items with "Bar" in either the subject, the body, or any of the to or from fields (or in the names of the Contacts associated with the email addresses in any of the to or from fields)
• All "recent" mail to or from a particular person
• A user's home calendar: all calendar events, tasks, notes, etc. in the "home" calendar
  • All calendar items with durations overlapping a given day/week/month (startTime and endTime denote the duration)
  • All calendar items with the word "Bar" in the headline or body
  • All calendar items that are in the Foo project
• All content items that have some relationship to "today"
• Any Contact item where the related ContactName has the value "Lee" for any of the attributes (firstName, middleName, lastName)
• Any content item with "Foo" in any attribute-value
• All content items with a "project" attribute
• A set of content items that the user has selected and dragged to the "MyStuff" view
• Some/any combination of these use cases, unions and intersections

• You also might want to look at the working notes about the "Dashboard" view (aka the PPF view)

We've been thinking of these use cases mostly in terms of "views". A view is persistent. A view might have an item because the user explicitly put the item in the view. A user might build up a view implicitly: (a) choose to look at calendar events and tasks + (b) choose a particular time range + (c) choose to look at items in a particular project. The view is composed of both some query/collection as well as presentation attributes (sort order, columns displayed, etc.). Its possible that we would think of "search" as something different in the interface, a dialog not unlike other search dialogs in other applications. The working assumption is that the query mechanism underneath would be basically the same. Whats not completely clear is whether or not the "collection" of items that a view mantains is just a query, or an item with bidirectional relationships to items + a query as a filter on top, etc. We're hoping that a concrete query proposal helps us think clearly about both the content model (e.g. how to model projects and calendars) and the model/design of the view.

-- KatieCappsParlante - 22 Jan 2004
-- BrianDouglasSkinner - 22 Jan 2004