Hi Jeffrey, see in-line
On Jul 31, 2006, at 2:58 PM, Jeffrey Harris wrote:
---+++C the Chandler User, Not-sharing
* C can see the invitation in their Chandler, in the collection
they
share with A as soon as A has created the item and a sync happens.
The
invitation is auto-triaged in C's Dashboard to Later, because it
is an
invitation for an event scheduled in the future.
Hmm. If C isn't sharing, I think the stuff about sharing with A is
erroneous here.
Oh, good catch. I got B and C mixed up. The stuff for C should really
be for B and vice versa.
* When A sends the invitation, C receives the invitation in their
email client; AND
* C receives the invitation item pops into the NOW section of C's
Dashboard
* C can reply to the email in their email client; OR
* C edits the item
* C updates the item
* A receives the update in their email client as a separate
email in
the same thread; AND
* A receives the update to the original invitation item in their
Chandler / Dashboard NOW section
* B receives the update in their email client as a separate
email in
the same thread; AND
* B receives the update to the original invitation item in their
Chandler / Dashboard NOW section
* C receives the update in their email client as a separate
email in
the same thread
* D receives the update in their email client as a separate
email in
the same thread; D can click on a URL ticket to view / edit the
item on
Scooby
* E receives the update in their email client as a separate
email in
the same thread
Does Chandler somehow know that D is a Scooby user but E never uses
Scooby? I've been assuming we'd just send them both a Scooby URL, is
that a reasonably assumption?
I think this is basically the how many URLs discussion that we've
been having on the Cosmo-dev list. The ideal proposal from a design
perspective is that there is a single URL that works for both
directing people to the Scooby UI and/or subscribing to shares via
Chandler. http://lists.osafoundation.org/pipermail/cosmo-dev/2006-
June/000893.html
[snip]
---+++E the Email client User
* E receives the invitation in their email client
* E can reply to the email in their client
* A receives the reply in their email client as a separate
email in
the same thread; AND
* A receives the reply to the original invitation item in their
Chandler / Dashboard NOW section as a separate email in the same
thread
* B receives the reply in their email client as a separate
email in
the same thread; AND
* B receives the reply to the original invitation item in their
Chandler / Dashboard NOW section as a separate email in the same
thread
* C receives the reply in their email client as a separate
email in
the same thread; AND
* C receives the reply to the original invitation item in their
Chandler / Dashboard NOW section as a separate email in the same
thread
* D receives the reply in their email client as a separate
email in
the same thread
Are you hoping everyone who responds will remember to use reply-to-
all?
Many users (myself lamentably included) occasionally forget to use
reply-to-all when they intend to.
Nope. Just sketching out what should happen if they do. We can't
really control it if they don't and they may be replying only to the
sender on purpose.
If we end up sending different tickets (and thus different
messages) to
different users, reply-to-all isn't even an option, there will
likely be
multiple emails sent, with different addressees. That's really an
argument against per-user tickets, in my mind.
We could put multiple recipients in the reply-to field, so at least
the
first response from a non-Chandler user would probably go to all the
original recipients (assuming their mail client handles multiple
reply-to addressees, I have no idea how common that is, Thunderbird
supports it). Unfortunately ad-hoc reply-to fields aren't sticky,
so if
E replied to all, some other email user might just reply to E
instead of
sending it to everyone else. I think no one uses this feature because
it's likely to confuse more than help.
Oh I see. I don't foresee per user tickets in the Beta timeframe. It
doesn't seem to be an idea that's gaining any traction.
Perhaps this isn't worth worrying about, but I thought I'd point out
that we shouldn't assume email responses will reliably propagate to
the
right people. The same is true for email by itself, and obviously the
world goes on.
Okay, good to raise a flag.
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
