On Sun, 3 Mar 2002, Peter Od�us wrote: > Hi > > Calendars/address books are somewhat trivialized when > it comes to implementing an electronical one. Due to > the fact that we all seem to know what a calendar is > (I cannot back that up, just taking a wild guess ;-)), > there is a danger in simply copying the paper calendar > artifacts and transferring them to electronic media, > not thinking too much about the new questions that are > implicitly raised by doing that. >
I would agree that everyone pretty much knows what a calendar is. I would also agree that it would be easier to just copy the paper based calendar with all its flaws. These are two good points. > Security and privacy questions are not the only ones. > The little research e.g.[Palen] that has been done in > the area, show that people need several convincing > features in order to commit to the new calendar > artifact, and eventually dispose the old one (why give > up the trusty old paper-, brain- or no calendar if the > new one does not give me a higher added value). > I will be sure to check out Palen's research as well as the other references. I am not a human factors expert by any stretch but I suspect that the advantages of a computer based calendaring system will be in the unique presentation and sharing capabilities that computers offer over paper based calendars. I suspect most of our efforts regarding features which will convince users to use our calendar will be in data presentation and not the design of the information itself. It seems that you have an interest in the human factors aspects of calendaring and groupware. Would you be interested in advising us as to what we might do from a human factors perspective? It would also be great if you could analyze the competition from a human factors perspective and tell us where we might be able to do better than say Microsoft's or Netscape's calendaring solutions as well as web based calendars available at most internet portals now. Any help would be greatly appreciated... > The new electronical calendar artifact is definitely > promising. The only problem is to reach a sufficient > state of mind-sharing in order to reveal all those > goodies (and issues). Before finishing the coding. > > So... > > How are we going about to formalize the requirements > and the design of this wonderful new system? Maybe > goal-oriented requirements engineering [KAOS] and UML? > Ideas, anyone? > It sounds like what we really need is someone to read the research and perform a use-case analysis based on the references that you have below. Once we have a use case analysis we can begin to build in the features that are most advantageous for successful adoption of the Periodicity server. Until then it is a matter of not painting ourselves into a corner where we have to do a major rewrite to get those features. I dont think that we are in danger of that right now. If you would like to pick up the torch for the use case analysis it would be greatly appreciated. In the meantime I will be downloading the research, reading it, and adding a task for a comphrehensive use case analysis of iCalendar and groupware functionality. > REFERENCES > > [KAOS]http://www.info.ucl.ac.be/research/projects/AVL/ReqEng.html > > [PALEN]http://www.cs.colorado.edu/~palen/dissertation/LPdissertation.pdf > > kind regards, > > Peter Od�us > Peter, thanks for the references I have browsed the table of contents of Palen's research and it looks like it could be extremely helpful. Your interest in Periodicity is greatly appreciated. I will be going on vacation starting Tuesday and will be sure to take a copy of the research with me so that we can continue this conversation when I get back Sunday March 10. Sincerely, Jeff Prickett -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
