RE: [ba-ohs-talk] Wiki experiences?
-----Original Message-----
From: cdent@burningchrome.com
* poor editing interfaces (01)
I was considering the other day that a well built web browser would
include a more full featured text editor for <textarea> form
elements. I do not write complicated wiki pages because it is a
pain in the butt. I could, I suppose, edit somewhere else and cut
and paste or something similar but that raises the barriers.
Are their editors out there which will spawn an external editor or
embed one? I think that would change the shape of collaboration on
the web. I use email as my primary tool for collaboration because I
have greater access to my personal toolset there. (02)
There are indeed editors that can substitute for the browser textarea
editors, but there aren't very many as yet.
Twiki has some discussion and some examples at
http://twiki.org/cgi-bin/view/Codev/AppletBasedEditor
A Google search turned up only a few. There are some sophisticated tools for
web management which can edit the web directly, such as
http://www.ektron.com/ .
Another approach is the one taken by Dave Winer which he calls Manila based
on Frontier and Radio Userland http://radio.userland.com/ . This is based
around XML RPC, SOAP, an outlining editor with a scripting language, and RSS
feeds. Manila http://manila.userland.com/ is a commercial server based
product which is part of Frontier http://frontier.userland.com/ . He hosts
Manila sites at http://www.manilasites.com/ but they are no longer accepting
new sites.
What I would really like to see is an editor that turns out either XHTML or
XML from a relatively WYSIWYG interface that supported just the minimum that
HTML will support and does it cleanly. Netscape Composer is surprisingly
easy to handle for small pages, but its code is atrocious (all the hacks
that predate XHTML). With this plus the ability of the editor to generate
purple numbers and maintain them under edits, we would have a start at true
electronic journaling. If we could tie this to hacks on the mailing list
server, we might be able to do the whole thing with email, as you suggest. (03)
* granular addressibility is difficult (04)
Constantly changing pages means that persistent references have to be
associated with versions. That means, as mentioned elsewhere, you
can't just throw some purple number code into the presentation
engine and have them work well.
The straight text form of Wiki does make reference below the page level
difficult. There are hacks to support addressability at the heading level
and some Wikis automatically render a table of contents based on page
headers. (05)
I had a conversation with some friends once, probably last year, where
we discussed that the only thing that _really_ mattered that came out
of internetworked computers was email. This is certainly over stating
the case but I think it is true to say that email is _the_ killer app,
so much so that we've forgotten that it is an application at all. (06)
Unfortunate but true. Given that email (or at least the paradigm of local
stores of messages supporting immediate replies) is the collaboration tool
that has been accepted, it would make sense to capitalize on that when
constructing an OHS that we want to gain wide acceptance. It is clear that
if we tackled the problem of interfacing email to history and improved the
abilities needed at the email client and editor that much could be done, but
that is a real leap. The main thing that Wiki and Weblogs have going for
them is that all you need is a browser. The Radio Userland approach actually
puts a mini web server on you desktop and allows you to turn a weblog into
an RSS news type feed.
Somewhere in all of this is a way that can be made to do the job.
I am going to experiment with a combination of email, web pages, Twiki, and
links to documents by version for collaborating on the development of
technical documents. I'll report when I have any results. I expect that the
entire effort will be ignored, but I am having fun trying. (07)
Thanks, (08)
Garold (Gary) L. Johnson (09)