Category Archives: Design

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.

The Cobbler’s Kids are Shoeless

There’s a 16th-century proverb that goes something like, “The shoemaker’s children go barefoot.” Or unshod. Or something olde-timey like that. But however you phrase it, the sentiment certainly seems true today.

Last week, Apple announced that their developer site was hacked, and that potentially thousands of developers’ emails and other info may have been compromised. The hack (and the hacker) have since been called into question, and the real scope of the intrusion is unclear. But, to put it mildly, it ain’t good.

If Apple, with all of its resources and intricate technological knowledge, can’t keep it’s, ahem, stuff together with basic security, it seems like there’s not a great amount of hope for the rest of us. At least under the current security regime. Some of this is certainly due to neglect close to home — the shoemaker/cobbler proverb again — but much of it is based on how we handle security in general.

The username/password or email/password security approach just doesn’t work. It really doesn’t. Oh, sure, you might argue, it’s ubiquitous, so it must work fine. But there are SO many examples of breaches that something is amiss, and even where there aren’t breaches, it may just as likely be because nobody has really targeted that system yet.

So if not that, then what? Biometrics? RSA keys for everyone? Implanted chip under the skin? How apocalyptic sci-fi movie do we want to get?

Frankly, I don’t know. Each of those approaches has definite pros and cons, including a glimpse of dystopia. But I know this: what we have now is not working. And perhaps this is just another example of Apple leading the way.

Not that they were wanting to lead in this particular area… Apple, get your kids some shoes!

Know Thy Tools

A while ago, I was reading an issue of Dr. Dobb’s when I came across the assertion that programmers waste a significant proportion of time because they don’t know their tools well enough. And I think that’s probably right. But it doesn’t go far enough.

Earlier on the blog, there’s a post about the importance of having a broad and deep toolset. But both the Dr. Dobb’s comment and the earlier post focus on the development side of things. I think the assertion is just as true on the design side as well, although the perils may be a little different.

When developing, if you’re working in an IDE and you don’t know the intricacies of how it works, you’re definitely going to be working more slowly than you need be. When designing, if you’re working in a design tool and you don’t know the ins and outs, you’re restricting the scope of your creative output. That’s perhaps an even more catastrophic outcome!

Think about Photoshop, for instance. That tool is both broad and deep, and it gets moreso every cycle. Now that it will largely be available as a subscription only, the changes will just keep on comin’. But if you don’t know how the filters work, you may no longer have those design choices in your visual vocabulary to work with.

In contrast, if you don’t know how to do multi-file grep-based search and replace in BBEdit — something that is roughly comparable in terms of complexity and importance, I think — you have a bunch more work to do to get to the outcome, but you can still get there.

Regardless of the specific poor outcome, the lesson remains the same: know your tools. Whether you’re an information worker who lives in Word, Excel, and PowerPoint; a coder who lives in emacs, BBEdit, or Notepad++; or a designer who lives in the Adobe or Corel worlds, you’re probably missing out.

Besides, how can you complain about the limitations of your toolset if you don’t really know what they are? Think of the fun you’re denying yourself!

Should Lorem Ipsum Die?

Last month, Paul Souders posted a piece that was one-part futurism, one-part opinion, one-part rant, entitled: “Content-first design ain’t herding cats.” He raises a handful of design trends and then makes leaps to what he perceives to be the best responses.

Amidst some of the all-caps and bolded pieces is the underlying premise that content should always drive design, and thus, the content should be present before the design is done. Not necessarily a revolutionary sentiment, but certainly an admirable one — sort of the web design version of form following function.

In practice, though, it seems like it’s a goal but not often the reality. Usually, content is getting reworked (or generated) as the design is being done as well. So Souders’ contention that we should “[k]ill Lorem Ipsum for good” might ignore how projects tend to work. Or at least how they’ve tended to work in our experience.

That’s not to say design drives content — quite the opposite. But often, a design framework will be in place well before the content is “done” (put in quotes because when is content ever really done?). When the content is ready to go into production, there are often tweaks and alterations to the design. But to hold one up altogether for the other would extend project lifespans considerably.

Other responses are predicated on the idea that walled gardens and Instapaper will be the primary way we view content in the future — web scrapers that take someone else’s content and puts it in their display. I’m not so sure about that future, both for copyright and commercial reasons. Big brands aren’t going to want some third-party app effectively removing their specific brand pieces (trade dress), nor will they stand for it for long, if it threatens to become ubiquitous.

Further, it’s difficult to see how the Instapapers of the world would handle more intrinsically dynamic content, where design necessarily is a bit removed from content because the content can vary.

Thinking hard about content before thinking hard about design is a good idea. A great idea, even. Holding up the design process until the dots and twiddles are done to accommodate a scaper-driven future? I’m not convinced.