[Design] [Cosmo] Proposal to defer Time zone work to Post-Preview

[Mimi Yin]

What we have today: We can figure out the system GMT offset. However  
we can't figure out what the actual time zone is.

The bad news is that this complicates workflow. (See below for a  
laundry list of all the workflow issues.)

The good news is that Bobby and I agreed that all of this work can be  
deferred to post-preview. This means that for Preview:
+ We don't need to change the sign-up workflow to force users to pick  
a default time zone.
+ We don't need to add a time zone pulldown to the chrome of the UI.
+ We always display events on the calendar canvas wrt the system GMT  
offset; and
+ We don't allow users to change that.
+ Non-floating events display a time zone abbreviation next to their  
start-times in the event lozenge.
+ Newly created events are automatically Floating unless otherwise  
specified by the user.

The downside: Admittedly, it would be nice to have the time zone  
workflow worked out for Preview as it is a point of differentiation  
with other web calendar clients. However, for Preview we're focusing  
on Stamping, the Dashboard and the Casual Collaborator scenarios as  
our way to differentiate ourselves from our competition.

Am I missing anything? Are there other issues to consider when  
prioritizing time zone work?

Mimi

===

Workflow issues having to do with time zones.
+ What do we display by default in the ticket view if a collection  
contains time zone information?
- Floating canvas?
- Just the GMT offset?
- Assign one of the possible time zones, based on the GMT offset?
- Nothing, force the user to assign a real time zone.

+ If we provide a time zone selector, do we display:
- All time zones? That's a lot.
- A set of 5-6 'common' time zones and dynamically add all time zones  
that match the system GMT offset?

If we, by default, display events on a canvas defined by the system  
GMT offset and provide a time zone pulldown so that users can assign  
a real time zone to the calendar canvas...
+ When users switch away from the GMT offset, can they switch back to  
it?

What about the time zone pulldown in the Detail View? What time zone  
is automatically assigned to newly created events?
- Floating?
- GMT offset? (Bobby says NO!)
- Assign one of the possible time zones, based on the GMT offset?

Other open issues
+ Do we want to force users signing up for an account to assign a  
time zone? So that we avoid the entire GMT offset problem for users  
with accounts?

===

Other improvements to Time zone Workflow that we should also defer to  
Post-Preview:
+ Ability to show / hide full list of time zones
+ Ability to dynamically add time zones to the time zone pulldown
+ Ability to explicitly add time zones to the time zone pulldown
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20070604/de5703b3/attachment.html