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.
2. Given that we need to display the calendar canvas' "timezone"
somwhere on the calendar UI anyway...(otherwise, the user won't
know what timezone the events are being displayed in) it makes
sense to use the timezone display as the timezone picker as well.
This is what Apple iCal does and what Chandler does today too. This
makes changing timezones easy to access, but it doesn't require the
user to deal with a pop-up every time they log into Scooby in a new
timezone.
Yep. I agree. The only question is how sticky is that setting. Is it
per session or does it persist across sessions?
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
