On Dec 8, 2006, at 1:38 PM, Bobby Rullo wrote:
I agree wholeheartedly with this. It seems the only safe way to use
these per-collection timezones would be for CC's w/o accounts. And
is it worth it for that one use case?
Option C. Directly inheriting a timezone from the shar-ER has the
advantage of making it unnecessary for non-account Casual
Collaborators to set / re-set a timezone every time they check out a
shared collection. However, my sense is that this is not a
requirement for Preview and should only be done if it is easy to do
from an implementation standpoint,.
Option B. For CC's with accounts and for Chandler, the proposal on
the table is to provide a prompt when non-time zone users subscribe
to a share with timezone info which takes them to a UI where they can
turn on timezone support and select a timezone for the calendar canvas.
All of the user's existing items will be assigned that timezone,
unless they are items they received via a subscription to a floating
time zone share.
For more details, see this thread: http://lists.osafoundation.org/
pipermail/design/2006-December/005893.html
So, in the end, it seems like we have to build Option B no matter
what and we can probably use Option B for both CC's with and without
accounts. Option C would be nice-to-have, but not a design
requirement for Preview.
Questions
1. Does, first implement Option B and then see if there's room in the
schedule for Option C sound like a viable plan from a dev perspective?
2. Where does Option B fit into the schedule for both Chandler and
Cosmo? I don't think the two need to move in tandem.
Still to be done
1. Design mockups showing workflow and prompt screens
Thanks!
Mimi
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
