Category Archives: Design

Advertising Saturation

I was at a restaurant the other night, and needed to use the restroom. As I was doing so, I could not help but notice that there was an ad in the restroom (for neither the restaurant nor its restroom services). That was a little offputting by itself, but moreso was it’s location: the bottom of the urinal.

Upon further checking (advertising research, not checking bathrooms), it appears this is quite the growth location for advertising — some entrepreneur has even come up with “interactive” urinal advertising. My, oh my.

It got me thinking (no pun intended) about advertising saturation. There has, for many years, been an evolving science of determining when one’s ads have reached as many people as they’re going to. This is the point, it’s theorized, that you can stop spending money on that campaign — to do more reaps diminishing returns.

But what about the saturation to the viewer? It is increasingly difficult to go through a day (let alone a few hours) without seeing ads. Surely this overload of messaging dilutes its effectiveness.

This comes up with our clients regularly. When working on commercial sites that wish to advertise their own wares, or publishing platforms that feature the advertising of sponsors, there are always conversations about placement, frequency, and the balance of content vs. ads. The initial tendency is often to create as many ad placement opportunities as possible — to really “get the message out.”

In our usability and interface testing, though, we find that there is a balance point, after which additional branding and marketing messages simply aren’t seen, and by that time, the effectiveness of the ones that are seen is also diminished. While we haven’t studied the results of our testing over the years, my guess is that the balance point has shifted over the years, as viewers get both more sophisticated and more tired of seeing wall-to-wall selling.

It’s a reinforcement for doing user testing, to be sure. But it’s also an incentive to look at more integrative ways to communicate advertising — and more restrained ways of papering it across the Internet!

The Importance of the Side Project

Every job has its ups and downs, not just the job of elevator operator. (Sorry, old and bad joke.) There are parts of the work that are engaging and interesting, finding answers to problems and implementing those solutions. And then there are the other parts — the prerequisites, the occasional begrudging task.

That’s where the side project comes in. Around our offices, we make sure that everyone has a side project to keep them sharp and engaged, even when the primary project might be a little stultifying. This gives our team members a chance to step away, shift gears, and focus on a different matter for a while.

It’s useful not just to provide a palate cleanser for drudgery. Sometimes, we can get so enmeshed in the norms and expectations of a specific project that our vision begins to narrow. Keeping another project on the side enables us to shift that perspective and keep our sights broad.

For some of our team, it’s a passion project — helping reach out to an underserved community through Internet broadcasting, for instance. For others, it’s a project that might end up being commercial one day, like a new and improved nonprofit management system. Still others combine the two, exploring a recreational opportunity app, for instance. (For one of us, it’s writing for this blog!)

Regardless of the specific project, it’s something we prize greatly, and I think it helps us stay sharp and balanced. Because even with the most fun of projects, there’s always a chance to get sucked in a bit too far!

From Metrics to Meaning

OK, I’ll admit it. I may be carrying around a little more weight than I should. The idea of an elegant dinner out sounds far better than a sweaty afternoon at the gym. But I’m not worried–technology is coming to my rescue!

After all, there are fitness bands that relay all my activity to an intelligent program. There are apps that will track my intake and exercise and help me monitor those metrics. But there’s a key element missing: the meaning.

We’ve all become fond of metrics, perhaps instigated by the lore of W. Edward Deming, who was thought to have said “You can’t manage what you can’t measure.” (Except he didn’t, actually, say that. In fact, his philosophy was quite inclusive, allowing (and even encouraging) people to make decisions that they knew to be right, even if they were unmeasurable.)

But anyway, back to the fitness path. So I get a band, or a device, or an app. Suddenly, I’m getting all of these metrics. I know how much I’m ingesting and how much I’m walking. Why isn’t my behavior changing?

Some might say willpower, some might say that last order of gyoza. But I suspect a leading contributor is the gap between metrics and meaning. There’s a step missing: okay, I know these are my stats, and something’s not working. But how do I get from point A to point B? What do the data mean?

This is not only a health issue, but a larger design one. Every time we show information to a user–every time–we should ask: what’s the context? What does the user need to make meaning of this data bit?

Think about breadcrumbs, as another example. Knowing what page you’re on in a complex website is useful. Knowing where that page fits into the site and your path within it is orientational. It changes one’s experience of navigation.

This is true on the analytics side, too — measuring clicks or session time is a good start. But what is the story that data is telling? Where do you go from here?

Over the last few years, we’ve seen an explosion of the amount of data available. We can measure more than ever before. But it’s not going to really transform us in the most profound way until we get just as good at providing meaning as we are at providing metrics.

In the meantime, it’s almost lunch…

The Evolution of HTML5 (and the Browser)

The grandly-named “Global Developer Survey” was released recently, sponsored by Kendo UI (makers of an HTML5 framework). As you might imagine, it focuses entirely on HTML5, and presents a fairly rosy picture.

They surveyed 5,000 or so developers from around the world and asked them about their use of HTML5 — what kinds of apps they build with it, which parts they use the most, what kinds of platforms they target, etc. Given the sponsor, it’s no surprise that more than two-thirds of respondents believed that HTML5 is important for ALL developers. Color me a little skeptical at that, but we’ll move right along.

But one part of the results that stood out to me was the focus of app development efforts by the surveyed developers: 60% were targeting desktop apps, while 26% were targeting mobile and 14% tablets. When asked what kind of software specifically the devs were building this year with HTML5, a whopping 87% said desktop websites/web apps, while only about half said mobile websites.

This generally tracks web traffic by platform (as of May 2013, in North America, only about 12% of web traffic was from a mobile device), which may make this more ho-hum. But it’s that ho-humness that is surprising. It has only been in the last version or two of most major browsers that HTML5 support has gotten more robust. The majority browser on the desktop, IE, still doesn’t support over a third of the spec! Meanwhile, support on mobile platforms has been more robust for quite a while.

Perhaps this gives hope that with so many HTML5 developers working on the desktop, the desktop browsing environment will get better for HTML5 — and, one hopes, more nimble in general, with the pace of adopting newer standards (3D Canvas graphics with WebGL, anyone?). And there are some signs that this is happening, albeit glacially. Chrome is poised to be the biggest browser on the web in North America any minute now (it’s almost tied with IE as of May 2013′s statistics), although the recent jump in browser share has been so sudden that it’s hard to know if it’s an anomaly.

Kudos to Kendo UI for sponsoring such an extensive survey, even if the participant selection was skewed. It would be interesting to get a more generalizable swath and see if the same desktop/mobile dichotomy holds true in other technologies (e.g., Java, Objective-C) as well.