Your App Needs an Editor | Localtype

Welcome to the moribund Localtype

RSS follow me on twitter

Point Reyes

Your App Needs an Editor

Originally written on: May 15, 2011 at 8:37 pm

Last Updated: May 15, 2011 at 8:37 pm


While the actual quote eludes my Google fu, Coco Chanel once said something to the effect of “Before you leave the house, take a look in the mirror, and take one thing off.”. People are notorious for wanting more, and yet rarely satisfied when they get it. This is made blindingly obvious in application development, where users often have direct contact with app creators before and after the sale. Wanting more isn’t just a user phenomenon. It starts in the application development process. Developers aren’t immune to the siren call of ‘more’ any more than anyone else. We should however, fight this urge if we want to deliver better apps.

All application development starts with an idea. “It’d be cool if there was an app that did…” is the spark that ignites the development and design process. Along the way, more ‘cool’ ideas come up, and often included. The problem with ideas that start with “It’d be cool if…” is that the answer is always ‘yes’.

In a sense, app development is similar to writing a novel. Functions are like characters. Each is explored, and given life. They develop unique personalities, and often, the characters tell the author what they will do next. This leads to a much more robust, believable character, but it can quickly get out of hand. At some point, you lose the narrative. In a worst-case scenario, you wind up with the Homer Simpson Bubble Car — or iTunes.

Like every good writer, every good app developer needs an editor — someone who can take a look at what your app does, redline the hell out of it into a leaner, more coherant story. Nowhere is this more needed than in mobile app development. The most successful apps on a mobile platform tend toward simplicity. They often do one thing, but do it very well. Apps like Instapaper, and Readability are popular for this reason. The limited space provided on a mobile screen demands a level of simplicity and focus. You want your users to launch your app, do what they need to do quickly, and leave your app so they can get on with their lives. Applications that provide this experience are used more often, as users don’t feel the dread of getting mired in the app’s UI or panoply of choices. People use apps like Flipboard because they are delighted by the content they bring.

As an exercise, start with an idea for an app. Take everything away until you have achieved an application that is so minimal, any additional functionality removed would cause the app to do nothing at all. Build that. Ship that. Observe how your users are using the app. Continuously refine your narrative based on observed evidence. The best apps lead users with intelligent decisions made by the developer. Users don’t have time to weigh the impact of their decisions within the app. If you hand them a diner menu of options, they will opt for a black coffee.

There is a story about an architect who built a university. All the buildings were designed and built, but there were no paths to any of the buildings. People couldn’t understand why no paths were built. The architect answered “The students will show us the best paths to make.” After a few months, the grass on campus had noticable wear where the students beat a path from building to building. Shortly thereafter, cement paths were created based on the natural behavior of the students. If they attempted to solve this problem before the students came to the campus, they would have made wrong assumptions. Now, they had empirical evidence on what should be done.

Building a simple app with limited functionality is also a fantastic way to create a solid, bug-free base on which to build. I am not an advocate for no functionality. I am an advocate for smart functionality. I have a rule of thumb: I will only build in a new feature if I think at least 90% of my users will use it nearly all the time. Your users will tell you what they want in an email, in conversation, or in feedback forums. Don’t be fooled. That is the siren song.

Users will show you what they need by hacking your app to meet their goals. Twitter is a fantastic example of this. When it first started, All it allowed you to do is post a 140 character message, and receive messages from people you follow. It was simple and elegant. People flocked to it in droves. There were no @replies, no RTs, no DMs, no Lists, and of course, no Dickbars. @Replies were born out of a need to respond to tweets. It was a convention that users made up themselves, and eventually incorporated into the application. The same goes for RTs and DMs. The one ‘feature’ that wasn’t originally hacked together by users was the Dickbar, and we all know how much of a miserable failure that was.

I’ve seen (and regrettably created) far too many apps that cram far too much into a user interface. We are reaching an age of transparent computing, where content is the most important, access is easy, and the best UI is no UI at all. Build small, and allow for discoverability, serendipity, and joy.




8 Responses to “Your App Needs an Editor”

  1. Furr says:

    I hear what you’re saying – and for some apps, simplicity works, and your example of iTunes as a horror is one I wholly agree with. The problem is when you get into certain areas (word processing is a notorious example) where people will want – nay, NEED – to use a tool differently. Does it make more sense to have a word processor that’s so targeted to profession X that virtually no one else will buy it – or to have one where there are features many people will never use, but the people who need them REALLY need them? College students need footnotes; most people don’t. Lawyers need features that enable the peculiar formatting of legal documents; most people don’t. Hell, WordPerfect is still popular with lawyers because it was the first to make it easy to do the kind of documents they need to create – and for a long time XyWrite was IT for the sciences because of some of its features. 

    Granted, word processing isn’t directly relevant to mobile/smartphone usage, but I can imagine that there might be an application serving the sort of use case(s) where this happens.

    • CM Harrington says:

      Indeed, the mobile app space is a different animal than the traditional desktop computing space. That said, a lot of what I stated can apply to both. 

      Your example of word processors is a pretty good one. My answer to that is to develop a better tool to meet the exact needs of a particular vertical market. Lawyers need to guarantee their documents are in a specific format? Make ‘LawDocs’, and make sure lawyers can use that application to efficiently and accurately do their job (it’d probably have a companion app that was all about search and retrieval). This is different from an extreme example, which would be a bespoke UI

      Another thing that happens is an app grows to have so many features, people use them for unintended (or bad) purposes. How many people do page layout in Word or *gasp* Excel? How awful are their ‘designs’? They’re not the right tool for the job, but they are the tools they know (when all you have is a hammer…). Interestingly, that’s also an example of app hacks I mentioned above. App hacks happen everywhere. Consequently, Apple saw what was going on with Word, and created Pages. It’s actually a pretty good word processor that does page layout right (real story flow, not faked with tables as in Word) without exposing a lot of UI mess in the process. 

      With mobile apps, everyone is starting ‘fresh’, so the opportunity to ditch legacy code, and re-look at problems from a fresh perspective abounds. It’s never been easier to create a niche app.

  2. Anonymous says:

    Mies van de Rohe famously said “Less is more.”  Many years later, Philip Johnson, tired of hearing this architectural truism repeated one time too many, countered “Less is a bore.”

    But I agree that almost everyone loves a clean, simple app and most loathe applications bloated with so many little-used features *cough* Microsoft Word *cough* that they are awkward to use.

    • CM Harrington says:

      If your app becomes so feature-laden that it becomes difficult to perform the tasks the app was originally meant to do, the narrative has been lost. 

      As far as Word goes, the only reason I have it on my system is so I can read the occasional client document that inevitably comes my way. While the alternatives do an OK job parsing the Word format, it’s never perfect, and I can’t afford to overlook client directives.

      Most of my compositions are done in BBEdit, a plain-text editor. I happen to type in a Markdown style, which allows for instant formatting into HTML, which is my usual publishing medium.

  3. James says:

    “Your users will tell you what they want in an email, in conversation, or in feedback forums. Don’t be fooled. That is the siren song.”
    Years ago we were told by a plant hybridizer who had been in our business for ages that if you let the customer dictate to you, you will likely fail. His advice paid in plant breeding and business in general. The idea is to *listen* to your customer THEN watch the actions for information on how to proceed.
    We know many of our customer’s buying patterns better than they do (having 25+/- years of sales records on hand). We anticipate what they will likely need, remind them of previous sales and work like hell to meet reasonable requests.
    I see apps as having a similar DNA. The ones I use most tend to be rather focused and have functions that ADD to a focused task rather than detract or distract. I might *think* x-y-z would help, but rarely would actually use x-y-z.

    • CM Harrington says:

      Anticipation is the key, which is learnt through observation, and experience. 

  4. John W Gintell says:

    “Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. “Antoine de St Exupery. My boss always made sure that was posted on my wall.