Hi Ted...
I believe the rationale is the latter: trade time zone features for
more time to work on dogfood and other bugs and/or testing of new
dashboard/stamping features.
Mimi
On Jun 4, 2007, at 2:54 PM, Ted Leung wrote:
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
