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.
The Citadel/UX project is slowly but surely moving towards becoming an Exchange-killer in more ways than one. It's a very extensive, modular system, originally targeted at BBS applications but being built up as a general purpose groupware platform. Currently the developers are working on getting IMAP support in place, but calendaring is next. With a robust data store already there, calendaring will be well supported.
It can already do SMTP and POP3 natively (i.e. you don't have to plug it into Sendmail to make it work on the Internet). The iCalendar protocols will be built-in in a similar way.
--
Tired of FB/Google censorship? Visit UNCENSORED!
Instead of providing the requested features which should be incorporated into this project - we have an insane Exchange sux vs Exchange is great debate! Having moderators bump this stuff up is even more crazy!
With that off my chest, let me proceed to actually answer the original post's call:
Sounds like you are already planning the most common group scheduling/calendar functionality. Basic email is a given as well. So that leaves the fine points to consider...
1) Consistency in and completion of the user and Admin interfaces - This is a priority, I've used/admin'd Exchange, Groupwise, Netscape Mail+Calendar+LDAP, and Notes. The huge weakness in the Netscape solution was interface. Simple adding of users was a nightmare since they had to be individually added to each component. We used a shell script to perform Unix, email, and LDAP account additions, then manually added the LDAP account to the Calendar program. All command line add/modify/delete utils used different syntax - so the script was ugly as Hell! When I left that company, I had just started incorporating the Calendar account in the script... UGH!
2) Stick with Standards! If a standard protocol or some such is lacking a needed feature, please document and submit the change to that standards body. Don't invent your own and keep it proprietary. That's MS's job.
3) Write your own client - and perform End-User Usability tests (with real PHB types). It's great that umteen different clients can connect and use all/some of it's features; but for a Corporate requirement, you need a full feature, easy enough for the executive admin to use client. This is the achilles heel of too many Open Source projects. You really need a 58+ year old "secretary" type to evaluate the client functionality, otherwise his/her boss is never consider it as a viable solution.
4) Some form of Disaster Recover functionality. Be it via hooks to 3rd party mirroring/clustering solutions, or integrated DR processes. Relying on backups of email systems when they exceed *GB of disk storage is unacceptable. In large-scale environments, some data redundancy is needed in case of corruption.
5) Finally, SNMP based management and traps. Again, in any moderately large environment you will find some form of SNMP based operations monitoring. I've used NetView, OpenView, and Managewise. You have to provide standard MIBS for these platforms and try to integrate as much operational monitoring as you can.
That's all I can think up at the moment. Too bad so much of this discussion went awry. I hope I, at least, was able to offer some valued suggestions.
I AM, therefore I THINK!
I'd like to add both my company's holiday list and that of my wife's company, with annotations so I know which are whose. And if the company didn't supply a file, I should be able to build the lists and email them to my wife. As this is an iCal app, that capability is undoubtedly there.
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!
Only 'flamers' flame!
Don't do that. Differentiate between local and global time.
As well as native and web interfaces, a Java interface would be a nice idea. Gives the extra flexibility over a web interface in terms of how the UI works, but also allows it to run on platforms that don't have a native front-end implementation.
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
Probably the best thing would be to make it a real groupware program, where you could publish/share just about everything......
It's either on the beat or off the beat, it's that easy.
I moderate therefore I rule!
--
http://sourecforge.net/projects/reefkn ot/
Why aren't you encrypting your e-mail?
Due to the fact that there will be migration issues, and other issues, I would assume that the "early adopters" of software like this would be techies who want to work fully in a Unix/Linux/BSD/whatever environment -- then it could be rolled out for other users when the following criteria are met:
Other niceties that would help get its foot-in-the-door would be: There's probably a lot more, but just typing out those sounds like a ton of work. These few are just some that pop out of my head on a quick analysis. There's probably a lot more. Good luck on your project, looking forward to playing with it someday!+++OK ATH
i'm a fan of wasting time on web bulletin boards.. but the reload/reload/reload/reload interface kinda sucks.
i'd like a web board that had an optional client side program that could show threads popping up in real time and let you expand/collapse or change views (ubb style vs. nested).. download all messages from last visit to current.. allow you to post publicly or to one person. etc..
it would blur the distinction between instant messaging/chat/e-mail quite nicely.
well, the calendaring would be secondary to the messaging, but for organizing a project on-line.. I think the flexibility would be useful.
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.
Smooth integration of all time functions without dumb limitations...
It has to do all the screwed up implementations of DST and interoperate between them.
http://www.timeanddate.com/time/ds t20 00b.html
It also has to be able to handle situations where people's days vary, in a variable way... For example... I'm in North America, somebody looks at my calendar and wants to book a conference with me in Europe. I should be able to indicate that I will be working from 9-5 in a different time zone for that particular week. It should not tell them they cannot book because I am not working those hours.
Another useful feature might be to see meetings from the perspectives of all the people involved. International teleconferencing needs this sort of thing... to be able to see that you're booking at 4:00pm in Germany while it's noon in New York.
(I think... I'll have to check my calendar on that one)
Most of my desires have already been mentioned except for this: cvs integration. Most of the big "enterprise" (cough, hack... I said "enterprise") software I've been looking at doesn't provide a nice way to share and update documents. In particular, it would be nice to be able to tie check-ins to message boards, email lists, schedules, etc... This isn't just for source code, this is for any document that must be maintained, be it documentation, source code, or html.
For example, if the document that describes our testing strategy has changed, the entire testing team as well as the developers need to be notified. This would provide the ulimate method for finding errors or miscommunicated information.
I suppose I'm not too threatening, presently, but wait till I start Nautilus
I believe you're mistaken 'bout that limit. Our enterprise address book has just about every person in our North American, European, and Asian offices (probably some in the other populated continents, too). I work for Motorola. I'm sure we have more than that number of people. They are, however, divided into domains. That might help in increasing the number you can use. (I dunno exactly how it works; I'm no exchange expert.)
My mind works like lightning. One brilliant flash and it is gone.
There's some great ideas on this list...
I hope my additions are worthy.
Let's keep in mind the technologies we'll have in the future. Especially bandwidth.
Maybe we'll want to have an option for webcams. Big bandwidth is more common now, and webcams are getting cheap. This weekend, Several local stores were offering them for free (after rebate). Although some people see webcam technology as bloatware, it may also be considered the "Gee-Whiz" factor that helps this software become mainstream. Personally, I'd like to see some sort of "shared whiteboard" type of plugin. It would be great if I could share a CAD drawing with a customer in another country and have the ability to move things arround on my screen in real time and let them see the changes. If they see something they don't like, they should be able to virtually draw on my screen.
Why bother having actual meetings in person if you could do most things over the telephone or over the net?
IMHO, The big question is, Who could most easily implement this software first?
My guess would be that educational institutions could. I think it would be pretty sweet to have my instructors post my homework on this bad boy. Maybe they could even have a script that automatically 'chmod's the answers to the last exam readable. Get students using this software, and it will be sure to have a future.
One last suggestion is to have the ability to implement this functionality into devices like the Pagers, Palm 7 devices, or cell phones. I'm already seeing a lot of people with these things, and although I don't expect them to replace PCs anytime soon, They will likely become the most convienient to use.
I organise my work by sub-projects. Each has a to do list, appointments related to sub-projects, I track my time, communications, contacts and I take notes that related to appointments and to do items.
I want a calendar that will not only keep an overall and individual project schedule, but which will keep a structured history database where I can take notes, then re-express the log and information as a LaTeX or HTML log book. That sort of log book is IMHO important not only for recording how I approached certain problems, but also as a record of what I was doing on a given day in case some dispute arises.
So in short:
As a general suggestion: the program authors need to study patterns of working behaviours. Take sets of individuals with varying degrees of personal organisation, and find out what functions in that personal organisational pattern can be usefully automated. Discover the commonalities in those patterns and then express them in a system. I'm probably not (quite) the most organised person on the planet, and have very definite working patterns that lend themselves to automation.
Firstly, a web interface is a must, but then it always is.
;) would be handy, if you'll excuse the pun.
Secondly, some easy way of synchronising it with popular PDAs (particularly Psions
Thirdly, a feature I'd love to see is the ability to schedule time based not on an individual user, but on some qualification of that user. It's all very well to say "Tell me whether John Smith is available in week 36", but what I'd really like to be able to say is "Tell me which certified Websphere architects we have available in week 36", or "Tell me which instructors can teach course NL06 in either week 25 or 26". Current solutions that I've been using haven't offered this.
++ Say to Elrond "Hello.".
Elrond says "No.". Elrond gives you some lunch.
I think two very valuable architectural features would be 1) a well defined CORBA (insert more component interface protocols here) interface. It would be a really nice thing to be able to include features in the server program itself directly into office apps connected to it. If you've got a well structured interface I can write a small collaboration app that uses the DB parser of your server (and the server's processing power) to find messages relevant to my project. Secondly I think a good interface to web servers is also pretty important. I mean sure you can have CGI or some such communicate through abstraction (and extra processes) to the calendar server. Let Apache talk directly to the server and make queries from an apache module.
I don't know if this goes out of the bounds of a calendar server but I think a very good addition would be either collaboration functions (a la Domino) or just the ability to store information about your projects in the calendar as relational objects. Being able to stick a new project on my calendar and then store meetings, trips, ect in my calendar and have them related to the project I'm working on. Collaboration features are also a big plus in the office, especially if it's all OS so you can add the ability to link adendum notes or comments to a document that reside on an intranet server. This feature set can also be referenced to your calendar so you can keep track of everything in a related way. Above all else it ought to be able to make better coffee than the secretary.
I'm a loner Dottie, a Rebel.
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.
--Be human.
--
And the men who hold high places must be the ones who start
To mold a new reality... closer to the heart
Don't forget about the UNIX tools philosophy that serves us so well - many programs, each doing one thing, and one thing well, acting in concert. (Bloatware is bad.)
</nostalgia>
Even if you're not planning to design your project like this, let us interact with its data files or database rows with command line interface tools, both standard ones and ones that you provide. This makes scripting that much easier. It also keeps the data as "open" as the source code. ("Open Data Software"
<rant point="little to none">
And for God's sake don't make it store all its data in XML. I can't stand programs that do that. It's so much more work to parse. Give me mysql/mysqldump and grep/sed/awk/perl any day. XML is a very good transfer/transmission psudeo-language, for platforms to talk to each other, not for storing data on disk.
</rant>
If you are going to be implementing a "built-in holidays" as mentioned in the parent post, remember to avoid being too US-centric. Perhaps there can be a "set country" feature where you can set what country you are in and that way it will only embed the holidys observed in that country. Either that, or all known holidays from the world can be put on a check list and the user can then can check off what holidays they want to show up on the calendar.
I'm not claiming that Steltor's Corporate Time is the end call be all server for this, but it meets almost all of your listed requirements above. The website is http://www.steltor.com
-jay
~~ What's stopping you?
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.
The entire article looks blatantly like market research. Not to imply it's for spamming or even, god forbid, closed-source software development purposes, but it raises some, how shall we call them, precursors to ethical questions: I sure with *I* could use slashdot as a vehicle to do market research for my products, dig? Maybe if I, oh, scratch the backs of the right people, nudge nudge?
Oh well, I got that off my chest, now to compromise my principles:
* support for differing time zones. This is so obvious it doesn't need to be mentioned, right? Believe it or not, dtcal in CDE doesn't do timezones. I get an appointment for a teleconference mailed from the east coast, it shows the same clock time for me as it did there. Or pull up someone else's calendar, and you can never see THEIR appointments in YOUR time (this is a problem with all the calendar apps I've seen actually). Maybe it was a configuration issue with dtcm, but it never even showed time zones at all for me to know for sure. un-freakin-believable. don't make that mistake, just store times in absolute format and localize it in the app. Let me see the same calendar from "my time" and "their time" side by side.
* Richer time and project management features. Let people attach notes to a meeting, let it be noted how long something actually took, allow one to put an appointment in "cancelled" and hide it instead of just deleting it, have reports that look for "wasted" time according to some various criteria like meeting overruns (but don't require the person to be a programmer to figure out how to run said reports).
* more fine grained time ranges than "working" and "non-working" hours. Some people have hours where they're in the office, when they're in the field, on call. Allow for warnings when scheduling someone in the "wrong" category, e.g. scheduling a staff meeting of the helpdesk but not the people currently on the phones.
I've finally had it: until slashdot gets article moderation, I am not coming back.
In the mid-'90s I worked at Apple and we used a program called Meeting Maker. The conference rooms (and other special resources, like overhead projectors) were "resource" users. You'd just invite them to your meeting. They would automatically accept any meeting invitation for time periods during which they weren't already allocated, and administrative users could go in and move the resource users' schedules around for the occasions when somebody with higher priority needed the room/device right away.
Oh, go on, check out my job.
Make sure you take a look at another project which has similar goals: WorldPilot. (See the nifty demo.)
Use Zope!
Actually, my manager would love me to join the company's calendaring system, but I can't, as I refuse to use Windows on a regular basis for practical considerations. The better "my" calendaring client integrates with my existing working environment (which might be considered a bit archane by some), the better the chance I'm going to use it on a regular basis.
So the only thing I could hope for in a calendaring system that already pleases my manager, would be either a mail interface that allows me to do most things working with my usual mail client - or, preferably, reefknot.el.
So, if this should really work, I must be able to schedule things on various levels of visibility. Private things (like a dentist appointment) should be visible to me only, but marked as busy time for others. Secret things (like a date with my mistress) should not even be seen as busy for others (Everything will never get in to the calnedar anyway). Department meetings should be visible to the whole department, but only seen as busy for other deps.
Also, consider security. Such a calendar would be carrying lots of practical information of the daily running of a company. Competitors and others may have great interest in this stuff. Just leaking out the names and titles of people can harm a lot (suddenly there are seven new managers in Boston, something's about to happen there! R/D department has stopped scheduling meetings in evening and weekends, they must be back on schedule. No, they also fired six people, they must have dropped a project.)
In Murphy We Turst
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)."Trust me - I know what I'm doing."
- Sledge Hammer
You asked for a wishlist...
1: Sync to/work with more than just the desktop. e.g.: Sync to a palmpilot or pocketPC, allow access via a web browser. Support calendar updates via e-mail (ie: e-mail to calender-server@company.com). In fact, heavily use e-mail for reminders, coordination of meetings, etc. If you're coordinating a meeting, the e-mail you send to request the meeting should be reply-able to the calendar server and update that users calendar.
2: Give a powerful text-based command language so 3rd parties can heavily customize the whole thing. Allow for hooks and an API to add modules ala apache/perl/etc.
3: Do more than 'calendar management'. How about timeslips? I know a lot of team leaders who would love something better than the paper-based system they use right now. This doesn't have to a be a fancy project mangement system; just provide a way to tag time as belonging to one or more user-defined categories and a way to extract this data as needed. Of course have a journal/notes entry for documentation.
4: Multiple access/management of time by various people. For example, my boss generaly doesn't update his calendar; his secretary does. Likewise, his secretary should be able to book time on my calendar. I know that outlook supports this to an extent, but giving more flexibility/security to such an arrangement would be great. In particular, support resource scheduling and pre-emptive access to resources based on who you are (ie: my boss could 'bump' my reservation of a conference room, and I (and all other attendees) would get an e-mail notifying us of a change of venue or that we need to find something else.
"But actually trying to use m4 as a general-purpose langage would be deeply perverse" --ESR
I have to make a disclaimer. I worked on CaLANdar, which had most of those features.
Fight Spammers!
This would be nice, but I would also like it to inform the person trying to schedule a meeting at a given time that such-and-such is/are busy then. It let's you know who to ask to reschedule their conflict if the meeting is important enough.
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.
----
Celebrate the finer things in life
We use C&ST in my company and it really doesn't understand timezones. It just puts everything into GMT and then displays it in the timezone of the viewer. This makes things really difficult if you are travelling since you ideally want to see things in the timezone of where they are happening. Also think of trying to schedule things like an airline flight where the timezone of the start and the ends of the flight are often different.
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.
Developers: We can use your help.
Thanks for the info, I'll check it out. I couldn't agree more -- for me, the value of having ALL the data one wishes to track in the SAME file, & being able to manipulate it at will, was so high it prevents me even considering using any replacement without that capability.
Btw, a W95 (32-bit) version of Ecco was produced & released & worked pretty well. Unfortunately, although I was able to download the 16-bit version to a PDA, the 32-bit version didn't fit Intellilink's (transfer) program, and they declined to produce a new module for Ecco.
Since the 16-bit version (of the database) could be translated into the 32-bit version but not vice versa (the usual post-MS standard -- remember when backward compatibility was routine?!), I was deprived of the ideal mobile version of my data. Of course, I could still export specific data (just contacts & appointments, for example) from the 32-bit version, import it into the 16-bit version, and then download it to the PDA, but it is a bit tiresome to go through this procedure routinely.
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.
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!
10 years ago, when a Finland student posted a newgroup message, no one would have believed in Linux either.
IIRC the command-line cal program does the holidays thing quite nicely, handling holidays for US, Canada, (several other countries), Christian faiths, Muslim faiths, and another major religion I'm forgetting. Maybe you (the programmers) could take a look at how they did it (probably pretty simple, IIRC the holiday data files were just plain ASCII in the form of date: description new-line).
--
News for Geeks in Austin, TX
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.
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.
This is not the way to build a lasting empire.
Don't forget to add scripting, so we can have some viruz and some fun time hacking...
...in random order, really...
... using LDAP)
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
I can think of more... I'd be happy to join this project as a system architect if the URL were actually working...
o/~ we are pissed, we are pissed, we have to resist... o/~ - ec8or
Well, being able to share your calander is one of the features that makes MS Exchange tolerable. But it would be nice if resources could be scheduled the same way. I can schedule a conference room on my outlook... once I look at ITs calendar. Not sure how to make it easier... I just have the feeling that it should be.
Those features would definitely do it for me. In fact, I'd like to work on it. I'm one of those alpha software freaks anyway and I've been searching for something good, but didn't have the time to start from scratch.