[Cosmo team, please scroll down to see the question in bold.]
Priscilla and I finally got a chance to talk over some of the open
issues concerning Cosmo UI that have been brewing on the list.
We both agree that for Preview any of the first 3 options outlined
below (A, B or C) are okay from a usability standpoint, we should
just do what is most expedient from a development perspective.
Option D (keeping the CC's canvas timezone in sync with the Chandler
Shar-ER is probably overkill and potentially confusing.)
Option A: Display all shares on a Floating canvas, even if individual
events have timezone information is not ideal, but that's how it's
been working in Chandler thus far and is also how it has been working
in iCal for as long as I can remember, so it's probably good enough
for us in Preview. Again to reiterate what Katie said in her recent
post on floating events, people who don't use timezones, don't use
timezones and people who do, do. And when/if ever the twain shall
meet, they can work out an agreement amongst themselves. Luckily for
us, our target user group for Preview is a close-knit working group,
so hopefully people are in close communication and are generally
aware of each other's timezone issues. http://lists.osafoundation.org/
pipermail/design/2006-December/005854.html
Option B: Subtly prompt CC's in a non-modal way when there's timezone
info and allow them to set their own timezone. Login not
required...is an improvement over A, but when/if cookies fail, CC's
without an account will have to reset the timezone over and over again.
Option C: Inherit the canvas timezone from the Chandler user/shar-
ER...is probably best, but has dependencies with Chandler, although
we've gotten feedback that it wouldn't require a huge change.
If we go with Option C, we will also have to implement Option B: for
CC's with accounts. When CC's with accounts subscribe to a
collections with timezone information, we don't want them to all of a
sudden lose timezone information they were able to see before
subscribing. As Priscilla pointed out in her original proposal on
timezones, we don't want to get into a situation where CC's first
experience a shared collection in the Shar-ER's timezone and then
once they subscribe to it all timezone info disappears because they
never turned on timezone support in their account.
This raises a separate question for Option C. If a CC with an
account, who has turned on timezone support for their account and who
is already logged in clicks on a URL ticket to 'preview' a share?
Should they view that share in the Shar-ER's timezone? OR Should they
view that share in the timezone they've specified for their account?
I don't think there's a clear answer to this question and we should
probably just try one out and see if people scream about it.
For Option B it's clear, display the share in the timezone the CC has
specified in their account settings.
So given all of this: Which option is the most expedient from a
development perspective?
Mimi
On Dec 6, 2006, at 7:14 AM, Mimi Yin wrote:
A question for the Chandler developers: How much work is it to
share the publisher's calendar canvas timezone when publishing shares?
Okay, I'm going to make a pass at trying to summarize the issues in
the timezone discussion. Wish me luck.
It seems like there are really 2 distinct discussions going on.
1. Finding a minimally annoying way to introduce the concept of
timezones to Casual Collaborators (I think this actually applies to
both CC's with and without accounts and should probably even
stretch to include Chandler users).
2. What needs to have a timezone? Individual events? What about non-
event items with alarms? A particular collection? The calendar
view? The user's account?
For Issue #1, it seems like there is no shortage of viable
solutions. Prompting CC's with a pop-up every time they access a
share is probably overkill. But a subtle 'Notice' banner at the top
of the page probably wouldn't be so bad. We may want to consider
something like this for Chandler users as well.
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?
+ How do we overlay collections that have different timezones in
the calendar view?
+ What is the timezone of an individual item if it belongs to
multiple collections, all with different timezones?
I think we can all agree on the need to: Display timezone
information on individual items. Beyond that, there seem to be a
number of options:
A. No timezone for the canvas for CC's by default. Login to assign
timezones.
+ By default, all shared collections are displayed on a Floating
timezone canvas.
OR
B. Prompt CC's when there's timezone info and allow them to set
their own timezone. Login not required.
+ Subtly prompt CC's to assign a timezone when Cosmo UI detects
timezone information in a share.
+ Allow CC's (with or without accounts) to assign a timezone to the
calendar canvas and to alarms on non-events.
OR
C. Inherit the canvas timezone from the Chandler user/shar-ER.
+ (I think this was Priscilla's original proposal) Do a 1-time
transfer of the Chandler user's global timezone from Chandler to
the CC in the Cosmo UI. The CC automagically views the shared
collection in whatever timezone the Chandler user used when
publishing the collection.
OR
D. Keep the canvas timezone in sync with the Chandler user/shar-ER.
+ Keep the CC's calendar canvas timezone in sync with the Chandler
user's calendar canvas timezone.
Are there other options I'm missing?
=====
Some more things that came out in the thread to keep in mind:
+ CC's are not using Cosmo UI to keep track of their own schedule.
+ The target user group for Preview is very small and close-knit.
Most CC's could probably guess the correct timezone of events in a
share without having to be told explicitly by the UI. e.g. When
Bear shared his calendar with Priss, she didn't need to have
timezone support turned on to know that his events were in EST.
+ Cosmo UI is slated to support alarms on non-event items in the
Preview timeframe.
+ Cosmo UI will most likely eventually support overlays in both the
calendar and Dashboard views.
Hope that was more helpful than confusing. :o)
Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
