Hi Katie,
Perhaps as a way to address some of the concerns that Jeffrey and
others have voiced (which are very real), we can provide a prompt to
users both on the publishing and the subscribing ends of the sharing
workflows.
If an user doesn't not have timezones turned on in Chandler and is
trying to publish a collection or free-busy calendar, we can pop-up a
dialog saying:
===
Will you be sharing this collection with someone in a different
timezone than you? If you are, we recommend that you assign a
timezone to your events and alarms.
[Ignore] [Okay]
Clicking Okay will turn on timezone support and assign a default
timezone to their calendar canvas that the user can change.
===
On the subscribing end of the workflow (and this would work for both
Chandler and Cosmo CC users with accounts, we provide a notice that
says:
This collection contains timezone information, we recommend you turn
on timezone support for optimal viewing.
===
This addresses several concerns at once:
1. It makes the way timezones work transparent to the user (no hidden
timezones that the user can't see).
2. It provides the do-the-math-in-your-head people a way to keep
their lives timezone-free ;o)
2. It alerts users when they're about to engage in anti-social
sharing behavior.
Is this feasible for Preview?
Mimi
On Dec 6, 2006, at 4:38 PM, Katie Capps Parlante wrote:
Hi Mimi,
Thanks for the summary. I'm going to restate some of what you and
others have said -- to make sure that I understand. All y'all can
correct me if I'm off here.
As I understand it, we have two cases where floating events/
timezone events/sharing collide and potentially create problems.
Floating view of timezoned events case:
+ The *calendar canvas* (or view, in the mvc sense of view) does
not have timezones turned on.
+ Events in the calendar being shared have multiple timezones.
Events don't show up with the proper relationship to each other,
which could have unintended consequences.
This case could show up in either Cosmo and Chandler, but it is
more likely in our casual collaborator scenario because the
starting point for the casual collaborator is that they are looking
at someone else's calendar, and that calendar might have timezones
turned on. If the default is that the casual collaborator doesn't
have timezones turned on, we might be setting up a problem.
I'd observe that as long as the canvas/view *does* use timezones,
we don't really have the above problem. It doesn't matter which
timezone is used, events show up in proper relationship to each other.
I'd argue that the reasonable solution here is to turn timezones on
in the Cosmo UI if the shared calendar uses any (non-floating)
timezones. Any timezone will avoid the problem, and the Cosmo user
could change the timezone to fit the one they wanted to view the
calendar with. (I guess this is either your (B) or (C) proposal).
Freebusy case:
+ A user does not have timezones turned on, all floating all the
time. The user is tracking timezone changes in their head.
+ The user shares their collection as free-busy.
+ Other users might not know what is in the first user's head.
(Then again, if they work/live closely together, the subscriber
might actually know how to interpret the times). If free-busy
subscriber has timezones turned on, the system needs to make some
guess at the first user's timezone.
+ CalDAV free-busy *requires* a timezone associated w/the calendar
to use for floating events.
This case isn't a barn burner for Preview. That said, presumably we
can pick the user's local timezone and associate it with a
published free-busy collection. You could also require the free-
busy creator to pick a timezone when publishing free-busy.
I am sort of concerned about introducing per-collection timezones
and what they are meant to mean and how they would interact with a
UI that displays multiple collections. Some thoughts...
Mimi Yin wrote:
Issue #2 is more complicated. I'm not even sure what a collection
timezone would do. + What does it mean for a collection to have a
timezone which in turn contains individual items that have
different timezones?
I assume the individual item's timezone defines the item's time.
The collection's timezone is a suggestion for the view, or *is* the
view's timezone. It is used to pick the timezone when a new event
is created.
I understand from Grant that even when items are floating, some
timezone is needed to make a decision about what events get
included for a given day/week. If I understand correctly, right now
Chandler defaults to use the system/local time for floating events.
One could use a collection timezone here, but that sounds hairy to
implement for not much benefit to get some edge cases right.
+ How do we overlay collections that have different timezones in
the calendar view?
You could use the timezone of the "top" collection, just as we do
for picking a color (Grant's idea). As you pointed out to me, this
approach could have the downside of the timezone jumping around as
you switch collections, which might not be what you really want.
+ What is the timezone of an individual item if it belongs to
multiple collections, all with different timezones?
The timezone of the individual item should be the timezone that is
used to define the item.
I'd be concerned about supporting different timezones for different
calendars/collections for Chandler in Preview. Its hard for me to
see how we're not opening up a can of worms if we add the timezone
to the calendar, but perhaps someone can help me here.
Cheers,
Katie
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
