| |
 |
Tuesday, April 23, 2002 |
|
The practical benefits of literary forms
As blogspace evolves all around us, new forms of writing appear. I mean forms in a technical sense -- literary forms, or patterns of writing. One of the most interesting of these is David McCusker's. Recently he explained why and how he writes in stanzas, with five fixed-length lines per stanza. "This obviously isn't poetry," writes David. "So you might wonder, why do I do it?" His answers resonated very much with my own sense of writing as an art which, like software, is creative yet mechanical.
The stanzas of Homeric verse were engineered to meet certain requirements. They helped people recite, absorb, and remember the stories that defined their culture. David says that his style:
- makes the writing go faster
- enforces brevity
- delivers "consistent quality of service"
Wondering what else has been said about the practical benefits of literary forms, I found a page about Haiku as a poetic form adapted to the present world. Here are some of the reasons:
- Haiku is quickly remembered. The fast [short-term] memory contains only 5 to 7 units information chunks.
- Haiku can also be quickly forgotten. It does not clutter mind because it is made of but one information block. It will be more quickly erased if we don't decide to remember it.
- As it is quickly written and published, it allows its authors to be quickly visible. Everybody writes to be read and appreciated.
Serge Tomé
Though I don't write stanzas or haikus, I do follow certain formal rules in this space. Titles and lead paragraphs play an important role. Recently, several folks wrote with suggestions to improve Paul Holbrook's RSS truncation rule, which I have adopted here. The problem to be solved is that an item might not have an appropriate lead paragraph, in which case some other algorithm perhaps should be used to make the RSS description.
In the end, though, I decided that writing a self-sufficient lead paragraph is a good rule for me. If I need to stretch the definition of a paragraph in some cases, I can, by switching to Source view and moving the </P> tag so that it captures what I need. But this rarely happens.
We (that is, we technical types) focus intensely on form when we write software. Poets aside, who else but programmers could seriously debate the merits of Python's significant whitespace? So it has always seemed odd to me that these same people (with some notable exceptions, including McCusker and the Wiki tribe) pay scant attention to form when writing email or other kinds of purposeful communication. Why not? The reasons are the same.
3:54:07 PM 
|
|
|
Thursday, April 18, 2002 |
|
Jeffrey P Shell, Zope's lizard brain, and loosely-coupled messaging
I had a nice response to a recent column on Zope from Jeffrey P Shell, a longtime Zopista and former Digital Creations guy who has decamped to the skiiing life in Utah. Jeffrey wrote one of the first BYTE columns on Python, longer ago than the web seems to remember. Anyway, in my column I talked about scripting Zope from the outside, using the RESTian approach of reverse-engineering its HTML management forms and calling them as URLs. I knew that XML-RPC was another way to do this. Jeffrey pointed out a third, little-known approach that taps into Zope's "lizard brain."
Did you know that Zope has always had a simple RPC mechanism, predating XML-RPC, and even predating Zope itself? There was a little piece of Bobo, which is now ZPublisher, called 'bci' for 'Bobo Call Interface'. I'm almost ashamed that more wasn't done to promote BCI, or turn it into an actual RPC mechanism (it doesn't marshal return data), because XML-RPC, while simple, is just a little too simple (no concept of None/NIL? No concept of authentication except as part of the API?). And SOAP.. *sigh*.
Anyways, ZPublisher.Client (which can be used without any other Zope modules, so you could install a copy of it into a common place) is another wy to do that Perl script that you wrote, while maintaining a cleaner syntax than writing a long URL. It basically generates the same URL (with all of the correct Zope marshalling, although I don't know if it knows of the more recent marshalling options) and does the same job. from ZPublisher.Client import Object myCatalog = Object (
http://host:port/repository/myCatalog)
myCatalog.manage_catalogFoundItems(
obj_metatype=['Image', 'File'],
obj_permission="Access contents information",
search_sub=1, btn_submit="Find and Catalog"
You can see the similarities to XML-RPC, which you might even be able to use in this situation, but there are some niceties about BCI. When constructing a ZPublisher.Client.Object or ZPublisher.Client.Function method, you can specify a username and password and you will be authenticated over Basic Auth. You can specify which HTTP method to use (GET/POST/PUT). You can upload files just by passing a Python file object (basically anything with a 'read()' method). You can also catch remote exceptions. While I recognize that XML-RPC has the concept of 'fault', for more intimate Zope scripting, sometimes more knowledge of the cause of the fault is required. This is the only real marshalled data that ZPublisher.Client (BCI) sends back.
Cool! By the way, Jeffrey is trying out a blog. I hope he sticks with it. He's a wonderfully thoughtful and articulate writer, and a really clever guy. l bet he'll have OmiOutliner hooked in before long.
Looking into blogspace with fresh eyes, Jeffrey wondered "Why write when there's so much else to do? Who's reading?"
These are great questions. I of course get paid for my writing, though not for what I write here. But what about most folks? Why write? Who will read? Lots of people have lots of different reasons. For me, it's mainly about optimizing information flow and managing attention. In a recent column I explored the idea of storytelling as a tool for project coordination. That's closely related to what Dave Winer means by "narrating work" (and is demonstrating in his outline). We do this narration all the time in interpersonal email. Something interesting happens when we instead write messages addressed to spaces.
Defining why it's interesting is hard to do. But I'm closing in on it. Today I realized the following analogy may hold: loosely-coupled message-driven architecture, the mantra of the web services movement, is precisely what blogspace is becoming for the realm of human communication. When we adopt this style of communication, we give up some of the benefits of tight coupling: message acknowledgement, tight feedback loops. But we gain (maybe) the ability to scale beyond what is possible when tightly-coupled messaging (email, discussion groups) is the only available mode. This doesn't mean there's no benefit to tightly-coupled interpersonal messaging. It only suggests that the loosely-coupled mode is also important.
3:39:10 PM
|
|
|
Tuesday, March 19, 2002 |
|
Bill Sietz on sending links-and-blurbs vs. sending whole items
Bill Seitz writes:
But I wonder whether it makes more sense to transport the full content, so that the reader can do some background BlogWeb processing, even if it only displays a truncated description. For instance, the reader could assign a blogbit to a reader-defined category based on matching keywords anywhere in the content. [WebSeitzWiki]
Yes, that's the flip side of the coin. If you knew that readers could reliably trim inbound items, you might want to make sure everything gets sent. The answer here partly depends on how soon you think we'll be living in a pervasive data cloud that makes replication less necessary than it historically has been. If you knew you could always get to the content through its link, and process it however you like, you'd care less about having it local.
Short-term (i.e. next decade) there will be many reasons to replicate. So here's another variation on the theme. Use your RSS writer's truncator not to omit outbound content, but only to suggest a boundary between the body (sent as RSS description) and the full item (sent as RSS enclosure). A reader could use, or ignore, this rendering hint.
We desperately need something like this in email. The email UI is sadly non-scannable: titles (often useless), and no blurbs. The reason email can't do what we're here imagining that blogs can do: it doesn't produce canonically URL-addressable content. Blogging produces such URLs as a matter of course. That's one reason it may become the laboratory in which email gets reinvented.
11:15:59 AM
|
|
|
Friday, March 15, 2002 |
|
Messages to spaces is publish/subscribe
Rick@Leaders.net:
Posting Messages into Spaces [via Jon]: This is a new way of thinking about communication. It is akin to posting to listservs where your message goes out to a group of people. Yet, blogs like this and "messages into spaces" are more akin to speaking to nobody in particular yet at the same time to those who are specifically interested in this subject either now... or at some point in the future. [Rick@Leaders.net: All Told]
Exactly. It's just like publish/subscribe, a technical architecture for many-to-many communication.
6:49:58 PM
|
|
|
Friday, March 08, 2002 |
|
We demand privacy! Yeah, right.
"It's not a good sign for secure e-mail demand, despite consumers' concern for online privacy."
Eighteen employees were laid off as a result of Network Associate's disbanding the PGP unit.
Network Associates drops PGP encryption. ZDNet Mar 8 2002 5:52PM ET [Moreover - moreover...]
I've used a client digital certificate for 5 years, and I sign all my email messages. Over the years, I think I've exchanged encrypted messages with about a half-dozen people. And three of those were cryptographers.
8:49:02 PM
|
|
|
Wednesday, March 06, 2002 |
|
Are we ready to address messages to spaces?
Are we ready to take the next step, continued
My environment currently consists of a large group (say, 50 people) made of several interdependent teams (sub-projects). Some people belong to more than one team.
A lot of communication takes place via email that reaches a few people from this team and a few people from that team, in order to accomplish some task. So these are little sub-teams that spring up around a task and then disband.
A significant problem is getting the right people to know about new issues that the sub-teams form around. Those people may want to be a part of the sub-team, or simply track their progress.
With a tool like Radio, those sub-teams may be able to form around an issue, and communicate with each other, out of their own self-interest, just as with email. (Or enough like email that the members do not feel an extra burden just to reach people who may or may not be interested in their issue.)
Others can "listen in" on the conversation via Radio in ways that are simply not enabled by email. Almost everyone in the larger group would soon benefit from this ability to see into the day-to-day conversations of sub-teams they otherwise would not be aware of until much later, sometimes too late, or wastefully late.
I thin this transparency offered by Radio can help avoid the sub-teams from losing focus and thinking too much about people outside their focus. [Patrick Logan's Radio Weblog]
Absolutely. And you're spot on when you say "enough like email that the members do not feel an extra burden." This was the opportunity I thought I saw, way back when, when I noticed that:
- email was ubiquitous
- email clients were closely coupled to news clients
- news was a groupthink medium
Once I set up the private news server that unlocked the latent power of the already-universally-deployed news client, which shared the same message composer as the mail client that was in constant heavy use, I thought I was all set. There was essentially no new software to deploy, or to learn.
Why didn't a lot more people catch on to this? Why, even in my own environment which was, like yours, made of overlapping subgroups, didn't it have the effect I thought it should have?
I say again: it wasn't primarily about the software. It was about the willingness of people to work transparently, for their own benefit and for the common good. And about the ability of people to think in terms of messages addressed to spaces, rather than messages addressed to people. This is a deep anthropological issue. As a species, we are now being invited to communicate in ways more abstract and indirect than tens of thousands of years of cultural history have conditioned us for. I know we can adapt, and will. The $64,000 question for me is: how soon?
9:38:34 AM
|
|
|
Monday, February 04, 2002 |
© Copyright 2002 Jon Udell.
|
|
