Simple, or why companies reinvent solutions

A designer knows that he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away – Antoine de St-Expurey


At work, we are currently experimenting with HipChat.  HipChat, if you aren’t aware, is chat client like IRC.  In fact, the similarities are great.  You log in, you join a chat room, you can talk to people, it keeps a history.  Even there client reminds you of an IRC client.  So the question becomes, in a world with IRC freely available and at your disposal, with MSN and ICQ and various other chat applications available, how could HipChat hope to make an entrance.

Through simplicity.

How does HipChat work? Well, you log into your account, and then you can start chatting away in whatever room you want.  Its contrary to the way IRC works.  With IRC, you have to decide on a server.  Actually, before that, you have to figure out which IRC client you want.  And, of course, you have to learn to use the application.  You probably still have to set up an account on the IRC server (unless you don’t mind not “owning” your name).  Doing this means learning how nickserv works on that network.  Then you have to learn how to join a chatroom… well, it’s annoying.

How does your car work?

Specifically? How do all the computers in your car play a part?  Do you know?  Does it affect your ability to drive?

HipChat works by hiding the complexity.  Driving works because it hides the complexity of the engine and everything that makes it work.  Computers do this as well.  Considering all someone has to do to get a computer and OS up and running is turning the power on, it’s fairly simple from a user perspective.

So, HipChat is successful because it has removed everything unnecessary from the process of group chat.  It doesn’t even require a local client.  You can log in to a website like you do everywhere else and start chatting.  No download required.

One Button

Oddly enough, this is something Microsoft discovered and pioneered before Apple’s iPhone.  Once you started your computer up, there was a button: Start. This made further use of the computer simple.  It was the single starting point, and it even said “Start” so you had a good understanding that whenever you wanted to do something with Windows, you’d Start there.  This of course led to the joke that if you wanted to shut down, you’d want to Start the shutdown process with the Start button.

Regardless, both the Start button and the iPhone/iPad/iPod’s single home button have become popular.  The idea here is removing all unnecessary buttons from the device or system.  The less you have to do, the easier the action becomes.

Less is more, as they say.

Apple took this further with their Magic Mouse.  I’ll admit, I love the little thing.  The combination of a mouse and a touch interface makes it a pleasure to use.  The Magic Touch Pad is also another nice addition.  In this case, there really is no button on the device (that the actual device is an entire button is beside the point).  It’s just flat.


Keyboards are, in some respects, the anti-thesis. It has many different buttons, and modifiers that do different things. Luckily, for the most part, the buttons follow simple rules. The layout is in such a way that makes touch typing incredibly easy.  That touch typing is a skill that’s been around since before computers makes it an easy mechanism to use.  After all, why not build on top of what people already know.  We do this with most calendar applications, which are laid out in a way that is familiar to most everyone.

So, even with all those buttons, a keyboard is still fairly simple because it’s not necessarily attached to the keyboard.  It helps that the letters are printed on the keys in a standard order.  So, because of these simple rules and the fact that their is a history attached to the use of the keyboard, it’s an exception to the rule.  Somewhat.

Virtual keyboards, while following the same layout in most cases, generally don’t share some of the common properties with physical keyboards.  After all, one of the principles of touch typing is actually touching the keys, returning to the home row, and this is facilitated by the little bumps on the ‘F’ and ‘J’ key.  With these, we can easily return to our starting position (And, if you’ll note, on a numerical key pad, you have the same bump on the 5 key).  Virtual keyboards don’t actually have this (despite the “bumps” appearing drawn on.

I’m actually surprised by the number of people that don’t realize what these little bumps are for.

Regardless, people like Swype are looking at ways to improve the virtual keyboard experience.  In Swypes case, while the virtual buttons remain, the actual number of presses are reduced.  You just move the pointer, or your finger, over the keyboard.  This ceases to be a keyboard, and more a drawing tool.

What does this all mean?

I don’t think it’s surprising that simple works best.  Simple doesn’t just mean one button (HipChat isn’t just one button, and keyboards have many), efficiently usable by everyone (keyboards work best when touch typing, but other people can get by pecking along with their fingers), or copying what already exists (after all, the single button approach for the iPhone was completely different from any other phone at the time).

Simple is an odd combination of all these things.  More importantly, it’s about understanding what actually makes things difficult.  Having a common rule for keyboards make them easy to use.  The iPhone copied this style.  All those little apps do something, and they all work the same way.  HipChat works just like any other site.  It’s akin to email, and one of the first things people learn to use is email.  The difficulty in using a smartphone wasn’t the nature of a mobile computing device.  It was simply that applications suddenly had different rules, keyboards had to be modified to account for the size, and they tried to carry over the windows motif from the desktop to the mobile device.  Function keys, modifiers, special keys for different things.

And this leads us to the point: removing that difficulty is something people will pay for.  Keyboards haven’t changed much because the difficult is displayed by the keyboard literally spelling out what each button does.  The challenge now is how to solve the problem of typing on a smaller device.  For the vast majority of users, this isn’t an issue.  They don’t touch type anyways.  However, this doesn’t mean it’s the most efficient way for them.  Swype has one solution.  Apple has another solution: Siri.

HipChat tackled the chat arena.  It was a market that wasn’t exciting from my perspective, and felt saturated.  After all, when you thought about chat, you thought about IRC, and the various clients out there competing for users.  HipChat came in and made a business out of it.

This is important.  When we look for future solutions, one thing we often ignore are the current solutions we use.  Is it really as easy as it can be.  Could we improve on it? What are the painful parts?

It’s not easy to do this.  Google, in some ways, has tried this in the past with things like Buzz and Wave.  Twitter is an example of this same thing: a problem existing, and while solutions existing, they weren’t simplified.  Facebook is the same thing (in some regards).

This all goes back to the Unix mantra: do one thing and do it well.

When I want to run a chat room, I want to run a chat room.  I don’t want to setup a server, or manually set up users.  I don’t want to manage nickserv, or anything else.  I simply want to do something, not manage or setup.  Lots of companies understand this.  Amazon’s cloud hosting services, Netflix and their video streaming, and even Amazon with it’s 1 Click purchasing.

So, don’t be scared to solve something that’s already been solved.  Countless companies have built empires on top of “simply” removing things from existing solutions.

Ideas of March 2012

That time again.  I wrote something last year, covering the ideas of march.  Last year, bloggers came out and shared their ideas, and I imagine this year will be just as fun.  So, once again, I’d like to share my thoughts on blogs.  This year, I’d like to take on the point of view of a reader as opposed to a writer of blogs.  After all, far more people consume blogs then actually write them.

Having trouble keeping up? Share!

It’s hard.  Even with a feed reader, it’s hard to keep up with everything that is going on.  In the PHP world, I can head on over to good-ole PHPDeveloper to find out what is going on in the PHP world, but these days, it’s more than just PHP.  I can of course subscribe to my favorite blogs, but as I said, there is far more out there to read than I have time to enjoy.  Twitter helps some, as I can follow a link from twitter from someone I followed, but even if they post something, I might miss it in the ever moving Twitter stream.

What really helps is when people share.  Between Reddit, HackerNews, people retweeting things they’ve found, DZone, and, of course, PHPDeveloper, there are numerous ways to share.  If you are a reader, and you’ve read something, share it!  A tweet about an article might only bring in a few people, but those are people that might not otherwise have found the article.  Share the article!  Help curate, and get it out there.

That’s something I’m trying to commit to.  And while sharing and those ‘social media’ buttons on articles might seem annoying, they actually serve a purpose to remind us how we get our information.  Just because someone has tweeted an article doesn’t mean his followers will see it.  Too often I find myself following a retweet because I missed the original.

And don’t be afraid to submit to sites like Reddit or HackerNews.  Both are wonderful resources.

Your voice matters

Even if it’s a simple thank you.  You don’t need to spend much time, but every little bit helps.  If you read something, and enjoy it, let the author know.  Nothing makes us happier than when someone takes the time to actually respond.  Not everyone will comment, but getting just one comment usually spawns a few others.

If you are nervous about what you have to say, you can also always send an email.  I think it’s fair to say that unless they say otherwise, bloggers have a standing invitation to contact them.  We’re geeks just like you, and we’re writing about stuff you’re clearly interested in as well, so we already have at least one thing in common.

Read, enjoy

Most of all, and most important, is to read the articles.  Spend time and enjoy them.  All too often we get sucked into the 140-characters or less, StackOverflow-style short answers that let us get in and get out.  I find I enjoy blogs so much more when I just allow myself to read and focus.  I don’t just skim the headlines looking for the answer to a solution.  I sit back with a cup of coffee, and spend a little bit of time reading.  I don’t rush through.  I don’t start an internal debate with what’s being said.  I just read.  I just enjoy.

Too often we allow ourselves to become masters of multitasking.  And there are times this is good.  But we need to learn to shut this off.  Blogs give us this chance.  If it’s worth reading, it’s worth focusing on.

To Bloggers

This is a message to bloggers.  Don’t wait for the perfect article.  Just write.  Share stories of projects.  You don’t need to provide a tutorial or novel solution every time you write.  Simply recounting what you did, even if everything you did is what is normally done, can be just as revealing, just as interesting.  Just write.  Share your stories.  People want to read, and not every article need contain examples of code.

Share your mistakes, share your accomplishments.

I should take my own advice.  Recently we launched Locals at myYearbook.  The web version was my baby.  It’s an awesome product, and combined with the mobile version, makes for something an interesting story on the challenges we faced and how it works.  I haven’t written anything on it because, frankly, I worked on it so much that I can’t see the forest for the trees.  It’s completed, and remembering all the interesting details would take time.  And, wrongly, I feel that to do it justice, I would need to go over everything.

Ideas of March

Finally, here are some ideas I am working on for future articles.

  • Basics of tmux, getting strated with the terminal multiplexer
  • vim maps based on file types
  • An approach for a DIC for PHP 5.4
  • And just for kicks, writing a PHP app without conditions or loops (not recommended for sanity!)


vim faster with maps

At myYearbook, we pack our JS and CSS files.  Much of this is automated now with Jenkins, but we still have legacy code that must be packed by hand.  And, at the same time, it’s generally wise to test your product with a packed file regardless.  I also try to make it a habit to phpcs my file as often as possible.  The goal here is to keep the file as tidy as possible, and not waiting for the end to fix everything.  Also, during the course of development, I might come across other little things I want to do, and I use vim to make things as easy as possible.


I do this through maps.  I map is fairly simple to setup in vim.

:map ,cs <ESC>:w|:!phpcs --standard=myYearbook %:p

Typing that into a vim instance means I can type ‘,cs’ in normal mode, and vim will w my file to disk, then run phpcs using the myYearbook standard on the current file I’m working in.  Now, I use that often enough that I’ve added it to my .vimrc file.

map <Leader>cs <ESC>:w|:!phpcs --standard=myYearbook %:p

If you aren’t aware, <Leader> is set to ‘,’ using this bit of code in .vimrc:

let mapleader = ","

The comma is popular, but you can use whatever you want, really.

I can also pack my javascript and CSS files with similar ease using “,pj” and “,pc” (pack javascript, and pack css).

map <Leader>pj <ESC>:!jspack %:p > %:p:h/%:r:r.js
map <Leader>pc <ESC>:!csspack %:p > %:p:h/%:r:r.css

You might be wondering what the ‘%:p’ part is.  It’s actually part of the expand functionality of vim.  Basically, the important parts here to understand is that the % is the current file name.  The “:p” and “:r” parts are the modifiers.  In this case, “%:p” has us expand to the full path.  The “:h” modifier removes the last component.  So, “%:p:h” basically says “Give us the full path, and then remove the head.  The head in this case is the file name, so if the full path (“%:p”) is /Users/jasonlotito/test.php, “%:p:h” gives us “/Users/jasonlotito”.

“%:p:h/%:r:r.js” allows me to rename my file.  In our setup, unpacked files contain the extension “.unpack.”  By Simply using the “:r:r” modifiers, I strip off the “.js”, and then the “.unpack”, leaving me with just the file name.  So, if my javascript file was named Modifiers.unpack.js, I’d be left with Modifiers.  I prefix that with %:p:h/ which gives me the directory the file is in, and append “.css” to the path.

Being able to map commonly performed actions, especially to external tools, means I can stay in vim longer.  Sure, I’ll still background vim when I need to perform certain actions, but I’m more apt to start scripting repeated actions, and then mapping them.