[Kolab-devel] How to deal with multiplied Kolab UIDs

[Florian v. Samson]

Hi Georg,

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 
correct, then).

"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 
on MS-Exchange. 

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. 

HTH
   Florian

P.S.: 
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 
(including "complete"). 
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 
revisited.
- 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.