What Would Your Dream Calendar Program Look Like?

srl sends in this query: "I'm on a project team for Reefknot, which is building an open-source/free shared calendar server. This is not a replacement for Evolution; this is a server that any iCal-capable client can talk to, to do group scheduling and event planning. It may also include project-management features. In short, we want people to have a free alternative to MS Exchange's calendaring features. We are in the pre-alpha design stages, and we want input from end users of calendar software. This might be you, it's definitely your boss. So, we want to know: What does your enterprise calendaring software do that you like? What do you hate about it? Why? What features should we implement to be competitive with existing commercial software?" We've recently talked about Exchange, and calendaring functionality is one of the reasons that it keeps finding its way into the enterprise. If you've ever wanted an alternative, now is your chance to speak up.

sweet.. here are my needs

It would have to be able to interface with a mail program. I have not tried evolution, but if it could interface with that it would be nice. Netscape as well or pine && emacs too.

Of course it would need to work under Linux.

I'd need to be able to easily sync it with my palm pilot.

It would need audio reminders.

It would need to be able to interface with with my address book (netscape or evolution).

I'd need to be able to check to make sure that others were not busy and check their schedules as well. Similar to that of MS schedule.

I'd need to be able to schedule appointments with those using Outlook as well.

Basically what I'd need would be Outlook functionality on Linux. Thus I would not need a windows box anymore. Okay now it is not that I hate using windows, it is just that there are some things that are easier to do under Linux for me. I do lots of server side development and our servers are linux and solaris and BSD. So rather than sshing into the servers I have a linux box at work that I do my devlopment on then I port to the other 2 UNIXes. To do this development on windows is not possible as the porting is much more complicated. (Think apache modules, perl, php). I have a windows box that sits so I can check my email and check somepages in explorer when I need to. To have that functionality on Linux I'd never use windows.

I don't want a lot, I just want it all!
Flame away, I have a hose!

Link Broken, here's the fixed linke

http://sourecforge.net/projects/reefkn ot/ [sourceforge.net]

Some ideas for you

Your obviously trying to find a balance between pretty features (GUI) that suits will like and reliable and fast solid backend that techs will like.

1st and most important, it /must/ have a graphical interface. It doesn't matter how reliable, scalable, or enterprise ready it is, if it isn't easy to use. You don't have to send any graphical data over the network, just have a GUI interface.

2nd, it must be intuitive. One of the biggest mistakes most programmers make is making programs that are intuitive for programmers. Design the interface with the CEO in mind. He doesn't know a damn thing about technology, and doesn't want to.

3rd, you have to have a central database that is resistant to corruption. There can be corruption issues with opportunistic file locking (enabled by default on windows, disabled by default on novell), or virus scanning (particuraly heuristic) programs that are allowed to touch the central database.

4th, is version control. One way to do this would be to set up a version counter that is incremented on the servers (never clients) time. This should also check to make sure that incoming requests are coming from machines with the correct date. This may sound unlikely, but it is decently common. If the date is off, you need to send a clear message declining their ability to use the calender and why.

5th, is widespread availability. If you truly want a replacement for MS's calendering functionality, you've got to make sure that you have a client that is available for Win95 and up. Even though Redmond is selling W2K and WME, corporations are still predominantly going to run 95 or NT 4. I would certainly encourage a Linux and Mac client as well. If you can, wait to release all clients at the same time. Many people will only evaluate a product when it comes out. If they see that they can only use this on some desktops, they aren't going to be checking again in a month to see if you added an Solaris client.

6th, make sure it uses TCP/IP. This may not be the most efficient protocol, but it is the most widespread. Your going to have a very hard time convincing almost any administrator to implement anything else.

7th, make sure it generates a small impact to network traffic. Don't upload or download redundant or unrelated data. There is no reason someone in marketing needs to know that the helpdesk is going to have a barbeque. The perception of speed is going to be based on this. If users have to download large files, this will have an impact.

8th, make sure this ties with MS email clients. The people you are trying to get to use this are going to use exchange, outlook express or outlook. If something is scheduled for someone, tying this is the central address book on the exchange server to notify those involved is important. Likewise, try to cull data from the global address books on the exchange server (and PAB of the client) for your database of users. This can avoid having multiple redundant databases which can be hard to sync. This also allows people to add people to meetings etc with the same naming conventions that they have already learned.

9th, syncing with remote clients. If a remote client isn't able to connect to the network, they shouldn't be able to schedule anything for anyone else than themselves. Also, and very important, if someone is dialing into the network, allow them to decline updating their calender. This can save very valuable time when connecting to the network for other things (like a server going down). It would also help to build in support for Palm Pilots along these same lines.

10th, is to avoid arrogance. You may be highly skilled programmers, with a wonderful open source product. But if the guy who has to implement this isn't familiar with Unix (remember this is intended to be a replacement for MS products), or feels the documentation (or lack thereof) is talking down to him over this, he won't be able, or want to use it. Assuming that the only competent network admins are *nix users is probably one of the biggest turn-offs to open source software in the corporate world.

11th, make sure this can be remotely configured. A good way to make sure it can be configured regardless of client ws OS is to give it a html interface.

server side & client side client

It would be nice to see an implementation of a client using a set of Java classes. If designed properly, these Java classes could then be wrapped in a Swing-based GUI (client-side application) or in a JSP-based tag library (server-side application). The end result would be the same core libraries providing both a client-side app and a server-side app.

If properly designed, this would allow multiple web-based clients--one for WAP, one for HTML + Javascript, one for plain HTML, etc. And client-side Java under JDK1.4 (not out yet--I've seen some alpha-tests) is really quite acceptable. The main advantage, though, is that you'd be using the same core for multiple clients. If you add a feature in the core, all the clients get the feature.

Of course, the client application should also be sufficiently disassociated from the server application, allowing native clients (C++ or C or whatever) as well. But there is a real advantage to having a sample implementation done in Java.

My request

1. Provides several methods for notifying me of an impending event. Examples: making my computer beep, sending email, paging me, even calling me.
2. Methods for importing data from other calendar services. I use Netscape's online calendar.
3. Cross platform. I have Mac and OS/2 clients which would need to use it.
4. Ability to email appointments in some standard cross-platform format to other people, so that they can update their calendar (even if they use a different service) with the appointment. I've always found this to be a sorely missing feature. For instance, often I would email my friends about upcoming events, like a party. It would be great if I could attach some kind of file which would be known to any calendar application. Then the recipient could update his calendar with the schedule if he wanted.

--

It depends on the bandwidth doesn't it?

In the high bandwidth world maybe something like the rich complex group calendar functions in Notes is the way to go. Granted Notes works in a dialup mode but I'd hate like hell to have to check a group calendar that way. The best way to approach that is to send out invites and allow the recipient to reject or accept which isn't much of an improvement at all really. What you want to be able to do is search for free time by person in a group by various categories: classifications of work, priority topic and then allow for or disallow things like double-triple booking, selective autoprocessing of inbound and outbound invites.

Then there's the whole subject of shared vs. partially shared vs unshared address books. You want to be able to respond to a message or a calendar entry or a note in one but you also want to respond to every name in a list of recipients as well as some that are not on the list and not respond to some that are. Parts of the local address book should be shared upstream for common use as long as deltas for shared entries are handled correctly. If you look at Wesync they try to do this with some success. It sounds like a shared lock while update problem on a relational DB.

The application has to allow for automatic handling of entries inside/outside of the profile so that something happens differently when you are requested or request someone to atten a meeting @ 4am or some outlier time. You also need to handle timezones so that the shared address book has some notion of the recipients time zones. Without this you would have to know the timezone of every recipient. What you want to do is have the calendar function automatically adjust the local time. You also have to handle DST. Next you have to be able to allow for local timezone adjustments outside of the calendar so that recipients can travel and plug their new timezone in a temporary profile override.

Now all this is fine and good in, as I said the high bandwidth world. In the low bandwidth or wireless world you have a different notion of the timeliness of a shared event or a shared data entry and how you reconcile multiple updates to the same sahred event are different. For example you can send invites to many people. In one scenario you have agree/reject or you have autoprocess for a majority or you reject the whole list for a single reject. Do you have a central server look for a best fit and reschedule the event based on that and then notify everyone on the list? Or do you rely on multiple iterations of a person's intervention to reschedule until some number of people agree on a time.

Next, how do you handle recurring events? Do you ship a whole entry down to the client for every occurence or do you have some different data structure that represents multiple occurences. And of so how do you edit each occurence later on if for example you happen to schedule something on a holiday and it has to be moved? The individual entry method is easier to handle after the fact as long as you repropagate updates upstream. But the multiple occurence data record approach works better for low bandwidth.

Last but not least you need a method to perform some level of authentication or record ownership so that only the originator or its delegate can chnage an entry if you deem that people should change a record after the fact or in the 'best fit' case. Otherwise scheduling chaos ensues if anyone can change any group event.

My Wishlist:

I'll avoid the obvious, since you already know what a good calendaring app does (I hope.)

1. Synchronous, "real-time" architecture based on either TCP connections always open from client to server, or UDP packets to update status. What I see on my workstation should never be out of sync with the 'real calendar'. Microsoft's message-based architecture is the wrong way.
2. Windows client that supports both synchronous on-line operation and disconnected operation (for notebooks). Of course if you make an appointment while disconnected, it stays 'tentative' until you sync, and may get rejected then. I don't like Windows or notebooks, but the reality is that the heaviest calendaring users use both. It would be nice to have a similarly featureful Unix client, but realistically most technical people don't like or use calendaring much, while calendaring is the lifeblood of suit/PHB types. The app lives or dies by how well it works for the suits.
3. Outlook compatibility. For now. Ultimately I assume Microsoft will twist Outlook's protocols to make this impossible.
4. Scalability without server sync issues. The existing calendaring apps seem to create 'separate universes' ala Everquest for people on different servers. Therefore you might think you've scheduled a scarce resource, and then find out later when the servers sync up that it was already taken. I think the preferrable architecture is one big database server with a ring of application servers around it.
5. Open API for non-trusted users. There should be a way for people other than the calendar admins to easily script reports, etc. without compromising security. It could just be a simple web interface that doesn't change much. This could also be used to write better clients. It goes without saying that you'd provide an open API for the admins to script to.
6. Fast response. Sounds obvious, but some calendaring apps are sluggish at enterprise sizes.
7. Transactional integrity - two users should never see contradictory information, such as two people thinking they've booked the same room. The only ambiguity allowed is on disconnected laptops, where the ambiguous status is clearly shown to the user.
8. Web access. I guess that's obvious, but please don't use Java or JavaScript or unnecessary graphics. Concentrate on speed, simplicity, and clarity.
9. Again, scalability. It's really easy to make a calendaring system that works on the small scale and can't scale. Once you're supporting far more users than can connect to one machine, you start wishing you had a good architecture. Maybe you should develop the app on a cluster of 486's to force scalability from the beginning.
   1. That's about it. There are lots of bells and whistles I could ask for, but all of them can be added if the API is open. Good luck!

When does the week start?

This may sound dumb to many people, but it annoys the hell out of me: all the calendar software I've seen has the week starting on Sunday. It may be so in the USA, but it is NOT in many other countries - I'd rather have my calendar setting monday as the startinng day. Even better if it's user configurable to any week day.

ALSO: a cousin of mine works in a company that has many deals with a japanese company, and she has to take into account both local holidays and japanese holidays. I've seen software that either

• has the holidays fixed (no config possible)
• has the holidays of one country and you can input more (but no way of distinguishing between both categories)
• has the "generic" holidays for many countries and displays them all, without any filtering chance.

I'd rather have a calendar that lets me mark holidays for several different countries (user configurable, of course) and marks them differently (green for my country, blue for japanese, for example).

Collaboration

The main thing I love about an exchange type setup is having the ability to share your appointments with other users. A manager can schedule meetings and events that will show up on everyone's calendar. Another nice feature would be build-in holidays in the database. It's annoying having to check a "real" calendar for what dates holidays fall on and then enter them manually in my calendar.
----

Re:Collaboration

It would be good if it can also automatically find a time and day that each individual invited to the meeting is free to meet. So all you have to do is select the people and let the software do the scheduling negotiations to arrange the meeting time. I believe Exchange can do this, but since our Exchange server is just being set up (precisely because we need these calendaring features in fact) I don't know yet for sure.

Enhanced calendar features

One limit with Exchange that my company reached was a ceiling for the number of contacts that it can manage. We have custom contact management software, and for various reasons we wanted the contact list available directly through Exchange. I don't know exactly what the limit is, but it couldn't store our 150,000+ contacts.

As for features, I'd really like to see good project management capabilities. Right now, I can't even find the feature I want in any project management software (please post any especially good ones if anyone knows of any). Employee calendars and project management should be easily tied together, and for obvious reasons. For example, if my department has a meeting about a specific project, I want it tied into any project mgmt reports. Ghantt charts (however that's spelled) just don't cut it for me. I should easily be able to see if my co-workers are busy, and if mgmt allows, let everyone see what projects everyone else is working on and on what schedule. With Outlook you have to arrange a meeting, then it compares to their calendars, but sometimes I'd like to just see everyone on my calendar, and I'm sure mgmt would love that. And of course other obvious features are speed and expandability. VBA in Outlook/Exchange stinks. The object model is bulky and very slow. I want to be able to drastically customize the calendar (for myself or anyone else I choose), maybe adding features myself.

My priority is...

not so much on the functionality than on the data interface. What I am saying is, it is more important that a standard interface using a standard way of communicating data from server to client and vice versa, such as an XML application, is vastly more important to me than how it looks and what it can do, at least at first.

Once you establish, for example, how your client can query a calendar of scheduled appointments and events given some criteria (or not), a calendar server, at least as far as I'm concerned, merely need to serve up the data. Let some other third party (another website, let's say, or some kind of java frontend, perhaps a WAP device of some sort - anything at all is possible) handle displaying the information and presenting it to the user.

In this way, the calendar server is only responsible for serving up the data, and you wouldn't care about the capabilities of the client, because after all the client will determine its own capabilities and process and display the data according to what it can do.

For end users...

End users are typically most impressed by the following features:

• Ability to differentiate between calendar entry types - e.g. Appointment (Normal calendar entry), Meeting (Calendar entry that is also sent to others so that they can choose to place same entry into their calendar), Event (All day calendar entry, usually used for holidays/days off), Reminder (Start time is same as end time - no time marked as being used, as it's only there to remind you of something) and Anniversary (A reminder which repeats anually or even less frequently).
  
• Creating a calendar entry should automatically mark their time as bsy for the duration of that entry, unless it's a Reminder or Anniversary. Or unless they choose to "pencil in" the item, in which case it's nor confirmed so it's not advertised to other users
  
• Ability to look to other user's free/busy time when booking meetings
  
• Ability to schedule repeating calendar entries - must be flexible - e.g. options like every N days, every day of week, every Nth day of month. Also the ability to move the appointment to friday/monday if it falls on a weekend to be incorporated here.
  
• Ability to look at other people's calendars
  
• Ability to mark calendar entries as private, so that other people won't see them when they look at your calendar. (The time tey take should still be marked as busy unless otherwise specified by the user, though.)
  
• Ability to look at calendar using the following views: Daily, weekly, 5-day weekly, fortnightly, monthly, yearly planner
  
• Ability to categorise your appointments
  
• Ability to set reminders for your appointments
  
• Ability to email reminders for your appointments
  
• If you're doing anything with to-dos, integrating them into the calendar is nice
  
• Conflicting entries must be marked clearly in all views. Checking for conflicts before you accept an invitation to a meeting/create a new calendar entry is also a must.
  
• The administrative team should be able to create Rooms and Resources, which can be invited to meetings in the same way as people. This helps for scheduling of rooms, and also for things like projectors etc. Normally, booking should be done automatically on a first-come first-served basis, but you should be able to designate someone as the "owner" of each room or resource's calendar, so that they can confirm or deny bookings if necessary.

I'm acually coming from a Lotus Domino perspective, but if you put those features in you'll duplicate most of the important features of Domino's Calendaring and Scheduling systems. And the Yearly Planner view is one that Domino doesn't have, but users are crying out for...

One of the most impressive parts of Domino's C&S systems is the sheer scalability of it. You can have huge installations, yet free time lookups are easily handled by the system, even across WANs. You'll need some kind of referal system to handle this kind of stuff, otherwise it'll never fly in an enterprise. You can't have people's clients trying to cross the networks, y'see - but the servers will probably have access across WAN links to talk to each other. So almost all your free time stuff needs to be "referable" at the server side.

Also, you'll have noted that free time notation is seperate from the actual calendar. Free time should be stored somewhere else other than in the user's calendar, to make it easily scalable. It helps increase cache hits on the server, if nothing else. There would be nothing slower than having to open 20+ people's calendars to retrieve their free time information when booking a meeting with them. If it's all in one database, you're sorted then. If you're putting it all in one database anyway, make sure that free time is stored seperately in a table of its own. This should do the trick.

Note that free time is seperated from the actual entries anyway - sometimes you really do just want to pencil in an appointment, but not mark yourself as busy. Whenever we're asked why this feature is there, we can never think of a suitable example of why. But the person asking us usually gets back to us within a week with their own example... ;-)

Having seen the code that Lotus uses in their Calendaring/Scheduling systems, I have to say that the hardest thing to get right is the repeating appointments part. Good luck!

Just duplicate Ecco for me, please (-8

Several years ago, a company produced a PIM which was actually a disguised relational database -- the GUI included the usual pretty calendar, rolodex-style contact management, outliner, and notebook functions, etc. The same company (last aka was Net Management, I believe) produced a browser (for serial port connections, as well a telephone connections), FTP, and other useful products. Their PIM was called Ecco, and once you got the hang of how to use it (which didn't take long if you had the smarts, since you then began to use it to manage every other program and so were using it continually), it was wonderful. Then MS released its "free" calendaring program, and you know the result.

If you want to know how groupware should work, try to get hold of the manual for Ecco. If you do reproduce its functionality, I'm interested in your program. 'Til then, I'll just stick with Ecco, thanks.

Important: Don't leave out the part where I can set up project management/invoicing/expenses for my independent consulting, and shoot any data or combination of data as formatted ASCII to a template file prepared by my advanced WP program, using saved sets of instructions.

Two of Many

I can think of many key items I'd like in a calendar program but a few that are immediately relevant to what my department is trying to accomplish right now: 1. Document sharing. It is becoming increasingly important that we can share our notes from different meetings. This is mainly due to the fact personnel are meeting with different vendors, but all the information needs to be known to the entire department. A quick, easy way to upload note files for the entire department to reference, particularly through a search function, would be great. 2. Basic project management. A lot of our meetings are based on projects. If the calendar program could have a simple to-do list (with the option of a more advance system) that can assign tasks to specific people, that would be good. 2.

My Dream Specs

...in random order, really...

Accepts Outlook 2000 as a client on Windows

Provides an open-source O2k-like client for Linux and Solaris, giving integrated mail, contact management, and calendar a'la O2k

Also allows Web interfacing (over SHTTP), providing calendar, contact, and mail management via an HTML interface

Provides user and group calendars, multiple group membership for users, and administration ability assignable to users, groups, and all (so that assistants and secretaries can manage calendars for their employers and their groups)

Allows selection of which calendars to view, so that the user can see only their individual calendar, or their individual calendar and that of one or more groups they belong to

Automatic creation of group calendar entries based on project plans from M$ project and a similar program on Linux and Solaris (previously existing, or created by the project)
Tags deadlines as "modified" but doesn't delete them when changed using the project mgt software (can select to view modified only, or modified and previous dates in the calendar view)

Allow calendar entries to have dependencies (entered via Project-like software, but also in the calendaring system by clicking on another entry), and the ability to tag each calendar entry as success (in which case dependent entries remain the same) or push them back (in which case dependent entries all move back by same # of days)

Alert users and admins of conflicts between ALL calendars (group and individual) a user is subscribed to, when scheduling new events

Automatic notification of events when they are scheduled, and selectable reminder e-mail params (periodic or one time)

Periodic events

E-mail calendar notifications a'la O2k
Integration of contacts and calendar a'la O2k
Notification of accept / decline of attendees by e-mail a'la O2k; allow attendees to suggest alternate times and meeting scheduler to accept an alternate time and send a new meeting notice

Though client is integrated, back-end system should allow for separate mail and calendar servers (contacts could be stored in the calendar server, or, also separately ... using LDAP)

I can think of more... I'd be happy to join this project as a system architect if the URL were actually working...

Wish list:

• accessible through a web browser.
• ability to send reminders to wherever you are logged on, e-mail, pager, cell-phone...
• synchs with palm pilot
• search for available time among all attendees of a meeting
• ability to attach documents to a meeting (agenda, attachments, etc).
• ability to attach minutes to the meeting after it happened
• create critical paths between events
• recurring appointments
• different settings for reminders (for homework deadline remind me a week before, for a work meeting five minutes before)
• day/week/month view
• ability to cut and paste a text date (Say from an e-mail or web page) and have the day and time pop up.