[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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20060209/0a62184b/attachment.htm