I agree with Mimi and probably everyone else that Timezone
functionality is lower priority than Dashboard stuff, and that we
probably won't be able to do ALL of what is currently slated.
However, I do think there are ways to stage the TZ functionality in
ways that provide value to our users. Something like:
1) Add timezone picker (as is) to calendar canvas, with the system
offset as default. Doesn't affect event creation, which still would
float by default, unless they choose a "real" timezone
2) Add timezone to sign up
3) Improve timezone picker
I'm not trying to back out on what we discussed yesterday, I'm just
saying that I don't see the point in saying right now what we're
postponing, when we can instead prioritize and do what we are able to
do.
I also think that the issues you bring up are tricky to nail
perfectly, but if we don't it won't be that big a deal to the user as
it would be to us. In other words, we can pick one of the
possibilities, run with it and get some feedback from people.
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.
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?
Why not?
- Just the GMT offset?
Even better. This is the user's system timezone, which is usually
what people want to see their events in. It's how stuff appears now.
- Assign one of the possible time zones, based on the GMT offset?
No, for reasons I think we are are familiar with.
- Nothing, force the user to assign a real time zone.
Why would you do that?
So I don't see this as an issue - we can just choose one and run with
it.
+ If we provide a time zone selector, do we display:
- All time zones? That's a lot.
For now yes.
- 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?
Sure, or make them choose a "real" timezone.
What about the time zone pulldown in the Detail View? What time
zone is automatically assigned to newly created events?
- Floating?
Yes, unless they've chosen a real timezone in the picker.
- GMT offset? (Bobby says NO!)
I don't like creating events with these "fake" timezones. It will
confuse people and cause problem when DST rolls around and the offset
doesn't change.
- Assign one of the possible time zones, based on the GMT offset?
Please no.
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?
Yes, eventually. But I think it would be ok if we didn't for a while.
===
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
