commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Prickett <prick...@www1.kc.aoindustries.com>
Subject Re: Periodicity requirements & design
Date Mon, 04 Mar 2002 03:12:49 GMT
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:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message