INTERACTIVE AXIOM #3 : Embrace The Limitations
INTERACTIVE AXIOM #3 : Embrace The Limitations
EMBRACE THE LIMITATIONS OF THE TECHNOLOGY
Arguably more commandment than axiom, this was, and still is, the most often repeated, most useful, and most practical axiom to come out of my years in interactive development. One might’ve called it “Embrace the way of the medium” but that does not honor the challenge in interactive where the technology - the very medium itself - constantly changes.
Embracing the limitations of the technology - as a fundamental part of your creative concept and execution - will make your work look, behave, and function better than the vast majority of the world's web sites, apps and other digital executions.
It requires that you follow these basic steps:
a. Set the Bar High
Before you even begin approaching development, you must first prepare to judge your eventual work, your project, with a high, medium-agnostic, qualitative bias. You must demand and expect intentional grace, beauty, and perfection in the work that manifests through it, regardless of the medium it exists in.
You must never, NEVER, offer up the technology as an excuse for less than intended perfection. I often hear my contemporaries saying "Check it out, that's pretty good for the web!" Such a forgiving qualifier as "…good for the web" was never tolerated by Red Sky creative directors. Either it was excellent, relative to the best work anyone could find in any medium, or it was bad. The medium's unique weaknesses had to be irrelevant when judging a project's quality. If the work didn't present itself with medium agnostic perfection, it was considered flawed. That's a damn high bar today. And I can tell you it was a damned higher bar in the 90s. I still encourage my creative teams to work in other mediums every chance they get. Among other things, it keeps you objective. Keeps you from falling into the excuse trap.
b. Identify the Limitations
As project concepting is about to begin, you must first fully understand, internalize and accept the technology's strengths and weaknesses. And don't be fooled, identifying technical strengths Vs. weaknesses is a tricky art-form itself. One must go to great effort to distinguish between mere capabilities and strengths. Often the developers of a new technology will be quite excited by aspects of their new updates and tools. And if you are correctly approaching this evaluation with your medium-agnostic glasses on, you will - rather often - not be as excited by it yourself. Creators of the new tool will hyperventilate that it does X, Y and Z. But you then must decide that it does X well, but actually does Y and Z rather poorly. This is a difficult discipline to learn. It's so easy to get caught up in the hype and novelty of some new function or feature. Weak creative teams jump on these new updates and technologies because it seems novel, exciting and fresh. But this is a junior mistake. Your concept must be exciting and fresh, and technology is irrelevant there.
(Related Axiom: Don't mistake technical advancement for creative solutions)
To facilitate this step at Red Sky the creatives and engineers (teams that critically shared a common language, having worked together on many projects previously - this is key) would often sit down before project work was to begin, solely to explore the technical landscape in detail. These were a dialogue between the creatives and the engineers that would typically start with the engineers showing freshly researched tools and features that they thought were exciting and relevant, and the creatives asking a lot of questions aimed at finding the stress points. These questions would usually result in the engineers having to do some digging - some testing of the tools - to find where the tools would choke. Naturally this is how we identified the current state of LIMITATION relative to our creative process. As a result of these regular sessions Red Sky's creatives typically had a better grasp of the technology than their creative contemporaries. Where some perhaps didn't code, they at least had a solid gut understanding of the tech that made them easy for engineers to work with at this stage.
Incidentally these in-house sessions were one of the reasons Red Sky utterly ate the lunch of ad agencies who ventured into interactive advertising at the time. Big Ad Agencies were (and most still are!) loathe to hire significant teams of broadly skilled engineers - engineers who don't just work in Flash, say. This aversion to investment in ongoing in-house technical research and development is really the worst position one can take where the technology - the very medium - is a constantly flowing river of "change". Preferring to outsource development, the big ad agencies rarely manage to embrace the limitations effectively, because they don't live with them. They don't understand them. They aren't current.
c. Develop A Concept That Behaves The Way The Technology Does
With the limitations of the technology solidly identified and internalized, you can begin concepting. Every creative has an internal set of filters that tells him/her whether an idea is a good one or not. Now knowledge of those technical limitations and strengths must layer onto the creative's filter stack. If in concepting, the creative team utilizes this knowledge, the final piece will be gorgeous. It's almost impossible for it not to be.
More often, in teams where this process is not practiced (and sadly, that is most of what's out there), you will see oh so common markings. You will see the clear effect of technology that is working too hard to do things it doesn't do well. Long load times, jerky animation, slow frame-rates, ambitious gymnastic interfaces that don't behave well, items that stutter and pop on screen in unintended ways, laggy response to interaction, generally poor behavior.
Embracing the limitations of the technology means that none of this will happen (except through anomaly). The piece will move smoothly, gracefully, and it will be responsive. Frame rates will never be an issue, they will run at appropriate speeds and the effect will be smooth. Any weaknesses in the technology will not reveal themselves.
Here is a very simplistic, literal example.Let's compare two different solutions where dynamic text is in motion.The junior creative imagines some sophisticated, full screen motion graphic - like something you'd see on TV. Sounds exciting and cool. The concept art looks killer, it's beautiful. In production, each discrete frame looks lovely. The engineers and production artists optimize as much as they can, but there is only so much they can do. The concept demands the movement of a lot of pixels. And then it gets implemented. The piece loads slowly. The motion is broad and complicated, and it's running in a browser so it quickly chokes the standard PC system resulting in a frame rate of maybe 10 or 12 frames per second (FPS). The animation therefor appears jittery and staccato - common for the web, but not the smooth, graceful effect the creative had designed. If this animation instance was airing on TV you would assume it was animated by someone with limited skill.
On the other hand, the team that understands the limitations came upon a concept that requires text to be displayed as though it was a neon sign. This art too is beautiful. It's also full-screen. It's photo-real, and once animated the neon pops on and off in a choreographed sequence. One of the letters is even "damaged" and realistically flickers as the neon goes through its cycle. In this case the frame rate selected was 8 frames per second, but you had no idea. Neon behaves naturally at 8 FPS. The team chose that frame rate, but could have chosen a faster one. They just didn't need to because the concept worked hand-in-hand with the limitations.Basically the weakness in the technology is invisible because it doesn't show through the content.
Don't let this simple example deceive you. This axiom works - no matter how sophisticated and powerful your tools are.You may have realized as I did, that really, it's not so much about merely embracing limitations - only the negative - as it is embracing the full, true condition. Strengths as well as weaknesses. But I have found that developers have very little trouble embracing technical strengths. That all too often we do that to a fault as we will embrace all advertised features, strong or weak, as strengths. When that happens we are rather embracing the promise of the tool - as opposed to it's actual state. So I have found that focusing this axiom on the limitations ultimately results in better work.
Lastly - this axiom is unique among my other axioms in that it can be applied to virtually all aspects of development. And maybe I'm taking it too far - but "Embrace the Limitations" can even be applied to any aspect of one's life and work. I have no doubt there is some Zen teaching that puts this axiom to shame where living one's life is concerned - but it continues to inspire me to problem solve in all aspects of my life none-the-less.