Author Archives: aaron

Working With Style Guides

We work with clients big and small, so we run the gamut when it comes to design constraints. Sometimes, the client wants to start from scratch and gives us just a few parameters, while other times, we’re just making some minor changes to an already-established brand.

Somewhere in the middle is where we often find ourselves dealing with a style guide. This is a document from the client that outlines (in varying levels of detail) how their brand is represented across all media. Often, it has things like when and where to use the corporate logo(s), official colors, fonts, and that sort of thing.

We are used to working within these bounds, so that’s not a problem. But sometimes, the style guide can go just a little too far.

For instance, we worked with a client at one point whose guide specified the minimum size of the logo for display on the web at around 500 x 300 pixels, and that it had to remain on screen at all times. Think about this in a mobile perspective — that would take up most of a phone screen, and if it has to be onscreen always, then the content is doled out in 5-word increments!

It was clear in that example that the company hadn’t thought very clearly about the different devices and media that might be in play. Conversely, the reverse can happen as well — where the style guide is so vague that you’re not sure if you’re following the rules until you discover later that you’ve broken them.

Sometimes, we find ourselves in the position of creating these guides for clients, and while that can be tricky, it’s a useful reminder of the challenges involved.

What we’ve found is that even when a style guide is clear, it’s no substitute for good and open communication with the client. Sometimes what’s written isn’t what’s in practice, and it’s always good to get the straight skinny.

Retro Tech: The 200-year Old Computer

It was nearly 200 years ago (okay, 191) that Charles Babbage came up with the design for his Difference Engine, a mechanical calculator that could solve polynomial-based equations. In the 1820′s, he also sketched designs for a printer to go along with it!

What’s perhaps more amazing is that when, in 2000, the printer and difference engine were built, they worked perfectly. And they still do!

As we move ever faster into quantum computing, wearable computing, holographic interfaces, and all the rest, it’s sometimes useful to take a moment and look back. This week, to look WAY back, and celebrate one of the foundational moments of the technology.

The Computer History Museum in California has a working Difference Engine No. 2, and also has a wonderful interpretive website about it all.

Worth checking out!

The Rise And Fall Of Programming Languages

Everybody out there who is fluent in conversational Latin, please raise your hands. (Peering out) Not many. How about Esperanto? Perhaps a few more, although you all seem to have shaggy beards and a perpetually quizzical expression. (Not that there’s anything wrong with that.)

Human languages come and go, even though they are so closely identified with a people. There are efforts to keep them going wherever possible, and records indicate that there may be as many as a thousand or more so-called “endangered languages.”

So it should come as no surprise with the pace of technology that there are endangered programming languages as well. Some, like B, were stopgaps until something else came along. Others, like COBOL, were historically important but really aren’t around much today (other than a lingering small group).

When does a programming language become pervasive enough to get interested? And when does it wither enough in ubiquity that it’s no longer relevant for a project? Both are tough (and squishy) issues.

In terms of the upswing, my bias is to get interested pretty early in gestation — not necessarily to use the language for a client project, but to get a sense about where language (and compiler) development is going. I’m not likely to use Ada or even Haskell when building something that others will need to maintain, but, as an example, looking at how Haskell handles lazy evaluation and “first-class” functions is fascinating, and broadens the knowledge of the team.

So perhaps the better questions are about when to use a language for a project that will be released into the wild — and when to stop doing so, as a language’s star is falling? The answers to both are really the same: when maintenance and long-term expertise is easy and relatively cheap to find.

We’d love to be in lifetime engagements with clients. And many of our clients are with us for many years. But we don’t assume that, and we don’t want to build something that will create hassles for the client later. So that means, no matter how much we love Forth, we’re probably not going to use it to build a web application. There just aren’t enough people out there to support it. (Plus, that’s not really a great use of the tool.)

But let’s take a tougher example: perl. Fifteen years ago, it was everywhere. If you didn’t know it, you weren’t considered serious about building for the web. As PHP has usurped some of that space, perl remains a widely-used language (although more and more, it seems to be confined to the back-end and server side).

But man, I love perl. It has an ability to work with bits of data and patterns that is perhaps matched, but rarely surpassed. Contrary to some of its reputation, it can be elegant — but it doesn’t force it. (Why is there so much bad perl code? Bad perl coders.) And the CPAN archive of modules and third-party libraries is peerless.

What to do, then? Objectively, perl’s fortunes are falling. Has it passed the threshold of use on a major project? Well, as of this writing, I’d say no — but it’s getting close. The thumb on the scale that balances cost-benefit of using a language for a project is getting kinda heavy. It’s probably in the space where we will build and maintain perl-based projects that are already in that language, but are unlikely to starting something from scratch in it.

Which is sad, but for every one of those, there’s an Objective-C or a C# that’s climbing up the charts. Goodbye Esperanto, hello Mandarin.

Patterns Everywhere

As humans, we see patterns all over the place — how do we read? We identify patterns of letters. How do we navigate around our world? We see visual patterns and respond to them in our habitual ways. In fact, there’s a common phenomenon called apophenia, where we see patterns in randomness all the time (even when there really isn’t a pattern there).

So why not put this pattern-seeking behavior to good use? When doing design or development, there are also an array of patterns out there. In terms of development, this may be a broad framework pattern, like Model-View-Controller, that specifies how one can build the basic structure of an application — or something smaller, like how a variable can be structured.

But patterns exist in design as well — and I don’t mean the textured backgrounds or patterns that dress up a layout. Rather, as in development, these can be broad structures (like a layout pattern, for instance, a grid-based layout), a navigation feature (like double-tab navigation), or a functional aspect, like a captcha.

So why are these patterns important? Well, the more comfortable you are with the patterns, the easier (and faster) it is to bake them into projects. Even better, as you get more comfortable, you begin to extend the patterns and do new variations that help evolve design (and/or development) in new and interesting ways.

And therein lies the potential problem with pattern-based design or development — it can make it too easy to stay within the same set of parameters, and things stagnate. Nobody wants to see that you build the same old thing for every different client or need. If you hew too closely to the patterns or use them by rote, you are losing a lot of creativity.

But knowing the patterns and how they work is one of the best starting points there is — after all, if you’re going to leap off into the great design/development unknown, why not start atop a foundation of years of others’ expertise. You’ll get a lot further that way.