Hi Jeffrey,
Thanks for linking to the previous discussion, that context is useful.
I read your motivation for re-opening the discussion as: people who
implement calendaring standards for a living don't grok the end user
motivation for having a calendar with floating events. I don't see this
as a good reason to revisit the design, especially right before Preview.
Also, I've heard feedback from Mitch and other users he's talked to that
the timezone design is spot on, and does a great job of supporting the
two types of calendar travelers.
I do understand that the floating events provide a problem for
free-busy. More below.
Are there other reasons or end user problems for proposing we undo the
floating calendar event design?
My understanding from Mimi, Priscilla, Mitch and others is that we see
two distinct types of people-who-use-calendars-in-different-timezones,
(a) the do-the-math-in-the-head people and (b) the
explicitly-track-timezones people. The one group tends to not understand
why the other group would do it that way, but both types of users really
do exist.
It is true that the do-the-math-in-the-head people in some sense are not
playing nice if they try and share with the set-the-timezone people. I
think that just is what it is -- the user's preferred behavior isn't
great for people who need to coordinate across timezones. If users
really need to coordinate across timezones, the one user needs to ask
the other user to use timezones to make it work, imho.
Given that the do-the-math-in-the-head people are the set of people who
just don't want to think about timezones, even though they travel
around, I suspect that adding an option "ignore timezones when
positioning events" isn't going to make much sense, whereas "turn on
timezones" does make sense to the track-timezone people.
In other words, I'm not in favor of altering the design here. I think we
need to try the current design out with real users, and go from there.
We may need to do some adjustment for freebusy and to coordinate with
the Cosmo UI (more in a separate thread), but I think we can do that
without revisiting the Chandler UI design.
Cheers,
Katie
Jeffrey Harris wrote:
Hi Folks,
I'm sorry to say I'm reopening a discussion we've gone around and around
on in the past, but our past compromise just isn't sitting right with
me, so I'd like to broach the topic again.
For reference, a summary from the last time we discussed this:
http://lists.osafoundation.org/pipermail/design/2006-January/003894.html
In a different, more recent, thread, Mimi then Grant said:
A question for the Chandler developers: How much work is it to
share the publisher's calendar canvas timezone when publishing
shares? ...
I don't think it's a lot of work to add it when sharing (and it's a
good idea for CalDAV, too, assuming we don't already do it).
However, I'm not quite sure how things are supposed work out if you
subscribe to a calendar with a different timezone than yours, and
that calendar has floating events. Would you want Chandler to
interpret "floating" differently depending on the share/collection?
That seems as if it would be difficult (barring a brilliant idea from
someone like, say ... Jeffrey :) .
I'm not sure how difficult it would be, but if we follow the iCalendar
concept of floating events, it's really not what we're supposed to do:
floating events are really *intended* to mean different absolute times
in different timezones.
It happens that floating events do the right thing when someone lives
their calendared life in one timezone and always interacts with other
folks in that timezone, but I think this is misleading. As soon as that
person transitions to collaborating with people in a different timezone,
all their existing events are actually wrong.
My sense is that other calendar apps that don't display timezone UI are
still by default creating timezoned (not floating) events. They're just
not displaying the timezone if it's local. This seems like it should
meet non-timezone users needs, and it transitions well if such users
later discover the joys of geographically dispersed events.
So it seems to me we're defaulting to UI that caters to (from the
summary link above):
+ Users who do travel but prefer to do all the timezone math in their
head.
I realize some users actively want a 2PM EST and 2PM PST event to show
up in the same time slot. In the past I've deferred to the argument
that we should make the calendar work right for these folks. But I've
gotten fairly steady private feedback that this is really weird, and
very little positive feedback. I'll freely admit that all that feedback
is coming from calendaring people, so my anecdotal sample group may not
correlate perfectly with Chandler's target audience. But I still think
this isn't something we want to default to.
I'd prefer that we use two timezone preferences, one "display timezone
information", defaulting to off, that would control whether timezone
drop downs were visible, but wouldn't affect where events were rendered
on the calendar (2PM EST and 2PM PST would show up at different times,
non-local timezones would continue to show up with their "EST" next to
2PM). This would suffer from the poorly-set-system-timezone issue, but
perhaps we could address that issue by prompting users for their
timezone when Chandler first starts?
We could add an "ignore timezones when positioning events" option that
would default to off, to support users who really actively want to do
what we're doing now by default, e.g.
A) showing 2PM EST in the same slot as 2PM PST, and
B) creating floating events by default
Sincerely,
Jeffrey
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
