hi, (01)
i was thinking about it for the general question: how do we make
impact/change? how big changes happened? (02)
i think at the end it boils down to a personal(?) voice, a manifesto, an
article or a paper (in scientific or non-scientific sense), a web page
(or whole website), a statement of any sort (and then action to support
it) - i see no shortcuts here (or technomagic) - synthesis and writing
must happen but what can be done is to make easier to create a statement
that uses and points to online resources (using links, transclusions,
allowing for comments, automatically gathering backlinks using
TpVortex?, (purple)linking to archived emails and other resources, being
aggregator friendly etc.)? (03)
and then there is great UI challenge: how to make it easy for readers of
an online statement to follow their interest to the level they want to
'research'? (04)
Wiki is good but i do not see it as a way to create such statements more
like way to provide supporting materials, distill and gather many
resources in one place. Outlining is similar - it is a tool but does not
seem a crucial one to me. I can always write it in LaTeX, Word or
directly in HTML but it is not truly interactive then - i think we need
more like a tool with a blog-like UI for writing such statements (or
something even easier ...) (05)
best, (06)
alek (07)
Eric Armstrong wrote: (08)
> We almost got there a long time ago, when the
> subject of Wiki pages came up. It was a narrow
> miss. The important concept was within reach,
> but we missed it. (Some may have seen the
> possibilities. But I never penetrated to their
> potential. I only saw how they were being put to
> use at the time. So I say "we" because anyone who
> saw this before really shoulda made sure I saw it,
> too!)
>
> Wiki pages give us tremendous potential for
> shared editing. But as I begin to imagine the
> potential of server-directives that process typed
> links, the next question that arises is:
> how does someone other than the owner of the
> server change a page?
>
> Suppose, for example, that I create a server
> system that lets me create a representation of
> the design conversation, as I plan to do. To
> the extent it works, I will be the bottleneck
> in the pipeline. If someone else authors a
> different proposal, they'll have to send it to
> me to add to the server. If they send a comment
> in email, it won't appear in the server's
> rendition until I get around ot adding it.
>
> That's where Wiki pages come in. With a few
> primitives like typed links and client-side
> outlining routines, it's possible to create a
> "lab" where people can try different dialogue-
> management strategies.
>
> The typed link primitives make it possible to
> transclude material, display a link to it, or
> provide a provisionally-displayed link, as needed
> --for example, for a backpointers, which might only
> be needed in an authoring context, so they would
> only appear when editing the page.
>
> Outlining primitives could conceivably be
> included automatically in the headers, so that
> the displayed page had either an outline-control
> frame on the side, or had outlining controls built
> into the page--conceivably something that would
> eventually be under the viewer's control.
>
> With those primitives, different dialogue managing
> ideas could be created. Pages would be constructed
> manually at first. Later, we might think of ways
> to integrate them more thoroughly with the email
> archive.
>
> Note:
> An additional requirement for the server: loop
> detection, so a transclusion of material that has
> already been transcluded turns into a local link.
>
> Some of the dialogue-management ideas that spring to
> mind include the Question/Alternative structure of IBIS,
> a general purpose Proposal/Alternative structure such as
> the one mentioned previously, and the possibility of
> specialized structure, such as one for design problems
> with sub-structures for problem identification, design
> proposals, and implementation proposals--all of which
> necessarily link to one another.
>
> In the ideal world, it will eventually become possible to
> create a schema that constrains structures so that have
> the specified kinds of relationships. That will make it
> possible to ensure that a dialogue stays true to its
> precepts. But that's a solution for a problem that becomes
> more pronounced when the system graduates to the real
> world.
>
> In the "real world" scenario, you need to help new folks
> learn the structure and keep them from wrecking it. But in
> a lab setting, the flexibility to play "fast and loose"
> with the structure will make it possible for the standards
> to evolve, so that the eventual schema codifies best
> practice, rather than constraining it.
>
> (09)
--
The best way to predict the future is to invent it - Alan Kay (010)
--
This message is archived at: (011)
http://collab.blueoxen.net/forums/cgi-bin/mesg.cgi?a=yak&i=43CAA9B9.1080708@cs.indiana.edu (012)
|