[chandler-users] [d/f] Assorted Usage Notes

Andre Mueninghoff andre_mueninghoff at fastmail.fm
Tue Jun 26 03:38:59 PDT 2007


Hi Mimi,

Yes, I did have the understanding that edits to shared data do sync
automatically without one having to click Update. If I understand
correctly, one goal of using the Update button is to provide an extra
highlight to those with whom I'm sharing an item that I've made
important changes. I think maybe my subconscious expectation was that
the changes I make to a shared item would cause the item, when synched,
to appear in the In collection for those with whom I'm sharing, and that
that would be sufficient "notification" for Chandler users, but perhaps
I'm stuck on the current insidious email model. You guys are very
generous, but I wouldn't read too far into the gap in understanding I
seem to have. Others may be much quicker about this.

Also, I have realized the scenario that prompted my initial feedback
about the Update button is different than the ones offered by you,
Jeffrey and others. I use the IMAP Chandler folders to send events and
tasks to myself to Chandler from other email clients. Specifically, I
use the following email addresses to drop these messages right into
their respective folders:

username+chandler_events at imapmailservice
username+chandler_tasks at imapmailservice

The Chandler IMAP download and import works great. When I next begin to
process these items in Chandler though, for example, change their triage
status to Later or Done, the Update button appears (because the
email/communication stamp is on the items by virtue of their having been
retrieved from the Chandler IMAP folders). The appearance of the Update
button is not really an issue, but seems incongruous in this flow since
there really isn't anyone else to update via email. (Provided I have
included the new items into a personal collection that I am sharing with
my other instance of Chandler, I do rely upon the automatic sharing sync
to propagate changes.) When I do click the Update button, Chandler sends
an update to the originating email address and unhelpfully in this case
also to the username+chandler_folder at imapmailservice address. This
begins the game of item ping-pong, as odd updates and conflicts being to
appear between the two instances of Chandler I use to sync with myself
between office and home.

Some possibilities that come to mind for consideration:

1. Don't stamp as email/communication those items downloaded from the
special IMAP Chandler Task and Chandler Event folders, even though, yes
they are coming from an email system. Then the Update button won't
appear when one makes changes to these items in the course of processing
them.

2. Alternatively, in the relnotes, suggest to new users experimenting
with these folders that they should consider removing the
email/communication stamp themselves or otherwise be aware of what may
happen next.

3. Don't send updates to the IMAP email account in which the Chandler
Task and Event folders exist, that is, from which the items were downloaded.

4. Provide the option to have Chandler delete the email in the special
Chandler Task and Event folders after it has been downloaded and
imported to Chandler.

5. Since Chandler users sharing an item will automatically receive
changes to an item, it seems to me that there may be regularly occasions
for sending updates to only non-Chandler users. If and when a
multi-selector thing is implemented on the tool bar (as discussed by
Davor and John - sounds great BTW - typically very useful and real
estate economizing in other apps), consider the following
variations/options on the theme of Send Update:

Send All Updates
Send Chandler Updates
Send non-Chandler Updates

Please let me know if you have any questions.
Thanks, Andre


Mimi Yin wrote:
> Send Update sounds reasonable.
> 
> Something to note: Update is only present for items that have been
> addressed. So in theory, you should get used to the idea that edits to
> shared data syncs automatically without having to click Update?
> 
> Andre, did you have that understanding before you noticed the Update
> button?
> 
> Mimi
> 
> On Jun 25, 2007, at 7:00 PM, Andre Mueninghoff wrote:
> 
>> Hi Jeffrey,
>>
>> As I begin to understand this better, I would suggest the label be "Send
>> Update". The potential advantages of this label are that the word Update
>> is preserved (I also connected the icon with the word Update), the word
>> Send implies (to me anyway) to Send to other people as compared to
>> merely updating the local item or even updating the sharing server or
>> something, and using the word Send leaves open the mode of transport,
>> whether email, Jabber, or other magic.
>>
>> Thanks much, Andre
>>
>> Jeffrey Harris wrote:
>>> Hi Andre,
>>>
>>> Thanks for the ongoing "outside the development bubble" feedback, Andre.
>>>
>>>> Is Update/Notify perhaps really intended for propagating changes to
>>>> non-Chandler users? If so, maybe the label or tool-tip could
>>>> clarify/amplify that intended purpose. If I'm missing the point, I
>>>> apologize. Wanted to give you my candid impulse response without
>>>> peeking first at the spec.
>>>
>>> Actually, I think Update is targeted equally at Chandler users.  For
>>> instance, if I'm editing a get-together amongst an ad hoc group of
>>> friends, the item may start as an outline without the formality of a
>>> shared collection.
>>>
>>> I imagine in this case, I'd send out a tentative event to a few friends,
>>> and they'd reply with counter-proposals and discussion (whether they
>>> were Chandler users or not).  But as agreement was reached on details,
>>> that could be reflected as an update to the original item, so the
>>> outline could grow into a clear, centralized plan.  Does that use case
>>> make sense?
>>>
>>> Regarding the fact that the Update/Notify button doesn't immediately
>>> convey I'm-going-to-send-an-email (which is a good point), how about if
>>> we changed the button's title to Update by Email?
>>>
>>> That suffers from the fact that it's kind of long for a toolbar item,
>>> but it seems much clearer.  I guess the Send state could be called Send
>>> by Email then, too.  I know we want to emphasize communication (could be
>>> Jabber, say) instead of Email, but for Preview, we're just doing email.
>>>
>>> I must confess I'm enamored of the way the icon states for updates look
>>> like U's which connect to Update in my mind.  That's not going to be
>>> true in non-English languages so I probably shouldn't be attached, but
>>> still, I prefer Update to Notify if we can use more text to clarify what
>>> we mean.
>>>
>>> Sincerely,
>>> Jeffrey
>>> _______________________________________________
>>> chandler-users mailing list
>>> chandler-users at osafoundation.org
>>> http://lists.osafoundation.org/mailman/listinfo/chandler-users
>>
>> _______________________________________________
>> chandler-users mailing list
>> chandler-users at osafoundation.org
>> http://lists.osafoundation.org/mailman/listinfo/chandler-users
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://lists.osafoundation.org/pipermail/chandler-users/attachments/20070626/61e28f72/signature.pgp


More information about the chandler-users mailing list