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.

Comments

Link Broken, here's the fixed linke

[mystik]

http://sourecforge.net/projects/reefkn ot/

My Wishlist:

[crucini]

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!

Collaboration

[Skeezix]

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

[Phrogman]

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.

My priority is...

[DeepDarkSky]

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...

[pstorry]

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!

My Dream Specs

[LHOOQtius_ov_Borg]

...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:

[Alomex]

• 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.