Take a moment and recall the last time you spent a lot of time working on a new feature for your piece of software. An app, a website, whatever. You spent a lot of time on it. Sweated. Bled. Argued. Fought. The feature is ready to go, and you’re ASBOLUTELY SURE that customers will love it.

Your app has some pretty prominent real estate dedicated to showing what it can do. Both a home screen/page and some sort of navigation bar/panel/element thingamajig. Those two places list all the important places in the app of which this new feature is of course one. That real estate on the home screen and the nav bar is expensive. Think Boardwalk and Park Place expensive. it’s pricey because it’s prominent and there’s not much of it. Just like with real world real estate, “location, location, location”, and “real estate is the one thing you can’t make more of”. But price be damned, this feature is the second coming of the savior himself, and deserves a spot right up front. After all, how will anyone know about it if you don’t tell them? Fair enough.

And then, the unthinkable happens.

Nobody uses the feature. Well… almost nobody. Turns out the customers loudly requesting the feature for the past year are only 2% of your customer base. Or even 20% of your customer base. Either way, it doesn’t matter. You’ve now dedicated permanent real estate to exposing a feature that the vast majority of your users aren’t interested in. No amount of beating them over the head with the feature is going to get them to use it.

Now fast forward several updates and you’ve overloaded that permanent real estate with more and more ads for all the new features you got excited about in each release. That space is so crowded that putting anything there has increasingly diminished value in terms of letting users know about it.

Why not just remove the link or button if most users aren’t using it? Because you’ve already taught that 2%/20% of your customer base where to go to find it. And they will scream bloody murder if you bury the entry point and make it harder to find. Remember, it’s so easy to add things to a user interface and almost impossible to remove them. Therefore you must be parsimonious about making additions.

What to do… what to do?

Well… and this takes courage… how about not putting the feature into the permanent prominent navigation affordances of the app until you know that a) the vast majority of your customers will use it, and b) your customers aren’t finding it effectively in whatever secondary place you’ve advertised the functionality?

Some will argue… “Hey, if you don’t prominently promote this new feature, then nobody will use it. It’s a self-fulfilling prophecy!” And they’re kinda right. Customers won’t use a feature they don’t know exists. But customers also won’t use a feature they don’t want to use even if it’s staring them in the face 24 hours a day.

This is why you need a relief valve. Ad space essentially.

In your permanent prominent real estate create one piece of programmable content. (By programmable we mean like a TV network programs tv shows and ads… not programmable as in coding.) That’s your internal ad space. You can rotate things in and out of that space to your heart’s content. You can pick and choose what to promote based on what’s important to you at the time. Or even based on your user’s preferences or behaviors. If a feature fails to catch fire? No harm no foul. You promoted it, not many folks used it, and you didn’t clutter your main promotional spaces with something that can’t be removed. And if it does catch fire you can decide whether making it more accessible will increase engagement or ease-of-use for your customers (or not).

Your precious prominent permanent real estate is a limited commodity. Treat it that way.

Human beings learn with all their senses. When it comes to decoding a user experience, we can only really on sight, sound, and touch (which I’ll use as a proxy for interacting with the interface itself). But for some reason, many tech folks these days believe that if a user can’t understand your user interface instantly and completely from sight alone then you’ve failed to make your user interface intuitive.

What’s wrong with letting a user play with a user interface a bit to learn what it does?

Could someone who’s never seen a car, but understands its general purpose, walk up to one and start driving? Some trial and error would probably be essential.

Of course, with software user interfaces we’ve trained users that the consequences of a misstep are almost as bad as they would be making the wrong choice in a car. Isn’t that our fault for making unforgiving software that punishes the user for trying things out?

Making intuitive software means making software that works the way a user would expect. It doesn’t mean that the user can instantly parse a user interface without pressing any buttons and know exactly how it works in detail. Software is expected to help us perform complex tasks. And sometimes it takes time for users to get “comfortable behind the wheel”.

And that’s ok.

Done right our software should be explorable. And pressing the wrong button shouldn’t result in a fender bender (or worse).

If you’re going to be an advocate of creating singular user experiences, it is important to have your bearings — know what came before you.

Before the first Macintosh arrived in 1984, graphical user interfaces were in their fetal form. Text interfaces were the norm. And consistency was nowhere to be found. Arcane commands and procedures ruled the day. And we liked it that way. It made us feel special that we knew how to view the file directory, and other people didn’t.

Then the Macintosh arrived. A common language with which to interact with the core functions of software was its gift to our industry. Pointing, clicking. Windows, menus. Selecting and operating on selections. Icons. Folders. The metaphorical language as well as the guidelines telling you when to use what verb, which noun, set the stage for Windows, and the next 10-15 years of software user interface development. The changes were so transformational that their benefit was undeniable. Only the crustiest of technologists lamented the loss of their clubbiness and branded these new GUIs as for simpletons only.

The icons got more colorful. The windows got bevelier (yes, we know that’s not a real word). And the menus got overcrowded. But ultimately not much changed, until the web.

The web introduced new tools in our user interface arsenal — most importantly the hyperlink, the back button, and the ability to update your software instantaneously for all your users (whether they like it or not). The first two were important extensions of the core language introduced to the masses back in 1984 by the Mac. The third enlightened us that it didn’t take 6-12-18 months to improve a user interface. It could be done instantaneously — for everyone. But beyond these three the web gave us an additional gift — it smashed our assumptions about how consistent our user interfaces really needed to be.

Up until well-designed web pages started showing up in the wild, the keepers of the User Interface fires would rely primarily on consistency and rules to maintain quality. But the web was out of control. Anyone could make a web page, and did. And while lots of web pages were ugly, or hard to navigate, some where beautiful, and compelling, and strangely, the human beings that used them were able to learn how to traverse these pages all by themselves. They didn’t need to be retrained. They didn’t need complex manuals. The web delivered user interfaces where the number of elements that needed to be consistent were much smaller than we’d been taught was necessary. And it didn’t seem to be a problem. The previous overly expansive focus on consistency now seemed foolish. (Hobgoblins, small minds, etc.)

This was more painful than you might think. Because the old guard was made up primarily of technologists. Technologists didn’t just love consistency for consistency’s sake, they loved it as it mirrored their understanding of the technology they were building from a code perspective. Engineers look to reduce the amount of code in their programs. They try to reuse pieces of code over and over in similar situations in their apps. Similarly, engineers try to reduce the number of concepts in an app. The remaining concepts form a framework that they teach to the user. The thinking goes, once the user knows the framework, they can accomplish anything in the user interface. This isn’t wrong so much as it is overdone in software. Humans don’t always perceive very similar tasks as similar at all. Sometimes they need things to feel different even when an engineer’s logic would dictate a more efficient path.

But even scarier, it wasn’t engineers that were creating all those inconsistent web pages, it was designers. And the engineers didn’t do themselves any favors. Designers were learning HTML and CSS and able to generate web pages without the help of an engineer. This was the beginning of the end.

The end result of the design vs. engineering conflict over user experience was never in doubt. The technologists with perspective switched sides and realized the benefits of the new approach. They would become amateur designers on their own, or professional ones in some cases. They would co-opt designers to join their teams (even if only temporarily). And ultimately, the combination of designers and technologists who saw the future started defining success as more than consistency but as usability. The seeds were planted in the early 90′s but the web really accelerated the ability of people to start designing software around humans, and the way they actually used the software, vs. the code and the functionality it expressed. Usability was core. Human-centered design was here to stay.

These new goals around discoverability, time to task, task completion, and general usability gave us engineering-like metrics we could use to start to measure our software experiences. This was sound thinking, and a great way to get the stragglers on board with the “new way”. We could measure user response to our software in scientific (or what seemed like scientific) ways. We could tell you which user interface was better. Definitively. And this was good. Measuring how users interacted with our software was and is a good thing. And yet, something was missing.

In the mid-2000′s two things happened. The first modern web browsers arrived with client-software-like user interface rendering capabilities. And, high-powered mobile devices (smartphones and tablets started to arrive) with powerful user interface rendering capabilities as well. All of a sudden the main places users would be experiencing our technology had very powerful capabilities when it came to delivering dynamic and engaging user interfaces. The designers had even more tools at their disposal. But the complexity of these new platforms meant that the engineers had to be more involved.

But something else mattered also — brand.

The notion that software not only could be, but definitively was an expression of the brand, the identity, the raison d’etre of a business, was something new. It had been staring us in the face for years. For years people’s opinions of Microsoft were formed by the multiple hours a day they sat in front of Windows (and much less so by the minutes per year they sat in front of Microsoft’s advertising). This was true for every technology company. The hands on user experience was core to the brand impression the company made. But this was almost invisible to many of the companies who created that technology. Apple had understood it for years, but (as usual) they were among the exceptions.

But just as big brands had heavily designed websites, they charged into apps with the same zeal for making a brand impression. When it was mostly websites that were getting this treatment, the notion that software was a brand expression could be dismissed. After all, “those websites are just ads. They’re not really software. They don’t do anything.” And while there are many apps that really don’t do much, brands started creating apps that did things. Now it wasn’t just the design that reinforced the brand, but the functionality itself that said something to the user about the company supplying the app. Companies were realizing that they could connect with their customers by providing software as a service that actually did something. And that getting users to use your app actually mattered. Not only was the fear of inconsistency a thing of the past, now it was imperative that your app actually stood out. It was imperative in a sense that your app be INconsistent.

Now that having software be desirable and creating an emotional connection with users were goals, how do you achieve those goals? Even if you built an app that was intuitive, appropriately consistent, measured high in usability tests, it might still leave users cold.

So here we sit, in this brave new world, where we must adhere to the lessons we learned in the 1980′s about appropriate consistency, the lessons we learned in the 90′s about updating our software regularly and not over-doing consistency, not to mention some ways to measure our effectiveness. And we must not forget those lessons all while we’re absorbing the teachings of thew new Millenium around how emotion, and perception, the way customers feel about our software, will ultimately dictate how successfully our technology performs in the real world.

It’s a lot to juggle, and yet, it’s the state of our art.

Sometimes it puzzles us how low the bar is among many software industry professionals. And while the current average quality of software experiences is an improvement over decades past, it seems that the highest aspiration for many software designers and technologists is to make their apps and web experiences… “usable”. Usable means many things including simple, intuitive, forgiving, etc. And these are important things.

To us, aspiring to make your software usable is like aspiring to make the food your restaurant serves not poisonous. Usability for your technology is the absolute baseline. And the fact that it often goes unachieved is great in terms of job security for legions of software professionals. But it’s not great for customers. It’s the bare minimum. Perhaps there should be a software “health” inspector?

The space beyond usability centers around the emotional experience of your software. This feels fuzzy to many people but it’s simple. Beyond usability lies vast opportunity to create an emotional experience with your customers. What will you say? How will you make them feel? Every time your user engages with your software they are reinforcing their feelings about you — the software’s creator. Whether it’s you personally, or your company, your user is forming and hardening an impression of who you are. Your marketing, your name, your logo, your customer service all play a role, but the odds are that the majority of time you spend with your customers is through your technology.

What are we really talking about here? Your brand.

Your brand is not your logo. It’s not your domain name. Or even your user interface. Your brand is the set of values that resonate with you and your customers. To put it even more simply — your brand is comprised of the reasons you come to work every day. It’s the passion and love that you pour into your software creation.

In our food analogy, your food is so much more than not killing you. Frankly, it’s more than it tasting good. The best food is one that sticks with you, in your mind (not your stomach). A meal you remember. A dish that conjurs up positive emotions and memories. That’s the food that you want to eat again and again.

And if you don’t care about your creation with that kind of passion, your customers will know it. It can’t be manufactured. It can’t be faked. It’s who you are.

Usability is the baseline. Your values, aspirations, and dreams are what fills the space above.

We live in a world of faceless corporations. It is so easy to forget that real people are behind that phone you use, that cup of coffee you bought, that car you drive. And that’s because companies work hard to carefully project a tailored and filtered image. People are generally not tailored or filtered. (Hence how hard it is to be a politician.) People are imperfect, say the wrong thing, look the wrong way, etc.

And yet… it’s those imperfections that make us human. Relatable. Real.

At some point in your user experience, it’s important to put the real people who created it right in the software. There’s no better way to humanize your software. Your technology is an expression of your hopes, desires, aspirations, and dreams. Putting yourself, the real you, into the experience (even in a small way) is a real advantage in forming a relationship with your audience. One that will last, and will ultimately help you stand out from the competition.

Periodically I see mail from people looking for a job. Often it’s more of a general call for work (rather than a specific request for work at our little startup). And often, the people who are calling for work declare their undying passion for user-centered design. They go on to talk about how understanding the user is the most important factor in creating great software, and how vociferous their support is of said user during the development process.

I don’t care what your role is (i.e. developer, designer, tester, etc.). Everyone should be a user advocate. Everyone should have a common bar for the caliber and quality of the software the team is delivering. Everyone should understand what it means for their end product to be “on brand”. And everyone should be able to balance that with the realities of the business and software development.

Declaring yourself as the “user advocate” can lead to four difficulties:

1. It assumes the worst case by default – nobody else on the team us a user advocate (which of course they should be).
2. It pre-supposes that you come into the team better at something than any of your new teammates. (Likely, you don’t.)
3. It absolves you of other responsibilities and perspectives on the team (or at the very least gives others the impression that you’ve absolved yourself).
4. And worst of all, it can absolve other team members of being user advocates in their own right.

Until every single member of an organization (from development, to sales, to tech support and beyond) is focused on the end-to-end customer experience of a product (whether it’s delivering software or gas) the experience is never going to be great.

I recognize that a significant number of software development teams are still technology rather than customer-focused (whether they realize it or not). I also recognize that a non-trivial number of the teams who declare themselves “user-focused” are no such thing at all (at least in practice if not intent). That said, while I may be out of touch with the rest of the software development world, to me when someone declares their passion for users as a software developer it’s like humans declaring their passion for oxygen. Yeah, we’re all big fans.

Many words are thrown around by user experience professionals to describe what they consider to be the keys to superlative software design. “Simplicity” and “intuitiveness” come to mind. We like both simplicity and intuitiveness, much as we like motherhood and apple pie. But there are less glamorous aspects to a user experience that are fundamental to making it a positive interaction.

Coming up with the “one” most important item in any category is often a difficult task, but when it comes to this category, If I had to pick a #1, it would be “responsiveness”. There is nothing more frustrating than a software user interface that doesn’t respond to a user’s request in a timely fashion. Forget whether it’s simple. Forget whether it’s intuitive. It can be ugly. It can be old. It can be downright rude even. But being unresponsive, being slow, is unforgivable.

What do we mean by unresponsive?

The user clicks a button expecting something to happen. Whatever needs to happen is taking a while. This is reality sometimes. The user has asked for a particularly large data set, etc. But even if the user must wait, the user needs immediate acknowledgement that something has happened. Without acknowledgement the user is likely to click again (and again). Often less forgiving pieces of software will initiate several requests simultaneously for the user thereby delaying all of them.

Whether the user is scrolling, or closing a window, or opening a menu, or navigating to somewhere new, instant gratification is always the minimum bar.

Obviously just getting the user what they want immediately and without delay is the optimal experience. But responsiveness is about the user feeling in control. Without it, the user feels controlled, frustrated, and no matter how great a job your software does, you have someone who is using it begrudgingly. Don’t bother spending money on designing a great user interface if responsiveness isn’t already in the budget.

In the left-brained world of software development all problems are nails, and logic and reason are the hammer. It goes something like this:

We’re building a new piece of software. We should understand who it’s for so we can build the thing they want. How can you know what to build if you don’t understand the person you’re building it for?

And in essence, this is correct. Knowing the needs of the audience who’s problem you’re trying to solve can be a big help in building the right experience. But therein lies the rub. When understanding the dreams, motivations, and fears of human beings that are not ourselves, are tools are woefully crude. More often than not, whatever tidbits we do glean about our audience are just that — scraps, fragments. Certainly not a complete picture. Even worse, we have no idea how heavily to weigh these factoids, and we have essentially no idea how large the space is that remains undefined.

But in a world where people are clamoring for logic and reason as the basis for decisions, we’ll base our choices on the data we have. Is this really any better than flying blind?

Matters get even more complicated as the value of technology is now no longer just about its functionality but also about the emotional connection it makes with the customer. Worrying about an emotional connection is usually reserved for products of the arts. But software too is now subjected to this dimension. Who is the target customer for the TV show 30 Rock? Would knowing anything about what elements bind the show’s audience help the writers make it funnier? More interesting? Would the creators of the program have been helped by speculating about their target audience in advance of their first episode? Possibly creating a mock persona of the 30 Rock audience member? This is not to say that there aren’t things that bind the audience of the show — mostly their appreciation of Tina Fey’s sense of humor. It’s just that what binds this audience doesn’t really help its creators make a better experience.

Here’s the difficult truth. The customer for your new piece of software is… YOU.

It has to be. There’s no other person you can know.There’s no other person for whose feelings you can really intuit, their dreams, what makes them tick.

Once a product exists, once a product is in production, then you can shed your burden. Then you have real customers. You can find out who they are. You can watch them use your product. You can ask them questions. But until your software is in use, by real people, in non-contrived environments, the customer is you. Whether there are other people who share your feelings and values about the product your building, and will pay to user it, is another matter entirely.

Software is a conversation with your users. And yet historically, the “person” talking to you when you use most software is a passive aggressive asshole.

Let’s take one of the simplest examples, present on thousands of forms across the world wide web – the submit button. Submit. How does that make you feel? Is the software talking to the user? Is the user talking to the software? Is barking out a terse ‘submit’ ever a nice thing to say? (Don’t answer that.)

Confusingly, language is an incredibly powerful AND weak tool in software user experience design. Google built its ad business based on text advertisements, not the flashier graphically heavy display advertising. Headlines on blog posts make all the difference in the world when it comes to enticing someone to click. And yet, we know that most of the text found in software user interfaces simply isn’t read. Users are perpetually scanning, skimming, and jumping around trying to do the least work possible to understand how to accomplish their goal.

Let’s listen in on the traditional thinking:

A concept is hard to explain to the user with only a self-evident user interface? No problem, just put it in the user manual. And as for the user… RTFM!

But…

…manuals are now extinct. So when we have something that’s hard to explain, how about putting in a bunch of explanatory text? The user will read the text in the actual user interface and then understand the complexity of the software.

But we know users won’t read it, and will be confused, so what is the answer?

The answer is the respectful helper.

While depending on the brand of the software experience the voice of a piece of software can vary to a certain degree, the baseline to start with is that of someone friendly, but not overly familiar, and ultimately there to serve – an incredible server at your favorite restaurant perhaps? There when you need them, gone when you don’t. Not overly familiar, but definitely putting you at ease. Efficient in language — definitely not verbose. And ultimately focused on serving the user effectively without being overly familiar or chummy.

Some thoughts on language in software:

• Coherence. Whatever your tone is, it needs to carry throughout the experience. On your website, in your app, when someone talks to tech support, in the marketing materials, and even when watching a demo at the trade show booth (or whatever it is people do instead of trade shows these days). Your software, your company needs one voice. One coherent voice. If the ads speak in one voice, and the product in another, your customers will experience the cognitive dissonance of realizing their date doesn’t look like the picture in the person’s dating site profile. Nobody wants that.
• Friendliness. Walk the line between informal and overly familiar. There’s no need for ma’ams and sirs when it comes to software text. But, being too friendly makes people uncomfortable. And ultimately, software is someone you work with — occasionally, not a member of your family or a boss. Say please and thank you.
• Brevity. Your users don’t read. And even when they do, they don’t comprehend. Not because they lack reading comprehensions skills, but because they have better things to do than read your essays explaining the complexity of your software. If you need to “explain” something with a paragraph of text in the user interface, you’ve already lost. The less text on the screen, the more chance they’ll read what remains. Edit edit edit.
• Testing. Test that text. When it comes to driving users to act. There’s really no better way to know what users will respond to best than testing a few options. That headline, that subject line, that link text, that text ad, can all be tested. Whichever drives the most customers to take the action (and be happy they took it) is the right line. Some people are better than others at writing text that drives action, but nobody is a perfect predictor. Testing trumps all on this one.

If all this is too much, do this simple test. When you write a piece of text for your user interface, say it aloud. To another person. Seriously. Are they annoyed? Do they want to punch you? Are their eyes glazing over? If so then you need to rewrite that text or get rid of it entirely.

In fact, let’s summarize this entire piece of advice. To quote a famous Rabbi out of context, When it comes to using language in software user experiences, “that which is hateful to you, do not do to your user.”

There was a time (and in some people’s minds that time is still today) when people thought of software as a spreadsheet, or a word processor. Or in most cases, with normal human beings, software was something made by geeks that doesn’t really affect their lives in a day-to-day fashion. And even though those of us in the technology field know that software permeates and brings to life an increasingly larger percentage of the hardware we use every day, we have often treated software as a narrow silo rather than the unique and increasingly universal canvas it has become.

Historically technologists have viewed software as distinct from content. Software solves problems, it does stuff. Content is created by writers, musicians, filmmakers, et al. It is consumed. The narrative tells us that engineers create software to help those creative types create more content. They create software that authors, edits, displays, and shares that content, but the software itself is distinct from the content.

The dictionary is helpful in illustrating the out-of-date (and narrow) view:

soft·ware /ˈsɔftˌwɛər, [sawft-wair] –noun
General expression used to describe a collection of instructions enabling a computer to solve one or several tasks.

The first crack in this definition was the web itself. At first most people considered the web browser the software and web pages the content. But as web pages became more sophisticated in functionality, the distinction lost its usefulness. Compare Microsoft Excel vs. Google Spreadsheet:

Even though designers have gotten more involved by virtue of the fact that many people feel that web pages need to be “designed” unhelpful distinctions still exist. Let’s look at another example: what’s the difference between these experiences?

Or these:

Or these:

The movie isn’t interactive while the game is. Does that mean the movie isn’t software? The map and the video game are almost indistinguishable from each other. Newspapers are still printed on dead trees but they still have a user experience, and you can still interact with them.

Most software professionals are allergic to (or in the some of the best cases not steeped in) the techniques that are used to create compelling content. Content doesn’t wake up in the morning thinking about how to be useful. Content isn’t trying to solve a problem. Content is born to make you feel something — to elicit an emotional response. Content is trying to tell you a story. It is this purpose that needs to take its place alongside functionality and usefulness as core to every piece of software we create.

The line between software and content isn’t just blurry, it’s completely irrelevant. But its continued existence makes many technologists eschew the foundational design and storytelling techniques that are critical for making great user experiences.

Every new idea in the modern world, every new initiative, just about every effort, public or private, personal or business-related, includes some form of digital expression. Software is the medium for that digital expression. Today, software is everywhere, whether we know it or not. Not just on our computers, our tablets, our phones, and our gaming devices (which could all be the very same object) but in our cars, in traffic lights, and in our thermostats. And in the future, this pervasiveness will only increase — dramatically. Imagine a world where every surface (and plane) is a potential display. Software is the primary language of the digital world we are creating.

Whether it’s a birthday party requiring invitations, selling a house and advertising it on a web page, a new business, a new non-profit, a new curriculum from a third grade teacher, they all generate a need for digital expression. And that digital expression is more often than not sloppy, unfriendly, dumb, and in many cases… insulting. Whether the person with the idea is writing new software from scratch or using existing software to create a digital experience is irrelevant. The time we spend interacting with these creations is only going to increase. And the need for modern and talented technologists and software designers who share a holistic perspective on making these experiences positive has never been greater.

Software is the ubiquitous and universal medium that blankets our exponentially expanding digital world. More software is coming — whether we like it or not. The only question is whether any of it will be any good.

Yesterday I posted a story about an interaction I had with Bill Gates when I worked at Microsoft.

The gist was that some* engineers overapply the thinking they use in coding to user experience problems and that it results in overly abstracted user interfaces that don’t relate well to human beings who are not as neatly organized and categorized as some of the code these engineers produce. And right on cue, some folks who disagree with me made comments that illustrate my precept (or theirs depending on how you feel about the point I was trying to make).

“I’ve worked with designers who justify making multiple interfaces for similar functions. Frankly, this approach is almost always wrong and results in confusing interfaces and repetitive, difficult to maintain implementations. Simplifying an experience to it’s essence and ensuring that users learn quickly through consistency is key to design.”

“The author of this post strikes me as the bad sort of designer, one who views design as anything other than engineering and who justifies bad design with tortured “emotional” arguments.”

“Giving analogies mean 2 things: Either the receiving person is stupid or the one giving the analogy is bad at expressing his ideas.”

“too bad you spent all the time worrying about the design instead of securing the system. with all the malware attacks – beginning especially in the early 2000′s – the poor quality of windows products pretty much turned them into expensive toilets.”

“You have correctly identified the analogy fetish as a weakness. In UI design there are few facts and alot of preferences. If you dont have a black and white answer besides your taste, you cant expect anyone to follow your lead,”

“Bill was right. You sound like an artist, not a designer. Someone who could create beautiful objects and design simple interfaces, but has no clue about how to much engineering and deduction really is essential design. I learned my lesson working on interfaces with designers who think every situation requires a tailored interface. While correct in rare, highly explainable situations, this attitude is almost always to the detriment of quality and experience.”

“It was rude and I think you added nothing with your analogy. Apple may be able to find some work for you to do though.”

These are generally the people I avoid working with — we just view the physics of software design very differently.

* Let me be clear — I have been fortunate to work with several incredible software engineers who either understand how to balance engineering realities with the softer science of software design, or understand how to partner with talented designers to create something great — together.

There was an almost interminable pause in the conversation, as Bill thought about what I had said. And then he looked up at me after some processing and exclaimed: “That’s just rude.”

~ ~ ~

In November of 2003 it was my job to get Bill Gates on board with the new designs my team had planned for the Windows user interface. I’d been in countless meetings with Bill, and already knew that I wasn’t great at convincing Bill of much. When it came to discussing the user interface of Windows we generally spoke past each other, which didn’t make sense to me then, but makes a lot of sense to me now.

The currency of the software industry, an industry that Bill Gates had a large hand in creating, is the engineer. Software gets built without executives, without marketers, without designers, and without accountants. It even gets built without testers. But it doesn’t ever get built without engineers. Bill is the ultimate engineer. Back in the 1980’s when graphical user interfaces were new and shiny, Bill internalized many of the lessons that made those original GUIs work. Concept reduction, consistency, skill portability, were all core to how to make a great UI. Why have 17 different ways to pop up (or drop down) a menu? Why have 17 different graphical treatments? With “one menu to rule them all,” users could learn how to use the menu once and then apply this knowledge anywhere they saw this affordance. That way, developers don’t have to reinvent the wheel, and users don’t need to relearn the wheel.

And this is still a sound fundamental principle of user interface design.

But engineers (like everyone) see the world through their lens. Engineers look at code all day. And when they see two pieces of code doing roughly the same thing, they immediately think about ways they could eliminate the wasted effort by combining them into one piece of code that performs both functions. And often, when coders participate in UI design, they make the same observations, and can overdo this principle.

Additionally, though it’s uncomfortable for the left-brained among us to discuss, another one of the fundamental aspects of today’s state-of-the art user experience design is to focus on how the software makes the user ‘feel’. You can imagine how popular a fuzzy notion like this is in a company (and industry) where empirically -minded engineers and their fans are running the show.

Just as I’d known it before all my previous meetings, I knew that Bill didn’t love my fuzzy notions about what makes for a great user experience. I’ll also confess at this point that I have a personal weakness when it comes to beautiful analogies. I overestimate their power to get people excited about ideas in which I’m invested. They’re certainly effective, but perhaps not to the degree that I imagine.

Back to my meeting in the board room with Bill Gates, and the 3 or 4 executives between he and myself in the Microsoft org chart. While the actual specifics of the day’s discussion are lost to history, I do remember clearly that we were debating the merits of my team’s user interface designs for powerful new data management features in the Windows Explorer. From my perspective, Bill’s preferred direction was overly abstract. We had created a compact set of tools to help users manage their files and folders where we felt we’d balanced the “learning curve” that comes with anything new with the way human beings actually think about things. Bill felt that we could reduce the concepts much further, thereby easing each user’s learning curve, and ultimately making them more powerful as they could employ this learning across a wide variety of scenarios. Cue my “beautiful” analogy.

At one particularly frustrating moment, I offered the following: “Bill, a shower, a toilet, and a water fountain all have mechanisms to control water flow, places where the water comes out, some sort of porcelain basin to hold the water, and a drain, but we don’t combine them into one thing to reduce their learning curve. We don’t merge them into one object because each of them are in use in fundamentally different ways at different times.”

Then the pause.

Then Bill’s verdict.

Ouch.

As I saw my career disintegrate before me, I started to question just how “beautiful” my analogy really was. To his credit, Bill was forgiving, and met with me many times after that, giving me numerous opportunities to get him on board with all manner of ideas coming from my team (with varying degrees of success on my part). Ultimately, I never did succeed in making Bill really comfortable with a more emotional approach to software design. But the real lesson of the day was learned. In the software industry, as long as the engineering-minded run the show, the notion of subtle and textured user experience design that balances the emotional and functional aspects of a software experience will always struggle to take root.

Five years ago this week I left an incredible job at a great company to co-found my own business with Jenny and Walter — Jackson Fish Market. Leaving the security of a big company and a job that most people would kill for was incredibly counter-intuitive. And building your own business is way way harder than you may imagine. The press loves to talk about amazing success and spectacular failure, but people who are plugging away building their businesses one (virtual?) brick at a time do so mostly outside the spotlight. Luckily, there’s no magic to this effort of building your own business. Every time I learn a lesson (which I do almost daily) the inevitable conclusion is that more hard work is required. And that’s something I can do.

But the question still remains, why leave the great job at the big stable company to work your ass off in anonymity with no guarantees of ever recouping your lost wages? There are many reasons people give for this, but I’ll give you mine, and it’s the same as the day we started JFM five years ago.

Anyone familiar with the innovator’s dilemma knows that companies who’ve achieved incredible success doing one thing have trouble shifting gears. And in my experience, conservative thinking, and those who come up with reasons to say no are the ones who are trusted to be in positions of responsibility. Nobody usually gets fired for saying “no” to a risky idea. There’s almost never proof that it was the wrong call so there are almost never any consequences to folks who say no. And as a bonus, saying no makes you seem more like a grownup at a big company. Big successful companies like people who seem like grownups. After all, the company has a franchise to protect. You don’t put people with wacky ideas in charge of protecting something valuable. And in truth, ideas are a dime a dozen, so why not have some grownups there to weed out the good from the bad? The thinking is sound on paper.

In running my own business I have learned that the only way we make progress is by trying 100 things. For every 100, 2 usually show some promise. We then come up with 100 new ideas based on the learnings of the 98 failures and of the 2 modest successes and try to make some more forward progress. This is an awful lot of work, but there’s no magic to it. And that’s reassuring as I never got an owl from Hogwarts.

But at most big successful companies, where your job is to protect the franchise, trying 100 things and having 98 of them fail is career suicide. In fact, investing in only 2 ideas and having 100% of them show only modest returns is a “career limiting event”. The internal ecosystem is brutal. And if you don’t have a runaway hit out of the gate, your project is usually done. Interest flags, and the project is tagged as failure. Nobody wants to be associated with it. So let’s say you even manage to get your idea going internally, there will be an endless amount of people tweaking, tuning, and “improving” your idea to make sure that it has the best shot of success. And this is important, because inside the big company, the perceived cost of failure is enormous. (Whether the real cost is so large I’m not entirely sure.) And because everyone is so worried about failing (or as they put it – “giving your idea the best chance to succeed”) the amount of time the company invests in your idea goes up. As the investment goes up, so do the stakes. And the cycle reinforces itself.

This cycle is familiar to many. But here’s what I consider the worst part. The point of trying things even though most of them will fail is to learn something, iterate, and keep trying. By the time the original idea has been through so many cycles of peer and executive feedback, it usually is so far from what the originator conceived that the only thing they learned is not to let people fuck with their ideas anymore. And not because the idea would have been successful. But because at this point, they haven’t learned anything. At the end of the day, the originator keeps saying to themselves, “if we’d just done this the way I conceived originally, maybe it would have been successful”. Maybe it would have. Maybe not. But at least there would have been learning.

I left the generosity and stability of a large successful company so that my failures could be my own. I geniunely want to be good at what I do. The only way I know how to improve is to learn from my mistakes. But they must be my mistakes, or I’m not learning. Thanks to the incredible patience of my business partners, I now learn on a daily basis. Creating your own business is treading water in a sea of failure until you’ve built something small that can float. I’m so grateful that I’ve had the time and latitude to build our cozy little rowboat called Jackson Fish Market. Don’t be surprised if after a few thousand more failed experiments it turns into a pretty nice sailboat.

So many times, when designing a software user interface, it’s helpful to ask yourself if you would enjoy interacting with a human being who talked to you the way the software did. If the answer is “no” then you have more work to do. Inevitably, this exercise gets turned on its head when user experience experts spend time dealing with actual human beings. Is my call to the sales or support staff of a company any less of a user experience than my interaction with their website or their app?

But often it seems like there is even less care given to the experience customers have with live human beings at a company than the interaction they have with the software. Nowhere is this more evident than the incredible aversion that many customer service personnel have to saying “I don’t know.” – which for bonus points can be preceded by “Good question.”, and followed by “Let me find out for you.”

I don’t think someone is dumb, or a company is awful when someone doesn’t know an answer to one of my questions. What does make me borderline insane is when they try to bullshit their way through an answer that I know is simply not true. And of course, once they start down this path, things can only get worse. If I gently give evidence that their answer is without a doubt wrong, it just makes them stick to their guns even more. Now that they’ve claimed to know, the only course of action is to back up their claim at all costs. And now, for disagreeing with the “expert” I’m the asshole.

Attention customer service departments and any business group that has people speak or interact with customers in any way. Rule #1 should be, it’s ok to say “I don’t know.” The customer may not get their answer immediately, but at least they won’t be subjected to some nuttiness that just wastes their time.

And while we’re at it, Rule #2 should be: if you ask a customer for their credit card number after they just typed it into their phone, you should be shot.

That is all.

There’s something about this trailer for GTA V that amazes me. It’s not that the graphics are higher resolution or more photo realistic. They’re not. I’ve seen new games recently that look much more realistic. Especially when it comes to the people. But the world illustrated in this trailer is amazing nonetheless. It just feels realistically alive. There’s a shot of a guy just crossing the street at the 0:54 second mark that just feels flat out real. I think this shows that there’s more to making a realistic virtual environment than pixel density.

I have always considered myself a video game nerd. I grew up with an Atari 2600, an Atari 800, a Sega Genesis, a Dreamcast, a Playstation, and both Xboxes. I also played games on Macs, PCs, and even spent many hours of my youth playing games in actual arcades. Pretty typical for many guys my age and background. Over the last 10-15 years something happened that put me further on the periphery of gaming. I don’t know if it’s the nausea I feel playing first person shooters, or just my lack of interest in blowing shit up, but most games seemed not for me. More recent games that I have loved included SimCity, Age of Empires, Escape Velocity, World of Warcraft, Diablo II, Railroad Tycoon, Torchlight, Lego Star Wars, etc. I know there’s some mayhem in these games, but each of them has an emphasis on collecting things, building things, or exploring things as well. Those are the things I enjoy. (And in the interest of full disclosure, I’ve spent plenty of time playing Angry Birds, Bejeweled, various Scrabble games, and more.)

I have not played Farmville or other games of that ilk. I get uncomfortable spamming my friends (unless it’s something I’m selling), and paying to advance in a game (rather than to unlock new content) feels unfun to me.

When I first saw Tiny Tower I was enamored of the 8-bit graphics, the jazzy soundtrack, and the memories it brought up of one of my favorite games of yesteryear — Yoot Saito’s SimTower. It was free in the app store. I downloaded it to my iPad and started playing. The goal of the game is to build your tower with a mix of residential and commercial floors, keeping your ‘bitizens’ employed in jobs they like and are good at, and keeping your commercial ventures stocked with inventory and making you cash to spend on more floors. There are plenty of artificial delays built into the game that you can skip by spending some of the ‘TowerBux’ you can earn (or purchase via in-app purchase).

I’m no expert on game mechanics and psychology, but I know enough to know that while levels usually require progressively more investment, they also yield progressively more exciting rewards. Not so in Tiny Tower. The only thing that appears to increase in Tiny Tower with each level is the amount of time you have to spend to get anything done. Now… I understand why this is. They’re hoping at some point that I reach my breaking point and give in spending actual dollars in exchange for TowerBux that I’ll use to accelerate my progress. My pain increased exponentially while my rewards moved linearly. A very different dynamic, despite which I achieved 100 floors in Tiny Tower (evidence below) without any in-app purchases or cheating. (I also had 164 of my 182 Bitizens in their dream jobs at this point.

When my wife and I used to play lots of Age of Empires she would invariably look up the cheat codes. Driving her huge American car all over the maps and shooting anything that moved was fun for her. But for me the cheating was a novelty but not fun. And it was only something I chose to do after I’d exhausted the gameplay. She went straight to the cheating. I’m not making an ethical statement (it’s just a video game) but I really can’t distinguish between the Age of Empire cheat codes, and the TinyTower in-app purchases (or buying black market gold for WOW for that matter).

I understand that this is where the money is these days in games. And the number of people who would pay 99 cents (or even 199 cents, or — amazingly — even 499 cents) for a Tiny Tower that was tuned for regular gameplay is probably dwarfed by the number of people who want to pay to get ahead. I wonder what would happen if they made two versions. One for people who like to work/play hard to earn achievements, and another for people who like to pay their way to the front of the line and see which one makes more money over the long term. In my version the developer could even use the in-app purchase system to let me buy access to a second tower, or other cool features.

Here’s my prediction (which of course is worth what you’re paying for it)… paying to advance in games is clearly popular (even though I find it decidedly unfun myself). And while I understand that it’s letting companies like Zynga essentially print cash, I think it’s got a short shelf life. Just as it seems consumers are getting bored with daily deals, I think they’ll get bored with games that are just designed to inflict pain in exchange for actual cash. Well… I hope that’s the case. Otherwise, i foresee even fewer video games in my future. (Maybe we’ll have to make some games just to have something enjoyable to play.)

Recently I saw an article about a new startup called Small Demons. The premise was vague, but had something to do with the publishing industry. Being interested in publishing I signed up to be notified of their launch. Today I went to their website and was introduced to their premise of cataloging real world details mentioned in books and visualizing the connections between them. OK.

Cataloging large amounts of data with interesting connections and visual representations is always a fun user interface challenge. There are usually lots of opportunities to do something interesting with the UI. And the video (starring ubiquitous hipster startup video spokesperson whose name currently escapes me) doesn’t disappoint. Well, at least not at first. The video is set in a room full of books with our friend slowly explaining what the site does. Details from books are flying out of said books in 2.5 dimensions. UI is hanging in the air and sliding all over the place. Very creative. Lovely and inspirational aesthetic. On point and well done.

Our friend is grabbing details from the air and using them in real life. Really fancy.

And then the UI of the actual experience makes an appearance. What a fucking disappointment.

Hey there boring grid on white background. Nice to see you… AGAIN! There’s nothing wrong with a grid or white background per se. But where’s all the inspiration from the UI that was in the video? Where’s the aesthetic? (Or any aesthetic?) Where are the small details that reinforce why I’m on this site passionately combing through the “Storyverse” as they call it. The people who made this video clearly understood how to articulate the passion behind the site in a visually expressive and inspiring form. Could those people have not been used to design the user interface that the users would actually use? It’s like the difference between the picture of the steaming, delicious, appetizing, tasty burrito on the box of frozen burritos and the actual mess that comes out of my microwave.

No. I don’t expect the service to deposit me in a 3d virtual world where i can wave my hands Minority Report style and navigate their interface (grabbing items from the virtual world into the digital world in the process). I’m sure there are lovely and smart people working on Small Demons and I wish it nothing but success, but this just seems like an opportunity lost. I would have hoped that the folks at Small Demons would see the contrast between the aspiration articulated in their video and their UI and realize that quite a bit more “special” was called for to deliver on the promise they made.

Perhaps in v2.

Two years ago, we launched an online children’s book service called A Story Before Bed. The service lets parents, grandparents, teachers, authors, and even kids record videos of themselves reading a children’s book that can be played back over and over again. We’ve been lucky enough to work with some amazing children’s book publishers who’ve put their books up on A Story Before Bed including Charlesbridge, Soundprints, Orca Book Publishers, Chronicle Books, Sourcebooks, Immedium, and more. It’s possible that being around all those great children’s books inspired us to create some of our own. Or maybe we just always had it in us and needed a venue to express it. Either way, in the course of creating A Story Before Bed, with an amazing team of authors and illustrators we’ve hand-crafted almost sixty children’s books. And while we’ve talked about it informally, we’ve decided to officially launch our publishing imprint — Jackson Fish Market Books.

To celebrate the launch of this new venture, we’ve decided to do something a little different. We’re taking our entire catalog of books, and making them available for download completely free for non-commercial use. Kids, parents, grandparents, teachers, librarians… go crazy. Download them all. They’re all completely free.

Expect more creativity from Jackson Fish Market books in the coming months and please spread the word that all the books are free to download right now.

Every year at the beginning of October Seattle sees the advent of one of the biggest Lego conventions in the country. And each year lego hobbyists (like me) start working months in advance on their Lego creations to display at the convention. Enormous spaceships, moon monorail layouts, entire cities, castles, sculptures and more fill every bit of surface area. This year I decided that my Lego creations would be collaborations with each of my three children. My 10-year-old son Sivan and I decided to build a miniature Lego arcade cabinet. But what to do for the actual game? Instead of building a screen out of Lego we decided to use an iPad as the arcade monitor. And on that iPad we would have a game. A game made entirely of Lego. Not just for display, but actually playable. And then we decided that the game would be good enough to actually put up for sale in the app store. And thus Lila the Ladybug was born.

The characters on the top of the cabinet are the actual Lego we scanned in to make the characters in the game.

Clearly this was an insane idea, but once we started there was no stopping us. We started with the game. It was originally going to be Frogger, but with a ladybug. Cause… well… ladybugs are cute. But that turned out sucky. So we shifted gears and created something a touch more original. Sort of a Centipede/Kaboom combo starring our adorable ladybug… Lila. And while most ladybugs do eat aphids, some are veggie eating leaves and mushrooms and avoiding raindrops that can derail them from their munching progress. The game is targeted at little kids which is only fitting since a 10 year old did a bunch of the programming, designing, and building.

Lila the Ladybug is available for iPad and iPhone today in the App Store. Sorry, the Lego Lila arcade cabinet is not included.

In case you were wondering… my collaboration with my 8 year-old daughter Bella was a reproduction of Nathaniel Currier’s 1846 lithograph of the Boston Tea Party. And my 5 year-old daughter Rakefet and I built a modular princess castle based on the Jonathan Coulton Song, The Princess Who Saved Herself. Maybe next year we’ll do some games based on those.

As you may know, Jackson Fish Market is a bit of a hybrid business. We’re a software startup with products like A Story Before Bed and Thrilled for You, but we also have a user experience consulting side that helps other companies make their software special. We’ve worked with dozens of companies and are proud of all our collaborations. We also are wary of taking more than just a smidgeon of public credit for the results. While we are proud of the role we play, there’s a lot of work on those apps that goes beyond our design efforts to bring them to market.

But, we’re going to show off a little bit more than usual when it comes to the new eHarmony app for iPad. We’re proud of the work we did providing a deep set of initial designs for their app. But, the eHarmony team took the ball and ran with it. No… they sprinted with it. Not only was it amazing for a successful business to come to us with such open minds and hunger for innovation, but they took the work we did it and made it way better. They executed our contributions beautifully, but took them to the next level as well. Various transitions and animations are fantastic. Navigational systems were extended with style. And small touches of personality (make sure to tap the coffee in the coffee cup on the opening screen) are pixel perfect (not to mention adorable).

Even if you’re not looking for that perfect partner, I highly recommend you download eHarmony’s new app for the iPad. The screenshots below just don’t do it justice. This is an example of a next generation user experience that can’t be ignored. And here at Jackson Fish Market, we’re very glad to have played a small role in helping make it happen. Bravo eHarmony team.

There aren’t many things more enjoyable than the surprise learnings you get from shipping a piece of software and seeing how people actually use it. We created A Story Before Bed to connect families, but were surprised to see just how useful teachers and educators found the service for use in their classrooms. Imagine letting kids record books at school and then watch the recordings at home in the evenings with their parents?

With difficult budget situations across all 50 states, school teachers are finding it more and more difficult to do their jobs every day. For that reason, A Story Before Bed is giving away 100,000 free recordings to teachers for use in their classrooms. Please help us spread the word.

Teachers can sign up here for their free 2 month subscription to A Story Before Bed. It gives them unlimited recording of 50 pre-selected books from our catalog. And even once the subscription expires they can keep all the recordings they’ve made.

If you know a great teacher, we’d appreciate you letting them know so they can take advantage of our offer before we run out. Thanks!

We’ll be talking to the makers of TinyTower about their unlicensed use of our images.

Jared Spool recently posted about “Why the Valley wants designers that can code.” Basically, he makes the good point that hiring managers at startups are always looking for ways to get more value for their dollar. And so based on that understanding he recommends “If you’re a designer, you don’t have to learn to code. But if you do, and you get good at it, you’ll find more opportunities as time goes on.” And in this he’s right. But of course his comments would be just as valid if he wrote a post titled “Why the Valley Wants Marketers That Can Code.” Or Engineers that can write press releases. Or any other combination of useful skills.

Except… the Valley doesn’t want marketers to write code or engineers to write press releases. Because, they don’t trust marketers to write code, and they feel that writing press releases would be a waste of the engineers’ valuable time and skills.

So what’s the real reason that many companies look for designers who can code? Because fundamentally they don’t understand and therefore properly value what great software designers do.

Spool says: “If you’re in a room filled with designers, bring up the topic of whether it’s valuable for a designer to also code. Immediately, the room will divide faster than Moses split the Red Sea. One side will tell you coding is an essential skill, while the other will vehemently argue how it dilutes the designer’s value.” If I’m in a room full of designers and any of take either of these positions, then I’m in a room full of designers I would prefer never to work with.

High quality software designers are true singer-songwriters. They can deliver a combination of interaction and visual design that don’t just make a product shine, they make the product what it is. They create its essence, its DNA. Should they have deep empathy for the software development process? Yes. Should they understand technology and be “technical” to a degree? Yes. Should they have passion for software as their medium? Yes. Much like a designer focused on print projects should understand how various ink/paper/press combinations will impact their final product’s design as well as cost, software designers should understand the canvas on which they are painting. But do I want a true software designer spending time fighting the various inconsistencies between browser CSS implementations to get the UI perfect? Nope. It’s a waste of their time. They should be doing more designing.

(If you’re annoyed by the previous paragraphs, this next one will make you crazy.)

Are there true singer-songwriter software designers that can write high quality code? Yes. But they are the exception. Anecdotally, I’ve found that most (not all) “designers” who can code are in fact coders who have empathy and passion for design, and may even have some good interaction design chops. But often they are weak when it comes to visual design. In our left-brain dominated industry, visual design is often looked at as fluff. Often people will say things like “art is the last step” or “that’s the lipstick”. I believe that when you treat the visual elements as some sort of layer of paint, then all the visuals can be is a layer of paint. And I believe that most “designers that can code” aren’t really designers at all.

The worst part is that design schools are complicit in this misunderstanding of what software designers should do. They’re busy teaching HTML, CSS, and Flash (yes Flash) to art students as if these skills are mandatory for them to succeed as high end software designers. These potentially talented software designers have an allergic reaction to spending their careers writing markup instead of drawing and decide to focus on “print”! Print! Pardon the profanity, but… WHAT THE FUCK??? The most incredible canvas in the world for designers — software — exists, and needs them. It lets them combine text and images and video and audio and user interaction in incredible ways, but they want to go make business cards and annual reports. Our industry needs a fleet of talented software designers and design schools are failing to produce them.

At some point, we will have more than a smattering of true software designers in this industry. They won’t be employees either. They’ll be founders and co-founders. And their companies will produce beautiful usable products that stand out from their competitors. And some of these designers will even be able to code. But we won’t let them, because we’ll want them spend every minute designing beautiful software.

A note: I’m sure that some of you will take exception to this post. Many of you will be annoyed because you either subscribe to the notion that designers should code and that it’s a good thing, or that you are designer that writes code and you are annoyed that I question your visual skills. Understood. I hear you. Please know, just because someone doesn’t fit the model of the designer I think we should be replicating, doesn’t mean I think they aren’t a valuable contributor.

And finally, some of you may criticize me and say that it’s easy for me to lobby for this model for software designers when my co-founder Jenny Lam exemplifies it. And to that I will say… you’re right.

When we started building A Story Before Bed in late 2008 there was really only one place to have customers record videos of themselves reading children’s books – inside a web browser on a PC or Mac with an attached webcam. So that’s the path we pursued. But a year and a half later when the iPad was announced, we realized immediately that there was no better device on which to record (and watch) yourself reading a bedtime story than on a bedtime computer. And while A Story Before Bed is definitely a positive experience on a PC/Mac with a webcam, the cuddle factor is decidedly low.

While the first iPad didn’t have a camera (front-facing or otherwise) we knew that it was only a matter of time before it did. We worked hard over the past year to slowly bring the functionality from the web app to our iOS app until last Sunday night we submitted version 2.0 of our app to Apple. And now, if you have an iPad2, you can:

• record any of 350+ books right into your iPad2′s front-facing camera and mic (just the 3 freebie books if you’re not a Mega subscriber)
• have those recordings sync back to our website so anyone with a PC or Mac or with any of the Apple mobile devices (iPad1, iPhone, iPod Touch, etc.) can watch the recording
• and of course sync recordings made on a PC or Mac down to the iPad as well

Record from anywhere. Watch from anywhere. Everything synchronizes beautifully. It just feels… lovely.

I mistakenly thought that when we launched our service in November of 2009 that it was ready to show people just how magical this scenario can be. We had a lovely launch and did a good job getting there. But, the service we have now is so much more mature, deep, and ready to really make families happy with the over 350 books (and growing) in our catalog. The journey is definitely taken one small step at a time, but it’s nice when there are milestone moments where you can pause for a brief second and enjoy just how many customers you can now make happy.

OK. Moment over. On to the next round of improvements and investments.

In our efforts to connect with the potential audience for A Story Before Bed, we’ve spent lots of time finding folks online who care about things that A Story Before Bed can help with… like connecting families, and promoting literacy. On the literacy front, these blogs are among the best:

• Educational Technology in the Classroom
• Jen Robinson’s Book Page
• Jerz’s Literacy Weblog
• Literacy Launchpad
• Literacy Toolbox
• The Book Chook
• The PESD Language & Literacy Blog

(currently under reconstruction)

• dot.Learnt

They’re super thoughtful sources of information, and while I haven’t met any of them in person, the authors seem like good folk.

All the more reason we’d want to cultivate positive relationships with them. Instead, I did the exact opposite.

Awhile ago I thought it would be cool to aggregate their content into one source and have that source connected to our children’s book service. I go to their blogs regularly, and know that i often want to see them all together so I can browse that topic in one place. Aggregating feeds of different sources of information is a fine thing to do on the internet as long as you attribute, generously link back, and only post an excerpt – not their entire post. It also helps if you add some value to the post your linking to with some original thought. I screwed up. While we did attribute, and link back generously, we reposted entire posts (not cool to say the least), and hadn’t gotten around yet to getting the site to where it should be which was adding original content and value to their already thoughtful posts. It also helps to ask permission depending on the context. I didn’t do that either. (Strike three.)

When the bloggers noticed (and were rightfully super annoyed) we pulled down all the content immediately. (Deleted!) We also sent out apologies to each blogger (where we had contact info) and offered free subscriptions to our service if they would like. We’re super sorry, and of course will use drastically improved judgment in the future.

The nice thing about the internet is how easy it is to do whatever you like. The other nice thing is how many people will tell you when “ur doin’ it wrong”. Thanks for the course correction, and we’ll work hard in the future to make entirely new dopey decisions and not repeat ones we’ve already made.

We shipped A Story Before Bed, our recordable children’s ebook service back in November of 2009. In the year preceding the launch we spent plenty of time talking to publishers to see if they would license us their books for inclusion in our service. And we did find three intrepid publishers (Immedium, Charlesbridge, and Bubblegum) who were willing to take a chance on us at launch (we’re now up to 350+ books from over 20 publishers). But in the early days, that was far from certain. We worried that we would show up on day one with a great service for recording children’s books minus the actual books.

We may have been naive but at least we were brave… we decided that as a backup plan we should make some of our own children’s books. If publishers didn’t license us their books, at least we’d have a dozen or so books of our own on hand. How hard could it be? It turns out that making children’s books isn’t hard at all. Making good ones however is a challenge.

Lucky for us, our genre of books has a pretty rich catalog of public domain stories and characters that can get you off to a good start. Disney itself started by doing interpretations of public domain children’s stories (and still does). We picked a bunch of stories, hired some writers and illustrators, and set to work. Our results were not bad. And in some cases, they were pretty decent. Our books had some rough edges but they had some cute moments. We threw away the ones that didn’t make our cut, and put the ones that felt professional on our site. And then we realized that because we owned these children’s books we could do pretty much as we pleased with them… including giving them away to get people to try our service. What we had thought was a backup plan turned into an incredible asset. What we thought was a one-time effort turned into an ongoing investment.

A year later we’ve created over 60 children’s books that are featured on A Story Before Bed. Two examples that I’m particularly proud of include Lil’ Red Riding in the Neighborhood – by Aleen Adams and illustrated by Elizabeth Haywood and Snow White in the City by Shanon Lyon and illustrated by Cate Kennedy:

In our early creations I don’t know that we had a perspective or a style other than trying to make them as professional and entertaining as possible. But as with most things, the more you do it, the better you get (and the more opinions you form about how it should be done). I particularly love both of the books above because while they’re based on familiar tales, they feel fresh and modern both in terms of the writing and the illustrative style. Elizabeth Haywood’s illustrations are so striking they could be in a fashion magazine, and everyone falls in love with Snow White’s hair. The creators of Lil’ Red have worked on many more books for us. And I’m proud to tell you that the creators of Snow White in the City have agreed to a two sequel deal… Snow White in the Country, and Snow White in Paris are coming to A Story Before Bed (hopefully before the end of the year).

Our business model is different than most publishers. We have our own distribution direct to consumers, and we don’t really worry about individual sales. Since our business is primarily a subscription business, we mostly care about adding value to the overall offering. The more quality books we have, the more valuable our subscription offer is for our paying customers. Unlike the big publishers, we don’t need a hit book to carry us. We can offer all kinds of books that only a few customer may love. The Raven for example. Not exactly right for smaller children, and with a ballpoint pen illustration style that’s definitely mature. We know it’s not for everyone, but we love it. And we have room to experiment. We’re not constrained by the number of pages a printing press in Taiwan can print books at. We’re not constrained by what Barnes and Noble or Wal-Mart is willing to feature. We’re only constrained by the talent we can find, and our own inexperience at creating children’s books. But we’re getting more experience every day, and finding more talent as well.

And besides… it’s fun.

Right before Valentine’s day we came across an Etsy creator, Stephanie Burrows, who was making cool scientist valentine’s cards. Alan Turing saying “Decode My Heart” and Werner Heisenberg saying “I’m certain about you.” Very nerdy. Very cute. We were inspired. Why not create kids books around these famous scientists. If you’re old enough you might remember the Muppet Babies cartoon on TV. Basically the main Muppets from the Muppet Show but as babies. We have a fascination with younger versions of things I think. (Little Archie, Young Indiana Jones, Superboy, etc.). How about a series of books about scientists when they were kids where their young adventures foreshadow their later discoveries? Not historical fiction exactly. It would be strictly accurate on the science, take some liberties with the story, but keep to the spirit of the character and their accomplishments.

We have done exactly zero market research.

We have done no focus groups.

We have done no competitive analysis.

We just don’t care about that stuff. This sounded like a cool series of books. We would start with Marie Curie. Cause, well, she’s Marie Curie. Now all we needed was a writer. Enter Jennifer Swanson, accomplished children’s writer and middle school science teacher. Here she is in her own words:

Jennifer Swanson’s lifelong interest in science began with her flower collection at 5. Of course, they weren’t in a vase—no– she would take them apart to analyze their insides. Then, at the inquisitive age of 8, Jennifer created her very first science club, right in her garage. Much to her mother’s dismay, Jennifer felt the garage was not the best place for her most valued discovery – a cow skull. Many chemical sets and several science projects gone awry later, Jennifer found herself graduating from the U. S. Naval Academy with a degree in chemistry. After teaching at the prep school level for two years, she decided it was time to pursue her other love – writing. Taking class after class, Jennifer learned to create characters, dialogue and setting. She went on to receive her Masters in Education in K-8 science from Walden University. Her overwhelming desire was to share the fun and excitement of the science world with children. With this in mind, Jennifer took a job with Johns Hopkins Center for Talented Youth as a middle school instructor. In addition to her teaching Jennifer has authored several books, both fiction and non-fiction. Uninvited Guests and Body Bugs will be published by Capstone Press in December 2011. The Child’s World will publish 5 of Jennifer’s books in fall 2011. These books are part of their “How Things Work…” series. When not at her computer, she is out in the backyard, yes, taking apart more flowers.

As you can see, Jennifer was the perfect choice. She’d already written two books for us (both still in production) a version of the Secret Garden on an urban apartment building rooftop, and a version of Aladdin set in an archetypal Disney tween version of high school. We knew she could write and we knew she had range. We were so happy to discover her love of (and expertise in) things scientific.

With that, we’re happy to give you a preview of the first few paragraphs of “Question Everything: Marie Curie’s Guide to Life”. The first book in our new Kid Scientist League series of books.

As a child, Marie Curie was filled with questions.
“Why is the sky blue, Mama?’
“Why does the lake freeze over with ice when it’s cold?”
“Why does the moon light up?”
“I don’t know Marie,” said her mother.
Marie sighed. Her mother never had time to give her a proper answer.

The youngest of five children, Marie was often left by herself. While her older brothers went to school, her sisters stayed home to help with the chores. Since she was small, Marie didn’t have many chores. Instead, she spent her days dreaming about going to school.

Sitting on the grass, Marie would close her eyes and see herself in a classroom, studying science. She imagined that when called on, she could answer every question asked. In fact, her teacher would be so happy to have her in class that he would proclaim to everyone what a fantastic student she was. School would provide the answer to all the questions she had about the world.

It was an impossible dream. At that time, most girls didn’t go to school, let alone study science. Instead, they were taught how to read and manage a household. Still, Marie, had hopes.

We don’t know how long it will take for this one to be finished but we’ll keep updating you periodically as we make progress… sharing sketches, illustrations, and some finished pages until it’s done. As the illustration department gears up on this book, Jennifer is already hard at work on the second book in the series starring a young Nikola Tesla. Electrifying!

(BTW, we’re looking at doing a Kid Artist League as well. Think Picasso and Chagall as kids. And we need an amazing writer with a passion for fine art and artists. Let us know if that’s you.)

I just happened upon an article by Matt Marshall on Venture Beat: “How HTML5 will kill the native app.”

Ugh.

This article reads like an HTML5 marketing document. There’s good reason to be excited about HTML5. But I believe there are a couple of key things missing from this discussion:

1. The value of cross-platform code to developers is a myth. — Yes, many people say they would love to standardize on one platform and write once and save “billions”. But in reality, developers like to learn new skills, platforms, and languages. And clearly having to rewrite code to a brand new platform hasn’t stopped hundreds of thousands of apps getting written for iOS. The best modern developers are well-versed in a variety of client and web-based technologies and platforms, and recognize that one solution doesn’t fit all. And ultimately they, and the businesses that employ them will flock to any platform that has a real promise of commercial success and novel functionality no matter how much new code they have to write. Do we really think iOS is the last time that a new platform will attract tens of thousands of developers to write hundreds of thousands of new apps from scratch? If that’s true the software industry is dead.

2. HTML5 has still not addressed a critical piece of the UX — responsiveness. – HTML5 and it’s predecessor Flash have are not focused on the degree of responsiveness we demand from really polished software. It’s true that in many cases, we don’t need instant responses. And with the advent of AJAX style development web-based apps have come a long way from needing to reload the page every time you make a state change. However, the fundamental value of an HTML page (and app) being able to load progressively is often counter to the type of rock-solid responsiveness that we need from many software experiences. I know that most user’s will live with little delays and not even be able to articulate that there’s a problem. But like the soft click of a door closing on a well-engineered luxury car, customers do know when something just “feels right” (and conversely… when it doesn’t). When I can load thousands of items in a list on a webpage without having to do pagination, when that loading feels instantaneous (even though there may be progressive loading of the data into memory), and when scrolling feels smooth as butter and super fast, then I’ll feel like web apps are getting closer. I don’t think there’s a technical limitation on this per se in HTML5, it’s just that it’s not optimized for these types of interactions. Responsiveness is one of the unsung heroes of a polished user experience, and even with all its innovations and AJAX goodness, GMail can still be frustrating to use for heavy mail users.

To be clear, I’m a fan of HTML5 and here at Jackson Fish Market we will use it as appropriate. It’s a tool, like many other tools in our toolbox. We’ll use it when it’s the right tool for the job. And we’ll use other tools when they are appropriate. The most rational and easy to work with developers I know share this philosophy. I’ve found that developers who like to spend lots of time arguing about which tool is the “end all be all” are doing me a favor by letting me know up front that I shouldn’t be working with them.