[Design] [Cosmo][Sum] Time-zone on Cosmo UI

[Mimi Yin]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20061207/c8e5d662/attachment.htm