All posts made the week commencing Sunday 12 Jan., 2003:

The Optical Telegraph | "...a pivoting wooden panel, five feet tall, pained black on one side and white on the other. By flipping it from one colour to the other, Chappe could transmit the numbers on the synchronized clocks. A telescope could help to see the wooden panel from a great distance. On March 2, 1791 [Claude Chappe] sent a message 10 miles [16km] away. In about 4 minutes they transmitted the phrase: 'If you succeed, you will bask in glory'" [source]. This was the tachygraphe (rapid writer), then later: the telegraph, or far writer.

Chappe moved to a secure semaphore system (the Chappe code assigns numbers to flag positions; the meaning of these numbers is known only to those in charge). Napoleon sees the benefit and a 15 station line from Paris to Lille is built. The network grows. This history of the Chappe Telegraph System has some wonderful photographs of the semaphore towers, and points to a remarkable map of the system at its peak -- 556 stations over 4800km [source], with similar networks in Sweden, Denmark, England and many other countries. But it was not to last. By that time electronic telegraph was in the ascendent, and would grow to supplant the European semaphore networks.

I've run across a few simply remarkable resources on the optical telegraph and communication:

At the same time as Chappe, Edelcrantz was working on a similar telegraph device in Sweden, and something he wrote resonates with me: "It often happens, with regard to new inventions, that one part of the general public finds them useless and another part considers them to be impossible. When it becomes clear that the possibility and the usefulness can no longer be denied, most agree that the whole thing was fairly easy to discover and that they knew was significant" [Treatise on Telegraphs (1796)].

But this doesn't affect me as much as the fact that we're solving the same problems again and again, and I'm sure we should be looking more to history. Ever heard of the Western Union Telegraph clock?

To finish, I have a question. I remember reading about another potential communications network, also originating in France. It was based on sound, a way of simplifying language and encoding it into a five-tone system, such that it could be communicated across a battlefield using specially tuned cannons. This same language was also popular across Europe in other forms: in more detailed code to speak using trumpets, and as a stage act, showing off this method. It was championed by a single man, and never achieved success in the establishment. Do you know what it was called, or who the man was?

"I waited. My host continued to speak in near paragraphs": The McKee Recursion at Ftrain. Wonderful.

Ubiquitous computing is "roughly the opposite of virtual reality. Where virtual reality puts people inside a computer-generated world, ubiquitous computing forces the computer to live out here in the world with people. Virtual reality is primarily a horse power problem; ubiquitous computing is a very difficult integration of human factors, computer science, engineering, and social sciences". On this site are so of the most intelligent and ahead-of-their-time essays I've read. Ubicomp is a manifesto for what we should be building right now. And these guys have thought of it all already. Picking out two in particular:

The Coming Age of Calm Technology (1996) gives the wonderful example of the Dangling String that makes invisible ethernet traffic visible and understandable.

Building Invisible Interfaces (1994) powers its way through the nature of interfaces and the problems faced by ubicomp (where else have you seen a calculation of the maximum bandwidth available based on the surface area of the Earth?). And the ideas! In an energy scare world: "pushback to user what is hard or easy. color every button according to power-cost of pressing it" (in the real world!).

The Xeroc PARC Principles divide tasks into two sets (copying is easy, creating is hard. There are more) based on the Nature of Human Beings: "What are human being like? They are impatient, have short memories, are slow, awkward, have limited logical abilities, get easily confused, like pictures better than words, are control freaks, vary considerably in their habits and preferences, lazy, make lots of mistakes even on easy tasks, are overly sensitive, can be easily made to feel guilty and inadequate, have limited imagination". Out of this come the idioms of the modern day graphical user interface.

How to be a Small Town Slut is too lol to quote only bits of, so just go read it all. Tardbag. More filthy dirty funny stuff at Rocketpack [cheers Thayer].

newdocms throws away the hierarchic nature of directory and subdirectory based filesystems, and implements a metadata system. It's pretty far advanced, and implemented for KDE. Check out the open and save dialogues. There's also a taxonomy feature, so searching for animals will find documents you've tagged as being about dogs. Neat.

See also: the Liquid File System, which can be sliced and diced along any file attribute axis. Bookkey implements this liquid system (screenshot) for browser bookmark management. [Links via nooface.]

Some answers to yesterday's question:

  • "Liminal" says Anne Galloway: "Liminal spaces are the spaces in between, thresholds or transitions from one state or space to another. Also boundaries, beginnings, becomings, and similar forms of cultural transition".
  • "Phase shifts" says Stewart Butterfield
  • "Exclamation points, or little bangs" says Anil Dash
  • My favourite, from RavenBlack: "The punctuation, surely?" Of course!

I've been thinking about this in terms of habits. Every so often my critical paths get mucked up. Everything is suddenly inefficient. I do everything wrong (dry in the wrong order after my shower, forget whether to make tea before or after turning the computer on). Why does this happen, after months of running on automatic?

Okay, so habits are good: they free the mind for important things. But habits are not necessarily optimal, so have to be shaken up every so often (like punctuated equilibrium). But what good is that if you do it on your own? Everyone else's habits and the habits of the environment will force you back into your groove.

(The idea being, the environment picks up habits from you. This is how special offers work. Lower the barrier to entry to go to Starbacks, and you go there more. Put it back up, and you still go there because your habit is now to cross the road earlier and so you're nearer it. Someone else, who used to walk in that spot at that time every morning now walks somewhere else because of your new behaviour. When you shift your walking position, you're displacing someone else's habit. Shifting back will be hard.)

In which case, if habit shake-up is a good thing but the environment puts a stop to it, then evolution will find an answer. There's not much to do about physical world's ingrained habits, but it is possible to do something about other people.

Concept: Habit-breaking days spread like a virus through the population, so everyone can shake up at once and settle into a better equilibrium. We're designed to trigger an internal shake-up of all habits if we're exposed to an external event that challenges any one of them (unexpected externalities puncture the stasis). That's why breaking one habit throws you off the groove completely, so it spreads to other people, outward and onward, and so on. I can't prove this, of course.

Question. What do you call the bits between the equilibria in punctuated equilibrium?

Muxway has the best signal noise of any pure links weblog I frequent. (Muxway also has an RSS feed.)

I'm more-or-less extremely intrigued by the Hep Message Server. It's software to abstract away the difference between different message types: In go RSS feeds, email; out come weblog posts, more email, html, or whatever. IMAP, WebDAV, Jabber are all two way.

For example. Send an email, catch it with a standard email filtering recipe, direct it to your weblog. Where Hep is going explains more.

See also: pyblosxom is a (Python) port of the tiny blosxom weblog software. Also, some musings on Hep with pyblosxom. Oh, and on a not-very-related note, Rohit Khare on generalising server to any resource over any protocol.

This is so close to where I've been thinking recently. Weblogs should indeed be thought of as a kind of flow of messages, outwards from the author, and routed and directed as necessary. Standard email filtering would be good for routing. The filesystem is good as a file store. Email is almost perfect as an extensible metadata format. Then it's a matter of putting the IM, email and www editing interfaces on top of that. Oh, and making it simple. Hm.

A couple of pieces of feedback on Lazy Mac OS X: Weblog links sidebar [how to post using the magic of AppleScript]:

  • Greg Restall suggests using the comment field of the Internet Location File to store the weblog post itself, and possibly other pieces of data. A good idea. I'd completely forgotten about using the comments field. It used to be wiped quite a lot in Mac Classic, so that's force of habit for you. I guess that's not a problem any more.
  • blech on 2lmc blog used to maintain a slush url folder too. And also suggests using bookmarks to queue, which lets the linktitles come into play. Hm.

I've got a few ideas for a part 2 article, mainly because there are limitations with this form of 'logging that are already frustrating me. Coming soon, hopefully.

"Lists of hyperlinks are the future of the web!" cries Anil Dash in his well futuristic list of hyperlinks. I'll echo that, but only because I'm really lazy, and posting a naked hyperlink is easier than link plus commentary.

So I've automated the process on Mac OS X. A link dragged to my desktop posts to my weblog automatically. (The machine-writable www is so much less effort than the machine-readable one.) How? All the details are in Lazy Mac OS X: Weblog links sidebar.

This is the first in what might well be a series of articles about how to hack things together in potentially useful (and pro-lazy) ways. Something that on OS X is within everybody's reach. I'm trying to explain as much as possible for that first nudge up the learning curve. There's not enough of that out there at the moment.

Adaptive design for weblog software | I've been thinking a little about software architecture, and primarily how to structure it to encourage two qualities:

  • the evolution of this particular piece of software
  • the evolution of the field

(based on the assumption that no program is going to be ideally suited when originally created, but that an iterative period will cause it to be better suited to use).

The spectrum of software development has two ends. On one end is the push model (yes, I'm going to lapse into the push/pull dichotomy again), which is the model where you set your sights on a goal, and build a tower to get there (like Windows). On the other end is the pull model, which is more like an ecology. Tiny steps, filling niches, each new piece of development just taking advantage of what's already there, and creating new capabilities -- like, life creates conditions conducive to life, in everything that it does. But it's undirected, not goal oriented, and slow. It can't be forced.

I've come to think that the Unix philosophy is towards the pull end. It's slow and steady, and each small piece is selected to be the fittest. Not only are components evolved, but abstraction layers too. But it's slow.

So every so often somebody looks ahead and says "We could do this instead!" so they leap and (in a fill of push development) make something that doesn't fit in with the ecology, like, well, Microsoft Word, or Quicktime, or maybe even XML. Then slowly, slowly, the ecology follows that leap ahead, and does it in its own way. There's a lot of idea-sharing involved, between both sides.

Anyway, I think pull is better, for two reasons. Firstly, because I think the resultant software itself is better. diff, patch and grep (say) are brilliant at what they do. And I think they've got there because they're separate programs, rather than as components of an application. Evolution can't happen to an application, it can only happen between applications. It's application versus application, but imagine how much better it would be instead if you could take the best parts of Microsoft Word and merge them with the best parts of BBEdit.

Trying to evolve a single monolithic application is like trying to order using bogo-sort.

The second reason is that pull is a way of exploring the software landscape. A push model of development by its very nature means developing in a deliberate direction, which means features are limited by the imagination of developers. Exploring with pull on the other hand means the only limitation is how people - any people - combine the parts. Ideas for free, almost.

And I guess this is what people call adaptive design.

Those are the two qualities I mentioned at the beginning. How to design software to itself be evolvable, and be open to other possibilities in the greater software ecology? (Incidentally, I don't think we've had the fundamental improvements necessary in the ecology since diff and patch. XML is a leap-ahead; the ecology needs a better form of structured text, because then we can have solidly grounded zoomable interfaces.)

It's a way of designing software to allow features to be shallow.

Start with weblogs! There needs to be flexibility both in the components, and the abstraction layers themselves between the components (the second is the tricky bit). We can take some hints by looking at what's already in the software ecology. So, some design decisions.

  • For storage, we already have a standard database -- data should be stored in individual posts on the filesystem, in plain text files.
  • Lacking a better structured, extensible text format, the files should use something like RSS. The storage format must be independent of both output and input styles. (Or maybe use email style storage, with headers and body?)
  • There need to be growth points to anchor commenting, trackback, trails, categories and so on.

Although both input and output into the datastore are unspecified here, and many systems will jostle for ways, some suggestions:

  • The input API should either use plain HTTP, like RESTlog, or allow storage on the filesystem without any further gateway (using scp, ftp, copying, moving, or editing files directly).
  • The output should be flexible and so loosely joined that even though there can be multiple templates and so on, there's no concept of republishing.
  • Templated output is a form of cache. Caching must be invisible.
  • Tiny tools should do most of the work, like qmail.

Because of these principles, the system will work with any combination of input styles so long as the output of them is recognised, like the Movable Type text formatting approach.

Okay, so I'm looking at something that involves parts of RESTlog, parts of blosxom. It takes design hints from the way mail systems hang together: procmail for filtering, mbox or similar as a plaintext storage format, simple protocols to view and send mail... (Oh, and now you've read all of this, go back and read the comments in the hyperlink tooltips. There's yet more in those.)