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

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


Eric.    (01)

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.    (02)

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.    (03)

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.    (04)

Henry    (05)




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.
> > >
> > >
> 
> 
> 
>     (06)