[lug] The deal with applets / notifications / panels / indicators / systray.....

[Rob Nagler]

Hi Bruce,

> How would you do it without a framework?

It depends on what you mean by framework.  When we built CAL54, we did
it to model the problem "What's happening in Boulder?"  We didn't have
a framework, we had a programming language and a general application
framework.  Yet, we knew we had a problem: indexing temporal data from
websites.  There are three steps:

1. Identify websites with calendars
2. Describing the calendar programmatically
3. Canonicalizing new paradigms

We haven't figured out a way to do (1) fully automatically.  We have
some ideas, but there is the problem of identifying exactly where
"here" is for a website and making sure the data is not spam.  Many
sites publish calendars, but you don't want them.  You want "here" to
be bricks-and-mortar.  Non-trivial.

We have a lot of experience with (2) for various applications.  When I
first approached people on solving the problem, they said you couldn't
do it.  I said I could, and we do, now.  For (2) we have a modeling
language, but it only evolved out of this specific problem, and not
from our general "canonicalize website data" tools.  The modeling
language evolved with our understanding of the data, not the other way
around.  It's such a good modeling language that we had high school
kids coding with it this summer.  However, it is not a generic model,
and it maps to what we know about (3).

The last step (3) is very interesting, because you would think that
the concept of calendars is well known.  There is even quite a verbose
standard for calendars.  Yet, consider the problem of movies.  You
want to describe them as having a "run" of days (repeating event) with
an end date, but you do not want to show each event as a separate
entry or one single entry.  Rather, you want to display times a movie
is being shown on a particular day, or perhaps, the list of movies
being shown today at a specific theater.  Go to movies.google.com, and
you'll see what I mean.  There are other paradigms that come up as you
gather data, such as, it may say "blues", but you would want to
include that as "jazz" in a small place like Boulder.

IOW, we are still evolving the modeling language for CAL54, and it
involves direct experience.  We could have, alternatively, said, "This
is a calendaring problem.  Let's start building a solution that does
calendaring."  Or, we might have put in GIS into modeling language,
because that's an important feature of an events calendar.  We didn't
do this, because our experience tells us that doing so is putting the
cart before the horse.  We don't know the problem we are solving until
we solve it.  Some people call this emergent design, but I just call
it, "cut twice, users measure", since there is no cost to cutting
software, and there's a huge cost to measuring something of which you
don't know the dimensionality.

> tools. Imagine if we could get lots of folks as did Wikipedia. Call me

Yes, that's what we all imagine.  That's what we imagined with CAL54,
for example.  Turns out that attracting users, even if you have useful
models, is a rather tricky business.  Nobody can explain
satisfactorily why Facebook is about to IPO for $+75B and MySpace is
about to go bankrupt.  Furthermore, how did Facebook become the
"passport" that Microsoft and OpenID tried to be?  The specific
details matter, and frameworks create distance from those details.

Rob