in reference to: http://software-carpentry.codesourcery.com...pware/report.html#3

One pressing need is faster and continuous access to new ideas and critical feedback.

A comment via email from Wolfgang Appelt:

> I have read with great interest your excellent report
> "Internet Groupware for Scientific Collaboration". May
> I draw your attention to the BSCW System developed
> by GMD (http://bscw.gmd.de) which was specifically
> developed for scientific collaboration over the Internet.

Because the report was already much longer than planned, there were a number of groupware systems that I didn't mention. BSCW is one of them. It is noteworthy, though: a free service that supports discussion and shared pools of documents through a Web interface.

- Jon

A comment, via email, from Evan Williams, president of Pyra, maker of Blogger. I've interspersed some comments.

> Excellent report, Jon.
>
> About the weblog/Blogger point, however, I must offer a
> clarification, as well as a refutation.
>
> Disclaimer: I'm the president of Pyra (makers of Blogger).
>
> First, Blogger is not really a portal. It's a publishing
> tool. It links to 3,300 of the 10,000 or so (active) sites
> that are published with Blogger, so it has a portal-like
> aspect. But, primarily, it's a web application that
> automates posting to weblogs -- as well as "what's new"
> pages, journals, or any other page with a format of
> (usually) short, chronologically arranged posts.
>
> Speaking of which, this *format* is really what
> weblogging, or blogging, is about. Despite the prevalent
> definition of
> weblogs as "links" pages, if one actually looks around at
> what's being published on blogs, they will find not only
> links and commentary, but news, diaries, photos, poetry,
> mini-essays, project updates, even fiction. What's
> consistent -- and unique to the format -- is a simple,
> approachable, and -- with tools such as Blogger, GrokSoup,
> Manila, and Pitas -- extremely convenient way to publish
> information to one's own web space at the "chunk" or
> paragraph level, versus the page, which requires much more
> complexity and overhead.
>
> This low-friction method to getting thoughts onto the web
> has opened the floodgates to all kinds of publishing and
> communication that never would have happened before. And
> it's the reason that weblogs (in the way I'm defining
> them) are not, I believe, a passing fad. This format
> simply makes sense for certain types of content. Granted,
> a lot of what is suddenly being published is mediocre at
> best. But this is irrelevant. Actually, it's good! As
> with any medium, there's not likely to be great stuff
> without a lot of bad.
>
> I'm surprised to see you quote an anti-weblog argument
> that is so obviously illogical. To imply that those who
> use weblogs for "self-gratification and self-absorption"
> reduce the ability of others to use them for "reaching
> out and connecting with the world" makes no more sense
> than saying that all the amateur pages at GeoCities spoil
> the potential of the web. Or, for that matter, that dime
> store pulp novels somehow take away from what's possible
> with books.

A good point. What I meant is that blogging is as susceptible to abuse as any other mechanism allowing public graffiti, such as Usenet.

What I think may be a passing fad is the sort of communication one sees when weblogs are trying to achieve global scope. What I believe, and hope, is not a passing fad is the more focused kinds of communication that weblogs can enable within like-minded interest groups, and among such groups.
 
> The difference that saves blogs from the fate of Usenet is
> that, well, this is the web, if you don't like something,
> fortunately, you don't have to look at it.

And I would argue the same holds for NNTP technology, as distinct from the Usenet. What has poisoned our perception of the Usenet is its global manifestation. But NNTP technology, like weblogging, can and should be deployed at a variety of scopes. In more private scopes, both technologies can produce dramatically different results than we see when the scope is public and global.
 
> Lastly, I think you're overlooking one of the most
> compelling uses of weblogs -- one that is directly
> applicable to your main topic: collaboration. Private,
> collaborative weblogs, where a small group can post news,
> links, announcements, status updates, etc about a project,
> event, or other topic of mutual interest are extremely
> useful and simple tools for collaboration. They're not
> perfect for everything, but having a single, non-threaded,
> easy-to-update page as the focal point for communication
> among a small group has unique advantages over the other
> tools you mentioned as alternatives to email for group
> discussion. Many small companies and project teams are
> using Blogger (and probably other tools) for this purpose
> currently, and it's an idea that's catching on. We
> installed an enterprise version of Blogger inside Cisco
> for this purpose just yesterday.

If I failed to make this point specifically w/respect to Blogger, than I apologize. This is exactly how I recommend people should use Blogger, or Manila, or Wiki, or NNTP, or any group messaging technology.
 
> Blogs have more potential than most people think. You
> should try 'em out. :)

For years, I've been deeply involved in an ongoing conversation with a group of like-minded technologists. The medium happens to be NNTP/web discussion forums. But what happens in those forums is, to my way of thinking, the same kind of communication that weblogs enable. NNTP is, though rarely acknowledged as such, another way to "publish information to one's own web space at the "chunk" or paragraph level."

in reference to: http://software-carpentry.codesourcery.com...are/report.html#220

Hi, Jon. Thanks for the report -- it's a great
summary of many of the various issues surrounding
collaboration. It's a pretty huge space.

I was surprised that you didn't mention Crit, as
it provides exactly the kind of annotation
facility which you have clearly worked hard to
construct for your document. In particular Crit's
strength is its ability to permit annotation on
any Web document at all, so i think it deserves
mention. I can see that although what you've done
required some special processing work on your
report, it has paid off in providing a
particularly nice interface -- the subtle
paragraph numbers (though they don't show whether
any comments are attached or not) and the really
nice view of the entire discussion forum.

Regarding the granularity of the annotations,
the earliest incarnation of Crit (before it had
that name) actually did attach small buttons at
the end of each sentence, with different-coloured
buttons if annotations were present. Later demand
for finer control led to the current system which
lets you attach a comment to any specific sequence
of words. My future plans for Crit definitely
include a facility for seeing an overview of the
comments on a page, as that's clearly a current
weakness.

Anyway, if you feel like saying something about
Crit in your report, that would be pretty cool.

-- ?!ng

in reference to: http://software-carpentry.codesourcery.com...ware/report.html#56

In response to your dramatic and effective
illustration of the "Re: syndrome", as you
call it, i'd like to suggest an idea for
threading messages that popped into my head
way back in late 1998. It still awaits an
implementation, and sadly i haven't had time
to write one yet though i've been dying to
try it.

The idea is best illustrated by the mock-up
page that i put together then, using messages
taken from a real e-mail discussion list.
Have a look:

    http://www.lfw.org/ping/criticons/

Content is threaded at the paragraph level
rather than the message level, since paragraphs
are the chunks in which people more commonly
organize their thoughts. Subject lines are
ignored (as i think it may be a lost cause to
try to convince people to always rewrite more
meaningful subjects) -- instead, the topic
sentences of the paragraph are used.

And -- almost magically -- the index of the
content reads like a neatly summarized
conversation outlining all the positions in
the discussion!

I can't wait to build this tool.


-- ?!ng

Unfortunately crit.org is temporarily down.

You can get the source code for CritLink at

    http://www.lfw.org/ping/crit-0.9.2.tar.gz

or play with a running server at

    http://www.lfw.org:8080/

You can use the server to make annotations on any web
document, including Jon's paper, for example:

    http://www.lfw.org:8080/http://software-ca...oupware/report.html


-- ?!ng

Ka-Ping Yee wrote:

> I was surprised that you didn't mention Crit, as
> it provides exactly the kind of annotation
> facility which you have clearly worked hard to
> construct for your document. In particular Crit's
> strength is its ability to permit annotation on
> any Web document at all, so i think it deserves
> mention.

You're right, that was an unfortunate omission -- which several people have already pointed out here.

I guess the real message, though, is that given a commenting mechanism -- of whatever flavor -- such omissions can be rectified.

As you point out elsewhere, a commenting system ought to be able to indicate the existence of comments, as the one I'm using here does not.

This mechanism has, however, been extremely helpful as a way to collect, in one place, a bunch of things that would want to get woven into a next version of the report.

> Unfortunately crit.org is temporarily down.

I've been wondering about that...

> a running server at http://www.lfw.org:8080/
> You can use the server to make annotations on any web
> document

Excellent!

> I can see that although what you've done
> required some special processing work on your
> report, it has paid off in providing a
> particularly nice interface -- the subtle
> paragraph numbers (though they don't show whether
> any comments are attached or not)

Yes, that part is clearly suboptimal, good point.

In CritLink, how often have you run into parsing problems when handed random web pages? What kind of parser are you using?

> i think it may be a lost cause to
> try to convince people to always rewrite more
> meaningful subjects

Perhaps. Doesn't it seem odd, though, that programmers -- who instinctively try to structure their programs, and assign meaningful names to classes, functions, and variables, would not want to carry the same discipline into the messaging realm?

- Jon

Ka-Ping Yee wrote:

> My future plans for Crit definitely
> include a facility for seeing an overview of the
> comments on a page, as that's clearly a current
> weakness.

I see that you do, however, offer a Wiki-style "recent changes" page:

http://www.lfw.org:8080/recent.cgi

It doesn't look too hard to correlate these fragments to the docs they relate to.

- Jon

Good news: crit.org is back up.

> I guess the real message, though, is that given a
> commenting mechanism -- of whatever flavor -- such
> omissions can be rectified.

True. Are you continuing to revise the original document?
Its title is numbered "Draft #3", so i got the impression
it was a work in progress.

> This mechanism has, however, been extremely helpful
> as a way to collect, in one place, a bunch of things
> that would want to get woven into a next version of
> the report.

Right. The way you've integrated your specially-processed
document with the QuickTopic service is very clever.

> In CritLink, how often have you run into parsing
> problems when handed random web pages? What kind
> of parser are you using?

The most common parsing problem arises from abuse of
HTML comments. (Actually, i think this is the only
kind of parsing problem i've come across.) Unfortunately,
invalid comments like <!------------------> are all
too frequently seen.

The parser is homegrown (actually it doesn't really qualify
as a parser -- it's merely a lexer, as it only outputs a
stream of tokens), and most of the effort in writing it was
indeed expended in trying to come up with acceptable
heuristics for handling bad comments. But it's still
quite small.

> Perhaps. Doesn't it seem odd, though, that
> programmers -- who instinctively try to
> structure their programs, and assign meaningful
> names to classes, functions, and variables, would
> not want to carry the same discipline into the
> messaging realm?

Ah... but programmers are lazy! Like all humans, they
will take the easy way out when one is available. Some
have argued that programmers are among the laziest,
since we're always working so hard to get computers to
do our work for us. :)

Yeah, i bet a group of programmers might have slightly
better mail-composing habits, but on the whole i think
it's hard to get people to change their ways. (When
writing programs, there is a compiler to enforce certain
kinds of clarity -- with e-mail, there is no such
enforcement.)

As a result of common practice, the subject line has grown
to have a purpose of its own; perhaps an unfortunate one,
but it has one: the subject line has become the *thread*
label, not the message label. If indexing tools treat the
Subject line as a thread title rather than a message title,
and look in the content for a better message overview, i
think they'll end up with better results.


-- ?!ng

Jon Udell wrote,

> Perhaps. Doesn't it seem odd, though, that programmers --
> who instinctively try to structure their programs, and
> assign meaningful names to classes, functions, and
> variables, would not want to carry the same discipline
> into the messaging realm?

Not so odd, perhaps. For one thing most of the best
programmers I know are subscribed to dozens of e-mail lists,
receive scores or hundreds of e-mail messages a day, and
send dozens more. The time devoted to each of these is
necessarily small. (That's why tools are important!)

Source code is something that lives on, and therefore
programmers naturally feel that it warrants careful
attention. Messaging, groupware tools like this one
notwithstanding, is perceived as something transient.
Programmers format their code more carefully than their
mail headers for the same reason people don't observe the
more formal rules of written language when they're speaking.
If you want to change this, the first task is to
convince programmers that their messages carry as much
information as their code, and therefore have as much
long-term value.

Integrating documents with services

Ka-Ping Yee wrote:

> The way you've integrated your specially-processed
> document with the QuickTopic service is very clever.

Actually, I've done the same kind of thing using NNTP as the discussion service, and could do it as well with anything offering a reasonable Internet API.

When there's no guesswork or special effort involved in parsing the document, it's rather trivial to integrate the document with any kind of service.

It's not the processing of the document that's special, in my view, but the *ability to process* the document. So what's special, in this case, is that I wrote the document in well-formed XHTML, making it trivial to parse.

This is one reason why I think it's a priority to be able to use writing tools that think natively in terms of well-formed (and possibly valid) content. Then, a whole range of ways to integrate docs with services -- revision management, collaboration, etc. -- become easily available.

- Jon

Alex Samuel wrote:

> Most of the best
> programmers I know are subscribed to dozens of e-mail
> lists, receive scores or hundreds of e-mail messages a
> day, and send dozens more. The time devoted to each of
> these is necessarily small.

If the digests of those mailing lists were usefully
scannable, how much time might be saved? More, I'd
argue, than the time expended to label those messages
descriptively.

In this vein, I've been thinking about something Ka-Ping Yee wrote. It was in email, but I don't think he'll mind me quoting it here:

> Conversely (also a bit of a surprise) i've discovered
> that people perceive a win when they use criticons

by "criticons" he means "(a convention of little
typographic symbols: [+] [-] [?] [#])" used to
indicate the type of a message (confirmation, refutation,
question, etc.)

> After i
> introduced the convention, people liked it and picked
> it up pretty easily and understood what it meant.

In other words, people don't naturally tend to develop a useful new habits. But when shown one, they may pick it up -- if it is not too different from existing practice, and not too time-consuming. I think descriptive titling falls into this category, though very likely I'm wrong because few people seem to agree that it does :-)

All this notwithstanding, I also think that the role of a "list guide" as mentioned in the report, coupled with a way of connecting that guide's summaries to the RSS network (or something very like it) is going to be an increasingly necessary way for people to follow what happens on lists. Certainly a key service provided by a list guide is descriptive titling and blurbing.


- Jon

Edited by author 08-08-2000 10:56 PM
**Jon**, I agree with your & Ka-Ping Yee's point about usage conventions, and have 2 more supporting examples:

1. Instead of using mid-sentence links like http://www.tbtf.com, Keith Dawson (of TBTF) uses references like [1], and includes the link at the bottom of the message. I think he first introduced this in his newsletter.

2. Julianne Chatelain introduced a Quick Topic convention in its early beta days: when replying to a specific person's message, quote their name with asterisks so it stands out. (She said "In the 'zine world we call this 'facilitating ego scanning.'")

These conventions caught on readily in various circles.

[1] http://www.tbtf.com

**Steve** in your #34: "Instead of using mid-sentence links like http://www.tbtf.com, Keith Dawson (of TBTF) uses references like [1], and includes the link at the bottom of the message. I think he first introduced this in his newsletter."

FWIW :-) I find this "un-webby." Scholarly yes, but if I want immediate gratification [XYZZY] to find what [1] actually means, I have to interrupt my train of thought, scroll down to find [1] and then go thru it. Don't get me wrong I like the notion of a reference/bibliography list just fine (having compiled too many of 'em for too many theses/publications) but it's a bit too heavyweight for me these daze. At _least,_ hyperize the [1] for Type A mouse-holders like me.

Which then leads me to the question of what sort of hyperlink...

Part of the thought behind this type of convention might be the common webmaster issue where if you provide an in-text link, the reader may just click away and never see the rest of the site's deathless prose (and banner-ads). That's why I urge others to consider doing what I practice myself: providing in-line external linx that open in another TARGET="foo" window. If the other window always has the same name, then the alternate info can be perused and then you switch windows back, presto, more deathless prose. That's the way that Steve Yost does it here in QT. More confusing to the newbie perhaps, but ultimately more efficient for the aficionado and eyeball-retentive imho.

MSIE allows a link to be opened in a new window (right-click instead of left-click) but that takes me a few silly milliseconds longer every time, which grates (instant gratification, _q.v._ above)... so I find myself wondering why the HECK search engines like AltaVista persist in offering their hundreds of hits in same- rather than in new-window mode.

[XYZZY] ==> As someone said apropos of the "Is it legal to link into someone else's website's content?" debate: "Cicking on links is what we DO!"

Regarding "criticons" (the use of symbols like [+], [?], and so on to indicate message type/content): if the world was using rich mail content, would we attach real icons (stop signs, smily faces, etc.) to messages, just as we used to put colored tabs on folders and documents, or would most of us not have the necessary self-discipline? What if mailers (like Eudora) *always* attached icons to messages, but allowed us to choose an alternative? (I have visions of corporate logos attached to email messages, like the logos that now appear in the Internet Explorer "Favorites" list for some sites...)

Greg Wilson wrote:

>Regarding "criticons" (the use of symbols like [+], [?],
>and so on to indicate message type/content): if the world
>was using rich mail content, would we attach real icons
>(stop signs, smily faces, etc.) to messages, just as we
>used to put colored tabs on folders and documents, or would
>most of us not have the necessary self-discipline?

I'd like to think that it often wouldn't require much self-discipline, because the messaging tool simply invites and encourages us to specify semantic metadata conveying things like:

- I am making a request for an appointment on a date.

- I am promising to perform a task for person x, as part of project y, to be done by date z, and will require resource r.

- I am agreeing with your idea.

In other words, it is aware of various types of common "speech acts." I borrow this term from the realms of philosophy of language, and literary criticism. To tell the truth, I have never been able to figure out exactly what people mean by speech act theory. Very possibly it is just academic mumbo-jumbo. But what I take from the little I've read is the idea that speech acts are basic types of communications (requests, promises, commands, etc.) uttered in hopes of influencing listeners in specific ways.

To me there would seem to be great value in having our communication tools know about, and make explicit, a basic repertoire of speech acts.

Criticons are an example of this idea. I think in the end it will turn out that so much of our routine communication is categorizable in this way, that it makes sense to look for explicit tool support to aid in the expression of speech acts, rather than just relying on convention.

With explicit support comes dependable structure that you can actually do something with -- thus, when your message is a Request for an Appointment on a Date, my software can consult my calendar and respond appropriately, or at least automatically formulate a proposed response for me to approve or modify.

- Jon