Pie in the sky or real world?

Post #3,429 by jbrabeck 8/1/01 11:49:49 AM Reply	Pie in the sky or real world? Immediate need would be no interaction, we'd have two lists (My group only consists of 5-15 people). But I can see how this could grow, and then we'd want to only have one list of users. Joe
Post #3,440 by drewk 8/1/01 12:48:04 PM Reply	The specs are deceptively simple Just a web-based app to schedule meetings for a list of people is relatively trivial. Of course for it to stay that way would require everybody using it. What I mean is, if you want the app to make everyone's calendars available to whoever is doing the scheduling, or to other users, then all the users have to keep their calendars up to date. (Or someone has to do it for them.) This could be done in a couple of days if the specs really are: * Every user will keep their personal calendar up to date -- or -- * Someone keeps all calendars up to date * There is an interface to schedule meetings that then appear on everyone's calendars * A central user list that is owned by this application * A central schedule that is owned by this application But I assume there are plenty of people who already have preferred calendar/PIM/planning programs. Either they all convert to this new application, or the application will have to talk to some set of the currently-in-use apps for the lists, the schedules or both. Anything that will involve multiple users instantly becomes as much a political decision as a technical one. If there is someone with the authority and the willingness to enforce a standard, this is fairly straightforward. If there isn't ... This is my sig. There are many like it, but this one is mine.
Post #3,498 by jbrabeck 8/1/01 5:13:28 PM Reply	Re: The specs are deceptively simple I used GW as an example because that is what I am most familiar. Features: * Every user will keep their personal calendar up to date * There is an interface to schedule meetings that then appear on everyone's calendars * A central user list that is owned by this application * A central schedule that is owned by this application add * Notification feature to remind user of meeting * Facility list owned by application to prevent double booking of a room * Find meeting time. I want to meet with Drew, Wade and Norm. Find a time that all of us are available. * Allow user to accept or reject the meeting. Not "scheduled" until user accepts meeting. * Cancel meeting or change meeting date or time These were the basic features that groupwise offered. Joe
Post #3,568 by addison 8/1/01 11:57:48 PM Reply	Re: The specs are deceptively simple [link\|http://www.slashdot.org/askslashdot/99/07/18/1714250.shtml\|http://www.slashdot...714250.shtml] Didn't look hard, couple of years back, but there ya go. If you were running Solaris, there would be DTCM. :) Addison
Post #3,610 by drewk 8/2/01 11:04:43 AM Reply	Looks to me like a fairly straightforward web app If no one has already done something that includes that -- and several packages have calendar componenets, see PHPGroupWare, Twig and a few others -- that's an easy feature set. Like I said, getting the buy-in that all data is owned by this app, meaning it's the primary source for scheduling, is the hard part. If you've got that, the implementation can be done in under a man-week. Take a look at [link\|http://freshmeat.net\|freshmeat] and [link\|http://sf.net\|sourceforge] to see if there's an existing package that does what you need. If not, let me know and I'll see what I can come up with. This is my sig. There are many like it, but this one is mine.

Welcome to IWETHEY!