Status Throwing this out to engineering for feedback

Goals

• Play around with ideas that will simplify the date/time widget (fewer fields)
• Make it clear to users that they do not have to fill out complete date/time information
  • Leave it blank
  • Just date
  • Just date and @time
• Make the first iteration of what we implement relatively low cost
• Design must ultimately be internationalizable with off-the-shelf stuff
• Instrument the date/time widget to see how people are using it, if they're using it in the ways we had hoped

Problem we're trying to solve

It would be nice to try an iterative approach coupled with instrumentation to try and figure how we can provide users with a date/time widget that allows them be more "squishy" with their calendar scheduling than calendar date/time widgets currently allow. The theory being that squishi-ness is one of the things paper calendars are good at (I need to do this some time around the 3rd week of March) and that the lack of squishi-ness in electronic calendars is what prevents most people from fully using electronic calendars.

Another way to put it is that electronic calendars only allow for 2 sizes of scheduling blocks. Events on a specific day with a specific duration OR All-day events that span 1 or more days. Paper calendars are a little more analog in that they provide users with a continuum of scheduling block options: From specific durations on specific days to Some time this day to Some time in these few days to Some time this week, month, few months, year... This is essentially because you can scribble whatever you want in the margins. So the question for us is...how can we simulate that in a relatively low-cost way?

Proposal

Basic premise is that users fill out as much information as they need to. If they leave certain fields blank, those fields will disappear from the detail view unless the user goes back to edit the date/time widget.

• Events don't need to have specific time information unless the user explicitly decides to fill it in.
• Events don't need to have duration unless the user explicitly decides to fill in an End time.
• Events don't need to display an End date unless the user explicitly decides to fill in an End date that is different from the Start date.

We hope that this will address the needs of users who find electronic calendars to specific and cumbersome to use right now to either schedule their own life or schedule meetings with others, by allowing them to be a little more squishy with the items they put on their calendar.

Note Features below are divided into Basic (B), Nice to have (NTH), Really nice to have (rNTH), which might be a good way to stage implementation. Just to summarize:

• B Basic features encompass the abillity display example date/time text and leave fields blank
• NTH Nice to have features show and hide blank fields depending on whether the user has filled them out or not. It seems like users might be confused by having example times that won't actually apply without a little more explanation. How about an ellipsis or a question mark (along with greyness) that disappears if you click in the field? -- JeffreyHarris - 26 Feb 2005
• rNTH Really nice to have features automate the process of filling out the End date and End time fields by setting defaults to auto-calculate End dates and End times to be respectively 1 day and 1 hour after the Start dates and Start times.

• B Separate fields for Start date, Start time and End time (no end date, end date is calculated)
• B All 3 fields are visible if user leaves date/time field blank
• B All 3 fields are prepopulated with "example" text in grey: Today's date. Next hour to the Next next hour.
• DateTime_WhatTimeIsIt.gif:
  

• Anytime this day
• NTH If user only fills out Start date and hits enter, the Start time and End time fields disappear
• NTH Start time and End time fields reappear if user clicks or tabs back into Start date field
• DateTime_AnytimeThisDay.gif:
  

• This day @this time
• NTH If user only fills out Start date and Start time and hits enter, the End time field disappears
• NTH The End time field reappears if user clicks back into either the Start date or Start time field
• DateTime_ThisDayAtThisTime.gif:
  

• This day from this time to that time
• rNTH If user changes the Start time field, the End time field's example text should automatically recalculate to be an hour after the new Start time.
• rNTH If user tabs or clicks into the End time field, the sample text should become selected as live text and the user can either type over it or hit enter to confirm that it is correct.
• B Since there is no End date field, it would need to be calculated based on the Start date. (ie. Feb 28, 2005 10PM to 2:15AM actually has an end-date of Mar 1, 2005.) This means that users will NOT be able to create events that last 24 or more hours. Unless it's an All Day event. The likelihood of longer than 24 hour events that aren't All Day does seems really low. We might want to have a menu item that opens a more heavy weight widget for all possible start and end datetimes, just for completeness. -- JeffreyHarris - 26 Feb 2005
• DateTime_TimeWithDuration.gif:
  

• All-day this day
• B If user checks the all-day box, the Start time and End time fields should disappear.
• B An End date field should appear with "example" text that is 1 day after the "example" or live text in the Start date: field. Feb 28, 2005 to Mar 1, 2005.
• NTH If user hits enter after filling out the Start date field, the End date field should disappear.
• NTH If user clicks or tabs back to the Start date field, the End date field reappears.
• DateTime_AllDayOneDay?.gif:
  
• DateTime_AllDayOneDayConfir.gif:
  

• All-day multi-day
• rNTH If user changes the Start date field, the End date field's example text should automatically recalculate to be a day after the new Start date.
• rNTH If user clicks or tabs to the End date field, the sample text should become selected as live text and the user can either type over it or hit enter to confirm that it is correct.
• DateTime_AllDayMultiDay.gif:
  

0.6 Proposal without Anytime event feature

This is an alternate proposal if/when we decide to cut the Anytime feature from Kibble. Most of the widgetry is the same as the proposal above. The onyl difference is that without the notion of an Anytime event, we can simplify the semantics of what different formats represent.

• Date, Start time and End time are still separate fields
• The appearing and disappearing of unfilled out fields described above still applies
• The auto-entering of sample text in grey described above still applies
• The auto-selection of sample text as live text for End times and End dates described above still applies

• Users can enter the following date/time formats to get an event to appear on their calendar
• Date: Feb 28, 2005 creates an all-day event
• Date and Start time: Feb 28, 2005 6:00PM creates a "this day @ this time" event
• Date, Start time and End time: Feb 28, 2005 6:00PM to 7:00PM creates a "this day from this time to that time" event

• If users check off the multi-day option, a second set of date/time fields appears
• If users only fill out the Start date and End date: Feb 28, 2005 to Mar 1, 2005, they create a multi-day, all-day event
• If they fill out all fields: Feb 28, 2005 6:00PM to Mar 1, 2005 7:00PM, they create a multi-day with duration event
• There are no "multi-day @ this time events"

• 01ALT_DateTimegif.gif:
  

• 02ALT_DateTime_Allday.gif:
  

• 03ALT_DateTime_Allday-.gif:
  

• 04ALT_DateTimeDuration.gif:
  

• 05ALT_DateTime_Multiday-.gif:
  

• 06ALT_DateTime_AlldayMultiday.gif:
  

• 07ALT_DateTime_MultidayWithTim.gif: