
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.
iCal-capable client (Score:1)
Using cron as a backend for scheduled alerts (Score:1)
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.
Re:Lead, don't follow (Score:1)
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
yearly updates (Score:1)
DJD
If you present me with a rich meal I will be able to tell your future from it. Really
Re:Just duplicate Ecco for me, please (-8 (Score:1)
Re:Be careful... (Score:1)
I'm looking for the whole package (Score:1)
from the academic side of the fence (Score:1)
(and yes, i tried vmware, but had a *horrifying* experience with the combination of it and redhat 6... never again...)
Citadel/UX (Score:2)
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.
--
Re:My Dream Specs (Score:1)
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.
Low-level model features (Score:1)
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 Want it Visual (and Colorful)! (Score:1)
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
My god who's moderating today? (Score:2)
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.
Re:My Wishlist: (Score:1)
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!
LAN Support would be kewl (Score:1)
Searchable notes! (Score:1)
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
Re:A Good Groupware Application (Score:1)
It seemes like an excellent program, it just isn't worth $ right now.
Just my worthless
Re:Be careful... (Score:2)
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.
global deployment, scalability, integration (Score:1)
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.
sweet.. here are my needs (Score:3)
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!
3M (Score:1)
Re:Understand timezones (Score:2)
Don't do that. Differentiate between local and global time.
The Important Features (Score:1)
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.
Re:My priority is... (Score:1)
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*
--
Public Access (Score:1)
Event notification... (Score:1)
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.
Re:UNIX tools philosophy (Score:1)
flexible recurrence, to-do integration, etc. (Score:1)
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.
Re:wish list (Score:1)
Keep the paperclips. Add support for console lightgun hardware.
Palm Synchronization and a few others (Score:1)
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,
Working link... (Score:1)
Visor, mods, private (Score:1)
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
Re:Ideas for Calendaring Software (Score:2)
Lookup this one... (Score:1)
@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
One thing to add (Score:2)
Probably the best thing would be to make it a real groupware program, where you could publish/share just about everything......
Please Noooooo!!! (Score:1)
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).
Link Broken, here's the fixed linke (Score:4)
Ideas for Calendaring Software (Score:2)
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!my dream calendaring/correlation program (Score:2)
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.
Calendar features (Score:1)
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.
Re:Tough features (Score:1)
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.
prioritized to-do list, hooks for 3rd party pgms (Score:1)
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.
Some ideas for you (Score:3)
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.
reeferknot? (-: (Score:1)
What makes Palm so popular... (Score:1)
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.
Compability and invitation issues (Score:1)
And please don't send invitation to meetings by mail... (Keep mail separated from calendar issues if possible).
I like it simple. (Score:1)
Interface (Score:1)
Re:My Wishlist: (Score:1)
its the System Integration, stupid. (Score:1)
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.
Calendar Server (Score:1)
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
Re:A Good Groupware Application (Score:1)
Tough features (Score:2)
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)
Re:iCal-capable client (Score:1)
Lead, don't follow (Score:1)
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? ( + links ) (Score:1)
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]
filling it in (Score:1)
cvs integration (Score:2)
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.
Re:Wish list: (Score:1)
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
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.
Re:Enhanced calendar features (Score:2)
how about ... (Score:2)
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.
Log-book Maintenance (Score:2)
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.
Features I'd like/need (Score:2)
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.
High flying price of sanity (Score:2)
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.
server side & client side client (Score:3)
If properly designed, this would allow multiple web-based clients--one for WAP, one for HTML + Javascript, one for plain HTML, etc. And client-side Java under JDK1.4 (not out yet--I've seen some alpha-tests) is really quite acceptable. The main advantage, though, is that you'd be using the same core for multiple clients. If you add a feature in the core, all the clients get the feature.
Of course, the client application should also be sufficiently disassociated from the server application, allowing native clients (C++ or C or whatever) as well. But there is a real advantage to having a sample implementation done in Java.
My request (Score:3)
--
UNIX tools philosophy (Score:2)
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>
Be careful... (Score:2)
Re:My Dream Specs (Score:2)
Pipe Dream (Score:2)
It depends on the bandwidth doesn't it? (Score:3)
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.
I'll bite, with some reservation (Score:2)
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.
Meeting Maker (Score:2)
Worldpilot (Score:2)
Merge the worlds of Ties and Techies (Score:2)
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.
Only one calendar - security issues (Score:2)
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.)
My Wishlist: (Score:5)
When does the week start? (Score:3)
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
Some biggies (Score:2)
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.
Private schedules! (Score:2)
I have to make a disclaimer. I worked on CaLANdar, which had most of those features.
Re:Collaboration (Score:2)
Collaboration (Score:4)
----
Understand timezones (Score:2)
Re:Collaboration (Score:4)
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.
Re:My Wishlist: (Score:2)
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
Enhanced calendar features (Score:3)
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.
Re:Just duplicate Ecco for me, please (-8 (Score:2)
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.
Re:Be careful... (Score:2)
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.
My priority is... (Score:4)
Once you establish, for example, how your client can query a calendar of scheduled appointments and events given some criteria (or not), a calendar server, at least as far as I'm concerned, merely need to serve up the data. Let some other third party (another website, let's say, or some kind of java frontend, perhaps a WAP device of some sort - anything at all is possible) handle displaying the information and presenting it to the user.
In this way, the calendar server is only responsible for serving up the data, and you wouldn't care about the capabilities of the client, because after all the client will determine its own capabilities and process and display the data according to what it can do.
For end users... (Score:4)
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!
Re:UNIX tools philosophy (Score:2)
Re:Lead, don't follow (Score:2)
holidays Re:Collaboration (Score:2)
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).
--
Just duplicate Ecco for me, please (-8 (Score:3)
Several years ago, a company produced a PIM which was actually a disguised relational database -- the GUI included the usual pretty calendar, rolodex-style contact management, outliner, and notebook functions, etc. The same company (last aka was Net Management, I believe) produced a browser (for serial port connections, as well a telephone connections), FTP, and other useful products. Their PIM was called Ecco, and once you got the hang of how to use it (which didn't take long if you had the smarts, since you then began to use it to manage every other program and so were using it continually), it was wonderful. Then MS released its "free" calendaring program, and you know the result.
If you want to know how groupware should work, try to get hold of the manual for Ecco. If you do reproduce its functionality, I'm interested in your program. 'Til then, I'll just stick with Ecco, thanks.
Important: Don't leave out the part where I can set up project management/invoicing/expenses for my independent consulting, and shoot any data or combination of data as formatted ASCII to a template file prepared by my advanced WP program, using saved sets of instructions.
Two of Many (Score:3)
scripting (Score:2)
My Dream Specs (Score:5)
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...
Useful features (Score:2)
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.
My list (Score:2)
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.
Wish list: (Score:4)