Initially these are in no particular order. Some of them are mine, some
of them were suggested by others when I asked about this (I went looking
for a product that did all of this). I'll be writing these up into a
more coherent form - this is more of a brainstorm. Something missing?
Drop me a line.
- User interface: views (mine, group, organisation).
- Group management: we inherit from a lot of these requirements
the need to track groups - both those defined by others and user-defined
ones. Membership details of groups and entry/exit etc. are also subject
to ACLs for visibility/modification permissions.
- Scenario: if the semantic web allows me to determine that Charlie and
Alice are a couple, Burgular Bob would find it quite helpful to
find periods of two weeks or so when they are both listed as unavailable
for meetings. Odds on they're on holiday. How do we combat this?
- Navigation and views (again, UI issues, but these are important)
should be reasonably slick and configurable.
- Resource booking should be possible as well as getting people to
meetings. Use the iCal approach of treating a resource as a calendarable
- Two levels of events: instances (eg, meeting, notice) and the generator
of one or more instances - permitting repeated appointments, etc.
Generators should be highly flexible (this group of people ought to meet
once a month until further notice; such a meeting should be in the first
week of the month; etc.).
- No changing the past (except for annotating previous events with
information, minutes, etc), group memberships in the past should be
recoverable. However, it may be that new members of a group should find
previous closed minutes are now accessible.
- must know about: people (roles), groups, groups within groups.
- users must be able to define their own groups
- must handle: notices; appointments, "is X available?"
- synching: a better machine interface
- scheduling meetings for a set of people
- more structure in the appointment descriptions
- all objects with fine-grained visibility controls: personal, group,
dept, public, etc.
- personalised "intray" handling of appointments: "you've been invited
to this meeting. Join/decline?"
- warnings of upcoming events. What have I got on this week?
- changes to group membership should not affect history
- double-booking prevention/warning
- resource handling/booking: resources available to different
categories of people
- scalable across a large userbase
- write/update permissions to appointments, etc. also fine-grained
- TODO integration? Deadlines?
- multiple interfaces: email notifications, etc.
- "what is Y doing this week?"
- Scenario - busy/available categories: eg, I'm available for meetings,
but only in Boston (not Bristol), only by phone, working from home, etc.
- use some of the work done for DC.coverage for geographic availability?
- (Libby) It would be good to have a public 'is X available page', don't know if
- (Libby) Machine interface: yeah, especially an RDF interface ;-), especially by
- (Libby) I think syncing would be rather difficult. I'm wondering whether rdf
smooshing of several calendars and then querying them would be enough (I
guess that would require people with PDAs to be able to handle turning
their calendar files into rdf pages somhow.
- distribution: don't rely on a single central server that knows about
anyone. However, don't rely on a single installation per person either.
How much fo this generality is really needed?
- More distribution: does a person have a "remote calendar API" address?
More than one? How do we keep multiple instances of X's calendar in
sync? (eg, two big installations and a palm pilot).
- If distributed: transport mechanism(s) should ensure reliability,
recovery, security, assurance of identity, etc. as much as possible.
- Roles: single-member groups (with membership controlled by another,
- Easy one: time-zone aware / independent.
- Multi-level events: eg, a 3-day meeting with agendas for each day.
Bob agrees to the timing, but regrets that he can't make it for day 3.
(Scheduling different rooms for each day?) In the limit, different
agenda items could be viewed as sub-events of the parent meeting;
is this too cute a generalisation?
- Fuzzy scheduling. Not sure exactly what this means: currently it's just a cute phrase.
"I'm 90% likely to be there",
"the meeting starts at about 2pm" - analyse usefulness of this (low, I think).
Although, measuring a participant's intended attendance on a (probabalistic) scale of 0-1
seems reasonable. Permits boolean or fuzzy attendance :-) Probably over-engineering here.
It's clear from the above that a fundamental need for a calendaring
system is a (distributed) user/group management layer that can identify
"calendarable resources" - people, roles, groups, resources.
This list should be refined into a proper set of requirements that can
be used as the basis for a critique of existing
standards and products.