Tag Archives: Design

New Theme

This probably has no interest to anyone but me, but you may notice a change in the blog theme today. I’ve been dissatisfied with the typography of the blog for quite some time. Today I set out to try to find a theme that had better typography. Man, what a mess!

There are a zillion WordPress themes out there. Some awful, but many quite good. However, finding a minimalist theme intended for writing and reading is surprisingly difficult. They seem to jump from those with no bells and whistles at all (see mnmlist or less or Hemingway Rewritten simple for example) to those that have galleries and seem to be photo driven. A lot of “responsive” themes seem to give ugly results when shown on a nice big monitor as opposed to a tiny phone screen.

I just want to write stuff and have a few side widgets. It has to be capable of supporting code listings, of course, and the few little widgets I use for navigation (archive, categories, and tags). That’s enough for me.

So this is now Two Thousand Twelve, an update to the Two Thousand Eleven them I used previously. There are still things I don’t care for, like the way the blog header and image are laid out, the typography (could be better), ugly links to read the rest of long stories, and on and on. But I’m too lazy to write my own. It isn’t really hard, just tedious (says the guy who has only read the tutorials.)

Dave Winer’s new outliner, Fargo, does most of what I want and seems a great tool. It even integrates with WordPress. Maybe that’s something to look into another day. The Truly Minimal theme looks almost right too.

Write the Manual First

Back when I was involved in designing medical devices, I had a saying to help guide the design: “Write the manual first.” This seemed to be an easier way for the teams to clearly describe what the device should do. Once everyone had a good feeling for how the system should operate, it was easier to move on to the more formal requirements management. Surprisingly, not everyone on the team was as fascinated with that as the Systems Integration team 😉

The same thing applies to software. There have been posts about working with the API of a program before the API is actually written. Makes sense to me. It’s just another approach to top-down design.

The approach has a couple of advantages. First, in terms of requirements elucidation, you get involvement from team members who have no training or interest in the formal process of requirements management. They don’t have to figure out what the final design will do based on a series of isolated requirements statements. They get a more holistic view of the product.

Second, it seems to lead to better architectural designs. If you start coding up the low-level classes based on your intuition, that often leads to attempts to fit the final design to a bunch of low-level architectural decisions that weren’t quite right to begin with.

This approach was not always taken on teams I’ve worked on, but on the occasions when it was, it has lead to simpler, more reliable designs in less time. It might work well for you too.