[Design] [Cosmo-Last Call] Time-zones on Cosmo UI

[Priscilla Chung]

My comments below:

On Dec 1, 2006, at 5:17 PM, Mitchell Kapor wrote:
> *Not Logged-in Cosmo*
> + The calendar canvas will be viewed in floating time-zone (ie. if  
> you have 2 events at 2:00pm PST and 2:00pm EST, they both show up  
> at 2:00pm)
>
> My two cents.  It would be better if this were flagged with an  
> alert to the user to suggest they turn on time zones. An event at  
> 2:00 PM PST and an event at 2:00 PM EST do not happen at the same  
> time.  Showing them in the same slot and doing nothing else is a  
> very bad idea.
>
> This could happen if the user is subscribing to a calendar in which  
> events are being entered with different associated time zones.
>
> Maybe a published calendar should have a "suggested" time zone  
> which is used in just this case - when the user hasn't set a time  
> zone view and there are event sin more than time zone.
>
> Maybe this is gilding the lily, but then I fall back to saying the  
> user should at least be alerted.
>
>
>>> + Clicking on an individual event will display the time-zone  
>>> information it was created in the detail view (ie. PST, EST etc).


I agree about showing both 2PM PST and 2PM EST at the same time on  
the calendar canvas. My original proposal was altered because from I  
was told, Chandler does not send out time-zone information on the  
ticket/URL.

 From the handful of interviews Mimi & I have conducted and from  
comments on the list, I think most users either use time-zones or  
they don't. I realize this is a very generalized statement. From my  
own personal experience using Chandler/iCal, I never even thought  
about time-zones until I had to and I didn't even realize my time- 
zone support was turned off.

Which brings me to my concern about prompting an 'alert' box to  
select a time-zone for the 'Not logged into Cosmo' Casual  
Collaborator (CC) user. If the primary target user is using Cosmo UI  
for casual use, they may not even be familiar with Chandler or  
perhaps the calendaring world. Prompting a dialog box in-front of  
these users to select a time-zone could be disorienting. In addition,  
every time the CC clicks on the URL/ticket sent from the Chandler  
user, who happens to have time-zone support on, the 'time-zone alert'  
prompt could become annoying, especially when they just want to do  
one thing, ie put in their PTO on the office calendar.

Remember the CC could be regularly using Cosmo UI without ever  
signing up for an account. And if the user is not logged in to Cosmo,  
the information of the chosen time-zone will not be saved.  (Dropping  
a cookie could be a potential option in this case, but let's table  
that discussion for later as there are issues with cookies as well.)

One thing which I might not have stated clearly in my original  
summary is that If you're not logged in to Cosmo, you currently  
cannot view more then one collection at a time.

My original proposal is when a Chandler user sends their ticket/URL,  
the CC should be able to click on the ticket/URL and when viewing the  
calendar collection in the 'Not logged into Cosmo', it should always  
be in the time-zone the Chandler user sends it as. As if the calendar  
information is mirrored on the web browser. (sort of meets that  
Consultative User huh?) ie. The calendar canvas time-zone and the  
individual events also should be in the time-zone the Chandler user  
set them as.

*The issues for users 'Not logged into Cosmo*
+ When you're not logged into Cosmo, there is no way from the browser  
to do a best guest and set a 'default' time-zone on the calendar  
canvas. This would have to be done manually by the user.
+ Setting a time-zone once would not be saved* (except for cookie  
comment above). Subjecting the CC to choose a time-zone every time  
could be disorienting and annoying.
+ Not everyone uses time-zones.

I may have another suggestion and I'm going to pull it out of this  
discussion so everyone will be able to comment on the specific proposal.

-Priscilla
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osafoundation.org/pipermail/design/attachments/20061205/15a70f7a/attachment.htm