raison d'etre
Dan Mosedale
goals of Mozilla Calendaring; I'm attaching the portion of the meeting
log that encompasses that discussion to the bottom of this message. I
postulated at the beginning of this meeting that one high-level phrasing
of what we're doing could be "that we want to use the net to make time
management and scheduling easier for people". After we had the ensuing
discussion, I still think that's a pretty reasonable way to look at it.
Now some of the main modifications that people proposed:
* including one of "open standards/interoperability/service neutrality"
This seems reasonable to me; I'd be interested to hear
suggestions for how to phrase it
concisely enough. On the other hand, one could look at this as
just an implementation detail.
* innovation
There's no shortage of innovation in the Calendaring market, but
I think we do want to do it
when appropriate. Whether this really belongs in such a
high-level goal, I'm not sure.
* alternative to Outlook
I don't believe that defining ourselves in terms of another
product is a good idea.
We're trying to find some semi-concrete goals, and "be like
Outlook but not" isn't something
that one can really focus on. Additionally, it seems to that
it's likely to
push us in the direction of "do X because Outlook does it", not
because it actually helps
users.
* offline
I think the interesting thing to convey here is that we want a
"smooth intermittently-connected
experience." The idea here is that we want to be very good at
dealing with and discovering
Internet resources while offline, and then syncing those locally
as appropriate, such that
things will, as much as possible, simply continue to "Just Work"
if/when the network
connection goes away. This too might or might not be
high-enough level to include in our
main goal. If we do include this in our main goal, that would
seem to suggest that it would
be a required feature for 1.0.
Thoughts?
Dan
----
<dmose> as we're thinking about product design & users that we're
designing for, one thing that i think is likely to be helpful
<dmose> is to try and come to some level of agreement on what it is
exactly that we're trying to do, at a very level
<dmose> s/very/very high/
<dmose> in particular, why is it interesting for the mozilla project to
be involved in calendaring?
<dmose> i spent some time thinking about this, and to me, it seems like
one possible way of looking at this is
<dmose> that we want to use the net to make time management and
scheduling easier for people
<dmose> i'm curious as to what folks think about that as a summary of a
raison d'etre
<dmose> and what other possibilities there are
<jminta_> also note that there really isn't any cross-platform
calendaring solution in existence at this stage
<dmose> that kinda depends how you segment
<dmose> i can think of a bunch, but they tend to have caveats
<dmose> eg "meeting maker/notes, but they're proprietary"
<dmose> yahoo/google calendar, but they're web only
<ctalbert_> I think yes, you want to use the net to make time management
easier for people, but you also have to realize that there must be an
offline solution. Most people who are not programmers are not online
very much of the time. Which is where a thick client app like lightning
or sunbird comes in.
<jminta_> i agree with ctalbert_, i'm reluctant to have 'net' feature so
prominently in our reason for existence
<dmose> well, when i say "net", i wasn't referring to constant
connectedness
<ctalbert_> you meant sharing and such?
<dmose> but, rather, things like the ability to get at your calendar
from multiple places, and to interact with other people's calendars, and
share your own, and discover events via evdb
<dmose> and publish iCalendar and hCalendar stuff
<lilmatt> however one aspect that holds us (as well as everything
mentioned before except mmaker/notes/outlook/corptime) is the lack of
freebusy & resource scheduling, so net is important.
<muhjiko> you might want to hook unto googles online calendar, or even
get there first choice in calendar applications, just as ff did
<lilmatt> holds us back...
<dmose> muhjiko: yeah, i think it would be constructive to have
discussions with them at some point
<dmose> right, so open standards are a big part of what we're trying to
use and drive here, i think
<lilmatt> Yes.
<jminta_> do we want to take a page from firefox's book and include
"increasing choice"?
<jminta_> or choice/innovation
<dmose> maybe
<dmose> that positions us more as an outlook competitor, however
<dmose> because there's no shortage of choice or innovation in the
web-calendaring space
<jminta_> right
<dmose> and while trying to compete with outlook is relevant here, i'm
not convinced that that's our primary raison d'etre
<dmose> as far as not being too net-centric, i think that would be a
mistake, and here's why
<jminta_> do people feel there is a need that we're filling or that
we're more geared towards expanding/innovating?
<dmose> some of each, i think
<dmose> there's clearly a need for good calendaring that works offline
<dmose> there's also clearly a little of interesting stuff going on in
this space which takes advantage of the net
<dmose> and makes calendaring and scheduling more compelling
<dmose> this actually ties in with why i think the net should be centric
to our mission
<dmose> which is that there are plenty of old-school PIMs and really
basic calendars for doing calendar-management-only
<dmose> but the innovation is what is likely to make what we (and other
net calendars) do more compelling
<lilmatt> (read: we're not trying to reinvent Palm Desktop)
<dmose> because it has the potential to make things easier for users
<dmose> but this is mostly in the realm of scheduling / sharing
<jminta_> why not talk about 'sharing' more generally, which would
include other methods of sharing including export/print/etc?
<dmose> eg freebusy, iMIP, shared calendars
<dmose> web pages with hCalendar embedded
<jminta_> right
<lilmatt> Yes. Currently the scheduling/sharing/freebusy stuff in other
non-propietary products is pretty horrid.
<dmose> eVite
<lilmatt> (and in some propietary products even)
<lilmatt> Example: I'
<lilmatt> m not rolling out iCal.app to all my folks because it has
basically no _real_ sharing/scheduling functionality
<dmose> well, iCall does at least allow you to propose meetings via
iMIP, right?
<ctalbert_> I think that sharing is where it's going to be at. Most of
the sharing applications out there .Mac, simdesk etc want you to be a
part of their service. What we have a chance to do here is do sharing
across all services.
<jminta_> so, not only do we want open standards, but we want people's
schedules to be as open and free-flowing as they desire?
<lilmatt> Yes
<lilmatt> ^ to dmose
<lilmatt> ctalbert: Exactly. Don't bind me to your service, be it
Exchange, Domino, .Mac, Zimbra, or whatever
<dmose> jminta: for me personally, a lot of this isn't so much about
sharing my calendar with folks
<dmose> jminta: as finding and discovering events that are happening
locally and making it trivially easy to get them into my calendar app
<jminta_> what is it about?
<jminta_> right
<lilmatt> dmose: My point about iCal.app is that it's really lacking
when people are coming from a MeetingMaker/CorporateTime world
<dmose> and in that, i include stuff like parties that people send out
evites for
<dmose> lilmatt: yeah, if you're used to be able to look at somebody's
freebusy, you're kinda crippled in the current iCal world
<lilmatt> No "Check for conflicts" button
<jminta_> dmose: i think i agree, basically i meant "people can find my
events" = "open" and, "i can get events from anywhere" = "free-flowing"
<dmose> jminta: ok, yeah, does sound like we agree
<jminta_> dmose: but this sounds like it's placing less emphasis on
scheduling
<jminta_> and more on search
<jminta_> which i feel like some might disagree with
<dmose> scheduling's a big too
<ctalbert_> And more on publishing
<dmose> witness our attempts to try and get meeting times that all of us
can attend
<dmose> it's currently a pathetic email-groping
<dmose> which is really unwieldy
<dmose> s/big/big thing
<dmose> one of the interesting things to me about the internet is that
it does allow groups of people to easily collaborate in ways that didn't
used to be possible
<lilmatt> cross-organizationally
<dmose> right, exactly like we're doing right now
<dmose> so being able to schedule stuff like online meetings seems huge
to me
<jminta_> so, personally, i feel like this is headed back to the
imaginary-users, because i feel like the scheduling bit is only
interesting to a particular segment
<dmose> oh, absolutely
<dmose> the reason i included this brainstorming in the agenda
<jminta_> i can bite on the find/retrieve (search) stuff
<lilmatt> Sure I can invite people from work currently in my Oracle
Calendar, but why can't I also invite dmose and jminta and KNOW that
it's gonna work (unlike current Outlook *-*-*-*-* crap)
<dmose> is that i thought it would help us get a focus on imaginary
users and product definition
<dmose> jminta: i'm sure you're right that not all of our users are
likely to use scheduling stuff
<dmose> jminta: that said, i think there is room in this space for
innovation
<dmose> for example, i think eVite drove a set of users to do online
scheduling who never would have wanted to do it before
<jminta_> so i'm just saying, let's make our raison something that
covers all the bases
<lilmatt> but there's a whole huge untapped market for a
non-Outlook/Exchange scheduling solution
Mike Beltzner
> We started a discussion in our meeting last week about the high-level
> goals of Mozilla Calendaring; I'm attaching the portion of the meeting
> log that encompasses that discussion to the bottom of this message. I
> postulated at the beginning of this meeting that one high-level phrasing
> of what we're doing could be "that we want to use the net to make time
> management and scheduling easier for people". After we had the ensuing
> discussion, I still think that's a pretty reasonable way to look at it.
> Now some of the main modifications that people proposed:
>
> * including one of "open standards/interoperability/service neutrality"
> This seems reasonable to me; I'd be interested to hear
> suggestions for how to phrase it
> concisely enough. On the other hand, one could look at this as
> just an implementation detail.
Interoperability is the key, which was nicely summed up in the chatlog
you attached as "Don't bind me to your service". I think there's a
need to create a product that makes the market *expect* to be able to
share, publish and access their calendar data from everywhere. There
*needs* to be a clean solution to the free/busy problem other than
"make sure that you're using the same service as the other guy.
> * innovation
> There's no shortage of innovation in the Calendaring market, but
> I think we do want to do it
> when appropriate. Whether this really belongs in such a
> high-level goal, I'm not sure.
Is there really innovation, or is there merely choice? I think it's
perfectly acceptable for this group to make innovation a part of its
mission, as opposed to simply offering a choice. This will affect
every design decision, every RFE, etc, and hopefully keep the focus on
making things better for the user, even if that means departing from
some assumptions of what a calendaring client is or is not.
> * alternative to Outlook
> I don't believe that defining ourselves in terms of another
> product is a good idea.
> We're trying to find some semi-concrete goals, and "be like
> Outlook but not" isn't something
> that one can really focus on. Additionally, it seems to that
> it's likely to
> push us in the direction of "do X because Outlook does it", not
> because it actually helps
> users.
Totally agreed. The Firefox charter handles this well, IMO, in that it
never directly expresses that the goal is to create an alternative to
IE. Whether or not you want to express the desire to ensure an easy
transition from leading calendar clients (here I'd include OE, Notes,
iCal, and maybe Palm Calendar) is something to think about, though.
> * offline
> I think the interesting thing to convey here is that we want a
> "smooth intermittently-connected
> experience." The idea here is that we want to be very good at
> dealing with and discovering
> Internet resources while offline, and then syncing those locally
> as appropriate, such that
> things will, as much as possible, simply continue to "Just Work"
> if/when the network
> connection goes away. This too might or might not be
> high-enough level to include in our
> main goal. If we do include this in our main goal, that would
> seem to suggest that it would
> be a required feature for 1.0.
This is definitely key.
[..snipped out irc log...]
cheers,
mike
--
/ mike beltzner / user experience lead / mozilla corporation /
Michiel van Leeuwen
> We started a discussion in our meeting last week about the high-level
> goals of Mozilla Calendaring; I'm attaching the portion of the meeting
> log that encompasses that discussion to the bottom of this message. I
> postulated at the beginning of this meeting that one high-level phrasing
> of what we're doing could be "that we want to use the net to make time
> management and scheduling easier for people". After we had the ensuing
> discussion, I still think that's a pretty reasonable way to look at it.
> Now some of the main modifications that people proposed:
The way the sentence is now, the net is the first thing to be mentioned.
It's not like we want to use the net, and happen to think the
calendaring is a nice application. The order should be switched.
Calendaring is the goal, the net is an utility.
Also, the net isn't an utility by itself. It's used to communicate with
others. I think we should include that somehow.
>
> * including one of "open standards/interoperability/service neutrality"
> This seems reasonable to me; I'd be interested to hear suggestions
> for how to phrase it
> concisely enough. On the other hand, one could look at this as
> just an implementation detail.
I think using standards is pretty important. It is a requirement to not
be locked into a certain service or vendor. Choice and all.
> * innovation
> There's no shortage of innovation in the Calendaring market, but I
> think we do want to do it
> when appropriate. Whether this really belongs in such a
> high-level goal, I'm not sure.
Innovation doesn't need to be a goal, i think. We should try to make the
innovations usable for 'normal' users
> * alternative to Outlook
> I don't believe that defining ourselves in terms of another
> product is a good idea.
I fully agree.
> * offline
These days, the main reason to use a fat client seems to be that it
always works. So offline would be important. But I'm not sure enough if
it high-level enough.
About the exchange point: The number of reactions I read about people
using sunbird/lightning in their small offices (like 10 people)
surprises me. I think there is a pretty big market there. Easy, low
cost, exchange (pun not intended) of meeting details.
Michiel
Stefan Sitter
> Dan Mosedale wrote:
>> * offline
>
> These days, the main reason to use a fat client seems to be that
> it always works. So offline would be important. But I'm not sure
> enough if it high-level enough.
I think offline is an essential feature. If you always have to be
online to use your calendar why use Sunbird? You could use any web
based calendar instead. Offline modus is a feature that the web
based calendars can't offer.
Personally I prefer to keep all my data (calendars) on my local hard
disk. Therefore I download calendars and integrate them as a local
calendar instead of subscribing at the moment.
You could summarize this as: "Always edit the calendar locally but
have the possibility to view and/or share them online."
An use cases for this could be any calendar with sport events,
public holidays, movie theater program, etc. that is made available
online for subscription.
Restoring the 'automatic publish' feature from Sunbird 0.2 would
help on this topic. You have a local calendar that will be published
to a remote location automatically (e.g. every 10 minutes).
This has the benefit of a local calendar (performance and speed of
SQLite storage and offline modus) and the benefit of a remote
calendar (as backup or for read-only sharing).
From a developers point of view this should not be that much effort.
The publishing code is already existing and there is no need for
some kind of special offline caching.
And from a users point of view it is much better than doing
publishing manually every time. I have already seen several reports
in the german and english forum missing that feature in Sunbird 0.3a1.
/Stefan
Michiel van Leeuwen
> Michiel van Leeuwen wrote:
>> Dan Mosedale wrote:
>>> * offline
>> These days, the main reason to use a fat client seems to be that
>> it always works. So offline would be important. But I'm not sure
>> enough if it high-level enough.
>
> I think offline is an essential feature. If you always have to be
> online to use your calendar why use Sunbird? You could use any web
> based calendar instead. Offline modus is a feature that the web
> based calendars can't offer.
Sure, being able to use your calendar while being offline is important.
It's even so important, that it speak for itself. You should be able to
have a calendar that's fully stored on your own computer. And that even
works currently.
In recent discussion, when talking about offline support for calendar,
that meant being able to access your server-based calendar while
offline. For example, your caldav calendar or your calandar stored on
your http server. And that's something completly different. I think this
kind of offline support isn't high level enough to be our raison d'etre.
> From a developers point of view this should not be that much effort.
Saying that something shouldn't be much effort is a very dangerous
thing. It generally means that it's pretty hard.
Michiel
Michiel van Leeuwen
> * alternative to Outlook
> I don't believe that defining ourselves in terms of another
> product is a good idea.
> We're trying to find some semi-concrete goals, and "be like
> Outlook but not" isn't something
> that one can really focus on. Additionally, it seems to that
> it's likely to
> push us in the direction of "do X because Outlook does it", not
> because it actually helps
> users.
I came across this nice post today: (also read the link in it)
http://tieguy.org/blog/2006/04/22/guerilla-disruption/
With that in mind, only defining ourself as competitor to outlook seems
bad. There are some many other markets to look into! Small offices,
where simply sharing calendars would making appointments easy.
Home-users, sending event details to their friend, when going to a
movie. Websites, publishing event information, about which movies runs
where and when.
Just wanting to compete with outlook will needlessly narrow our focus,
and minimize the chance of success.
Michiel
Mark Harrison
Here's my feedback, based purely on being a user:
Main use case:
We have a church website and have a need to coordinate our
facilities (meeting rooms, etc). We have phpicalendar running,
and keep the .ics files on the web server.
So, we need an easy way for people to edit the shared facilities
calendar we have on the server.
Right now there are several different programs, depending on
your OS platform, that can edit .ics files remotely.
So, this might be a good use case to consider.
Important feature: easy to connect and configure server information.
Cheers and thanks for all the work!
Mark
Dan Mosedale
> On 4/19/06, Dan Mosedale <dm...@mozilla.org> wrote:
>> We started a discussion in our meeting last week about the high-level
>> goals of Mozilla Calendaring; I'm attaching the portion of the meeting
>> log that encompasses that discussion to the bottom of this message. I
>> postulated at the beginning of this meeting that one high-level phrasing
>> of what we're doing could be "that we want to use the net to make time
>> management and scheduling easier for people". After we had the ensuing
>> discussion, I still think that's a pretty reasonable way to look at it.
>> Now some of the main modifications that people proposed:
>>
>> * including one of "open standards/interoperability/service neutrality"
>> This seems reasonable to me; I'd be interested to hear
>> suggestions for how to phrase it
>> concisely enough. On the other hand, one could look at this as
>> just an implementation detail.
>
>
> Interoperability is the key, which was nicely summed up in the chatlog
> you attached as "Don't bind me to your service". I think there's a
> need to create a product that makes the market *expect* to be able to
> share, publish and access their calendar data from everywhere. There
> *needs* to be a clean solution to the free/busy problem other than
> "make sure that you're using the same service as the other guy.
Yes, completely agreed. Your above summary makes me think that this is
more important to our core mission than I had previously thought.
>> * innovation
>> There's no shortage of innovation in the Calendaring market, but
>> I think we do want to do it
>> when appropriate. Whether this really belongs in such a
>> high-level goal, I'm not sure.
>
> Is there really innovation, or is there merely choice? I think it's
> perfectly acceptable for this group to make innovation a part of its
> mission, as opposed to simply offering a choice. This will affect
> every design decision, every RFE, etc, and hopefully keep the focus on
> making things better for the user, even if that means departing from
> some assumptions of what a calendaring client is or is not.
It seems to me that there really is a certain amount of innovation in
the calendaring market (cg Google Calendar, EVDB, ...). That said,
there are also a lot of "me too" apps. I think innovation is a big
deal, though, as I think there is a lot of interesting things one could
do for the user by converging web-apps and fat-client apps (lots of
interesting hCalendar-based features come to mind).
Dan
Dan Mosedale
> Dan Mosedale wrote:
>> We started a discussion in our meeting last week about the high-level
>> goals of Mozilla Calendaring; I'm attaching the portion of the meeting
>> log that encompasses that discussion to the bottom of this message. I
>> postulated at the beginning of this meeting that one high-level
>> phrasing of what we're doing could be "that we want to use the net to
>> make time management and scheduling easier for people". After we had
>> the ensuing discussion, I still think that's a pretty reasonable way
>> to look at it. Now some of the main modifications that people proposed:
>
> The way the sentence is now, the net is the first thing to be mentioned.
> It's not like we want to use the net, and happen to think the
> calendaring is a nice application. The order should be switched.
> Calendaring is the goal, the net is an utility.
> Also, the net isn't an utility by itself. It's used to communicate with
> others. I think we should include that somehow.
I wasn't actually intending to imply that the net was the important part
by putting it first; I just felt the language was a little smoother that
way. But in general, I agree with the sentiment of what you've written
here.
>> * innovation
>> There's no shortage of innovation in the Calendaring market, but
>> I think we do want to do it
>> when appropriate. Whether this really belongs in such a
>> high-level goal, I'm not sure.
>
> Innovation doesn't need to be a goal, i think. We should try to make the
> innovations usable for 'normal' users
I could go either way on this one. One reason this may be important to
call out in our goals is that when innovating, it's sometimes necessary
to take risks and/or support things that users' aren't specifically
asking for. E.g. very few end-users are likely to ask for hCalendar
support until there's a certain amount of momentum in the marketplace.
That said, my personal feeling is that the hCalendar story is compelling
enough that leading that charge might not be a bad thing.
Dan
Dan Mosedale
> Sure, being able to use your calendar while being offline is important.
> It's even so important, that it speak for itself. You should be able to
> have a calendar that's fully stored on your own computer. And that even
> works currently.
> In recent discussion, when talking about offline support for calendar,
> that meant being able to access your server-based calendar while
> offline. For example, your caldav calendar or your calandar stored on
> your http server. And that's something completly different. I think this
> kind of offline support isn't high level enough to be our raison d'etre.
Perhaps not high-level enough, but it is (at least for now), a key
differentiating factor between web-based applications and fat client apps.
Dan
Dan Mosedale
>
> I came across this nice post today: (also read the link in it)
> http://tieguy.org/blog/2006/04/22/guerilla-disruption/
> With that in mind, only defining ourself as competitor to outlook seems
> bad. There are some many other markets to look into! Small offices,
> where simply sharing calendars would making appointments easy.
> Home-users, sending event details to their friend, when going to a
> movie. Websites, publishing event information, about which movies runs
> where and when.
I think there's a good analogy here with Firefox: Firefox became very
popular with personal users without ever really making inroads in the
enterprise market. Because Firefox cared especially for individual
users, it was possible to focus on doing a really good job with a
smaller feature set (i.e. not initially trying to be all things to all
people). Because it's a good solution, enterprises are now expressing
interest in Firefox of their own volition, without ever having been
explicitly targeted.
The analogy here is that I don't see how it's possible to ever become a
good solution for larger groups of users without first being a good
solution for smaller groups of users. My hunch is that we'll do well
worrying about the smaller groups Michiel mentions first, and
considering / worrying about larger groups later. This could help us in
deciding which features are most important for 1.0.
Dan
Dan Mosedale
high-level goals for calendaring, and I've come up with a new iteration
that I think does a reasonable job capturing a lot of the key stuff
that's been brought up. To wit:
"We're trying to provide software to make time management easier which
makes effective use of Internet resources and doesn't bind the user to a
single service."
Some thoughts on the phrasing:
* I picked "time management" because that includes calendaring, todos,
and scheduling.
* "easier" encompasses usability and learnability,
* "effective use of Internet resources" includes scheduling
(ITIP/freebusy), intermittent connectivity, and
searching/discovering/sharing calendaring info. It also makes it clear
that the Internet is to be used in service of the higher-level goal, not
just because net.candy is cool.
* "doesn't bind the user to a single service" includes low-barrier to
entry & exit (import/export), open-standards (adoption, participation,
and innovation), and seamless integration of data from multiple sources.
My current inclination for what to do with this (once we've reached
rough consensus) is to put together a charter page somewhat similar to
the Firefox charter page
<http://www.mozilla.org/projects/firefox/charter.html>, but with the
goal statement at the top, and then a short set of bullet points
somewhat similar to those in this post explaining the overall vision in
a bit more detail.
Also, for what it's worth, I suspect we'd do pretty well to accept most
or all of the bullet-points in the Firefox charter as our own.
Thoughts?
Dan
Joey Minta
> I've spent a bunch of time pondering the discussions we've had about
> high-level goals for calendaring, and I've come up with a new iteration
> that I think does a reasonable job capturing a lot of the key stuff
> that's been brought up. To wit:
>
> "We're trying to provide software to make time management easier which
> makes effective use of Internet resources and doesn't bind the user to a
> single service."
>
> Some thoughts on the phrasing:
>
> * I picked "time management" because that includes calendaring, todos,
> and scheduling.
>
> * "easier" encompasses usability and learnability,
>
> * "effective use of Internet resources" includes scheduling
> (ITIP/freebusy), intermittent connectivity, and
> searching/discovering/sharing calendaring info. It also makes it clear
> that the Internet is to be used in service of the higher-level goal, not
> just because net.candy is cool.
>
> * "doesn't bind the user to a single service" includes low-barrier to
> entry & exit (import/export), open-standards (adoption, participation,
> and innovation), and seamless integration of data from multiple sources.
>
> My current inclination for what to do with this (once we've reached
> rough consensus) is to put together a charter page somewhat similar to
> the Firefox charter page
> <http://www.mozilla.org/projects/firefox/charter.html>, but with the
> goal statement at the top, and then a short set of bullet points
> somewhat similar to those in this post explaining the overall vision in
> a bit more detail.
>
> Also, for what it's worth, I suspect we'd do pretty well to accept most
> or all of the bullet-points in the Firefox charter as our own.
>
> Thoughts?
>
> Dan
I like this a lot. It seems to have done a very good job balancing the
various points of view. I also second the idea of copying most of the
rest of the firefox charter, although we may need to decide our own
criteria for 'small download size'.
-Joey
Michiel van Leeuwen
> "We're trying to provide software to make time management easier which
> makes effective use of Internet resources and doesn't bind the user to a
> single service."
I like it :)
Michiel
Dan Mosedale
> Dan Mosedale wrote:
>> * "doesn't bind the user to a single service" includes low-barrier to
>> entry & exit (import/export), open-standards (adoption, participation,
>> and innovation), and seamless integration of data from multiple sources.
>
> Is 'service' the right word here? It seems like 'applications' bind
> people.
Hmmm, at some level I think we want to include both. Services I can
think of would include stuff like EVDB, trumba, Google Calendar, etc.
Applications would include the typical fat-client calendar apps and
PIMs. We could just say "service or application"...
Dan