ideapark: homepage navigation

Good information architecture doesn’t always take the form of a high school English paper outline (although this is a good standby).

Here’s another option: the signpost.

ideapark, a brand experience agency in Minneapolis, is doing the signpost very, very well.


Even those of us who didn’t grow up on M.A.S.H. re-runs know the signpost metaphor. It’s message is clear: “If you want this, go here; if you want that, go there.” It doesn’t get simpler than that, and simple is always better.

Information Architecture

The signpost metaphor is best for a site with more breadth than depth. Transactional and informational sites would not be best served by the signpost metaphor. The ideapark site is primarily an awareness site: “Hello, we’re ideapark and here’s why/when you need us.”

User Experience

ideapark’s implementation of the signpost metaphor is a stellar example of form and function playing well together. Page transitions are smooth and preserve a sense of movement without making the user seasick. The graphic treatment is consistent and crisp without being gaudy or becoming a barrier to what the user is here to learn or do.

(GoodShovel Rant: Flash-based splash pages can go die in a fire. Nothing makes me want to evacuate a site faster than a splash page mocking my attempts to get at the site’s substance by making me sit through a ridiculous, inaccessible disco ball pirouetting around some agency’s outdated logo.)

My only suggestion is to spend some time on optimized accessibility. The site goes all kinds of wonky when you turn off CSS and doesn’t work at all when you turn off JavaScript.

That said, I assume the target audience for this site is companies and organizations who need an external perspective and skill set to accomplish their branding needs. Most users in this demographic are going to have CSS and JavaScript enabled on their desktops and mobile devices. Still, it never hurts to be thorough.


ideapark’s identity page is three paragraphs: purpose, approach and culture. No subpages with poorly posed photographs of the staff. No timeline of the company’s inception. Just what the user is actually here to learn.

Let the slow-clap begin.

Once while interviewing for a technical analysis position, I was asked if I knew anything about Java. I knew something about Javascript, and I knew enough to know that Java was not the same thing. But that was it.

We front-end people (designers, content specialists, usability developers) hear about Java, .NET, etc., but rarely really understand how it all fits together.

What is Java?

Java is a programming language. (It is also an island in Indonesia, and an espresso drink I’m craving at this very moment.)

What does it do?

[Java] allows software designed and written just once for an idealized “virtual machine” to run on a variety of real computers, including Windows PCs, Macintoshes, and Unix computers. On the web, Java is quite popular on web servers, used “under the hood” by many of the largest interactive websites. Here it serves the same role that PHP, ASP or Perl might, although traditionally Java has been used for larger-scale projects.

WWW FAQs: What is Java?

Why is it cool?

Java applets allow interactive elements to be embedded within other applications, such as webpages displayed in a browser. And, in keeping with Java’s principle of portability,  “write once, run everywhere” means you’re not confined to only one browser.

OK, that’s not entirely true. You might need to download a Java plug-in, particularly if you’re running Internet Explorer, whose masters allowed their Java Standard Edition license with Sun Microsystems (now an Oracle Corporation subsidiary) to lapse.

There are pros and cons to Java. Some say programs and services written with Java run slower and require debugging to accommodate subtle differences in implementations. On the other hand: applets, people!

Ever have a hard time answering the inevitable “So… what do you do?” when people learn you’re a content strategist? Now you can tell ’em where to go: Rachel Lovinger‘s post, No, I’m not a Web Editor.

My favorite portion of the article far exceeds 140 characters, so consider this a 111-word Retweet:

Content Strategy is, at its core, a discipline that sits at the intersection of Editorial, Business, UX, Design, and Technology.  There tends to be a lot of emphasis on the editorial segment because – believe it or not – content has long been a neglected aspect of web design. But the real goal of the content strategist is not just to write good content. It’s to make sure that the content:

  • Is aligned with the brand and business objectives
  • Meets the user’s information and experience needs
  • Supports designs that in turn present the content in optimal ways
  • Can be implemented and managed using technology that enables a sustainable workflow

Zendesk Help Desk Software - Twitter For Business Infographic

First, I’m a fan.

The redesign will do wonders for information architecture (visual heirarchy on the homepage, as well as throughout the site) and for communication of context (see slide #5). Check out a full article and slideshow preview.

Second, because we all get sharper when we cut our teeth on one another’s bones, my one persnickety comment:

I don’t understand the need for a “New” badge to indicate the most recently published stories. What is that feed of titles if not the most recently published? There’s a brief note on videos being organized along matrices of both publication date and popularity, but I didn’t see a similar note for featured articles.

Still, big ups. This is a refreshing redesign, and I’m looking forward to the launch.

After a characteristically fruitless VP-mandated team “brainstorm” session on business goals not one of us has authority to influence, I was particularly refreshed to read Smashing Magazine’s recent post: Why Design-By-Committee Should Die.

As a content strategist trained on heavy artillery but often relegated to a BB gun, I would augment this title: Why Design-By-Committee Should Die–Slowly, and In a Fire.

An example.

My UX team and I had been working on a new interactive design for months. Balancing the complex, often-conflicting priorities of multiple stakeholders, we had finally arrived at an accessible, informative model based on research and industry standards.

The director of an adjacent department parachuted into one of our last meetings, having not attended previously, with this reaction: “Why are there so many words?”


You might assume that my gripe is with her question. It is not. She’s good at what she does, but what she does has absolutely nothing to do with the Web. I don’t expect her critique to be constructive, or even informed.

My gripe is that she was there in the first place.

How many brilliant products and services have bled to death on the altar of consensus-building? I don’t know. Is there a number bigger than a-hell-of-a-lot?

Now, I recognize how fortunate I am to have a job (at all, in this economy!) where I get to dig into so many communication channels even as they’re evolving. I love arranging and rearranging, learning and improving. I love content strategy! I only wish I could devote my time to it.

Instead, because of forces outside my sphere of influence, I spend much of my time in this sort of dialogue:

“I don’t speak Web.”

Allow me.

“What if my grandmother wants to use it and doesn’t know how to get back to the homepage?”

Your grandmother won’t want to use it. By the time you’re done with it, no one will want to use it.

Speider Schneider says it best: Most creatives choose to let it wash over them and collect their pay check. I suppose I don’t agree because I haven’t seen many pay checks made out to “Dance, monkey, dance!”

A word of advice to those of you who “don’t speak Web”:

I recognize that you don’t speak Web. I respect you for your expertise.

I do speak Web. Bring me your problem, then please stand back while I solve it.

A word to my colleagues and clients who do:

I promise not to bullshit you. If I made a decision based on my own preference, I’m not going to pretend I’ve got market research to back it up. But if I can back it up, let’s be done. We’ve both got better things to do than weaken this product with second-guessing and amateur input.

When everyone is steering, no one is.

When Wikipedia begins an entry with This article has multiple issues you know it’s not a cut-and-dry term:

Semantic Web is a term coined by World Wide Web Consortium (W3C) director Sir Tim Berners-Lee[1]. It describes methods and technologies to allow machines to understand the meaning – or “semantics” – of information on the World Wide Web[2].

I’m not going to reproduce the whole article here. Wikipedia would apparently appreciate your input.

Here’s my breakdown:

Semantic Web = automated connection-making.

There’s a lot of techno-babble in the mix (which, I have to admit, I kind of get off on), but when we break it down, that’s what we mean by Semantic Web: digital content that an automated service can crawl, make sense of, and connect to other digital content.

Semantic Web: Good Shovel, Not the Gold

As the “resident expert” (my expertise is relative to the context of my residency, I know) on Oracle Universal Content Management, I have a great appreciation for the technical groundwork that goes into developing for Semantic Web opportunities: metadata setup, HTML5, etc., etc., etc. It’s a beautiful Web we weave. But that Web still hangs on communication. Semantic Web is just another good shovel. Intelligible, relevant content is still what we’re digging toward.

Rachel Lovinger of Razorfish recently posted a presentation, There’s No Semantic Web Without Content and Data, about Semantic Web and intelligent content strategy.