[Dev] Re: [Design] Scoping out sharing-related 0.7 projects

[Sheila Mooney]

I just wanted to point out that any kind of sophisticated conflict  
resolution or versioning handling UI is out of scope for 0.7. We will  
likely implement things in stages but the first step for all of this  
will be to record the conflicts and log them in a way a user can view  
them and manually make updates if they choose to. Once we get that  
working (just to understand more about when conflicts are happening),  
we can figure out what enhanced UI would be the next logical step.  
Perhaps some of this will be done during 0.7 but I think it's  
important to get something primitive up and running first.

We do need to make a decision about how we will handle attributes  
that are currently being edited in the UI and are modified via  
background sync. Mimi is about to post something on the design list  
that focusses in on this discussion further.

On Feb 6, 2006, at 1:58 PM, Jeffrey Harris wrote:

> Hi Folks,
>
> I, too, am late to this thread, sorry.
>
> Bryan Stearns said:
>> This indicates that we end up needing a way to present two detail  
>> views
>> side-by-side. For approach 1, we'd also need to teach attribute  
>> editors
>> to conditionally display the "local" or "remote" version of the item;
>> for approach 2, we'd need to teach them to incorporate newer  
>> values from
>> a UserNotification item. Either way, this mechanism also requires
>> support from the change-notification mechanism (since the detail view
>> uses the change-notification mechanism to communicate with  
>> itself), and
>> would require CPIA work to handle two rendered detail views at once.
>> (I'm sure there's more than this, but I'll wait until more work's  
>> been
>> done on an intended user-level design.)
>
> I'd been envisioning a slightly different picture of how we'd render
> different versions of what, in the user's mental model, is the same
> item.  Changes received via sync seem like a special case of the  
> general
> problem of several people editing the same (mental model of an) item.
>
> ==> As an aside, I have a suspicion in some cases we'll represent
> different versions using versioning in the repository, at other times
> we'll have different (linked) items under the hood, to match the
> "emailed item" model where there's no authoritative source of truth.
> I'm going to approach this by assuming we can work out the
> representation issues. <==
>
> Here's my picture, based on what I think I've understood Mimi to be
> describing about scheduling workflow.  If an item has multiple  
> versions,
> the most recent version would show up in the table view, but it would
> have a thread expansion widget associated with it to open different
> versions in the table view.
>
> This would avoid the need for multiple detail views; users could  
> scroll
> through different versions in the table view.  It would be nice to
> highlight changed fields to call out distinctions between versions.
>
> To do this at a basic level, the table view would need support for
> something like threads.  I don't know if that's doable in 0.7, but it
> feels like a more appealing path to follow than trying to render two
> detail views.
>
> In this model, there could still be an RSS style view of recent  
> changes,
>  it would be basically look like sorting a collection into threads
> sorted by an imagined "last time modified by someone other than me"
> attribute.
>
> Sincerely,
> Jeffrey
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design