See in-line :)
On Dec 13, 2006, at 11:37 PM, Philippe Bossut wrote:
See in-line also...
Mimi Yin wrote:
Hi Philippe,
See in-line...
On Dec 12, 2006, at 2:17 PM, Philippe Bossut wrote:
Mimi Yin wrote:
I think this might be problematic. If you're a Chandler user who
is getting a Cosmo account to use the Hosted Service (as opposed
to using the Cosmo UI), you might think you're setting time zone
preferences for Chandler. Indeed, what would it even mean to
have timezones turn on in Cosmo, but not in Chandler?
I think we need to keep these in sync.
I don't think so. The TZ in Chandler is a "display" and "use as
default" thing. Once events are created, the TZ is stored with
them and moved with them. It's context independent at that point
and should stay that way.
Could you give an example to illustrate what you mean by context
independent? I'm not sure I understand.
What I mean is that an event item doesn't need any external info to
be understood in a non ambiguous way, it's self consistent and
doesn't depend of any data outside itself (e.g. calendar data or
user preference). IOW, it's interpretation doesn't depend of the
context in which it is being read.
Apologies, what I meant was that whether or not timezones were turned
on at all needed to be in sync between a Chandler user's Cosmo
account and Chandler. I agree that 'the display timezone' should be
independent of the timezone of particular events and should be
indepedent between clients.
I'd be worried if something made on a Cosmo account would require
changes on a Chandler install. What if Chandler is off line and
modifs done by the user? Besides, it assumes a 1:1 relationship
between Chandler installs and Cosmo accounts while you can have
several Cosmo accounts used from one Chandler install (not right
now though but there's no reason to preclude this) and several
Chandler installs pointing to the same Cosmo account (and that
you can do now and it can be useful if you have several machines).
I just worry about the following scenario...What if I assign PST
to my Cosmo account and Chandler is still Floating because I
haven't turned timezones on. On the same calendar, the events I
create on Cosmo will be in PST and the events I create in Chandler
will be Floating...and then I share this calendar and the sharee
is in EST. How do we prevent users from getting into this state?
Let's look at another scenario: what if I assign PST to my Cosmo
account and EST to Chandler and the sharee is in Paris/France Time?
Well, in that case, the events will show at the time they are
supposed to happen in their respective timezone. You'll certainly
say that, in that case, users turned TZ on and know what they are
doing.
Yes, I think once you've turned on timezones, you see the timezone
metadata for each event, so you have visual feedback about what
you're doing. What I'm worried about is when you have timezones
turned off and there is no visual feedback of what's going on.
OK so the problem we have is only because of the default case (when
TZ is turned off) which is floating.
Yup.
The naive user of your example is expecting (if I understand your
point) to see the event she created to be created with the
"right" (i.e. system) TZ, she doesn't expect Floating TZ to even
exist (she might be naive but she knows the Earth is not flat and
that, by default, an 8am SF event does not happen at 8am in New York).
I'm not sure I understand your characterization of the naive user.
The user who doesn't turn on timezone support either:
1. Doesn't need it because they don't really have events that happen
in more than 1 timezone.
2. Isn't naive at all, they have a very complicated schedule, but
prefers to store timezone information in their head.
The problem then is that our default is wrong. In which case, I
think we should change the default (have a default that is the one
expected by users, i.e. use the system TZ as default when TZ has
not been turned on) rather than create an inter-app Cosmo/Chandler
protocol to patch the problem.
I think there are many ways to characterize the problem. I see it
primarily as a context problem. When a Chandler user assigns a
timezone to their Cosmo account, they do so 'out of context': before
they've had a chance to understand how that timezone information is
going to be used...namely, as a way to anchor the Cosmo UI calendar
canvas in a timezone as well as to designate a default timezone for
newly created events in Cosmo UI, which may or may not be something a
Chandler user signing up for a sharing service will discover / use
right away.
Either way, I don't think this is a huge issue for Preview. Cosmo UI
in Preview is not targeted at the Chandler user, but instead at non-
Chandler using Casual Collaborators. Nevertheless, if we're going to
be implementing time zone prompts when Chandler and Cosmo users
subscribe to shares with timezones...we might as well do the same for
Chandler users who turn on time zones in Cosmo, but haven't turned on
time zones in Chandler.
Mimi
Cheers,
- Philippe
Mimi
Or may be I'm missing something (I need to confess I didn't read
in detail the long long Cosmo TZ saga...).
Cheers,
- Philippe
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
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
