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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
