How outlook compatible should Kolab be?(Re: Pre-KEP input sought: Priority for events? )

Bernhard Reiter bernhard at intevation.de
Fri Jun 17 13:06:23 CEST 2011


Hi Dough,

Am Mittwoch, 1. Juni 2011 23:22:06 schrieb Doug Finch:
> It may be that the majority of people
> don't use priorities in calendar events or tasks, but you will hear
> from the one company that uses them and now cannot.  Exchange is
> everywhere and because of that, whether we want to admit it or not, we
> all compete with it.  If Outlook has a feature that Exchange users are
> used to using - when we try to sell our product to them they will
> expect it to work there also.

this seems to be a general argument about how Kolab feature development
should be driven.

The two extreme positions as I see them are:
  We copy Outlook/Exchange as good as we can, including all defects
  and shortcomings.
                versus
  We offer new innovative solutions to the problems users are facing,
  which would mean users would need to learn a lot before they can make
  use of this better system.

Naturally we are currently somehow in the middle, which is good.
So we all agree that we do not want to copy Outlook, we want to shure users 
can solve their issues and they should feel at home to a certain degree.
Given the Kolab Format, we have to make sure users can get a very close
to complete Outlook/Exchange feeling. However it will never be perfect.

On the other hand: we should be a bit innovative as well.
User might learn to actually use some of the innovations of Kolab, like the 
folder security concept for the better and prefer it over the solution 
Outlook/Exchange could only offer them.

So for each feature I believe it will be a case to case decision
if it is used often enough or the solution better and can be discovered and 
liked by a large fraction of the users.

> As for handling both sides of the 
> equation, since there is no "priority" currently, we had to blaze our
> own method (see Shawn Walker's post) of handling these events so that
> our client (Bynari Connector) knows what to do with them.  

I agree that it is good to map how to behave in the cases
there is a difference.

> The reality 
> is that, even though our customers don't use Exchange, they may be
> interacting with people that do.  If an Exchange user sends a meeting
> request to you with a high priority assigned to it, the client must
> know what to do with that information.  
> Our Outlook users are going to expect to see it working.

Can you explain that use-cases in more detail?
We could for instance just map the priority in the text or the display.
Are there really people sorting their incoming meeting requests
by priority? And even if they did, after deciding for one meeting to attend,
would they need the priority still be saved and redisplayed?

Best Regards,
Bernhard

-- 
Managing Director + Owner: www.Intevation.net <- A Free Software Company
Kolabsys.com: Board Member          FSFE.org: Founding GA Member
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.kolab.org/pipermail/format/attachments/20110617/0733f39d/attachment.sig>


More information about the format mailing list