[Date Prev] [Date Next] [Thread Prev] [Thread Next] Indexes: Main | Date | Thread | Author

Re: [ba-unrev-talk] Document for Review


Thanks.    (01)

Granularity is in there. But I *really* liked your comment about
advertisers' possible objections!    (02)

BTW:
Do you know what happened to the link to the page with video segments
from the NLS demo? It used to be featured prominently on the BA main
page. Now it doesn't seem to be there at all.    (03)



Henry K van Eyken wrote:    (04)

> Eric.
>
> Glad you took it well. I was a bit in a blue mood when I wrote my
> response. So much to be done, so little time left for doing it.
>
> At any rate, a major item in your original post (and in your posts way
> back during the days of the colloquium) is granularity. Granularity in
> all web pages extant is very much desired. I believe that
> paragraph-level granularity is a good, practical goal. I am also
> inclined to believe that commercial interests are (will be) against such
> granularity in pages carrying advertising.
>
> But, then again, your immediate concern is not with web-wide level of
> co-operative work. However, it might be well, to keep such a future
> extension in mind.
>
> Henry
>
>
>
> On Wed, 2003-01-08 at 16:19, Eric Armstrong wrote:
> > Hey, Henry.
> >
> > Thanks for the post. I'm trying to get at basic infrastructure questions,
> > though, rather than large design concerns. I got caught up in the vision
> > myself, and list moved towards big-picture things.
> >
> > But mostly I'm trying to enumerate the low-level infrastructure issues
> > that emerge when the rubber hits the road, and someone tries to code
> > something.
> >
> > Actually, one of the things I should have put on that list is time
> > synchronization. When updates are happening simultaneously at remote
> > locations, and the results are shared, "which happened first" becomes important.
> >
> > (Note to Self: Examine the bread crumbs in the design document for other
> > low level issues.)
> >
> >
> > Henry K van Eyken wrote:
> >
> > > Eric.
> > >
> > > You are talking here about stuff dear to my heart, but it is so complex
> > > I cannot just immediately respond in a satisfactory way - especially
> > > because I am overloaded and my mind is getting slower while my body is
> > > screaming to get me away from my desk.
> > >
> > > I would want to tick off the points you raise in a media/educational
> > > setting, which is something I would want Fleabyte to evolve into, but
> > > which I am not likely to ever see.
> > >
> > > Media, typically are close to one-way instruments, from emitter to
> > > receiver. Oh yes, readers may write letters to editors, but it is the
> > > editors who select what and how much of each letter received is printed.
> > > In other words, the readers are under editorial control.
> > >
> > > Schools to a little better. Students may ask questions, but even those
> > > questions may be ignored or rephrased.
> > >
> > > Eventually I shall have to produce an article outlining how Fleabyte
> > > might move from being a webzine toward a collaborative tool. One
> > > question is: who are doing the collaborating? Another: what is the depth
> > > of that collaboration, the commitment involved. These questions ought be
> > > posed in a well-defined context of which I perceive various stages.
> > >
> > > Stage one is getting, evaluating, pruning information. We now have
> > > search engines; we lack evaluation engines. And we haven't got
> > > well-defined means of making individuals with their limited mental
> > > capacity feel comfortable with an extensive body of machine-held
> > > information. To make matters more complex, that body is dynamic with
> > > information continually added, removed, altered in a way that any person
> > > who exhibits this kind of a continually changing mind is considered
> > > fickle, unreliable, undependable, and, hence, even unemployable!
> > >
> > > Stage one would involve a moving feast of involved expertise, knowledge
> > > workers with a sense of the future and a sense of how directions in
> > > their field are potentially being deflected by projected developments
> > > elsewhere. (Think of Doug's "frontier outpost" people as discussed
> > > during the colloquium!)
> > >
> > > A next stage would involve "spreading the word" to a critical mass of
> > > decision-makers, which "at bottom" is the electorate, but which need
> > > depend on either experts trusted by their elected representatives or
> > > depend on digitally held expertise - a benign auto pilot.
> > >
> > > Following that comes planning for action, the problem of alternatives,
> > > levels of certainty, etc., all of which would lead into appropriate
> > > action.
> > >
> > > I guess I have gone a little beyond the kind of cooperation people
> > > normally think of when contemplating tools for collaboration. Really, we
> > > are here in the domain of dynamic, coevolutionary collaboration. The
> > > kind of stuff Doug is talking about.
> > >
> > > Too bad he has not been getting the needed support.
> > >
> > > Too bad, Fleabyte is likely to whither on the vine.
> > >
> > > But, by all means, let's keep on dreaming and scheming.
> > >
> > > Henry
> > >
> > > The production of the
> > >
> > >
> > >
> > > On Mon, 2003-01-06 at 18:10, Eric Armstrong wrote:
> > > > I've just published a document at my web site, entitled
> > > > Technical Impediments to Persistent Collaboration Tools.
> > > > http://www.treelight.com/software/collaboration/Technical_Impediments.html
> > > >
> > > > I would appreciate feedback from you guys.
> > > >
> > > > The document is an attempt to identify the set of necessary
> > > > infrastructure features that, by their absence, make it
> > > > difficult or impossible to develop usable collaboration tools.
> > > >
> > > > Essentially, it's an "infrastructure wish list", and you folks are
> > > > admirably positioned to tell me what's missing from the list.
> > > >
> > > >
> >
> >
> >
> >    (05)