The imperfection of our tools

I enjoy a well-crafted application. I place a high value on attention to detail, have opinions on what design elements make an application work, and try to empathize with the users of applications I’m involved in creating. Applications with a good aesthetic, a few novel but effective design decisions, and sensible workflow find themselves in my Mac’s dock. Those that don’t, do not.

The applications I observe fellow creators using to create often don’t fit into their environment. They don’t fit into the native look-and-feel. They ignore important idioms. Their metaphors are imperfect, the conceptual edges left unfinished.

In part I notice this because as creators we tend to live in a few different applications, and time reveals most shortcomings. But in part, I notice this because the applications are in fact flawed. Flawed to the point, that you would think given my opening words, that I would refuse to use them. And indeed, I refuse to use many of the applications that others find completely acceptable for making the same kinds of things I do.

Increasingly, it seems the applications that people who create things live in offer a disjoint user experience. I’m thinking of visual people living in Photoshop or Illustrator or developers living in Emacs or We use these applications because they best allow us to make what we want and get in our way only a little bit. But, it’s a tenuous relationship at best.

What’s this say about what we’re doing and the boundaries that we operate along? Would we accept the same kinds of shortcomings in say, a calendar application or a clock widget, if those were central to our workflow? That is, is there something about the creative process that leads us to accept sub-perfect tools? Is it inevitable that someone seeking to make new things will find their tools imperfect? Is the quest for ever-more perfect tools part of how we grow as makers?

I hate closing with a bunch of questions, but this piece is but an imperfect tool for discovering an idea.

Ed. Closing could use some work.

3 thoughts on “The imperfection of our tools

  1. I think your point might be strengthened with a few examples. I know you probably don’t want to pick on any one particular application but any reasonable developer should appreciate constructive criticism.

  2. Greetings,

    As a developer, the tools I use are by their nature unfinished. I want them that way, as finishing is a closing off of possibilities. I want emacs to have conceptual edges left unfinished, as I can finish them in a way that suites me, that best integrates with the way I think and program, which WILL be different than how you think and you program.

    Tools which support creative endeavor must be unfinished, so the creator can believe it adapts to them, not that they must entirely adapt themselves to it.

    Then there are tools like, which provide an infinity of power unobtainable by any pre-designed application. The flow of chaining piped commands together to build something supremely more powerful than any one tool could provide is a core part of why I work from the command line more often than not.

    I’ve used great IDEs, and I continue to use them, but as a software developer I _often_ want to do things that could never be pre-imagined by the IDE authors, sometimes because I just want to do them _once_, but I do a dozen _once_ operations a day. Sometimes because it’s a conceptual operation specific to the current project.

    Also, the unfinished edges of our tools are the places we add our own touches, the things that make a tool feel ‘right’ in the hand. It’s like a broken-in hiking boot; no boot from the factory is going to provide the experience you want, you have to wear it, break it in, smooth its edges with your own customizations.

    We wouldn’t approve of that in a tool not designed for assisting in the act of creation, because those tools are generally focused, purposeful tools. You don’t want your clock widget to encourage you to explore, or your calendaring system to encourage experimentation. You want them to do the focused job you need them to do.

    Our primary tools, as creators, are for exploration and experimentation. That necessitates a certain…unfinishedness of the tools, as we finish them through our use.

    I shouldn’t write stuff like this when I’m tired, I get all flowery and shit. ;)

    — Morgan

  3. Good idea Mike. The two that are on my mind lately are TextMate and Photoshop.

    TextMate is a fantastic editor. No other software development tool can compare on the combination of aesthetic, sensible extensibility, and feature set that it provides. The imperfection is that very sensible extension mechanism. You can go a long way with it, but there are things that are out of reach. You can’t really embed a terminal window in TextMate, or implement split windows, or proper full-screen editing by writing a TextMate bundle. _Perhaps_ someone could write something in Objective-C that mucks around with the TextMate insides, as the somewhat popular project drawer plugin does. But that’s a suboptimal solution. That said, TextMate does an astonishingly good job of reaching the 90% point of what developers need.

    I don’t use it or even own it, but Photoshop seems to be the subject of near constant abuse on Twitter. Between Adobe’s installation and upgrade procedures, its performance, its outdated UI, and its poor position as an OS X citizen, I’m often surprised people keep putting up with it. It would be quite difficult for a competitor to provide all the functionality needed to outright replace Photoshop, but I suspect the potential profit would be handsome.

    If I think of Adobe’s tools and something like Emacs, I start to think that creators easily eschew aesthetics and native feel for raw power. It’s probably a sensible trade-off.

Comments are closed.