[Design] [Scooby] Managing Calendar/Timezone

[Sheila Mooney]

I think this discussion is getting  a bit off topic so I just wanted  
to reframe what I think is up for debate here.

We decided a while back that timezone support was important for our  
target Chandler users. As Mimi mentioned, we have already worked  
through many of the questions/issues people are raising on the list.  
If there are questions about the decisions made etc for Chandler, we  
can refer people to more detailed specs/writeups to provide more  
context. Currently in the product, users can do the following...

+ Turn of and off timezone support.
+ Set a timezone for a specific event.
+ Set a timezone for their current calendar view.
+ Set a floating timezone for a specific event (ie: the event appears  
at 8:00pm regardless of timezone my view is in).
+ Set a floating timezone for the calendar view (ie: EventA at 3pm  
PST shows up at 3:00pm and EventB at 11:00am EST shows up at 11:00am).
+ By default (out of the box), timezone support is OFF which means  
everything is using floating timezones. This is the setup for people  
who don't care about timezones or want/need to have events show up in  
different timezones on different days of the same calendar view and  
therefore need to manage timezones in their head.
+ If you want the calendar canvas to know about timezones however,  
you can turn ON timezones.

I understand there are some discussion around setting a default  
timezone which gets reset each time you run the app. We should  
probably have a separate conversation about this starting with the  
applicable use cases that support this scenario.

In keeping with our ecosystem vision, this primary target user  
(person who will be dogfooding our Scooby calendar), will be a  
Chandler user that has shared their calendars onto Cosmo and wants to  
have web access to them or give others web access. For this reason,  
it's very important we maintain data integrity when viewing Chandler  
calendar data on Scooby. Users will expect a similar experience and  
to see things the same way. It would almost be better not to have any  
timezone support in Scooby rather than support it in a different way.  
Basically Scooby timezone support, as we implement it, needs to move  
in lock-step with Scooby for most issues. We do understand however  
that there are subtle differences in the way we need to handle  
certain things (storing defaults, persisting info across sessions)  
and these need to be discussed.

Priscilla's original email was really about determining which release  
we try and do the timezone work in or if we can do that incrementally  
and is less about whether or not people care about timezones. At a  
product perspective, having timezones supported in 0.2 vs 0.3 doesn't  
really matter as long as it's there for whatever release we are  
calling our "dogfood scooby calendar". The 0.2 release is just a step  
along this path and not intended on satisfying any particular target  
user scenarios.

It's my understanding that the development team feels we need to  
start on timezone support sooner rather than later and stage this. I  
think the real question to discuss here is "Can we implement some  
subset of the Chandler timezone functionality in Scooby so it's not  
confusing for users or do we really need to have the whole enchillada  
done in one release?"

Sheila

On Apr 20, 2006, at 11:29 AM, Jeremy Epstein wrote:

> John Townsend wrote:
>>
>> On Apr 20, 2006, at 6:23 AM, Mimi Yin wrote:
>>
>>> Many of the issues being hashed out on this thread are exactly  
>>> the ones we discussed during 0.6 and finalized in January. Here  
>>> is the thread in the list archive: http://lists.osafoundation.org/ 
>>> pipermail/design/2006-January/003965.html
>>>
>>> A few key things:
>>>
>>> 1. Not only do some people not care about timezones. They don't  
>>> even want the calendar app to automatically assign their "home"  
>>> timezone to the events they create. Instead, they manage  
>>> timezones entirely in their head. Tuesday, I'm in New York,  
>>> everything is in EST. Wednesday I'm in Chicago, everything is in  
>>> Central time. And they want to be able to view their calendar  
>>> like that. Unless we want to start supporting the ability to  
>>> assign different timezones to different days of the week on the  
>>> calendar, we need to have a 'No Timezones' option for users. This  
>>> is what Chandler provides out of the box in the trunk build today.
>>
>> I get that.. but maybe I am missing something. Isn't it important  
>> for the user who doesn't care about timezones to still provide  
>> data _with_ timezones? After all, he is interacting with people  
>> who DO care about timezones.
>
> Its not about providing data, just seeing it. There are only  
> certain specific events where I care. "conference call" is one  
> type, "web ex" or "Internet conference" is another. Most of my  
> events do not involve people in a different time zone.  In that  
> sense I only want to see time-zones when at least one invited  
> participant works in a different time zone than I (in order to be  
> courteous about scheduling). You can think of this as a  
> "jeremycentric" view of the world. The rest of the world can know  
> what my timezone is, but I just don't care. As far as updating my  
> timezone as I move around, I don't see how it helps me schedule,  
> because I am scheduling before I travel. There is no way to set  
> timezone on a week by week or day-by-day basis in any calendaring  
> software I have used.
>
> Jeremy
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> 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/20060420/fb111fac/attachment.html