Kolab client integration

Bo Thorsen bo at sonofthor.dk
Tue Jul 13 14:08:18 CEST 2004


On Tuesday 13 July 2004 13:37, Bernhard Reiter wrote:
> On Tuesday 13 July 2004 13:11, Cornelius Schumacher wrote:
> > On Tuesday 13 July 2004 11:03, Bernhard Reiter wrote:
> > > I guess I am allergic to strange "magic" criticism. ;-)
> > > Cornelius and many others can configure it
> > > and him saying: "Nobody can" is overplaying it.
> >
> > That's right. I was exaggerating to get my point through, that the
> > configuration is overly complex. It would be much easier with the
> > wizard. I think we agree on that.
>
> In general I think that wizards are suboptimal
> and usually a sign that othe parts of the design not good enough.
> Wizards can even lower the usability with introducing
> another way of doing the same think often with less understanding.
> Probably this is not the right place for such a general debate.
> With Kolab (and any groupware) users need some more understanding
> of the issues, a simple "configuration" is not the usual case.

I have to side with Cornelius when we're on the subject of setting up 
Kolab support. Only a few things are actually needed: Your name, login, 
password, email address and server host. Everything can be set up after 
this so Kontact behaves well in a Kolab setting.

Configuration *could* be simple, but it isn't.

There are two big problems with the wizard stuff in kdepim that stopped me 
when I tried working on it previously: It can only do initial setup, and 
the accounts of KMail is hard (almost impossible) to support. And a 
wizard that trashes your current settings is really suboptimal. That 
doesn't mean it's useless, because you do have to start somewhere...

> > What personally annoys me is that I spent time on creating the wizard
> > framework and implementing the KOrganizer side of the Kolab
> > configuration in the wizard, but then you did not pick up that work
> > and did not complete it although you promised to do this many times.
> >
> > > Michel's ongoing efforts are public at:
> > > http://kolab.org/cgi-bin/viewcvs-kolab.cgi/doc/proko2-doc/
> > > We do not have more internal documentation we could publish.
> >
> > The documentation belongs into the manuals of the client.
>
> Naturally, though it is better to have it there then to not have it.
>
> >That's one
> > important aspect of integration you have not addressed up to now.
>
> To make Proko2 possible at all we need to delay documentation
> until we have more important technical stuff done and properly
> integrated. You are saying that there are several "important" ones that
> we didn't do, and this is slightly overplaying again.
> I have seen many bad KDE documentations and blank spots
> even in the KOrganizer manual. I would not call it "important".
> Also I have not seen other "important" points, only the important
> bug about the collision you have mentioned.

A small point is that we almost did not have to touch KOrganizer for 
proko2. It's very few changes that have been done in it, and I think only 
the identity changes have been really significant.

The FreeBusy setup page lacks documentation though.

Bo.

-- 

     Bo Thorsen                 |   Praestevejen 4
     Senior Software Engineer   |   5290 Marslev
     Klarälvdalens Datakonsult  |   Denmark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.kolab.org/pipermail/users/attachments/20040713/4406e20e/attachment.sig>


More information about the users mailing list