Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Linux Business

What Would Your Dream Calendar Program Look Like? 183

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.
This discussion has been archived. No new comments can be posted.

What Would Your Dream Calendar Program Look Like?

Comments Filter:
  • Could someone be so kind to explain what is an iCal capable client ?
  • When I use various calendar program, it often irks me that the calendar program needs to be running for the alerts to be displayed.

    It would be nice to have a calendar program that would use cron (which is a daemon to execute scheduled commands) as a backend for triggering scheduled alerts. The concept could be expanded further by making the calendar program useful as a nice graphical application for scheduling system administration tasks.

  • This is baffling - the number of clients who we have seen happy with Exchange are far outweighed by those seriously pissed off with it. Some of our biggest deals this year have been hacking out stacks of this MS junk and popping in AS/400's with real enterprise levl software.
    Exchange just DOES NOT SCALE!!!

    In other interesting news, Microsoft themselves had to replace W2000 and Exchange with a high end AS/400. Hee hee hee.


    Frog51
  • I would like to see my personal calander automatically update dates that I set to be reocurring... Ala birthdays aniversaries or tax time. this saves a whole bunch of time manually updating those important events that I would otherwise (and most of the time) forget...

    DJD
    If you present me with a rich meal I will be able to tell your future from it. Really
  • I think that Ecco was purchased by Novell and turned into InfoCentral for PerfectOffice 3.0. Certainly InfoCentral had the same idea: it had an incredibly powerful relational database that allowed you to tie any entry in the database to anything else, essentially allowing you to add new functionality merely by tying things together. (One of the demos that came with InfoCentral, in fact, was a family tree--not exactly something which your average PIM can handle.) I liked InfoCentral so much that for quite awhile I kept a copy of Windows 3.1 running emulated on my Mac just to use InfoCentral, until finally I gave up and switched to Claris Organizer. But for those of you with PerfectOffice 3.0 (and possibly with Corel Office, although I have no idea if they still use that PIM), I strongly recommend you check it out. If you wrote your PIM in the style of Ecco and InfoCentral, I think you'd be able to make a name for yourself not only in free software circles, but if done correctly, then in the business world at large as well.
  • I recall being able to download schedule databases for MS Schedule 95, so you could get one that covered holidays in the U.S., Japan, various European countries, Saudi Arabia, etc. So perhaps making an object for a holidy, and then allowing an imported file to contain holiday objects is a good solution.
  • All these individual elements of free software work great, in my experience, but the problem has always been that no one sits down and puts together and end to end solution. It's all well and good reading on the SAMBA mailing list that you can tie it's password lookup into a kerberos box, or an LDAP box, but the thing that would start the avalanche is being able to buy, for example, RedHat PDC/LDAP/Sendmail/Apache/PHP all tied together with a single account database and all the "glue" work done. Now *that* would be something. Heck, you could even tie in your desktops and have a viable desktop alternative to Windows, Mac etc. depending on your apps.
  • here are some suggestions coming from someone in academia, who deals with advising, ta hours, and a lot of asynchronous collaboration:

    1. multiple front-ends to the pim: web-based, emacs plugin (please? :), maybe gui app, and so on.

    2. give access levels for remote users (so that people can sign up for meetings in open calendar slots, but can't change my existing ones, etc.)

    3. project management, timelines, goal hierarchies, etc. with file sharing (so people can view my todo list, etc.)

    4. integration with existing mail/news readers (mhmm... vm and gnus :)

    5. pda sync, including wince! synching with my wince box is the only reason why i still use outlook. :(
      (and yes, i tried vmware, but had a *horrifying* experience with the combination of it and redhat 6... never again...)

    6. simple integration to apache and other popular servers, as necessary, rather than custom rdbms's or web servers...

  • The Citadel/UX project [citadel.org] 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.
    --
  • **Accepts Outlook 2000 as a client on Windows**

    I'm a Linux fanatic, but the above is the *only*
    way anything new sneak into my company. The
    exchange web interface could use a lot of improvement.

  • More important to me than user-visible calendar features would be a data architecture that allowed great flexibility in representing timed events, and a distributed implementation that allowed a wide variety of uses.

    I've spent a considerable amount of time (under salary :-) thinking about how to represent timed events, and how to deal with the relationships between different schedules, and finally how to implement different kinds of services that work with that information. For whatever it's worth, what I decided was that just about everything can be reduced to the basic building block of an event cycle definition.

    The ideas I had came from thinking about the ways audio synthesis works, or how similar systems like texture synthesis (KPT Bryce et al). If you think about it, basic event cycles (i.e., your bi-weekly staff meetings) are like waveforms. If you can describe your staff meeting as a waveform and capture that in a way that you can perform arithmetic between waveforms, then you can glue the building blocks together and capture a very rich variety of scheduling expressions. Using a consistent algebraic system makes it possible to implement all sorts of semantics (searching for coincident points on various different schedules, "masking" operations for holidays or other policies, and so on).

    With an infrastructure like that, it'd be possible to put together a bunch of different kinds of clients that performed different kinds of scheduling. For example, there's no reason why the same system couldn't handle the tracking of scheduled IT operations as well as personal business schedules of employees.

    Just a thought.

  • I'm very very right-brained. I want to see my calendar in lots of beautiful colors! Can you do that, or at least make it an option? Here is how I imagine the problem of finding a time that works for a group of people:

    Imagine that each person's schedule is made out of colored Saran wrap. For example, if I am free Monday 1-5PM, then I have a red patch over those times. Everyone has different colors for their free time. Then to find out when they are available, you just put all the "pages" on top of each other and see where all the colors overlap.

    This would help visual people greatly! You could spot all kind of partial matches just by color, quickly. For example, if a Yellow and Blue person overlap on a time, the overlapped region would be green. Times where most people could go would probably be sort of brownish, and places where everyone could go would be black. (If I understand the general idea of the color spectrum filters right.)
    My request is: Make it Colorful!

    shane2020@hotmail.com
  • I'm sorry for starting out on such a sour note, but I just read the top 9 (at the moment) rated messages and they, as well as nearly all others, are completely off-topic.

    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.

  • Wow, those are some great ideas.
    I've allways wondered why calendar programs were not 'connectionless'.
    An open API is a great idea too, but I'd be nervous about using a system with an open API with a calendar program. There's allways bugs and I could see that loud, ugly chick in the cubicle beside me ending up with some meetings across town for a few days one morning :)

    A connectionless, open API web based calendar would really shake things up for exchange though!
  • I think LAN support would be kewl as well. I have a 10 System LAN at home with my roomie's. Having straight support for LAN and a Windows client would be very much appreciated. Kleedrac
  • A number of calendar applications I've used over the years allow you to add notes to events on the calendar. On occasion, that's become good enough to serve as a basic journal, helping me keep track of what I thought of various meetings, etc.

    It would be nice to be able to link those notes together by searching for similar terms, searching through repeating events, etc. and compiling them into extended text documents, separated by date:time markers.

    Just a wistful thought,

    Larsal

  • yeah it is under heavy development and costs a hefty price. I am not against pay/for software, but I am not about to pay for software that doesn't work right out of the box and is under development.

    It seemes like an excellent program, it just isn't worth $ right now.

    Just my worthless .02
  • There are a huge number of holidays [holidaysmart.com]. Holiday lists should be in files, with the ability to select and add them to your calendar with annotations (ie, "Company Holiday", "Religious Holiday").

    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.

  • In large enterprises with tens of thousands of users at various locations around the globe, it would be desirable to have a calendar server at each location, since most people are just going to be scheduling things that are relevant to that location. This cuts down on trans-Atlantic bandwidth usage for "doctor appointment at 3:00" appointments.

    The geographically dispersed calendar servers should be able to communicate with each other for the occassions that someone in Paris is arranging a meeting in New York with people from the Chicago and San Francisco locations.

    Notifications of events, appointments, etc., should be able to be done from the server, not from clients. That is, the server triggers events on clients (PDA's, pagers, some random unmapped X application). The notification mechanism should allow for local plugins to be provided. Shared library plugins are great, but one should allow for simply calling a shell script too.

    Time zones should be handled gracefully. Do not assume that all users are in the same timezone. Assume that when people travel, some change their watch and some don't. (Allow for temporary time zones for individuals?)

    Don't require that the calendar gets each users' info added into its own database. Be able to interface with directory services such as LDAP, and X.500. Notes, NDS and ActiveDirectory support would be great, but should be secondary to open directory protocols, since the proprietary ones tend to be able to provide the same data through LDAP gateways.

    Allow for clustering for high-availability and load balancing.

    Provide an NDMP (network data management protocol) (see www.ndmp.org for details [ndmp.org]) interface so that enterprise backup systems can back the calendar server up, while it is online.

    If an external database is used, abstract it so that the database preferred by the installer can be used. MySQL is a hard sell at a shop that runs Oracle on E10k's.

    Authentication via PAM

    Limited trust relationships that allow collaboration between different companies.

  • by josepha48 ( 13953 ) on Saturday November 25, 2000 @08:37AM (#602740) Journal
    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!

  • What's wrong with post-it notes and a pen?
  • I've heard that one product made appointments in the current timezone, then when you moved to another timezone it presented the appointments shifted to the original zone. So if you're in New York and make an 8 A.M. appointment in Chicago, go to Chicago, change timezones (one hour earlier), then see the appointment is at 9 A.M.

    Don't do that. Differentiate between local and global time.

  • I think the most important feature is useablility by people who know nothing, and the ability to extend it quickly. As luck would have it, I'm working on a calendar "server" as well.

    I put server in parentheses because servers usually require cgi or jsp, or something equivalent. We are making a prototype using JSP, however, this is difficult for the layperson to set up. A much more useful calendar would be updated via applet which copys itself via an ftp connection, and which is updateable in this fashion, while being viewable using javascript. Extesibility could easily be maintained via Javabeans. Make each event a bean, and then if you ever feel like it, you could connect those to databases, or whatever, and could easily change the javascript output they produce.

    I think that pretty much covers everything a calendar should do.

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

    Isn't that what HTML was supposed to be like? *g*.

    Of course, someone builds something like this, and the first thing they're going to whinge about is the lack the system's ability to set the colour of your fonts.... *sigh*


    --
  • There should be a read-only login so groups can present their schedule to interested parties without giving them access to change the calendar and without requiring every member to have a personal login.
  • I want to be able to tell it to send event notifications to my pager's email address and not my actual email address, without having to set up some sort of forwarding of the email on another server or via my email client.

    This will allow me to always show up for meetings and such without actually having to input all of the data into my pager.

    I also want to be able to tell it to ignore all events posted by certain people who have the ability (And gall.) to invite me to events that I will not actually attend.
  • XML is rather new, but with the right tools it is dead easy to parse. SAX for java and C++ is very powerful. And yes it is now available for perl Sax for Perl [slc.ut.us]. Once you go beyond simple tab delimetered flat files or relational databases XML becomes very useful.
  • Three suggestions from my wife, and end-user. These are somewhat client-centric but carry some implications for the back-end as well.

    1. Ability to change font and/or background color of each event.

    2. Ability to delete one occurrence of repeating appointment, without disturbing future occurrences. Possibly an e-mail reminder that the event for that day was cancelled.

    2. Ability to print a professional looking page for notebook or planner, in month or week view, with all days the same size.

    And from myself, I want to see a good integration of to-do list management into the calendar server. To-do's should be stored with discrete attributes for both importance and urgency, not just a generic priority. Also, an optional target date and/or hard-deadline date, intelligent status-change paths with event/notification triggers (send email to specific addresses whenever a task of type q moves from status b to c or urgency d to e).

    Sounds like a great project, hope you are successful.

  • Nonononono.

    Keep the paperclips. Add support for console lightgun hardware. ;^)
  • Palm Synchronization is very important to a Palm enabled work force.

    Other useful items would include, not just free/busy search, but the ability to see multiple calendars side-by-side. This is really useful for scheduling service work for customers as you can see at a glance how quickly you might be able to get somebody on site.

    For places such as law firms, date math and linked entries are a requirement. They need to be able to do things like schedule dates 30/45/60/90 days from today (either including or excluding weekends and holidays). They also need to link several dates together, so if some base date changes all linked dates change also.

    Stand Fast,

  • http://sourceforge.net/projects/reefknot/
  • Three things i would like to see would be (and i'm not very into outlook so i don't know if i'm being redundant) are:

    Ability to be imported to or exported from my visor.

    ability to have a moduling system for additional features. prog would prompt you to see if you wanted to download additional features.

    allow to make parts of your data visible to people. ex. your home phone, other busisness's you usually call. in case your out and somone needed to get in touch with one of your customers or somthing.

    yeah, i think that's it, oh and it should make me coffee.

    ---
    pack

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

    @work we use http://www.skyrix.com/ , OK it's not OSS, neither free, it uses apache, it's an DSO apache module, but has all a corporate calendar needs, even hot sync with a palm, win only in the moment IMHO, but everything else you can use with just a browser on every OS.

    It gets better with every version and uses sql92 (frontbase) to store the data. You get a working demo with every SuSE distribution, or can download it at their site. Would be nice to have something like this as OSS. I don't work for them. I just admin a bunch of linux servers and one of them is our skyrix server. Last upgrade was a bit tricky, but now it just runs. We don't want no stinking Outlook in our LAN, and this gives us the ability to provide the group features our customer demand, without using M$ server...:-)

    It should be a lot easier to build something like this based on things that just work, like apache & mysql, then starting from scratch.

    Michael
  • Last version of exchange I used was 5.5. One thing that it lacked that we wanted was the ability to have like a journal for each user on a contact. IE:, if you talked to Joe User on 11/28, and someone else talked to Joe User on 11/20, and there were some notes about the conversation that would be cool. The way Exchange 5.5 worked, to my memory, was that you could do this, but you couldn't share it with everyone...........

    Probably the best thing would be to make it a real groupware program, where you could publish/share just about everything......

  • Despite the story intro, I've seen many posts asking for an Exchange-alike. Let me say:

    Please don't make some huge monolithic copy of a huge monolithic microsoft product; if you want to do two tasks, make two tools with well-defined interfaces. Don't just integrate calendaring and e-mail so that anyone who wants to use your calendar service has to use your e-mail too. The power of Unix is small tools that talk to each other. If you want your database to interact with Exchange clients, write a separate backend rather than constraining the whole project to deal with microsoft's structure.

    Please don't reinvent the wheel. Use standards (like LDAP for a contact database, for instance).

  • Here's some things I would think would give me good arguments to be able to use the software in the mixed NT and Unix environment I work in. The company I work for has standardized on the Exchange platform to handle Mail, Calendar, etc.

    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:

    It should integrate with existing Exchange installations, including reading user and shared calendars already defined and able to "book" appointments with users still on Exchange. (Maybe something simliar to what the Jabber project has done with Instant Messaging...)
    It should handle timezones seamlessly. Book in my time-zone, someone else reads their calendar in their time zone. (In other words, stored appointments should probably be in GMT.) Many organizations are far-flung geographically and need this type of support.
    Clients should connect and send information to the server in an encrypted channel (unlike Exchange).
    Database replication between servers should be supported for applications that are geographically or network distributed -- some reasonable amount of time for replication to take place would have to be defined.
    Both native platform clients (speed) and web-interfaces should be created.
    Something better than the current Exchange "auto-answer" type resource booking stuff for things like conference rooms and projectors, or whatever is defined as a shared resource.
    Cross-platform compile, install, etc. BSD, Linux, and commercial Unices. :)

    Other niceties that would help get its foot-in-the-door would be:
    Using the server replication features mentioned above, if one of these servers could replicate to another one and then send those changes/updates to an Exchange server on the far end, thus losing the necessity for tons of traffic across WAN links for clients to view other client's calendars, this would be nice.
    Integration with a popular web-mail application like IMP or something simlar on the web interface would be nice.
    Writing the various clients in a cross-platform like Java or something similar would be nice for developers and offer less work down the road, but more up-front. This one seems somehow problematic to me in a number of ways, but it's just a thought.

    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!

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

  • A few things I can think of:

    For multiple servers to share calendars. My boss has the problem that with his two email accounts in two different offices, then calendars don't schedule correctly with each other, so he opten gets double booked.

    One problem with exchange is that a calendar appointment isn't booked with someone until they open the mail with the calendar appointment. It's the same with tasks. (Note: a good way to avoid tasks and meetings, don't open them!)

    I suppose the main think, is to look at *all* of the functionality of outlook and replicate that. Thta's what the PHB will look at. They don't care that's it implemented in C++ with funky data structures. They care about the user interface because that's *all* they see.

    That's all I can think of for now.
  • Another time related function of the client...

    A while back I had a DEC UNix box that had a calendar program. It's sharing features were cool, but the one thing that I really liked was that when you had it in single-day mode, the time portion of the window actually scrolled with the time-of day. i.e., if you opened the program at noon, 11:am would be at the top, and the current time would have the focus. It was nice not to have to scroll down to the current time.

    Some people probably wouldn't like this, so it would have to be selectable as an option.

  • I'm working for a small company that might, in the near future, want to generate action items for its users. It would be nice if there was an open protocol that we could code to (w/the obligatory Outlook translator as an afterthought). I'm thinking that in addition to our software being able to enter items into the to-do list, it will need to be able to receive status updates (e.g., "done").

    Note that this is independent of all the spiffy GUI features others are asking for.

    Apologies for the incoherence of this post. This was going to be my one final quick skim of /. before bed. Geez, it's 3:00 a.m. here.

    John.

  • by onyxruby ( 118189 ) <onyxrubyNO@SPAMcomcast.net> on Friday November 24, 2000 @11:04PM (#602763)
    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.

  • I don't mean to be inflammatory but the first thing you might want to consider changing is the name of the project. This tool will be most valuable to managers as has been pointed out. I don't know if a vaguely drug-related name will go over very well. The first thing you have to lose as a manager is your sense of humor. (-:
  • The Palm handheld device is extremely popular, but when you look at how the calendar works, it seems very simple. Maybe that's what people want: A calendar system they can understand.

    The way Palm compresses a day view when the Windows is little is very good.

    Personally, when I have added some recurring appointments in Outlook, removed some of them again etc., then I would very much like to have an overview of which appointments that were removed...

    If you categorize the calendar entries, it would be nice if one could print a calendar with only specific categories on it.

    A common calendar for the company, that you can blend directly into your own calendar would be extremely good. I hate to switch to multi-user view to find out, that there is a company wide meeting the same day I made an appointment.

    It should be easy to add one or more unattended accounts for resource allocation, like meeting rooms, and there should be a log for that account, showing who adds and who deletes which allocations.
  • Would it be possible implementing compability layers for Outlook and Notes?

    And please don't send invitation to meetings by mail... (Keep mail separated from calendar issues if possible).
  • chris@iso[2][02:49pm][6]:~:$ cal November 2000 S M Tu W Th F S 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
  • One of the advantages of Outlook and Office, is that I can integrate them with each other. I use an access database to track our Test Equipment. One of the many items the database tracks is "Date Due Calibration". Access interfaces with Outlook to ensure the proper people are notified when to take there test equipment in for Calibration. For the open source version this kind of interface would best be done in XML. Access/Outlook use Visual Basic for this interface, so for compatibility you may have to add a VBS module

  • A great set of requirements with which I would almost entirely agree. Here are a couple more musts for me 10) Synchonise with PDA (in my case Palm Pilot) locally (I also run a laptop) 11) Allow my secretary to arrange meetings on my behalf (she will typically be doing this between a group of about 5 of us - it needs to be dead easy for her to manage multiple calanders at the same time) 12) Ability to manage time zone changes gracefully. (let me explain). If I am on a trip to the US from the UK, I switch to US time in my mind, but I don't go into windows and change my time zone. Nevertheless I want (on my laptop and my PDA) to see meetings at the time in my mind. My secretary back in the UK must also see my calender and understand both the "real" time (in case these meetings are teleconferences with people in other parts of the world) and my "mind" time (so she doesn't schedule a meeting when I would rather be asleep)
  • I believe that one of the major driving forces behind the move to Exchange (2000)and other W2K subsystems (SQL-Server, IIS, SMS, etc.) is ease of administration, on the system level. Exchange 2000 requires the implementation of W2K's AD, to which many companies are moving for their server platforms. AD provides the "synergy" (god, I hate that word!). Admins don't need to take care of user/group/rights definitions in several different places (passwd, some obscure LDAP setup for the calendar, etc.), only in one - integrated - system, the AD. Notes provides equal or better calendaring, iCal systems probably do, too, Oracle and DB2 are great RDBMS's, and Apache is arguably the best web server -- but the multiple administration can be a pain in the ass. What we need is a standardized LDAP-based user/group/resource-information repository for Linux, that comes as a predefined component in the Distros, with a clearly defined extension mechanism/API, that can be our version of AD. Most important, it needs to be as "easy" to setup and understand as AD. And we need some apps that use it. Until we get this, its gonna be tough to penetrate the domain of W2K.

    It seems to me that the "scratching an itch" approach on this problem is just like scratching an itch. It treats the symptom and not the disease, which can be a bad solution, as anyone who has had the chicken-pox can attest.
  • I'm currently working on a php based "homeware" application and have been trying to decide how I want to do the calendar, I can write my own, use a calendar server or borrow one from another package. I'm currently leading toward writing my own because the current programs don't offer the extensibility that I need. The application is going to include financial software and a few others that require use of a calendar, rather than write a separate scheduling program for each, I'd like a calendar that is extensible, so that I can write my own applications for what to do when an event occurs. even if it's something as simple as running a command line. Other than that, here are my basic calendar requirements.
    being able to set who can view my calendar, I think three levels would suffice, public, private, secretary.
    automated scheduling
    event timers that include pager or cell phone( could be part of the extensibility)
    I know there is more, but that is all I can think of
  • Dude, its GNU software, its FREE. Licensed under GPLv2 for you to copy/modify/distribute and so forth.
  • 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 [timeanddate.com]

    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)

  • iCalendar is described in RFC 2445 [imc.org]. What an iCal capable client is, is left to the reader.
  • I use MS Outlook and Exchange server at work. It rocks.

    There are some *huge* problems with it. For instance, if you send a meeting request to a person who has marked themselves as 'Out of Office', and they have made 'Everybody' a delegate, then everybody gets the meeting request.

    And that's the worst problem I can think of. [Having worked with Exchange/Outlook for five years I think that's quite impressive]

    Question: How can a bunch of students hope to create a better system than one that 2,000 professional software engineers spent ten years building?

    Now, let's assume they do it. "Here is a better mail/news/groupware/calendar application then Exchange/Lotus Notes/". How many tens of million dollars have you got to promote it with? [If it's less than $100 million, go home now).

    I am sorry. Free software is now, and always will be, utter shite when it comes to developing "business desktop" software. Simple reason - a person costs $75,000 to hire, so $2,000 a year per employee is chump change.

    The place for free software is in the *server* arena. It's already winning there. No, I lie, It's already won. Most Sun Starfires have gcc, *very* few have Sun's CC.

    I burble, I am drunk again.

    Trying to reproduce excellent software like M$ Exchange and M$ Outlook is futile. Roll with the punches, and get accepted as an IETF engineer. IETF engineers (yes, I know there is no such thing...) build things that matter.

    But, for the sake of Eris DO SOMETHING ORIGINAL.

    Quit following, and start leading. Or grow up. It's your fucking choice.

  • Why perl? For a wider pool of potential developers I'd go with C.
    For a nicer language to work with, I think Java would be better.
    Somehow a scripting language seems slightly inappropriate.

    But if you're going that route you may as well help out phpgroupware.org [phpgroupware.org] ($0.02)

    There's also MCAL - Modular Calendar Access Library [chek.com]

  • How about if it atomatically accessed a personal database and filled in all the birthdays of friends and family that i forget about each year? It might be nice if it could remind me to take my pill.
  • 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.
  • &gt ability to send reminders to wherever you are logged on, e-mail, pager, cell-phone...

    Perhaps a text to audio plugin for telephones. I think it would be sweet if you could have a modem dial somebody's cell phone, and have a computer translate ASCII to something like a .wav file. Simply play the .wav file and the telephone's voice mail picks it up.

    I'm sure I could find a lot of other uses for something that could convert text to audio. Like maybe a program that converts slashdot.org text to audio, and burns it out to a CDRW for me to listen to on the drive home.

    I know I may get moderated down for this one, but how about a map option?
    Sometimes I have meetings in other cities, and maybe it would be possible to write some PERL that would take my orgin/destination, and plug it into some online database such as MapQuest.

    Probably a dumb idea, but I doubt it would be difficult to code.
  • 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.)
  • 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:

    • Permit global and sub-project organisation of calendar entires.
    • Allow free-form notes related to unschedule "To Do" and scheduled events.
    • Ability to write global and project log books suitable for typesetting.
    • Ability to track time spent on sub-projects and record this in the log book.
    • Project summary in log books: goals, contacts made
    • Seamless linking with e-mail from a project, linking with relevant project documentation and web pages. Ideally also scanned notes, audio records, phone call logs via the ISDN or caller ID interfaces on my equipment.
    • Log books need to have date anchors so that they can be referred to in other projects.

    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.

    Secondly, some easy way of synchronising it with popular PDAs (particularly Psions ;) would be handy, if you'll excuse the pun.

    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.
  • 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.
  • by The Mayor ( 6048 ) on Saturday November 25, 2000 @02:26AM (#602793)
    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.
  • by LordNimon ( 85072 ) on Saturday November 25, 2000 @02:45AM (#602795)
    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.

    --
  • <nostalgia love="unix">
    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" ... hmm...)

    <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 [steltor.com]
    • Multiple levels of control. Novice, intermediate, advanced.
    • Abillity to turn off all automated bullshit; autocomplete of addresses, damn reminders, etc.
    • Abillity to "drill down" through a wall calender view.
    • Abillity to embed critical documents, task lists, and other rich datatypes in date.
    • Open interface for calender plugins; encryption, chat, broadcast, conferancing features.
    • Abillity to create "open documents" which may be accessable to specified coworkers or the world.
    • Full use of all three mouse buttons!
    • Export of TODO lists, weekly notes, activity reports, time card reporting.
    • Multiple platform support and not a cheasy web based interface.
    • Export formats for other calendering applications.
    • Conversion of appointments to the palm world.
    • Automated weblog creation.
    • Core with numourous optional components to reduce memory footprint for users requiring only basic features.
    • Starts and shuts down rapidly.
  • by gelfling ( 6534 ) on Friday November 24, 2000 @05:37PM (#602805) Homepage Journal
    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.
  • 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.
  • Make sure you take a look at another project which has similar goals: WorldPilot [worldpilot.com]. (See the nifty demo.) [worldpilot.com]
  • 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.
  • I have found that I can only use one calendar system. At some jobs I was supposed to use the company standard, but I also wnated to keep my owb private calendar separate. I ended up having to check everything in two places, always out of sync.

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

  • by crucini ( 98210 ) on Friday November 24, 2000 @04:49PM (#602824)
    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!
  • by mfarah ( 231411 ) <{miguel} {at} {farah.cl}> on Friday November 24, 2000 @04:50PM (#602825) Homepage
    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).
  • 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.
  • I like the PDA and web access that people have mentioned.

    • What has not been mentioned is the ability to have appointments that other's can't see. I may not want to broadcast what my appointment with, but I don't want others booking me for that time.
    • The ability to slide appointments, when one runs late (like a doctor's office)

    I have to make a disclaimer. I worked on CaLANdar, which had most of those features.

  • 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.
  • by Skeezix ( 14602 ) <jamin@pubcrawler.org> on Friday November 24, 2000 @04:00PM (#602839) Homepage
    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.
    ----
  • by Anonymous Coward
    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.
  • by Phrogman ( 80473 ) on Friday November 24, 2000 @04:05PM (#602846)

    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.

  • Regarding the SSL - I would put it as an option.

    There are lots of places where you cannot access SSL based web sites (PDA's, old versions of browser, weak [40] protection, etc).
    Just keep in mind, as other people have posted here - that accessing this web interface for scheduling is important - even with PDA's, or lynx web browser.. - after all - you'll never know what browser you'll have on the other side when you'll need it
  • by truthsearch ( 249536 ) on Friday November 24, 2000 @04:06PM (#602851) Homepage Journal
    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.

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

  • Even better would be an administrator configurable holiday (or rather day off) database. Not only do different countries celebrate different holidays, but different businesses have different day off policies. My employer, for instance, has only 6 set holidays every year (New Years, Memorial Day, Independence Day, Labor Day, Thanksgiving, and Christmas) while many other employers in the U.S. celebrate many more holidays. Furthermore, some employers may have additional days off that aren't official holidays- the company picnic, or the founder's birthday, or whatever.

  • by DeepDarkSky ( 111382 ) on Friday November 24, 2000 @05:03PM (#602859)
    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.

  • by pstorry ( 47673 ) on Friday November 24, 2000 @05:03PM (#602860) Homepage
    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!
  • Very true, XML is not good for data storage (at least not a lot of it) but excellent for transmitting pieces of data.
  • 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).


    --

  • by techwatcher ( 112759 ) on Friday November 24, 2000 @06:10PM (#602867)

    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.

  • by Luminous ( 192747 ) on Friday November 24, 2000 @06:50PM (#602871) Journal
    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.
  • Don't forget to add scripting, so we can have some viruz and some fun time hacking...
  • by LHOOQtius_ov_Borg ( 73817 ) on Friday November 24, 2000 @04:10PM (#602876)
    ...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...

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

  • Well, here's my list. I'm sure most, if not all of these are addressed in other comments. In the spirit of surveys, I'll mention everything I can think of right now.

    • Palm Pilot integration on the client. I'm disappointed with the current UNIX offerings. I like KDE's tools, I used them until I got a Visor, and others in my office are still using them. I'm only using KDE2's KMail client right now. Unfortunately, this is a function of client software, not server software, unless the server can grok pdb. Actually, if the server can read and modify pdb files, a client would be simplified as you only need to do it once. The client doesn't have to grok it.
    • Cross-platform support. I mean UNIX, Windows, web, and WAP. I would like to be able to use native KDE tools and a web interface. Some people in my office use GNOME, the administration staff uses Windows.
    • Project management. This is something I have no problem using a web-only interface for. It's the easiest way. For this, I'd like support for separate departments, access control, team creation (sometimes among multiple departments), milestones, GANTT, project diaries (I'd like to be able to write down what I do as I do it), and dependencies (a milestone of one project is often dependant on a milestone of another).
    • Contact management. This should have the ability to set permissions (user, team, department, all, specific groups). It should also store public keys.
    • Email integration. Preferably, I'd like the server to PGP encrypt anything it sends me because I often get my mail from home, VBN/VCN ports, other offices, etc.
    • XML. Not just for buzzword-compliance. It would simplify a lot of data exchange.


    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.
  • by Alomex ( 148003 ) on Friday November 24, 2000 @04:19PM (#602903) Homepage
    • 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.

"I've seen it. It's rubbish." -- Marvin the Paranoid Android

Working...