Re: [Design] Joel on Software article comparing AJAX Calendar products

[Mimi Yin]

Hi Jeffrey, Let me rephrase your suggestion and see if I understand it: We could assign a timezone to the end time of a flight, but still display the entire event AS IF the whole thing was in the timezone of the start time. I think before supporting this use case, we would want to revisit the widget we use for setting timezone. Having two bulky pulldowns for timezone in the detail view all the time, when most of the time, feels like overkill. I agree in principle that we should support this use case, how we do it in a way that maintains the integrity of the detail view design requires a little more creativity. Some ideas: Less obtrusive iconic widgets (ie. globe) to pop-up a Timezone selector for start date/time and/or end date/time (to the right of the date/time fields).  Harder thing to do (deferred from 1.0 timeframe):  "Type as much data into the field as you need" approach to entering dates and times. A single field could support either: + A date/time with no timezone info : January 10, 2006 @10PM + A date/time with 1 timezone: January 10, 2006 8-12PM PST + A date/time with 2 timezones: January 10 Mimi On Feb 9, 2006, at 9:32 AM, Jeffrey Harris wrote: Hi Mimi, It seems like what's actually needed is the ability to assign multiple timezones to the same calendar canvas. Monday I'm in PST, Tuesday after 3PM I'm in EST. Otherwise, separate timezones for start and end times of a flight could result in a flight arriving before it departs on the calendar (which persists in a single timezone). Persisting a single timezone per event isn't the only option.  It would add a little more complexity, but we could certainly persist an end time timezone, if we wanted to. The calendar wouldn't get confused about how to render the flight, the calendar area occupied by the event would render the same way it does now, representing the true duration of the flight in the current timezone. In the detail view this would mean having two timezone drop downs, one for start, one for end, changes to start change end. This is another use case for a Floating calendar which is agnostic to timezone. Hmm.  I do think this is an argument in favor of a floating time UI for relatively stationary users, but I think so because I think doing so gives us more leeway to make the timezone UI more complex. I think the Joel Spolsky and Esther Dysons of the world really want complete timezone features.  Since we're going to have a timezone-less option to lower complexity for some folks, I'd argue we ought to go ahead and really implement timezones full on for globe-trotters. Sincerely, Jeffrey _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "Design" mailing list http://lists.osafoundation.org/mailman/listinfo/design

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design