[Design] Scoping out sharing-related 0.7 projects
jeffrey at osafoundation.org
Mon Feb 6 13:58:41 PST 2006
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
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"
More information about the Design