Peer Pressure

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.

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.

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.

I have always been, and plan to remain, fiercely of the opinion that ISPs should never be involved in traffic shaping at the application/layer 7 level. It is completely antithetical to the spirit of the network (stupid network and all that) and I think in the long run it is very bad business for ISPs.

If a customer wishes to do their own shaping to maintain quality of service (e.g. prioritizing interactive ssh sessions over retrieving web pages) more power to them. Such tools are available.

If an ISP wants to do shaping of the the total bandwidth any single endpoint gets across a switch, that makes pretty good sense.

But: If the ISP starts digging into packet headers and even packet bodies to do shaping they are introducing a huge cost for themselves. On the one hand their switches much do greater work. On the other hand there is now a presumption that the ISP knows or can know the content that is traversing their network and can be held liable for producing data about that content or controlling that content.

I get the impression that this latter point about liability is already a lost cause in the UK, which is a damn shame.

If BT or any other ISP is selling 8mbps connections to customers, then the customer should be able to expect that level of service for any type of content they get across the wire. If BT insists on being so oversubscribed that they can’t support that level of service at all times, they should shape total usage, not specific protocols or applications.

It’s interesting to me that BT would want to perform any kind of shaping. BT has an effective monopoly on the physical infrastructure that provides these services. By encouraging more and more intensive use of the internets they increase the demand for the infrastructure they provide.

Disclaimer: I do contract work with Osmosoft which is part of BT. These are my opinions. I’m sure there are lots of people within and without BT with lots of different opinions on this matter.

This is a followup to Invert the Web where I wrote:

Today I go to a web site and give it some output of my brain. The web site takes my content and in exchange it gives me a URL so I and other people can get to the content again. What should happen instead is that I make some content and give that URL to some websites so they can get to the content.

In typical me fashion that wasn’t very clear. Here I shall try to make parts of it more clear and other parts more muddy. Let’s expand the above.

Today when I publish a photo or make a tweet the mechanism goes something like this:

• I suck the photo off my camera, do whatever tweaking I like to it, and then upload a copy of it to some photo site (e.g. Flickr). My photo then gets a URL somewhere in Flickr’s URLspace and I can tell people about that URL, or people can browse Flickr and stumble upon my photo. If things go my way and I play the game right, the photo might even show up on Explore.
• I go to http://twitter.com/ or use an app like Twitterrific and type up my tweet. The content is transmitted to and stored on Twitter’s servers and gets a permalink in their URLspace.

What I would prefer is something like this, where the URL becomes a more Universal Resource Locator:

• I suck the photo off the camera and store it in my own personal URLspace, getting a URL that links to the content. I then give that URL to Flickr and whatever other services provide a nice URI for browsing photos. People can still browser Flickr and stumble upon my photo and the photo may still show up in Explore. And lots of other places too.
• I write my tweet and store it in my own personal URLspace. I use the returned URL and give it to Twitter, Pownce, Jaiku, Facebook, MySpace, iChat and a variety of other “status” related services.

At this stage of the conversation the first objection is usually, “Not everyone can host their own content.” Indeed this is true. It’s also true, though, that not everyone keeps all their money in their wallet, under the mattress or in a mason jar in a hole in the back yard. They use banks. And those banks provide a variety of services to provide incentives for people to deposit their money with them. So we could have banks for content.

Another objection is “I don’t want to do that two step publishing dance just to get something on Flickr.” Me neither, that’s why we have computers to automate the parts of processes which are fully describable. POSTting something in the content bank and then PUTting the returned URL to Flickr is fully describable.

Why would you want a bank for content? What would the benefits be?

• All content remains yours, held in trust by the bank, forever.
• If a presentation service goes out of business, your risk or loss is more manageable.
• Any publication of content can be immediately rescinded by changing access policies on the URL (modulo whatever caching policies you’ve chosen).
• You can (in theory) have access policies or capabilities statements on all your URLs.
• Anything which can be captured by a MIME type can be stored in the bank.
• You can host your own bank if you want: It’s just HTTP.
• You can publish your content to multiple places by reference instead of copy. When you make changes, you don’t need to worry about going round to several different presentation services.
• You have the option of maintaining several content accounts for all your various internet personas.
• Banks could differentiate themselves by providing different levels of service: different ways of managing access control, service level agreements, data sharding and redundancy. Some people might opt for free content accounts in exchange for allowing some or all of their content to be anonymously mined for targeted advertising purposes or market research.
• A suitably well featured bank could provide persistent and versioned storage for all your stuff, ever. Kind of like a github for everything, not just code.

And what about places like Flickr or Twitter, what we might call presentation services? What could they gain?

• They don’t need to worry about storage quite as much.
• They can concentrate specifically on the UI of their service, distinguishing themselves through innovations in that area.

These ideas are the latest synthesis of a variety of things which have proven to be important on the internet:

• Separation of concerns. The presentation services worry about presentation and banks worry about storage.
• Cool URIs.
• Data ownership and portability. It’s always yours.
• MIME. Lots of different types of content.
• Stupid Network. Put the smarts where the smarts need to be and nowhere else.
• The awesomeness of REST, or more accurately HTTP, and the open web it/they allow.
• Using content by reference rather than copy (c.f. Xanadu, Transclusion, Purple Numbers).

It would probably be possible to prototype a content bank in TiddlyWeb or CouchDB or some kind of interface to S3. My own first work related to such things was closet from which TiddlyWeb got a few ideas.