Signal transformers


I’m writing this in emacs.

That I’m writing this in emacs tells the tale of a shift in perspective I’ve been having about software interfaces - what started as a shift to minimal user interfaces has moved close to zero interface. After all, if a blog post is text content then all I need is something to manipulate text. After editing this post in emacs I just do <C-x C-s> and it’s published via an xml rpc call. There’s actually a lot of complexity between me editing text and you, the reader, seeing that same text presented in your web-browser (or otherwise).

If I had come at this having already distributed my thoughts in a different manner (such as in print) my thinking on blog posts might be different. For example, I might think it was cool to scan whole pages of my newsletter and distribute those electronically as a PDF or using flash (complete with a page turn effect). That would be me bringing interface baggage to a new medium. People still do this.

This blog, It’s all text that varies over time and space. Everything, including responses to my input can be thought of as a signal transformer. If that model holds well over a reasonable subset of problems then developers might be able to define programs as signal transformers. For a while that has been my thinking on how to write programs for user interfaces.

In programming terms, the concept of arrows is the best option I have seen. There’s a library for JavaScript called Arrowlets but it doesn’t quite seem to expose the underlying elegance of treating incoming events as a stream and processing them with arrows. For anybody interested in arrows a good place to start is on the Haskell wiki.

Somebody needs to get arrows done nicely in a dynamic language. I can’t say whether that will happen.

The next part if this is small programs that do one thing. Go and read Jeff Raskins’ “The Humane interface”. What I think is the best way to code UI’s is a fairly good match for some of Raskins’ ideas on humane interfaces. Unfortunately, there’s a lot of baggage, expectations and inertia regarding the types of interfaces that are acceptable and the ways in whcih they can be written.

Still, I don’t want to model every irrelevant bit of baggage in my programs, that sucks for everybody who has an interface to the program. I don’t want to, but usually I have to. My consolation is usually to find a way to bring simplicity out of at least one aspect of the program.

Of course, the type of simplicity, the type of minimalism I’m after here is an informed type that most of us only manage to get to after seeing many overly complicated, intricate solutions to problems and noticing that really, what a dozen complicated solutions do ends up reducing to one simpler solution. That takes time and practice.

The same would go for this blog post itself. I might distil all of the words down to one sentence and better convey the idea… and yet I know that a human does not always work like that and that sometimes the journey of the interface, in this case words, is an important craft.



CoffeeScript in Action


CoffeeScript in Action book cover

I'm the author. Get it from Manning.