Possible Calendar Features

What is this document?

This is an attempt to have a long list of all the calendar-related requirements that might be considered for Chandler in the fullness of time.

How will this list be used?

This list might serve as a kind of "menu", from which OSAF can pick which features to consider implementing in Chandler. OSAF could eventually pick a set of features from this list, and then prioritize those features to determine which features will go in which releases.

What is a "feature"?

I've tried to put this list together from a user's point of view. The "features" listed here represent things a user might ask for, rather than things an engineer might have to do. These features don't represent units of coding work, they're more like the items on a user's wish-list.

Why is this list so long?

I've tried to make this list fairly detailed. The idea was to try to come up with a list that was complete and specific, without being too pedantic. At this point the list has about 1,000 entries for possible features, maybe about half of which have some sort of short note to help describe them.

How is this list organized?

The features are clustered into sections. For example, all the features related to spell checking are together. These sections are usually broken down into sub-sections, and so on.

(The whole taxonomy of sections could use some work. I found it surprisingly difficult to come up with a good taxonomy. Ideally you want a taxonomy that makes it easy to find any feature you're looking for, and easy to file any new feature you want to add to the list. And the taxonomy should help prevent features from accidentally being listed in two places at once.)

Should these features be numbered?

Yes, maybe each feature should have a unique number. That way an entry in bugzilla could reference a feature here. Or an entry in a prioritization spreadsheet could reference a feature here. Or a wiki page could discuss some implementation detail and reference the feature that's being talked about.

How about anchor tags?

Yes, maybe each feature should have it's own anchor tag, so that other web pages can have links to specific features on this page.

Why is the formatting so ugly?

I originally wanted to create this list as wiki topic, so that it could be publicly available for anyone to look at and add to. Unfortunately, once the list started getting long, it become difficult to edit as a wiki document. It was just too much work every time I wanted to re-organize the sections, or move features to sections, or make other structural changes.

I ended up creating the list as a Microsoft Word Outline, which made it easy to move entries around and try to keep the list organized. I have the version in Microsoft Word set up to automatically generates the wiki headings for the features (you know, all those prefixes that look like this: ---++++). That way you can save the Word file as a .txt file, and then copy the .txt file into the wiki editing page. You still need to edit the original Word version rather than the wiki version, but at least you can view the document as a wiki topic.

Unfortunately, the resulting wiki page is painfully ugly. It's difficult to make sense of the wiki page, at least in part because the wiki generated page has almost no visual cues for displaying hierarchies (like, for example, indenting headers). And the original Word document is harder to read than it needs to be, because of the added wiki formatting tags. So this whole approach may be the worst of both worlds. If we want to keep maintaining this list, we should think about moving it into some other representation: a native Word document, or a collection of wiki pages, or a bunch of little flatfile database entries.

Where is the wiki version of this document?

There's a preliminary version available in Brian's Sandbox, at: BrianDouglasSkinnerJunglePages-Calendar-Features

Where is the Word version of this document?

Eventually the Word version should end up as an attachment on a wiki page, but for the moment there's a bug with the wiki that makes it impossible to post attachments. So for the moment, the Word version is available on Brian's web site, at: http://aloha.osafoundation.org/~skinner/2003/calendar/Possible_Calendar_Features.doc

Is this list finished?

No, the list is far from finished. Here's a list of a few things it might be good to do:

• Look at a bunch of other calendar clients and see what features they have that we might want to consider for Chandler.
• Look through Ducky's list of the possible e-mail features for Chandler, draw inspiration from it, and add features to this list. (Or, alternatively, re-factor common features up into a common feature list.)
• Give more thought to the taxonomy of features, and maybe try to re-organize the whole thing into a more useful breakdown. Try to eliminate duplicate mentions of features, or at least add cross-references.
• Ask the folks on the design or dev lists to have a look at this, and incorporate their feedback.
• Think about moving the list out of Microsoft Word and into some other tool.
• Clean up formatting inconsistencies.

---

Contents

---

Chandler Features

"Infinite" undo

• the user can undo any number of changes

Keystroke commands

• allow the user to perform most common operations without using a mouse

Unicode support

Foreign languages

support for English

support for other languages

UI language preference

• "What would be nice is for someone to be able to dynamically switch the language used for the UI, and have this preference stored as an attribute in a profile/personality/identity. Having this feature will make it much easier for people to share a single machine (because it often happens at home, or in the office)

calendar orientations

left-to-right, top-to-bottom

other

calendar systems

Gregorian

non-Gregorian

• Support for non-Gregorian calendars. (@@@ - for example, Julian?)

Spell checking

spell check events

spell check event titles / headlines

spell check event notes

spell check other event fields

spell check calendars

spell check all the events in a calendar

spelling and grammar panel

menu item that brings up a panel

panel is non-modal

panel checks spelling

panel checks grammar

panel explains spelling mistakes

panel explains grammar mistakes

panel offers suggestions

panel uses standard dictionary

panel uses user-defined dictionaries

panel imports ".DIC" format dictionaries

panel preferences

• spelling and grammar panel offers various preferences about what to do and what to ignore (e.g. ignore words in UPPERCASE)

highlight spelling errors

• example: in an event, all the words with spelling errors are underlined in red

right-click suggestions

• right-clicking on a highlighted word will bring up a pop-up menu with spelling suggestions

fix spelling as you type

• example: type "thier" and have it show up as "their"

type-ahead

• example: "Could Chandler have the ability to also look up and "display" words matching the partial words as I type them? This might be an alternative to a post-typing verification that the word I just typed is in the dictionary. Example: "T" does not resolve, "TW" resolves to (two, twenty, twin, twins, twice, twonky, twouble), "TWI" resolves to (twin, twins, twice).

Auto-save

• In Chandler, the user never saves documents. Whenever the user makes any changes, those changes are automatically saved, right away.
• example: Peter opens an event in an event editing window or pane. In the notes section, Peter starts to type: "Remember to bring crayons and". Just then Peter gets a phone a call, and after that he has to leave to pick Sara up from school. By the time he gets home again, Jack has closed Peter's Chandler session, and is using the computer to play video games. But tomorrow when Peter opens Chandler again, the note will be just the way he left it.

AccessibilityJunglePage^?

• The Chandler client should be accessible to the disabled.

Scale

Users per installation

• A Chandler installation should be able to handle the calendaring needs of an organization with NNN active users, where NNN is:

20

200

2,000

20,000

200,000

Users per server

• A Chandler server should be able to handle the calendaring needs of NNN active users, where NNN is:

50

500

5,000

Users per meeting

• A Chandler server should be able to schedule meetings of NNN users, where NNN is:

20

200

Accounts, Authentication, Authorization

use Kerberos authentication

use LDAP authentication

use Windows domain authentication

use Chandler authentication

strong encryption for passwords

• Chandler's password store uses strong encryption

no plain text password traffic

• Chandler does not transmit passwords in plain text.

flexible account ids

• Be able to use any arbitrary string as a Chandler account id.

Personal Calendaring Features

• This section is for features that a single person would use to keep track of their own schedule.

Calendars

• See MultipleCalendars

users can have multiple calendars

• example: a user has separate calendars for "work", "home", "kids school", "birthday calendar"
• example: user also subscribes to "US holiday calendar"

calendars display events

calendars display non-event items

• example: a calendar that displays a set of web log entries
• example: keeping meeting minutes organized by date

one event in two calendars

• an event can appear in more than one calendar

calendars have "skins"

• Each calendar can have a "skin", so that when a user opens calendar A it just looks different from calendar B.

calendars have event templates

default event fields

• example: By default, any new events created in the "Chemistry Department Colloquia" calendar will have a location of "Wilson lecture hall"

required event fields

• example: When you create a new event in the "Women's Soccer Team Schedule" calendar, you are always asked to enter the name of the opponent.
• example: When you create a new event in the "Chemistry Department Colloquia" calendar, you are always asked to enter the name of the speaker.

calendar info

name

• the name of the calendar
• example: "Kepler's book club meetings"

owner

• the user who owns this calendar

alternate owners

• a list of other users with owner permission

categories

• the categories that this calendar belongs in. Users can put calendars in any number of categories, and create hierarchies of their calendars.

defaults

default view

default event location

default event resources

default event invitation list

default event categories

users can create calendars

from templates

• Users can create new calendars from templates.

by cloning

• Users can create new calendars by cloning other calendars, either their own calendars, or any published calendar that they can see.

from a simple entry form

• Users can create new calendars using a simple entry form

from an exhaustive entry form

• Users can create new calendars using a simple entry form

Items in Calendars

Ad-hoc items

• See ItemsInCalendarViews
• The user should be able to view any Item with a date/time or date/time range in any of the Calendar View Types.
• example: Patrick Logan's use case: Highlight on a calendar the days where engineering change orders related to product X exceed some threshold. lists: Patrick Logan's use case

birthdays and anniversaries

• example: Abby has her calendar view set up to show her the birthdays of all her "friends" and "co-workers" in her contacts list, but not the birthdays of everyone else in her contacts list.

show birthday ages

• example: Tony's birthday appears on my calendar as "Tony's 8th birthday", rather than just "Tony's birthday"

Daylight Savings Time (DST) transitions

• example: When Jim looks at his calendar for April 2003, he sees that DST will start on April 6.

ad-hoc items in any calendar view

just ad-hoc items with a special "calendar start date"

any user specified date attribute

user queries for ad-hoc items

• A user should be able to create an arbitrary query against the repository that generates a list of items that will be viewed in the calendar view.

Events

• See CalendarEventEditing

Event info

name / headline

location

• This is where the event will be.
• This can be just a text string "Conference Room A"
• This can also be a link to a location item.

resources

• Automatically reserve some resource for this event. For example, reserve conference room B.

event time

time zone start time end time duration travel time

blocking vs. non-blocking

• If an event is blocking, then no other blocking events can be scheduled at times that overlap.
• If an event is non-blocking, it can be scheduled any time.

owner

owner

• the user who owns the event

alternate owners

• a list of other users with owner permission

invitees

required invitees optional invitees cc-invitees

invitation responses

• lists of who accepted the invitation, and who declined, and who delegated, and when all these things happened

contacts

• This can be any old contact, not necessarily related to the invitees.

phone numbers

• This can be any old phone number, not necessarily related to the organizer, or the invitees, or any contacts

priority

categories

• a collection of all the categories this event belongs in

recurrences

reminders

• a collection of all the reminders that should be sent

notes

links to other items

user-defined attributes

Creating & Editing Events

Create events without filling out a form

Create events using a simple entry form

Create events using an exhaustive entry form

Create events from templates

meeting template vacation template party template entertainment template custom templates

Create events by cloning other events

Reserve resources

• Support for booking resources such as rooms and equipment

Edit all event info

Smart-parsing

• When an event does have structured information (like the name of someone who's also in the address book), people don't go through the trouble to link to the address book entry even if their application supports it, they just re-type the name into the event subject. It would be great if the application recognized the name, with minimal overhead for the user. This kind of 'smart parsing' behavior can be found in other applications (e.g. the 'to' field in your email editor, Agenda's recognition of dates and times, SBook's pim information).
• Example: the user could edit the 'headline' of the event in place (e.g. "Dinner with Caroline"). Chandler's 'smart parsing' could recognize that "Caroline" is a person in your address book (or one of several "Caroline"s in your address book). Chandler could add "Caroline" as the value of an property associated with the event.

recognize names of contacts

• example: "Caroline"

recognize dates

• example: "24 Jan 1908"

recognize relative dates

• example: "Friday"

dumb-parsing

• When smart-parsing fails, the user should always be able to get the same results manually. For example, in the event "dinner with Caroline", the user might highlight word "Caroline" and then tell Chandler to link it with a specified contact item for Caroline.

un-parsing

• The user should be able to easily undo the results of any parsing.
• example: Sharon clicks in day view to create a new event, and she types "Go to the john". The Chandler smart-parser automatically creates a link from "john" to the contact in Sharon's address book for "John Greene". Sharon selects the new link and deletes it. Chandler remembers this explicit "un-parse", and Chandler is careful not to accidentally re-parse the field and create another new link to "John Greene"

Holidays

• See CalendarHolidays

Add holidays by group

• company holiday calendar
• holidays for a country, religion, etc.
• international (note: timezone issues with international holidays)

Remove holidays by group

Edit or delete a holiday

• same behavior as event

Create a holiday

• same behavior as event

Create a group of holidays

Custom event fields

Repeating events

• See RecurringEvents

Create a repeating event

Simple repeating event interface

• for common repeating event patterns.
• examples: every day, every other day, every week, every other week, every month, every year, this day every month, this date every year.

Full-featured repeating event interface

• for expressing any possible recurrence pattern. Should support any recurrence pattern that can be expressed in RFC 2445.
• examples: the third Wednesday of every month, every 12 hours, every Monday except next Monday

Edit a repeating event

cancel repeating events move repeating events which instances to change?

• UI defaults to never changing history.
• UI makes it possible to change history.
• UI makes it easy to pick what event to change.
• Example: Mignon moves the book club meeting from Monday to Tuesday. The UI makes it easy specify exactly which meetings should be moved:
  • Just this week's meeting?
  • All future meetings?
  • All past and future meetings?

Expiration notification

• A user should be able to get a notification when a recurring event expires

Non-ending recurring events

• iCalendar supports this. See section 4.3.10 of rfc 2445.

Time zones in recurring events

• for recurring events, store the time zone of the event
• See http://lists.osafoundation.org/pipermail/design/2003-January/001636.html

Event Templates

• notes: "I also suggest that we enable the user to create event templates. That way, when we have a type of event that is not unique in our experience we can set up a template. Let's say you're planning a party--you could have a checklist of objects that need to be associated with the event. A good memory prompt which only needs to be created properly the first time you use it." ... "Also, different users can trade event templates" lists: David Neeley

selecting an event template

creating an event template

deleting an event template

Event Sets

• See CalendarEventSets
• Events may occur in sets, with a 'master' event and one or more related events
• example: A series of events in a conference
• example: Commute time before and after an event

indicating events in a set

* some affordance for visually indicate the relationship between events

creating event sets

merging events into a set

breaking up a set

Categories

Assign items to categories

Display items based on category

• example: all "urgent" items appear in bold
• example: all "work" items appear in red

Create new categories

Create hierarchies of categories

Assign display properties to categories

Tasks

• See CalendarsAndTasks.

Task info

name

status

• open, closed, etc.

priority

task type

due-date

plan-to-do-on date

tentative start date

set-up and tear-down times

time estimates

time estimate estimation date estimated by estimate confidence percent complete actual time

delegation

owner assigned by accepted re-assigned to

sub-tasks

dependencies

preconditions (predecessor tasks) successor tasks

required resources

notes

links to other items

• e-mail messages, IM conversations, etc.

user-defined attributes

Viewing Tasks

Tasks on calendar days

Links

• You should be able to place a task in the calendar, and have the resulting calendar entry linked to the task in the task list, so that you can edit in either place and have the info updated.

Due dates

• Tasks with associated "done by" dates should be reflected on the calendar.

Advancing tasks

• Tasks that haven't yet been done should advance from day to day to on a calendar

task-time blocks

• calendar with task-time tentatively blocked in around appointments (i.e. would show tasks as a single block with sub-divisions for particular tasks) source: Mike C. Fletcher

To-do task view

Task view in calendar view

• To-do task view can be optionally included inside calendar view

Task list

• lists (trees) filtered by status, priority etceteras, filter by project, by task sub-type (e.g. all phone calls to be made) or by relation X (RDF) source: Mike C. Fletcher

Task tree

• lists (trees) filtered by status, priority etceteras, filter by project, by task sub-type (e.g. all phone calls to be made) or by relation X (RDF) source: Mike C. Fletcher

Task filters

• lists (trees) filtered by status, priority etceteras, filter by project, by task sub-type (e.g. all phone calls to be made) or by relation X (RDF) source: Mike C. Fletcher

Complex Views of Tasks

• display topologically-sorted (dependency-resolved) tasks as list, flow-chart, critical-path, etceteras source: Mike C. Fletcher

Editing Tasks

Assign a task

via Chandler via iTIP/iMIP

Accept an assigned task

via Chandler via iTIP/iMIP

Break down a task

• Break down a "task"-item into a series of sub-tasks (original says "write thesis", giving 8 months as timeline, you want to break it down into sub-tasks, such as "procrastinate" and "worry"). source: Mike C. Fletcher

Dependencies

Dependencies on tasks

• Establish dependency relationships between tasks/sub-tasks source: Mike C. Fletcher

Dependencies on non-tasks

• Capture trigger dependencies (write up an invoice and phone Phil when Tim replies to this email) source: Mike C. Fletcher

Time estimates

• Capture time estimates for a task (and allow for editing those) source: Mike C. Fletcher

Sub-tasks

• Tasks can have sub-tasks

Due Date

• Capture date anchors/restrictions (needs to happen next week, due date is Friday, do it before Monday) source: Mike C. Fletcher

reminders

• impending due dates automatically trigger reminders (e-mail reminders, IM reminders, etc.)

Plan-to-do-on Date

• Capture date anchors/restrictions (needs to happen next week, due date is Friday, do it before Monday) source: Mike C. Fletcher

Tentative Start date

• Allow for tentatively entering start-dates/times source: Mike C. Fletcher

Set-up & tear-down times

• Capture set-up/tear-down requirements, preferably available both for types and instances (e.g. phone-calls take no set-up time, while painting takes 20 minutes set-up and 30 minutes tear-down, but this particular painting will take 3 hours to set-up because I need to get the donkey to the studio, so don't schedule it for any period less than 8 hours) source: Mike C. Fletcher

Resource requirements

• Capture resource-requirements for a task (uses relationships) (allow potentially for scheduling external resources eventually to allow a scheduled task to be accomplished (or the inverse, for finding out when you can work on a task)) source: Mike C. Fletcher

Priority

• Capture criticality/priority of task (how important is it that it get done, how important that it get done on time, how important that a particular resource be available, etceteras) possibly inherit this from related objects source: Mike C. Fletcher

Actual time spent

• Capture real-time expenditures (journaling) source: Mike C. Fletcher

Percent complete

• Capture completion fractions/percentages source: Mike C. Fletcher

assignment

• Helen can assign a task to Angie.
• Angie can reassign the task to Ben.
• Ben can accept the assignment.
• Acceptance and reassignment automatically generate emails to the appropriate person, telling them about the acceptance or reassignment.

Task types

Smart parsing of task type

• Recognize common/registered task-types from item text and offer to add appropriate properties source: Mike C. Fletcher

Sub-types

• Capture task-sub-types (call vs write vs test vs registered-type-x, each of which is likely to be a different template of needed properties) source: Mike C. Fletcher

Scheduling preferences

• Capture user preferences with regards to block-lengths for particular types, preference for whether to schedule items (of a type) early or late in the day etceteras source: Mike C. Fletcher

Add tasks to an item

• Add tasks to an item (if is a "task", these would be sub-tasks, if not, the item would likely be promoted to the status of a "task" (add a type-declaration)) source: Mike C. Fletcher

Daily task reminders

• You can get daily e-mail reminders with a list of the day's tasks

Task workflow

status set by plug-in engine

• "Ideally the task status is controlled by a plug-in workflow state engine, with scripting to set other fields when one changes. The (ideal) end result is a issue tracker such as issuezilla (based upon bugzilla, the mozilla bug tracker)" - see http://lists.osafoundation.org/pipermail/design/2002-October/000395.html

Scheduling Tasks

Schedule whole task

• Whole-duration (drop tasks into a calendar, select time from widget, or whatever property you want) source: Mike C. Fletcher

Schedule time on task

• Partial duration -- schedule a block of time to work on a task that is less than the duration of the task (possibly provide mechanism for "continuation" placing as well, (see publishing software story-placement-continuation for useful precedent, click on a widget at the end of the task representation and you can then drop the continuation somewhere else)) source: Mike C. Fletcher

Auto-schedule

• Auto-schedule -- attempt to schedule tasks from a todo list across some time-frame (using some algorithm (At the very least this will require a constraint-solver mechanism)). source: Mike C. Fletcher

Look-for-opening

• Look-for-opening -- search the calendar for a time-block >= estimated time (allow user to immediately respond to requests from clients regarding whether they can accomplish a task in a given timeframe)

Auto-Re-schedule

• Re-scheduling of un-completed auto-scheduled items source: Mike C. Fletcher

Group Tasks

tasks for anyone

• example: Sally creates a task called "Take out trash". She then "invites" everyone in her lab to the task, just like she would invite them to an event. Anyone can mark the task as done, and then it counts as done for everyone.

tasks for everyone

• example: Hank creates a task called "Sign condolence card for Alex". Hank invites everyone in his department to the task. Each person can mark the task as done, and the task counts as done when everyone has marked it as done.

Record keeping

Time tracking

• Example: Jane the lawyer spent 0.5 hours today working on the Acme patent application. She wants to be able to make a note of that in her calendar.

Logbook

• Example: Joe strives to back up his hard drive about once a month. But he used to always forget when it was he last backed it up. So now, every time he backs up the computer, he makes an entry in his calendar.

Journaling

Time

Time zone support

user sets the time zone for an event

• See SimoneDuChampScenario - "Chandler allowed her to specify the time zone of appointments"
• See http://lists.osafoundation.org/pipermail/design/2002-November/000959.html
• See http://lists.osafoundation.org/pipermail/design/2002-November/000960.html

user sets the time zone for a Chandler client.

• example: Sally just flew to London with her latop. She's working offline, because her London hotel is still in the dark ages. She opens Chandler and changes the time-zone. When she left on her trip, the event "teleconference with home office" was scheduled for 4:00 pm. Now it appears in her calendar at 11:00 am.

user sets the time zone for a few days

• example: "I may be traveling to New York for a business trip and I have an 11:00am meeting in New York. Since I live in San Francisco I don't want to have to enter my appointment as being 7:00am, I want to enter 11:0am-EST. And while I am still in San Francisco, I want it to still appear on my calendar as 11:00am-EST because in my head I want to be thinking of it as a pre-lunch meeting (not a pre-breakfast meeting, that a 7:00am display would imply)" -- see http://lists.osafoundation.org/pipermail/design/2002-November/000959.html

user sets the time zone for a view

• See http://lists.osafoundation.org/pipermail/design/2002-November/000971.html

user views calendars in two time zones at once

• See SimoneDuChampScenario - Chandler "let her display one timezone's times along the left of the screen and another timezone's times (appropriately shifted) along the right side." ... "Chandler needs to have a View that supports independent time scales on either side of the window"
• see http://lists.osafoundation.org/pipermail/design/2002-December/001363.html
• see http://lists.osafoundation.org/pipermail/design/2002-November/000960.html

time zones in recurring events

• for recurring events, store the time zone of the event
• See http://lists.osafoundation.org/pipermail/design/2003-January/001636.html

Daylight Savings Time (DST)

Chandler knows all the DST regimes

• For each time zone, Chandler knows whether that time zone switches back and forth to DST every year. Chandler also knows the dates and times that the DST switches happen. For example, in the United States, in 2003, DST began on April 6 at 2:00.
• Here's an example of a chart that shows DST transition times - DST transitions

viewing DST transitions

calendar views show DST transitions

views do not show the missing hour when DST starts

views do show the extra hour when DST ends

events at DST transitions

the missing hour when DST starts

• A user cannot schedule an event in New York at 2:30 on April 6, 2003.

the extra hour when DST ends

• A user can schedule an event in New York on Oct 26, 2003, and the event can last from 1:30 to 1:15, and have a duration of 45 minutes
• A user can schedule an event for 1:30, and be able to know which 1:30 the event is scheduled for.

Dates and Times

Cross-day Events

• "Chandler should provide the ability to enter and display, in a meaningful manner, scheduled events that begin and end on seperate days. Daily, weekly and monthly views should handle these sorts of events in a clear and easily understandable manner." ... "Outlook handles recurring events that span days by breaking them up into seperate events for each day. This solution creates unexpected behavior when displaying monthly views because the event appears to be two seperate events."

Partial dates and times

Date and time

• Events can have specific dates and times.
• Example: "Dinner with Marty" at "28 Feb 2005, 4:30 pm"

Date but no time

• Events may have only dates.
• Example: "Dry cleaning ready" on "28 Feb 2005"
• All day events: Events that have dates but not times are sometimes called "all day events". For example, the holiday "Christmas" is an all day event.
• Some software apps handle all day events by record the event as having a start time of midnight and a duration of 24 hours. That leads to bugs when you view the event from a different time zone.
• See http://lists.osafoundation.org/pipermail/design/2002-November/000956.html

Dates with no day field

• Tasks may have vague "done by" dates.
• Example: "Backup computer" should be done in "Feb 2005"
• Example: "Release 1.0" scheduled for "Apr 2006"
• Example: "Release 2.0" scheduled for "2007"

Dates with no year field

• Events may have no year
• Example: "Ursula's birthday" is on "March 22"
• Example: Halloween is on "Oct 31"

network time sync

• "A system time sync to a network source would be a very nice option. It's one less program we need for those of us who already run them on our systems, and for those who don't, well, they will now." lists: Bruce Dykes

Sifting through info in views

Searching

Keyword search

Full text search

Search within a category

Search across multiple calendars

search for schedule conflicts

search for events

search for items in calendars

search for calendars themselves

Categories

View events by category

Search events by category

Filtering

• See FilteredCalendar

view a calendar through a filter

• allow users to look at calendars based on filters so they could easily look at, email or print a project calendar, a birthday's calendar, a meetings calendar, a co-worker availability calendar, etc.

create new filters

filter by field

• example: Alan is looking at the calendar of scheduled practice times for his daughter's rugby team. Alan creates a new filter, "Greg's practices", that only shows the practices (events) that were created by Greg

filter using text search

• example: Helen subscribes to the calendar for the summer lecture series. Helen creates a filter that filters out any event that includes the word "war" in any field.

save filters

• Users can give names to filters, and save them.

combine filters

• example: Leila creates a "no vacation talks" filter to filter out all the departmental talks that occur on days when she'll be on vacation. Then she creates a "no weekend talks" filter to filter out all the departmental talks that happen on weekends. Then she creates a filter called "Talks I might actually go to", which includes only events that survive both "no vacation talks" AND "no weekend talks". Later she creates a similar filter, but using an OR combination instead of an AND.

publish filtered calendars

publish the filters themselves

navigate in a filtered calendar

• after a user applies a filter to a calendar, the user can navigate through various views of the calendar (day, week, month) with the filter applied

Queries

views show query results

queries can be built from other queries

Overlays

• users can show a second calendar overlaid on top of the calendar you are viewing

Reports

Report customization

• (data extraction from past and future meetings)

Deleted events

• A user should be able, optionally, to see all the deleted events that used to be in calendar.
• example: Walter shares his calendar with all his long time companion Ed, who has full edit privileges. Walter is sure that he had a dentist appointment on Tuesday, but now he can't find it. He wants to make sure it wasn't deleted accidentally by the clumsy yet lovable Ed.

Printing

Printing

• See CalendarPrinting

date range to print

• allow user to specify date range to print

Supported Printers

black and white

color

Print Preview

• be able to preview any print job

Headers and Footers

Customizable headers and footer

Standard view print formats

• Be able to print from any view, and get a WYSIWYG print-out.
• example: print month view just as it appears on your screen

Special print formats

• Special print formats with printer-friendly versions that may differ from calendar "views"

Daily

Weekly

Bi-weekly

Monthly

Trifold

DayRunner^? page formats

Franklin DayPlanner^? page formats

Notifications

• See CalendarReminders. See CalendarNotifications.

Reminder timing

• A user can set the reminder to go off before an event begins. The user picks how far in advance the reminder should go off.
• example: a reminder 5 minutes before a meeting
• example: a reminder a week before a birthday
• example: a reminder 6 months after a dentist's appointment

Reminder delivery channels

email reminders

• plain text
• HTML

IM reminders

Jabber

dialog panel reminders

pager reminders

• send a text message to a pager

cell phone reminders

• send a text message to a cell phone
• call a cell phone, and leave a message

phone reminders

• call a phone, and leave a message

sound reminders

• have Chandler make a sound
• provide a list of alternate sounds
• allow user to load new sounds

OS specific reminders

• example: XP system tray
• example: OS X Doc

Reminder request granularity

• all events of some type (examples: "Birthdays")
• all instances of a repeating event (example: "Pay monthly rent")
• some specific event (example: "Pay monthly rent" next month)

Background reminders

• Chandler reminders should always get delivered, even when the user hasn't intentionally launched the Chandler app.
• example: Kurt uses Chandler on his home computer. He has a local repository, and never connects to any server. He launches Chandler, creates an event for sometime next week, and asks to get audio reminder an hour before the meeting. Next week he is sitting in front of his computer, but he doesn't happen to have Chandler running. He should still get the audio reminder, provided by some little invisible Chandler background task.

Last event in a series

• A user should be able to get a notification when a recurring event expires

Preferences

• See CalendarPreferencesOptions.
• (@@@ -- Discuss preferences for calendars (per view, globally for the calendar, etc.). )

default initial view

• The user can specify which view appears by default.
• example: Albert always wants to see new calendars appear