You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Peter Odéus <pe...@yahoo.se> on 2002/03/03 22:39:26 UTC
Periodicity requirements & design
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.
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).
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?
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
_____________________________________________________
Hitta snörapporter...
från 500 olika skidorter i Europa
på http://se.snow.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Periodicity requirements & design
Posted by Jeff Prickett <pr...@www1.kc.aoindustries.com>.
On Sun, 3 Mar 2002 javajoe2975@comcast.net wrote:
> Peter,
>
> I'm helping on Periodicity with some small things, like testing and a
> Time Zone implementation. I believe that a discussion and development of a
> complete set of requirements for Periodicity would be a great thing. The
> project will grow fastest and best when its goals meet the needs of a group
> of interested and involved people.
>
Reliability (and hence testing) and Time Zone handling are very important.
> A few days ago, the main committer on this project, Jeff Prickett,
> offered the following to a couple of interested developers:
> "Where we are is we have the basic design of the iCalendar objects
> "implemented. We need code to save the objects to a database, templates in
> "Velocity to view them in a web browser, security integration with Turbine
> "and JAAS. After that we should be ready for a 0.0.1 release.
> <snip>
> "I look forward to working with you and hope that you decide to
> "join us as we build a world class calendaring application.
>
This might be a good time to mention that I have checked in a formal
proposal (jakarta-commons-sandbox/periodicity/proposal.html) and a status
document (jakarta-commons-sandbox/periodicity/status.html). In these
documents the scope/mission statement of the project is defined.
I would like to point out the sentence where we state that we want to have
features comparable to if not better than commercially available
alternatives.
A more formal requirements design and analysis would greatly help to that
end.
> While this is definitely not a complete set of requirements, it does
> outline an absolute minimum set of capabilities that must be implemented for
> Periodicity to function. Additional core features, enhancements, and
> yet-to-be-identified critical components must be added.
>
> In your email, you said:
> > How are we going about to formalize the requirements
> > and the design of this wonderful new system?
>
> I look forward to working with you.
>
> Bottom line: Thanks for taking the time to look at Periodicity. Please
> contribute.
>
> Personal note: I am new to Jakarta and fairly new to programming. I
> appreciate you taking the time to include links to relevant documents in
> your email. I have downloaded the Palen dissertation and a Meeting
> Scheduler paper from the KAOS site and plan to read them over the next week.
>
Thanks Mike for downloading the documents. We should probably begin by
reading the documents and revisiting this conversation when the three of
us can all understand the relevant research. This may take some time.
In the meantime, we could all download a copy of ArgoUML open
source design software because I have some UML diagrams to add to CVS and
we should probably begin maintaining a use case analysis document.
> Thanks,
> Mike George
Thanks,
Jeff Prickett
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Periodicity requirements & design
Posted by ja...@comcast.net.
Peter,
I'm helping on Periodicity with some small things, like testing and a
Time Zone implementation. I believe that a discussion and development of a
complete set of requirements for Periodicity would be a great thing. The
project will grow fastest and best when its goals meet the needs of a group
of interested and involved people.
A few days ago, the main committer on this project, Jeff Prickett,
offered the following to a couple of interested developers:
"Where we are is we have the basic design of the iCalendar objects
"implemented. We need code to save the objects to a database, templates in
"Velocity to view them in a web browser, security integration with Turbine
"and JAAS. After that we should be ready for a 0.0.1 release.
<snip>
"I look forward to working with you and hope that you decide to
"join us as we build a world class calendaring application.
While this is definitely not a complete set of requirements, it does
outline an absolute minimum set of capabilities that must be implemented for
Periodicity to function. Additional core features, enhancements, and
yet-to-be-identified critical components must be added.
In your email, you said:
> How are we going about to formalize the requirements
> and the design of this wonderful new system?
I look forward to working with you.
Bottom line: Thanks for taking the time to look at Periodicity. Please
contribute.
Personal note: I am new to Jakarta and fairly new to programming. I
appreciate you taking the time to include links to relevant documents in
your email. I have downloaded the Palen dissertation and a Meeting
Scheduler paper from the KAOS site and plan to read them over the next week.
Thanks,
Mike George
----- Original Message -----
From: "Peter Odéus" <pe...@yahoo.se>
To: "periodicity jakarta" <co...@jakarta.apache.org>
Sent: Sunday, March 03, 2002 4:39 PM
Subject: Periodicity requirements & design
> 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.
>
> 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).
>
> 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?
>
> 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
>
>
> _____________________________________________________
> Hitta snörapporter...
> från 500 olika skidorter i Europa
> på http://se.snow.yahoo.com
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Periodicity requirements & design
Posted by Jeff Prickett <pr...@shpimp.com>.
On Mon, 4 Mar 2002, Joaquin Salvachua wrote:
> Hello,
>
> I think that the basic functionalitiy can be taken from the work at ietf
> cal-sched group. This is described in:
>
> http://www.ietf.org/internet-drafts/draft-ietf-calsch-inetcal-guide-02.txt
>
Thanks for the heads up. I think I have seen this draft before maybe not
this version. I am pretty sure I have not done anymore than skimmed it. It
is definitely a goal of Periodicity to be in compliance with all relevant
standards and emerging standards for Groupware.
> There describe calendar stores (just store) and agents (the one that
> renders a modify it).
>
This is great as we were just about to create software to store iCalendar
objects in a database.
> Perhaps Peridicity can have an store (where to keep the icals) and
> allow interaction by the ietf protocol (itip and imip) and also
> interactive editing, but behaving like any other agent.
>
> [just starting to think about it ]
>
I am just starting to think about it too. To be honest we have been so
deep in RFC 2445 that we have not had time to look at the bigger picture.
I am going away tomorrow someplace nice and quiet where I will not be able to
be reached by phone, fax, or email for the rest of the week. I will be
dragging some of these documents with me and will be reading them
thoroughly. Then we can have some serious discussions on how what features
to implement and how to implement them.
> Regards
>
> Joaquin
>
>
>
Thanks again for your interest in Periodicity...
Sincerely,
Jeff Prickett
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Periodicity requirements & design
Posted by Joaquin Salvachua <js...@dit.upm.es>.
Hello,
I think that the basic functionalitiy can be taken from the work at ietf
cal-sched group. This is described in:
http://www.ietf.org/internet-drafts/draft-ietf-calsch-inetcal-guide-02.txt
There describe calendar stores (just store) and agents (the one that
renders a modify it).
Perhaps Peridicity can have an store (where to keep the icals) and
allow interaction by the ietf protocol (itip and imip) and also
interactive editing, but behaving like any other agent.
[just starting to think about it ]
Regards
Joaquin
--
-----------------------------------------------------------
Joaquin Salvachua tel: +34 91 549 57 00 x.367
Associated Professor +34 91 549 57 62 x.367
dpt. Telematica
E.T.S.I. Telecomunicacion
Ciudad Universitaria S/N fax: +34 91 336 73 33
E-28040 MADRID SPAIN
mailto: jsalvachua@dit.upm.es // http://www.dit.upm.es/~jsr
------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Periodicity requirements & design
Posted by Jeff Prickett <pr...@www1.kc.aoindustries.com>.
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>
Re: Periodicity requirements & design
Posted by Peter Odéus <pe...@yahoo.se>.
> Jeff Prickett:
> ...
> 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 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?
Event reminders and the ability to tailor
sophisticated recurring events also seem to be crucial
according to [Palen].
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.)
-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.
> Jeff Prickett:
> ...
> 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.
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.
> 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?
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
kind regards,
Peter Odéus
=====
Peter Odéus
Raketgatan 13/141
413 20 Göteborg
+46 (0)31 81 40 11
peter_odeus@yahoo.se
_____________________________________________________
Hitta snörapporter...
från 500 olika skidorter i Europa
på http://se.snow.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Periodicity requirements & design
Posted by Jeff Prickett <pr...@www1.kc.aoindustries.com>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>