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

[Ted Leung]

Hi MImi,

I've no objections to postponing work, but I want to be clear on why  
you want to postpone here.    Did you and Bobby feel that the amount  
of time needed to solve these problems well is beyond the amount of  
time that we originally planned for?  Or do you simply want to trade  
timezone features for more time to work on dogfood and other bugs?

Ted

On Jun 4, 2007, at 12:08 PM, Mimi Yin wrote:

> 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/c5277a1e/attachment.html