Re: Periodicity requirements & design (fwd)

[Jeff Prickett <pr...@shpimp.com>]

My apologies if this is coming across the list twice. I dont see it in the 
archives and I sent it and never received it back from the list.

---------- Forwarded message ----------
Date: Mon, 4 Mar 2002 06:15:05 -0600 (CST)
From: Jeff Prickett <pr...@www1.kc.aoindustries.com>
To: Jakarta Commons Developers List <co...@jakarta.apache.org>
Subject: Re: Periodicity requirements & design

On Mon, 4 Mar 2002, Peter Od�us wrote:

> 
> I agree. Sharing is probably one of the most important
> things (at least in the business area). "Browse me"
> might eventually be the standard answer to the
> question "do you have time to see me next week?".
> Moreover, an important aspect of sharing is the
> default "openness" setting of the system, because
> users tend not to change default settings [Palen]. But
> maybe sharing is less important for people managing
> their personal, non-business part of the calendar. Who
> knows?
>

You are correct that users dont tend to change the default settings. By 
default sharing should be a relatively painless process.
 
> Event reminders and the ability to tailor
> sophisticated recurring events also seem to be crucial
> according to [Palen].
> 

Recurring events are tough to get right in just about every aspect. They 
can get extremely complicated. Luckily we have not implemented handling 
for recurring events just yet so we have not made any mistakes :).

> My personal thoughts include, but are not limited to:
> -Heavily localized information (dates etc.)
> -Tight integration between the rolodex/address book
> (vCards)and the calendar. My theory is that two pieces
> of data could relate intimately to each other, where
> one piece pertains to time (workout class schedule)
> while the other is fairly static (gym phone number).
> In those cases it might be important to be able to
> make such a strong two-way connection. (The gym
> publishing its workout schedule is an example of a
> [SKiCal] event, by the way.)

Good point. Again we have not quite gotten that far yet so we probably are 
ok. Tight integration with vCard would be great. Interactions between 
SkiCal also need a lot of research. It could be that we could just use the 
mechanisms outlined in RFC 2446, but I cant say that for sure because I 
have not read RFC2446 or SKiCal thoroughly yet.

> -Dynamic rolodex in the sense that e.g. an address is
> made non-atomic, which means that a phone number can
> be intimately related to the address.  
> 
> 
> I would be glad to give it a shot, even though I am
> currently more of an HCI novice than an expert. A lot
> of pointers are to be collected from [Palen], though.
>

We could start there. I downloaded it last night. It is a pretty hefty 
document and I am sure that we could learn a lot from it. As far as not 
being an HCI expert, thats ok. This is Open Source, we work on what we 
like even if we are not "experts". At work or in college you program what 
other people want you to. Here people program on what interests them. I 
suggested the HCI part for you because you seemed to have an interest.

One of my jobs as "leader" is to get people who are interested in 
iCalendar working on the part that interests them the most while ensuring 
that the project as a whole moves along. 
 
> > Jeff Prickett:
> > ... 
> > If you would like to pick up the torch for the use
> > case analysis it would 
> > be greatly appreciated
> 
> The goals of the system must be carefully elaborated
> (e.g. [KAOS]), and as you point out, a proper use case
> analysis must be done. But since I am an absolute
> beginner in these areas, there is obviously a need for
> an expert discussion partner. Anybody out there?
> 

I will be available for discussion and can advise you on use case 
analysis. Furthermore, if we get enough semi-intelligent discussions going 
other experts who may be listening may jump in and add valuable 
information. I will read some of the KAOS research and we can continue the 
discussions.

You will not be expected to shoulder the requirements analysis alone. I 
think that you could play an invaluable role in coordinating the 
requirements analysis. You could follow along with the discussions and 
maintain a use case document. If you need help with use case analysis we 
will help.

> REFERENCES
> 
> [KAOS]http://www.info.ucl.ac.be/research/projects/AVL/ReqEng.html
> 
> [PALEN]http://www.cs.colorado.edu/~palen/dissertation/LPdissertation.pdf
> 
> [SKiCal] SkiCal - an extension of iCalendar
> http://www.ietf.org/internet-drafts/draft-many-ical-ski-05.txt
> 

I will add a to do item regarding researching SkiCal to the to do list.

> kind regards,
> 
> Peter Od�us
<snip>

Thanks Peter

Sincerely
Jeff Prickett




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>