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
