How to deal with multiplied Kolab UIDs
Florian v. Samson
florian.samson at bsi.bund.de
Mon Feb 6 10:32:59 CET 2012
Summary here, details & reasoning below:
Covering up technical defects in Kolab-clients by automatically discarding
Kolab-objects with duplicate UIDs is inevitably detrimental for the
user-experience, as these duplicate UID-objects may have been created
purposefully by humans in concurrent edits. Hence a manual conflict
resolution dialogue is a must, else user-made object-changes will be
arbitrarily discarded by Kolab from the user's perspective.
As the rate of technically induced duplicate UID-objects in pure Kontact-E35
environments is approaching zero, well-behaving Kolab-clients are a
feasible goal and IMHO the only way forward.
Am Dienstag, 3. Januar 2012 um 14:28:53 schrieb Georg C. F. Greve:
> On Tuesday 03 January 2012 14.00:04 Bernhard Reiter wrote:
> > b) there is a need for human coordination, because secretary S1 entered
> > something while secretary S2 entered something else at the same time.
> What are the statistics how often this happens in practice?
> Do we know how many percent of our users have two secretaries which
> happen not to be sitting in permanently connected offices and thus would
> be subject to this occurring?
> > Again, the last modification *must* not win in case b).
> FWIW, I don't agree.
> Point (b) seems very much a fringe case, and requiring user interaction
> for this puts an onerous burden on all clients which substantially
> reduces usability in all the most common scenarios.
The need for a manual conflict resolution is inevitable, in case of
concurrently edited objects (dates, contacts, tasks & notes), which results
in different content and IDs most of the time (which was called "case (b)"
in this mailing-list thread).
Simply discarding all but one of the changes will result in very unhappy
users, stating Kolab arbitrarily discards their edits (which would be
"IMAP Idle extended" (aka "Push Mail", i.e. IMAP Idle plus signaling of the
altered folder) would significantly reduce the time-frame in which a
conflict can be detected, but only slightly reduce the number of conflicts
created by synchronising more rapidly.
Still, as there is no IMAP-object locking, the time-frame which is needed by
an user to manually edit a Kolab-object must be taken into account: Hence
there are always a couple of 10 seconds to minutes in which another user
starting to edit this object will create a conflict!
Practically *this* (an object conflict caused by humans, named "case (b)"
above) does happen regularly (at least a couple of times a week) in a
medium sized environment, e.g. ~ 500 users, ~ 100 shared writeable folders,
each with ~ 7 - 20 users. While shared writeable calendar-folders can (and
should IMHO) be avoided by use-case modelling, they are, along with shared
writable contact-, notes- and tasks-folders a very often requested and used
feature, last but not least as this seems to be the predominant use-model
All such object conflicts caused by client defects should be resolved by
fixing the Kolab-clients, as they cause a very bad user experience, as you
already pointed out. This is emphasised by the fact that technical defects
usually result in object conflicts hardly resolvable by an average user.
Actually in a pure Kontact-E35 environment with ~ 500 users such object
conflicts induced by technical defects rarely arise nowadays, but in the
past and in mixed client environments this lead and may still lead to a bad
reputation of Kolab being heavy on irrelevant technical user-interaction.
The current conflict resolution dialogue in Kontact-E35 was a vast
improvement over the former one:
a. (Non-technical) user comprehensible wording.
b. Properly displaying where (in which folder) and between which objects the
conflict occurred: That information has to be concise
c. Properly naming and offering all available choices in a uniform manner.
Special attention has been payed to provide the optimal defaults.
See <https://roundup.kolab.org/issue4112> for screen-shots, past discussion
and design details.
Ideas for evolutionary improvements, as I expect any revolutionary changes
to the conflict resolution dialogue to fail in practise:
- The choice of not showing any details of the conflicting objects in the
first place was made on the assessment that neither displaying all details
on first sight (resulting in information overload & massive dialogue bloat)
nor selecting the crucial details *including* sufficient context to fully
understand the object-conflict was feasible, but the latter only due to
time and budget constraints. Hence that approach may be worth being
- The "scope" radio-buttons may be folded in an "Scope" expert-option (i.e.
flipping open on mouse click as currently the "details" buttons for the
object-details), as they are presumably only used by expert-users. This
might provide some space for the first suggestion, without much increase of
the total size of the conflict-dialogue.
More information about the format