Peer Pressure

Tools Together

Brain Dump

As TiddlyWeb has matured, one of the things I have noticed is that people are often wanting it to do more than it does. The generic form of the query is something along the lines of “Wouldn’t it be more complete if it did X”.

This is interesting to me because in a way it is contrary to the TiddlyWeb point. At base TiddlyWeb is a tool for manipulating chunks of stuff called tiddlers on the web. It is one of many tools in the toolbox for doing web stuff.

An analogy may help. There are lots of tools out there that spin and accept attachments: screwdrivers, socket wrenches, drills, etc. You can make a drill be a screwdriver if you want, but sometimes it is overkill. TiddlyWeb is an extensible web service: with extensions it can serve up static content, use templates, do all the usual web framework stuff. But that doesn’t mean it should be used for all the usual web framework stuff. Maybe, maybe not.

TiddlyWeb comes out of the Unix tradition: small tools that do one job well and can be integrated with other small tools through pipelines. This is true in how TiddlyWeb can interact with other tools and also internal to the architecture of TiddlyWeb: separated layers with strict contracts for interaction. This means it is easy to extend and it interoperates nicely with other stuff.

The most performant and scalable implementation of a large scale service that involves TiddlyWeb likely involves TiddlyWeb; a separate web server (or two or three or four) serving static content, doing some URL rewriting, some caching; a memcached server; a database server; and maybe another framework (django, turbogears, rails, etc) presenting UIs that might use the TiddlyWeb server as a datastore.

This last thing (presenting UIs) is the main area in which TiddlyWeb intentionally makes no provision (to concentrate on effective backend handling). Good web frontend presentation is strenuous, there are existing tools which make it easier. A tool approach means that TiddlyWeb can play well with those guys.

Leaping Forward

I’ve been having a bit of a debate with @Casablanca about the need or merits of designing and developing for people who use Outlook or IE. It started with:

@cdent: This #fixoutlook thing is bullshit. Just don’t use outlook!

@Casablanca: @cdent it’s not about whether you use outlook. It’s about having to design for people who do (e.g. our client’s customers)

@cdent: @Casablanca don’t design for those people! Design well enough that they’ll want to use what you’re using. If U cowtow, they’ll never learn.

@Casablanca: @cdent you mean we should tell our clients to tell their customers to change their email clients? A bit impractical, no?

@cdent: @Casablanca Just because it is impractical doesn’t make it wrong.

@Casablanca: @cdent does that mean you’ve never tested code in ie, because you don’t want to design for those people either?

@cdent: @Casablanca I haven’t personally tested code in IE for several years, if ever. Nor do I test other code in non-posix envs.

My basic assertion here is that people or organizations won’t change to things that are better if they can get the cool stuff on what they already have.

A secondary assertion is that by requesting Microsoft fix Outlook, Microsoft is not getting the punishment they deserve for causing the problems they have caused over the last…well the last very long time. There shouldn’t be a campaign to fix Outlook, there should be a campaign to boycott Outlook and boycott developing for Outlook.

I understand the economic considerations involved in the calculus used to determine “shall we do the work to make this work in IE”. For people encumbered by relationships with the corporate world, it’s kind of inevitable that someone along the chain will declare an operating environment where things must work. Likely that is an environment where openness, consensual standards and interoperability are meaningless tokens, not thriving actors in the system.

I try to avoid those kinds of relationships, and think other people should as well. I’m well aware that some people can’t and some people don’t, and more power to them. In fact it works out quite well for me: Because I work on open code in open environments, if there are people who are interested in making the stuff I do work in non-standard environments, they have easy access to do so. The pain stays with the people who need or want to suffer it.

Yes, I’m being impractical. Yes, I’m being unrealistic. But I can see little to suggest that the practical realities of the world are the best ways of doing things, so I’ll continue.

S5 For TiddlyWeb

This evening FND and I were discussing how one of these days I’ll have to do a TiddlyWeb presentation: make slides, talk to people, gesticulate in awkward ways while standing in front of people and moving around for no particular reason. I remarked that I was going to use 3x5 cards to lay out my thoughts because they are physical and I think better with physical stuff.

This led to more discussion about how in the TiddlyWiki universe slide presentation systems are a bit of theme or motif. I said I had considered making a tool to present slides out of TiddlyWeb but figured I would do such a thing when I really needed it. What I had in mind was some kind of jQuery thing that retrieved content from the server as needed. In other words, a project, an investment of some kind. FND brilliantly suggested that an S5 serializer would be the ticket.

I had heard of S5 before, but never really knew what it was. So I went digging around and saw that the basics of S5 are not only incredibly straightforward, the fine folks at meyerweb.com have packaged it all up nice and easy.

So I thought to myself: All TiddlyWeb needs to do is make the s5 javascript and CSS available (either via the hosting web server, or the static plugin), gather some tiddlers, and push them into the HTML file provided for S5. I set about doing that and lo and behold it works! Here’s an example. Go have a look, it gives a bit of an idea of what’s going on.

And here’s the code.

The serializer architecture in TiddlyWeb has been designed from the start to be extensible. By configuration or a plugin you can associate a MIME type or a file extension with a Python module that implements at least some of the SerializationInterface. A serializer takes TiddlyWeb objects, such as a tiddler or collection of tiddlers, and turns them into some stringified form of some type (HTML, JSON, an S5 file, etc.). Some serializers go the other way as well (e.g. turning a JSON string into a Tiddler object).

The S5 serializer checks for some special tiddlers to set meta-presentation-stuff like title and presenter name, and then renders each of the tiddlers it has been provided into HTML. This HTML is then pushed into the template file (jinja2 is used) and the results are sent out over the web as an HTML file. That HTML file requests back to the server for the necessary javascript and CSS.

Because TiddlyWeb already has all the bits for generating the list of tiddlers and getting them to the serializer, the serializer itself can be quite small and concentrate on just the work it is supposed to do. The code is only 55 lines long, including whitespace. And I like whitespace.

There are still some things to clean up, but I reckon it is nice start.

• A demo
• The code
• TiddlyWeb’s home site
• An old posting about TiddlyWeb serializers. That one involves cake rather than presentation slideshows.

Update: I updated the link to the demo to a new location to reflect that there’s now support for ordering slides in the presentation.

Synthesis

Not long ago I decided to take a break from updating my status on Twitter and Facebook. It was a spur of the moment decision but the urge had been building for quite a while. What I said at the time was: “It’s mediating my conversations and I like the internet when it disntermediates.”

Meaning: Using Twitter and Facebook statuses gives me the action of initiating interactions with the world, satisfying something innate, but for the most part ends the experience there. On one hand this is perfectly fine: Broadcasting the ephemera of life maintains a loose contact, a finger in the ambient stream of ones social network. And every now and again someone will @you or “like this” to let you know that the world rolls on.

On a different hand, by granting a minor satisfaction of the urge to express, 140 characters of news bleeds off the pressure to say something of substance, something with significance, something that synthesizes.

This may be the most telling way in which I’m showing my age: Knowledge trumps Information; though communication is the grist of knowledge generation, action, results, doing, knowing is what matters. When I was at Socialtext and actively engaged with Blue Oxen I had occasion to play in the fields of the lords of Silicon Valley and often thought: All these Californians seem to do is travel from one conference, meetup, retreat to the next. When do they do anything? When is the synthesis? (It does happen, but it is on the fringes of the whirling soup of information being exchanged. People step out of the flow and then return with their synthesized new stuff.)

EEK (of Blue Oxen) and I, in our too infrequent conversations, often return to the topic “What happened to wikis?” Somewhere along the way the popular conception of a wiki transformed from a tool for synthesizing new understandings in a group to a tool for representing topical information which can refined. In many modern wikis, UI affordances emphasize the single page and the fact that it is editable rather than the entire wiki and its nature as an evolving (visible by recent changes) networked (via hyperlinks) corpus of shared understandings. A traditional wiki is a synthesizing tool when it exposes or strengthens the connections between distant concepts and categories. The group using a wiki learns by exposing, exploring and, eventually, refining those connections.

I get bored when I’m not learning, learning requires synthesis and synthesis requires reflection, reflection is something we pause for. Writing a tweet is vaguely like pissing with the wind: off it goes, out there with the breeze; easy, initially satisfying, but ultimately boring. So a pause. I’m sure I’ll return to it eventually but for the time being I need some reflection, some synthesis, and some doing and being.

While looking around for things I’ve thought or written related to this, I found this old email about knowledge representations from 2002 which has a bit to say about synthesis.