How outlook compatible should Kolab be?(Re: Pre-KEP input sought: Priority for events? )
dfinch at bynari.net
Fri Jun 17 17:48:00 CEST 2011
Please see my comments below:
222 W Las Colinas Blvd, Suite 1540E
Irving, Tx 75039
Skype ID: dfsixstring
The Leader in messaging and collaboration software
From: kolab-format-bounces at kolab.org [mailto:kolab-format-bounces at kolab.org] On Behalf Of Bernhard Reiter
Sent: Friday, June 17, 2011 6:06 AM
To: kolab-format at kolab.org
Subject: How outlook compatible should Kolab be?(Re: Pre-KEP input sought: Priority for events? )
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
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?
First of all, I don't think this would be a "normal" for a user to sort calendar events like this. But an example could be a case where a user prioritizes (sets up an Outlook Rule) meeting requests based on priority. For all we know, that user may also desire to move all high priority events into a special folder. In this special folder they can sort by priority, or however they want to sort it.
As for our product (Bynari Outlook Connector), we currently store the priority information in the RFC header "X-Priority". If the object is groupware data, we can store the priority in the iCal and Kolab (contacts/tasks).
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
More information about the format