Simplicity Rules

When creating products, feature creep is the usually slow process by which additional complexity is added. It is not intentional, but it is normal. And it doesn’t stop at your projects, either. It infiltrates your life, creating personal feature creep.

Rather than additional functionality, personal features are usually commitments we’ve made, or ventures we’ve taken on. In fact, that side project with its own feature creep might be contributing to your personal feature creep. As with creating real products, making your life the way you want involves questioning what’s necessary.

Zen Habits has a post on how to fix feature creep in your life, with a four step program:

1. Start from a blank slate.
2. Only add the features you really use and love.
3. Slowly implement the reduction in the code of your life.
4. Avoid future feature creep.

The process is similar to one of the two simplicity paths: build up from the core. And, though it’s twice the number of steps, my fix feature creep post can also be turned toward your own life. For example, “research before committing” is probably a good way to avoid finding yourself with responsibilities you don’t want.

The full Zen Habits post is worth a read, as it provides practical advice for each of the four steps.

Hat tip: Valerie Yakich

Nine months ago I stared at a blank page in Open Office. I was excited and overwhelmed to be starting my first book. I had a publisher and had cleared my schedule, but I was beginning to realize that was the easy part.

What follows are the lessons I’ve learned so far getting to the first complete draft.

Write Every Day

The most common writer’s maxim turns out to be true. Writing every day makes it a habit. Once writing became part of my routine, I ensured that I could take advantage of a powerful force: the large accomplishments that come from the compound effects of daily progress.

I was also greatly helped by continuing other writing. My productivity spiked once I had daily posts to log with Programmable Web. The outcome was contrary to my initial thinking, but daily accountability helped cement my routine. Plus, blogging works the writer’s sprinter muscles. I was able to write more, faster.

Don’t Quit Your Day Job

My original schedule had me finished with the book by May. Like most estimates, it was overly optimistic. But I had yet to learn an important lesson about my brain. It wouldn’t let me write for more than three hours per day, maximum.

Truthfully, some of my most productive writing days were over within 90 minutes. Writing a book is both a marathon and a sprint. It requires a series of short bursts of energy over a long period of time. The best part is that when my writing was done for the day, there was time for other projects. And whatever part of my brain controlled writing wasn’t used in programming or event organizing.

I wish I’d realized writing did not require a full day sooner, because I could have been easier on myself. If I write another book, I’ll do it alongside other projects. You do not need to clear your schedule or quit your job to write a book. To start, you don’t even need a publisher (remember, that’s not the hard part). Just write it.

Make Time For What’s Important

You can accomplish any large task if you consistently make small amounts of time for it. In The War of Art, Steven Pressfield described the things that keep you from forward progress:

“The secret that real writers know that wannabe writers don’t, and the secret is this: It’s not the writing part that’s hard. What’s hard is sitting down to write. What keeps us from sitting down is Resistance.”

I read Pressfield’s book, on my friend Kareem’s recommendation, in the middle of my writing process. Because many examples involve Pressfield’s life as a writer, it resonated on that level. It also reminded me of side projects that gather dust un-launched. We all have them. I believe writing a book is an excellent practice and can give you the encouragement to execute any idea.

My friend Tom recently begged readers to stop talking and start doing. “Just decide what you want to do and work your ass off doing it,” he says. It’s easy advice to give, but it’s even easier to ignore.

It turns out that writing a book–or finishing whatever project you have–isn’t hard to do. Just follow this simple list: 1. Start working on it. 2. Keep working until it’s done. If it really is important to you, the continued effort will be well worth it.

Blogging became popular because tools made it easy for anyone to write on the web. Type your genius into a box, hit a button and the whole world can see it. Look out, I’m doing it now.

Now we have many choices when it comes to expressing ourselves online. Yet, the strange thing is, it’s getting harder. The tools are trying to do more and, in the process, forgetting the one feature that made them useful.

Adam Mathes has a fun overview of blogging text boxes, where he shows the current interfaces of popular blogging software:

The primary purpose of blogging software is to blog. This entails the writing and publishing of short form content. Everything else is, basically, noise. Even if you don’t subscribe to a viewpoint that harsh, posting something should be the primary action of the software and treated as such. This appears to be a radical notion, given their interfaces.

The only blogging service that includes a full posting box on its main logged-in screen is Twitter. WordPress (which I use for this site) is a close second. It contains a “Quick Press” option, though it is only a tiny version of the full editor.

Times have changed significantly in the ten years (!) since Blogger was launched. I mentioned earlier that there are many new ways to create content. Similarly, there are tons of ways to digest it. The blogging ecosystem has moved on from statically-generated HTML files. In addition to sharing thoughts, bloggers care about comments, trackbacks, pings, feeds and traffic analytics. It’s a more complicated landscape with more complicated tools.

That’s no excuse, of course. Mathes is right that blogging should still be central to the software. Times will always be changing and nice-to-have features will always come along. You have to keep your eye on the original focus, stop feature creep and find a way to make your site fit into today without forgetting the entire reason you built it.

It’s not often that an account signup process on a website makes me happy. This happened today and I would love to share it with you.

I was covering MapQuest’s new directions API for ProgrammableWeb. Like most API providers, MapQuest requires developers to register. I thought I might have signed up, but the first username/password combo didn’t take. So, I decided to create a new account.

When I did, I was prompted with the following message:

“That email address has already signed up for an account. Would you like to have your password reset and your welcome letter resent?”

It’s a tiny change from the usual that makes a big difference. Most sites would simply present me with an error about an email address already being in their system. Maybe I’d be given a link to the forgot password screen. More likely I’d have to hit my browser’s back button, then find the form myself.

MapQuest has shown its developers understand the flow of interaction in that situation. It was just a login screen, but they put in that little bit of extra effort needed to make it work.

Login screens have been a common topic at Simplicity Rules:

• Adobe’s Hybrid Login/Signup Screen
• Band-Aids Only Hide Boo-Boos

I just returned from a cruise to Alaska. We made a quick swing through Victoria in Canada, which required the cruise line to collect my passport information. Like many people who find themselves with rare travel to another country, I just recently renewed my passport. That ended up being a pain using the site’s calendar-based date selection.

Using their widget, I painfully scrolled through the months. I clicked on the year and scrolled forward, three years at a time, to 2019, when my new passport will expire. It’s a Tuesday, if you were wondering.

Providing a calendar to make a date selection is useful when it’s sometime in the near future. In that case, it’s easy to scroll to a few short months away. In this situation, it’s useless.

I’d rather see month, day and year dropdown boxes. Or, even a text box that looks for the formats used by most passports (I had it in front of me to type in its info, of course). Anything other than scrolling through ten years into the future.

It’s been awhile since I added any functionality to the WifiPDX site. With the release of the third generation iPhone OS, I decided to add some geolocation capabilities to finding Portland WiFi.

Now when you search for hotspots, you’re automatically taken to your list of nearby locations if you have one of the following:

• Firefox 3+ with Geode add-on
• Google Gears
• Firefox 3.5
• iPhone OS 3.0

I explained iPhone geolocation in a post on my book blog.

We’re all creating a lot of content these days. We write blog posts, share our location, store links, microblog on Twitter, and more. Others can see the latest stuff, subscribe to updates in RSS, and view individual chunks of content.

In many cases, seeing old content in context is difficult. I can look at one blog post from a year ago. I can’t get from there to the posts the author wrote immediately prior or after. Most blogs are set up with an expectation that the most recent content is the most important.

New stuff matters most, but old stuff also matters.

The problem of context becomes larger with microblogging. The timeline shrinks. “Old” becomes hours, or even minutes. Understanding a single tweet sometimes requires the context of knowing what was said in the previous tweets.

For example, say you stumbled into this message:

What is Chris talking about? Wouldn’t it help if you were able to see his previous message, which mentioned he wasn’t going to wear trousers all summer?

Flickr does this well. Every photo is shown within the context of when it was uploaded:

We see an after picture. What’s it take to see the before? A single click on the thumbnail. And if we need more context, we can click browse and be taken directly into that photo’s spot in the stream.

I understand that providing context is a secondary job for lifestreaming services, which are so focused on what’s happening right now. But as long as the content is available, it will be indexed and users will become confused if they can’t figure out where they’ve landed.

How can you provide some context on some of your site’s more buried pages?

Photo credit: Bill Jackson III

If you’re lucky enough to have a Chipotle near you, chances are you already appreciate the simplicity of their menu. There are only a few ingredients, so there are only a few options (okay, well technically there are over 60,000 different combinations, according to Chipotle ). Taco Bell, on the other hand, keeps inventing new words to describe the same few ingredients.

Dustin Curtis notices the same thing about the In-N-Out Menu.

(Yes, this is from my 2007 Ignite Portland talk, but it never made it into a post until Mike Duffy pointed me to Dustin’s)

When I spoke at the first Ignite Portland, I said simplicity is two-fold. It’s about making things easier on your users, but it’s also about making things easier on yourself. When you’re lucky, you get to do both at the same time.

That’s the case for Ken Anderson and Janice Flint, husband and wife owners of Crystal Springs Software. Ken left his job at Adobe after 21 years to found the company, which makes iPhone apps. Its first product is an addictive little game called iZilch.

I’m sure Ken and Janice have many great iPhone app ideas, but they started with a simple dice game. The rules are straight-forward, so there weren’t a whole bunch of features to add before they were able to launch. They focused instead on finding the core. Although, Ken says it’s not quite as easy as it looks:

“Since it is a dice game, we focused the user experience on the dice and how you interact with them.  You drag the dice with your fingers to score.  You roll them by shaking the iPhone… All this results in a very transparent user experience, a game that sweeps you up and moves you along… It is actually a lot more work to design software this way, though the scope of this project is still small.”

Ken and Janice chose to focus on creating a few polished features instead of a whole bunch of fluff that doesn’t flow. Even better, they were able to get their first app out in just a few months. That’s counting the time it took Janice to learn the platform.

All the while they were creating the simple life they wanted while raising their four teenage daughters. Their primary goal was not to cash in on the riches of the iPhone platform. The objective was a lifestyle change. Ken says he misses some parts about working for Adobe, like having hundreds of people focused on the same goal. But, they’re enjoying their work, even if it is a little different:

“As an Indie developer, you have to do everything yourself, and you can’t do all of the traditional things that a big company does to make a product successful because you don’t have the resources.  Hopefully, we will be able to hang in there, build great products, figure out how to let people know about them and grow a sustainable business on our own terms, but it will take some time, and like iZilch, some luck.”

My friends at Wired are on their side. Chris Anderson wrote a cover story this month about The New New Economy, where there are more companies, each with fewer people. An old BestPlaces joke was that we only had a handful of people because in big companies, there are only a few people who really work.

In Crystal Springs Software we see two people choosing a simpler life and creating simple software. If this is the future, we’re doing pretty good.

It’s easy for technologists to get lost in the technology. We’re around it so much, we start thinking like technicians.

Sitting at my favorite tea house the other day, I was picking Andy’s brain about memcached, a back-end technology that’s really beyond the type of web work I usually do.

It turns out that what I thought was complicated is really rather simple. At least, it seemed that way after I read the caching story:

“Two plucky adventurers, Programmer and Sysadmin, set out on a journey. Together they make websites. Websites with webservers and databases. Users from all over the Internet talk to the webservers and ask them to make pages for them. The webservers ask the databases for junk they need to make the pages. Programmer codes, Sysadmin adds webservers and database servers.”

No, this isn’t a story that makes memcached accessible to the complete newbie. For a programmer who normally stays away from sysadmin tasks, likely a common memcached user, it’s spot-on. The story gives a perfect use case, adds personality and takes me quickly from knowing next-to-nothing to almost being able to implement it myself.

Other Open Source projects could stand to learn from this. Heck, so could any technology that requires documentation. This stuff isn’t just for marketers.

What do you wish came with its own story?