Morgen Sagen | 1 Oct 20:35 2007

Re: Updating share items results in false positive conflicts

On 9/25/07, Mimi Yin <mimi <at> osafoundation.org> wrote:

> Why did this happen? Well, unlike sharing changes, email updates do *not*
> carry with them a snapshot of the item *before* it was changed. This means
> that subscribers receiving Philippe's update via email have no way of
> knowing that Philippe actually edited the *latest* version of the event, the
> same version they have in their Chandlers. All they know is that Philippe's
> email update is *different* from what they have and so to be safe, the
> changes are flagged as conflicts.

Technically, Cosmo-based sharing updates don't carry along snapshots
of the previous state of an item either.  Let me see if I can rephrase
how conflict detection works:

When Chandler receives an item either from Cosmo sharing or via email
and that item already exists locally, the item is examined for
conflicts.  The rules for this are different depending on whether you
have already seen the item in the shared collection being synced or
not.  If you have, then we can compute what was changed both locally
and remotely for the item since the last sync, and only those changes
are compared.  If the item has not been seen in the shared collection
before (because it's either a new subscription or because someone else
just added it to the collection), we have no baseline to examine to
compute local and remote changes, and therefore *any* difference
between the local and remote copies are marked as conflict.  The same
algorithm applies to edit/update (email) sharing: if you have
previously sent/received the item to/from another person's email
address you have a baseline to compute changes from.  Otherwise all
differences are considered conflicts.

(Continue reading)

Mimi Yin | 2 Oct 03:20 2007

Re: [Sum] Improving the Who Column (nee Chandler IMAP folders and the mail-stamp)

I'm continuing this thread: http://lists.osafoundation.org/pipermail/design/2007-September/007662.html with a more holistic title.

After meeting separate with Bryan Stearns and Philippe today, I have a proposal for how we can iteratively improve the Who column to make it both more understandable and more usable for certain core sharing scenarios.

Core scenarios we'd like to solve:
1. Just like dates, for any given item, there are many 'who (aka person)' attributes: Created by, Edited by, From, To, CC, BCC, Sent by, Updated by, etc... Our goal has been to try as much as possible to intelligently display the 'who attribute' users *most* associate with any given item.
- For non message items, the rule has been either Edited by or Created by (if the item has not been subsequently edited).
- For message items, the assumption is that depending on whether the message is fromMe or toMe, the user will want to see the opposite attribute. For fromMe items, show who the message is 'to' in the Who column. For toMe items, show who the message is 'fr' in the Who column.
- For shared items, it's important to be able to see who edited an item last.

As you can see, problems arise when you have an item that is both shared and a message. Currently sharing wins over message-ness and 'fr/to-ness' is permanently lost in the Who column once a message item has been edited. 

2. Sharing group task lists. When sharing group task lists, it would be nice to see who the tasks are assigned to in the Who column. We'd like to encourage users to start using the Addressing stamp as a way to assign tasks. 

Currently this is hard to do because if an item is neither fromMe nor toMe (which will be the common case for shared tasks list, most tasks will be neither assigned to me nor assigned by me), we display the 'fr' field in the Who column, when what you want to do is display the 'to' field so you can see who the task is assigned to.

To better serve the 2 scenarios listed above, I've filed the following bugs.

Nominations for 0.7.1
10924 Leave Who column blank when user stamps an item but doesn't address it
+ Currently, we display the 'fr' field for fromMe items that are not addressed 'to' anyone. This confuses the model that all fromMe messages display 'to' and all toMe messages display 'fr' in the Who column.

10927 Make 'Edited by' in the Who column, transient for messages
+ This addresses the problem in Scenario 1 where if a message item is shared, the 'fr/to' attribute (which we think is the most important Who-attribute associated with message items) is lost forever from the Who column as soon as that item is edited. However, we don't want to be overzealous in preserving 'fr/to' metadata because it's also very important for sharing subscribers to see who last changed items in a shared collection. Bug 10927 would make it so that 'Edited by' displays 'temporarily' in the Who column, long enough for users to get an impression of who changed what in the shared collection...but not permanently such that 'fr/to-ness' is lost forever in the table.

10925 Display 'to' if message is neither fromMe nor toMe
+ This allows us to better server Scenario 2: Sharing group task lists and seeing who tasks are assigned to in the Who column.

Phase 2
10933 Don't change the Who column and Comm Status column when editing sent/recvd messages
+ I would have added this to Phase 1, but I have information that this is not a piece of cake to figure out. The reasoning behind this bug is that most of the time when users edit messages that have already been sent/received, they are not doing so to send it out again as an update. So until we have a way for users to explicitly specify whether they're editing just for the sake of editing or editing for the sake of updating, let's err on the conservative side and assume they're editing just for the sake of editing. This means that if I edit an email I received, I will continue to see no icon in the Communication Status column, as in, I will *not* see an outbound-draft-update icon AND the Who column won't replace who the message is 'fr', which is really what's important to me, with who the message is 'to' (which in all likelihood is me, since it's a toMe message).

10928 Temporarily display 'Last modified date' in Date column for Events and/or items with Ticklers
+ This is to make the Date column behave more consistently with the Who column as described in bug 10927 above. I only have this in Phase 2 because I'm assuming it's a bunch of extra work. If it's the same as bug 10927, we should do these 2 things together.

10930 Better visual feedback for 'transient' 'ed' and 'last mod on' attributes in the Who and Date columns
+ This is to provide better visual feedback, to warn users that the Who and Date columns 

Phase 3
10931 A way to specify what attribute you see in the Who and Date columns
+ This would provide users with the ultimate flexibility for specifying what they see in the 'Who column' to satisfy specific use cases like:
- Sharing group tasks lists and seeing which tasks are assigned to whom. If we do phase 1 and 2, we roughly have this scenario covered, but there will *still* be the case where a task is assigned 'to you' and is therefore considered a 'toMe' message and displays 'fr' in the Who column.
- Searching by a particular Who attribute

Future
10932 More specific flavors of 'From' and 'To'
+ Like Assigned by, Organizer and Assigned to, Invite     
+ By making the semantics of From and To more explicit, users may have an easier time figuring how use the 'From' and 'To' fields to do things like assign tasks and send invitations.

Open Issues
Philippe also had a suggestion for suppressing 'Created by' and 'Edited by' in the Who column for non-message items, even if those items are shared. This would in effect, leave the column blank whenever 'you' create or edit a none-message item.

There's been little controversy over suppressing this metadata for non-shared items. However, the thinking behind showing it for shared items was that it was useful for people to see what items they cr/ed versus what items other people cr/ed. However, Philippe pointed out that:

+ Even when collections are shared, they are often shared for the sake of sharing with yourself, not with others; OR they are shared with others who don't really edit the items very much. So mostly, all the items are cr/ed by 'me'.
+ For collections that are shared with and actively edited by others, users can still infer that they cr/ed an item by the lack of metadata in the Who column. In other words, blank Who column = cr/ed by 'me'.

I was about to log this bug and describe the above behavior. However, I realized that there is the funny case where you have a shared item that was last edited by someone else and then you come along and edit it and the Who column goes blank. Is that too weird?

Mimi



_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
Morgen Sagen | 2 Oct 19:13 2007

Automatic restoration of published shares

Last week Mimi and I talked about ways to streamline the process of
hooking Chandler up to collections the user has previously published
to their Cosmo account.  A couple example scenarios are:

1) Someone has two Chandlers running, and wants collections that were
published from one Chandler to appear in the other automatically

2) Someone is reinstalling Chandler and has collections on the server
they want to sync

In either case the user could use the Tools > Save and Restore >
Restore Published Shares menu item, but it might be nicer to automate
the procedure a bit.  The questions are:  how automatic do we want it
to be, and at what time(s) should Chandler query the server to look
for collections we own on the server?

I usually have one or two test collections on the hub that I don't
normally want to appear in Chandler, but we could call that a corner
case (I could always create a separate server account to own these
test collections).  Do we want the user to be able to select which
collections get restored (like the Restore Published Shares dialog
does today)?  Or should Chandler just restore all the collections
their server account owns?  Should there be any indicator in the UI
that the restore process is happening, or should it be all in the
background?  If in the background, where do I display errors, and will
the user be surprised to see collections suddenly appearing in the
sidebar?  I suppose that could be a pleasant surprise.  :-)

Next, how should the restoration be triggered?  We could add a button
to the account dialog, or perhaps we trigger it when the accounts
dialog is closed.  I suppose the restoration process could take place
at the beginning of each sync.

Anyway, those are quite a few questions for one email, and I'll let
Mimi ponder those.  :-)

After typing all this up, I guess my feeling is this should all be as
transparent as possible, ideally with no additional UI to hook up
Chandler to existing published shares.  The best bet would would
probably be to have the process take place at each sync so the user
doesn't have to do anything special to trigger it.

~morgen
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

Mimi Yin | 2 Oct 20:36 2007

Re: Automatic restoration of published shares


On Oct 2, 2007, at 10:13 AM, Morgen Sagen wrote:

> I usually have one or two test collections on the hub that I don't
> normally want to appear in Chandler, but we could call that a corner
> case (I could always create a separate server account to own these
> test collections).  Do we want the user to be able to select which
> collections get restored (like the Restore Published Shares dialog
> does today)?  Or should Chandler just restore all the collections
> their server account owns?

Yes, I think we should just call this a corner case and let users  
deal with it themselves, either by deleting collections from Chandler  
Desktop after restoring them or using a separate account as you  
mentioned.

> Should there be any indicator in the UI
> that the restore process is happening, or should it be all in the
> background?  If in the background, where do I display errors, and will
> the user be surprised to see collections suddenly appearing in the
> sidebar?  I suppose that could be a pleasant surprise.  :-)

I think we should make it modal. It's a set-up task after all, just  
like reload, so I think it's okay to lock down the UI and make the  
process 'transparent' so that users are sure to see errors and whatnot.

>
> Next, how should the restoration be triggered?  We could add a button
> to the account dialog, or perhaps we trigger it when the accounts
> dialog is closed.  I suppose the restoration process could take place
> at the beginning of each sync.

Let's kick it off when users close the accounts dialog and see if we  
get any complaints before adding more UI.

>
> Anyway, those are quite a few questions for one email, and I'll let
> Mimi ponder those.  :-)
>
> After typing all this up, I guess my feeling is this should all be as
> transparent as possible, ideally with no additional UI to hook up
> Chandler to existing published shares.  The best bet would would
> probably be to have the process take place at each sync so the user
> doesn't have to do anything special to trigger it.

Yup, I think we're on the same page then.

>
> ~morgen
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> 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

Mimi Yin | 2 Oct 20:38 2007

Re: Automatic restoration of published shares

Question: Is this going to have funny interactions with reloading  
your data?
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

Mimi Yin | 2 Oct 20:52 2007

Re: Updating share items results in false positive conflicts

On Oct 1, 2007, at 11:35 AM, Morgen Sagen wrote:

>> 2. Capture and send the 'last synced version' of an item when  
>> sending it out
>> via email so that Chandler Desktop recipients can tell if the  
>> sender/updater
>> edited the same version of the item they have.
>
> I don't think this is something that can be solved by only changing
> the way edit/update works because that would just solve the case where
> the item is received via sharing prior to receiving a different copy
> via email.  If the order were reversed and the item arrived via email
> and then a different copy arrived via sharing, the differcences would
> still be in conflict.

Morgen, when would this happen? When would the sharing sync version  
of the item be different from the email version?

In the example with Philippe's update, the updated version was the  
same as the one Jeffrey would receive via sharing sync. So there  
wouldn't have been a conflict.

If Philippe edited the item again and synced, would Jeffrey's  
Chandler be able to tell that Philippe had edited the version J  
received via email?

> You can even get these conflicts for an item in
> two shared collections without involving email:  if you are sharing
> collections A and B with me and an item is in A, but I copy it to B
> and make a change, then you sync only collection B, any changes I made
> will be in conflict on your item until you sync A (at which point the
> conflicts will disappear automatically). This is not a scenario people
> are likely to run into.

Sorry, I'm not understanding the item in 2 shared collections thing.

>
> So I am thinking that if I fix bug 10877 that will at least make the
> problem less likely to appear.

This is definitely a good start. We may not need to do more than this.

> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> 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

Mimi Yin | 2 Oct 23:23 2007

[Cosmo] [Desktop] Planning update

Design discussions on the list have started up again in earnest. Let's take a pause to summarize where we're at with design issues, bugzilla tasks and new feature work. The following is divided into:

1. Stuff that's ready to go
2. Stuff that needs more discussion
3. Still need to introduce to the list
4. New feature work introduced to the list

Stuff that's ready to go: 

1. Phasing proposal for improvements to the Who column: http://lists.osafoundation.org/pipermail/design/2007-October/007685.html and bugs logged.

Next action: Bug Council to assign bugs to release milestones. (We can probably fit some of the proposed tweaks into 0.7.1)
 
2. Proposal for improving Triage Sort was discussed back in May and logged as a bug. 

This is a significant change and may have serious performance consequences which may take us back to the drawing board. Probably not doable for 0.7.1, but should definitely investigate sooner rather than later.

Next action: Bug Council to assign bugs to release milestones.

3. When events pass in time, auto-triage them to DONE: http://bugzilla.osafoundation.org/show_bug.cgi?id=7894

4. Fix the 'from' field issue for sharing is logged as a bug and is also being discussed on the list in the context of a larger discussion of how to translate EIM fields into end-user attributes. In the short-term however, we should probably fix the 'from' field issue first because we know it's causing frequent (mis)triage problems in the Dashboard.

5. Implement notion of an edit session (so that the recurrence edit dialog doesn't keep popping up): https://bugzilla.osafoundation.org/show_bug.cgi?id=8242 

6. Improve event description text for items sent via email. Jeffrey and I and Jeffrey and bkirsch have had separate conversations about this. Our plan is summarized by Jeffrey on the wiki and logged as a bug. 

=====
Stuff that needs more discussion:

1. Rationalizing URLs and Keeping Desktop and Hub in sync.

Related threads include
+ API for accessing list of subscribed collections: http://lists.osafoundation.org/pipermail/cosmo-dev/2007-October/004840.html

2. Securing access to items in multiple collections

=====
Still need to introduce to the list:

1. Allow users to remove individual items from the Dashboard collection and rationalize Remove/Delete model for OOTB collections.

2. Improving conflict resolution experience

=====
New features introduced on the list:

Overlays in web UI
Month View for both desktop and web

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
Morgen Sagen | 2 Oct 23:39 2007

Re: Updating share items results in false positive conflicts

On 10/2/07, Mimi Yin <mimi <at> osafoundation.org> wrote:
> On Oct 1, 2007, at 11:35 AM, Morgen Sagen wrote:
>
> >> 2. Capture and send the 'last synced version' of an item when
> >> sending it out
> >> via email so that Chandler Desktop recipients can tell if the
> >> sender/updater
> >> edited the same version of the item they have.
> >
> > I don't think this is something that can be solved by only changing
> > the way edit/update works because that would just solve the case where
> > the item is received via sharing prior to receiving a different copy
> > via email.  If the order were reversed and the item arrived via email
> > and then a different copy arrived via sharing, the differcences would
> > still be in conflict.
>
> Morgen, when would this happen? When would the sharing sync version
> of the item be different from the email version?

If someone emailed me a new item, then they made a change to the item
and added to a collection we both share, when I next synced the
collection that copy of the item would be different than the one I had
received via email.

> In the example with Philippe's update, the updated version was the
> same as the one Jeffrey would receive via sharing sync. So there
> wouldn't have been a conflict.

There would only be a conflict between the time Jeffrey received the
email and the next time Jeffrey synced the collection (well, at least
after I fix bug 10877).

> If Philippe edited the item again and synced, would Jeffrey's
> Chandler be able to tell that Philippe had edited the version J
> received via email?

Yes.  Once you have received an emailed item from someone, you now
have a baseline to compare future incoming (and outgoing) changes to.

> > You can even get these conflicts for an item in
> > two shared collections without involving email:  if you are sharing
> > collections A and B with me and an item is in A, but I copy it to B
> > and make a change, then you sync only collection B, any changes I made
> > will be in conflict on your item until you sync A (at which point the
> > conflicts will disappear automatically). This is not a scenario people
> > are likely to run into.
>
> Sorry, I'm not understanding the item in 2 shared collections thing.

The rule is: the first time an item arrives via a shared collection
***, if you already have a copy of that item in your repository, any
differences between what you have and what is inbound is a conflict.
So in this case, you already had the item (because it was in A), but a
different version of it arrived via B for the first time.  Does that
help?

*** You can also substitute "a shared collection" with "email from a
given address" to make the rule apply to edit/update.

~morgen
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design

Mimi Yin | 4 Oct 20:35 2007

Bug 10928: Temporarily display 'Last modified date' in Date column for Events and/or items with Ticklers

https://bugzilla.osafoundation.org/show_bug.cgi?id=10928: Temporarily display 'Last modified date' in Date column for Events and/or items with Ticklers

I logged this bug as a part of the set of 'Improvements to the Who column in the Dashboard'. See list for summary: http://lists.osafoundation.org/pipermail/design/2007-October/007685.html

The idea was that when shared items are edited and pop to the top of the NOW section, along with always displaying 'who last edited' an item, we should also always display when it was edited thereby overwriting the event date and/or tickler date temporarily,where temporarily means 'until the user clicks on the item and it goes from unread to read.

I worry about this for a couple of reasons:

Dissonance between the 'reminder/calendar stamp' column and the date column. The former is supposed to function as a visual cue for 'what kind of date' is being displayed in the date column. I'm concerned that a 'reminder/calendar' icon next to 'last modified date' will be confusing.

We could temporarily remove the 'reminder/calendar' icon, but I think they're useful visual cues to keep around because they help users identify what the item is...'Oh so-and-so edited that event for next week.'

I'd like to try out https://bugzilla.osafoundation.org/show_bug.cgi?id=10927 Make 'Edited by' in the Who column, transient for messages and get a round of feedback on that before proceeding with 'syncing up the Date column and the Who column. 

I am concerned that bug 10927 will confuse people, but I'm not sure yet what the right visual feedback should be to allay that confusion. What I do feel fairly confident about is that losing 'fr/to' information in the Who column permanently to 'Edited by' is bad.

(FWIW, there *are* already other instances where the Who and Date columns are *not* in sync. For example event items that are addressed will display either fr/to in the Who column and the event date in the Date column, not the 'sent/received' date and I'm not sure if having the 2 columns in sync is more important than displaying the 'the most important Who/Date attribute'.)

Mimi





_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
Mimi Yin | 4 Oct 23:32 2007

Re: [Sum] Improving the Who Column (nee Chandler IMAP folders and the mail-stamp)

https://bugzilla.osafoundation.org/show_bug.cgi?id=10961

Okay, I logged a bug for this with your caveats in there and assign  
it to myself. I think I'd like to wait for more feedback on this  
before implementing this tweak. Perhaps wait for users to ramp up on  
sharing scenarios and/or using the addressing fields to attach who- 
ness to items.

The prevalence of 'cr/ed me' your experience may be a symptom of an  
unclear Who column design and perhaps generally making the Who column  
more useful to people will end up being a better way to address this  
problem.

Does that sound reasonable?

Mimi

On Oct 4, 2007, at 12:47 PM, Philippe Bossut wrote:

> Hi Mimi,
>
> Well, that resumes my position fairly well and I'll stand by this  
> writing :)
> It's true about the items that are collaboratively edited. May be  
> we could do a sort of double check on the whole history of the item  
> as in: if the item has been created by <me> and consistently on  
> only edited by <me> then display nothing in the Who column. Not  
> sure this is an easy to extract info though. Conceptually, it's how  
> I saw the "blank == <me>" in my head.
>
> Cheers,
> - Philippe
>
> Mimi Yin wrote:
>> Hey Philippe
>>
>> Could you take a look at this when you have a moment? I didn't log  
>> a bug for this feature b/c I ran into some design issues. Would  
>> like to get your input.
>>
>> Mimi
>>
>> Begin forwarded message:
>>
>>> *Open Issues*
>>> Philippe also had a suggestion for suppressing 'Created by' and  
>>> 'Edited by' in the Who column for non-message items, even if  
>>> those items are shared. This would in effect, leave the column  
>>> blank whenever 'you' create or edit a none-message item.
>>>
>>> There's been little controversy over suppressing this metadata  
>>> for non-shared items. However, the thinking behind showing it for  
>>> shared items was that it was useful for people to see what items  
>>> they cr/ed versus what items other people cr/ed. However,  
>>> Philippe pointed out that:
>>>
>>> + Even when collections are shared, they are often shared for the  
>>> sake of sharing with yourself, not with others; OR they are  
>>> shared with others who don't really edit the items very much. So  
>>> mostly, all the items are cr/ed by 'me'.
>>> + For collections that are shared with and actively edited by  
>>> others, users can still infer that they cr/ed an item by the lack  
>>> of metadata in the Who column. In other words, blank Who column =  
>>> cr/ed by 'me'.
>>>
>>> I was about to log this bug and describe the above behavior.  
>>> However, I realized that there is the funny case where you have a  
>>> shared item that was last edited by someone else and then you  
>>> come along and edit it and the Who column goes blank. Is that too  
>>> weird?
>>>
>>> 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


Gmane