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