Most software developers consider an application that runs offline a “phase 2” type of feature. Nowadays the Internet is everywhere, and it’s fast. In most cases only a small percentage of an application’s users lack a decent Internet connection. So rather than focus on the minority, at first we should focus on the majority, right? I say wrong—for a reason that has nothing to do with the speed of your Internet connection.
Recently, we at Cloudmanic Labs adopted a new mandate to build all of our applications—web and mobile—as offline first. Our first nonmobile example of an application that works completely offline is Heapless.
Why this new mandate? Very simply, offline is fast—really fast! Regardless of the speed of your Internet connection, storing your data and the files needed to run an application locally makes the user experience almost instantaneous. Modern browsers are able to prefetch all of the resources needed to run the application in the background using web workers. Which means that as a user goes from page to page or state to state everything is loaded instantly—no waiting for the application to communicate with the server. We use a similar approach to communicate data back to the server in the background to ensure that the user never has to wait.
Our primary goal of offline first is not to support users at 30,000 feet—the objective is making our application crazy fast and responsive. And thinking offline first has the added benefit of supporting our Internet-challenged users as well.
Whenever I hear a digital interface praised as "intuitive" my
eyelids twitch. What’s intuition got to do with it? What end users are really
saying is that the interface is so well designed that
it’s pretty much idiot proof. I get why we might not embrace that particular expression, but calling
an interface intuitive shifts much of the credit due the designer to the user.
And that happens because we tend to mistake the simplicity of a well-designed
interface for simpleness, discounting the hard work of good design.
What is good—or if you insist, intuitive—interface design
anyway? Most essentially, good design requires minimal knowledge and experience
on the part of the end user. It allows us to bridge the gap between what we do
know and what we don’t know without a lot of cognitive effort—that is, without
having to think too hard. And that’s a very good thing because more and more
digital tasks are being foisted on consumers, for better or worse. Which means
that good interface design essential: when you go it alone, shit-hot
functionality is useless without a well-designed interface that makes
navigation seem obvious and success practically inevitable.
For humans, a list is an exceedingly common way of organizing data. Typically a list is a collection of related items arranged vertically or horizontally, one item after another. Most databases store data in this very same manner.
A common first step when building a data-driven software application is to prototype data models in Microsoft Excel, a powerful tool for building and manipulating lists and managing raw data. The next step—product design—is the one that ultimately determines whether the software will live or die. And it’s here that Excel is causing great damage by modeling terrible design.
Many developers build data-driven applications that look and feel a lot like Excel. Although mimicking the table-based structure of Excel often seems like the most logical way to display data onscreen, this assumption is flawed because it discounts a very important factor in great software design: the emotional connection between users and the software.
Great software, regardless of how mundane the content is, should evoke an emotional response. Users should have an unexplainable, powerful attachment to the application. Take a look, for example, at the screenshots below. Which one do you feel more compelled to engage with?
I assert that the design of Option 2 is far more engaging. Each item is part of a conversation between people. The effect is personal and meaningful. In contrast, the underachieving design of Option 1 delivers a list and little more. The information slackly dissolves into mere bits on a screen, requiring the viewer to concentrate to make sense of it—sort of like one does with those Magic Eye stereogram images.
More than ever before everything is data and data is everything. Regrettably, managing data has become a black art involving Microsoft Excel VLOOKUPs and highly individualized spreadsheets. Though there has been a push to move data to more robust systems such as SQL Server, a large portion of data ends up at the opposite end of the software spectrum—in scary spreadsheets that are emailed and cut and pasted and generally lack the validation necessary to maintain data integrity.
The reasons for this misuse of software are numerous, but the most common are a lack of resources and limited skills. In both small businesses and large institutions (particularly those whose IT budgets have been slashed in the current recession), individuals often find it necessary to go it alone and come up with ad hoc methods for entering and retrieving data in programs they are familiar with—usually Excel. Overreliance on spreadsheets occurs when other options seem prohibitively difficult or expensive to implement. It can also be the result of a bunker mentality that sets in or when IT enforces the use of specialized, tightly controlled databases, driving some users to go rogue.
The spreadsheet solution seems great at first. You are empowering yourself and getting over on The Man. But over time a spreadsheet tends to turn into a mess of workbooks and worksheets that starts looking more like game of Battleship as your data sinks in a grid of B9:Z88 cells. Ultimately each one evolves into a hopelessly idiosyncratic contrivance that only one user understands. And then you go on vacation and someone renames a worksheet and all your VLOOKUPS and calculations fail. Or worse, you work late one evening and distractedly sort your columns—and scramble your data. Sometimes the spreadsheet solution is flexible to a fault.
Most people building software these days have heard of the Minimum Viable Product (MVP) strategy: construct only what is necessary to get a few users onboard and worry about the rest of the planned features later. The problem is, most of us suck at figuring out just how much is enough for a product to be minimally viable. As a result, we often times err on the side of too much. Cloudmanic Labs has launched a variety of products, and I like to think we are pretty good at gauging an MVP feature list. So recently I sat down and looked at the numbers to see how accurate we were at building an MVP release of Photomanic, our photo application for Evernote launched about a month ago.
We measure the usage of all features, which helps us determine whether we should invest more in a feature or not. One feature I insisted on was the ability to rotate images. I was convinced that without this feature users would not consider Photomanic viable. As it turns out, only 0.84% of the images uploaded to date have been rotated. Yet this feature is the one our development team spent the most time building—and one for which we generated a laundry list of upgrade ideas. Even I rarely rotate images, and I was the biggest proponent of the feature. Clearly, our perceptions of what is important are not always accurate.
In web design I see modal windows misused repeatedly—though, admittedly, this is just one man’s opinion of improper use. (Or is it? read on...) But I should begin by clarifying three things. First, a modal window appears within another window, something like this:
Second, while Cloudmanic products do use a few modal windows, most reflect poor judgement on our part and will be phased out over time. And third, there is a time and place for modal windows—some examples are described below. Nevertheless, I submit that 90% of the time modal windows are misused.
Why Modal Windows Are (Usually) Bad
Modal windows are useful because they delimit a space in which
the user performs one or two simple tasks. The unpleasant side effects,
however, are often not worth it. Here is my short list of why you should use
modal windows sparingly:
Most developers neglect to think about different screen sizes with respect to
content. For example, if the modal window content requires scrolling, the
screen displays both the modal window scroll bar and the browser scroll bar and
your wheel mouse behaves differently based on where the cursor is. Yes, the
browser scroll bar can be disabled, but doing so has never felt natural to me.
mobile friendly. Modal windows are almost always difficult to manage on
mobile devices. They’re slow to load and slow to hide. Unless the developer
does tons of testing, the content can get wonky—such as when when the onscreen
keyboard pops up.
They require a
lot of developer time. Developing a modal window requires extra effort
because the association between the parent page and the modal window page must
be maintained. And developing modal windows for a modern ajaxy type web
application is especially complex.
and cause angst. The appearance and disappearance of a modal window
disrupts the screen in a big way, forcing the user to refocus. And if, when the
modal window disappears, users do not refocus on the correct area of the parent
screen, they might wonder if anything even happened. Users need good visual
cues to confirm that a change has occurred. The idea of modal windows causing
Cloudmanic users even such micro forms of angst bothers me.
When Designing Software, Think About My Wife
Actually, that’s a shitty title. It should be, Don’t ever think about my wife again! Maybe it’s best if you think about your wife, husband, girlfriend, boyfriend, or cat. Think about the spark that brought you together. Think about the emotional attachment you have to one another. Think about all the times you almost broke up–but stayed together.
When I design software I try to model it after my relationship. I want every user to be as enchanted with the software as I am with my wife. I want users to trust me in the same way my wife trusts me. I want to have a commitment with every user that is like the commitment my wife and I have for each other. When building software, I try to build that marriage between user and the software with every feature.
Sparking the Relationship
When you meet someone new and there is a spark, it often leads to a first date. You might not be able to verbalize the spark, you just feel it deep down inside. It might be how the person is dressed, how they conduct themselves, where they are from, their profession, and or something you can’t even identify. Often it’s just one or two things that ignites the spark.
When building software, you have to find those one or two things that sparks a user’s interest. You need to convince the user to go on a “first date” with you. Once on the date, you can show off all your other amazing qualities, but if you come on too strong, you’ll never get that date. What are the one or two things that really makes your software spark someone’s interest? Why would they want to “go out” with you in the first place?
We all know the saying “Location, location, location.” This is a great saying to live by for many different industries. But when it comes to the web startup world, I would say there is a more important saying: “Product, distribution, product, distribution, product, distribution.”
Nine times out of 10, I can detect a first-time entrepreneur – and have a pretty good idea of their future success – based on how they see product and distribution. To make my point, look at the two responses to the question “How will people discover and engage with your product or service?” Which of the following responses is from a first time entrepreneur, and which is from a veteran?
We have a complete social media plan in place, along with a budget for an on- and off-line marketing campaign; we plan to reach out to media for press coverage, and we have an all-star team of writers for our blog to spark traffic via SEO.
We're not really sure what channels of distribution will lead to the most conversions. We have a small budget set aside for experiments. Of course our experiments will be across all channels – we will be measuring everything! Once the data is in, we will know what channels we will focus our attention on. Really, distribution is something we are only experimenting with in the early days. Our focus is on the product and the iterations of the product.
Maybe my fake examples gave it away, but anyone who tells me they have a very clear distribution plan in the early days of building their company is fooling themselves. The person who realizes they need to try all distribution channels, coupled with product iterations, is most likely the seasoned entrepreneur.
Once upon a time, software was very different. You did not have app stores. You could not download free versions. You could not simply create an account and run the software from your browser. Software required commitment.
Back in the day, if you wanted software, you got in your car and drove to Staples and engaged with the sales doob about which software was perfect for you and your computer. Once you decided on the software you were given a shrink-wrapped box with a CD inside. Oh yeah, you also had to pay for it. And software was not cheap in those days, either.
Before you ever installed your new software you already had a pretty big commitment. You spent time at Staples. You spent your hard-earned money. And typically, you could not return the software once you opened it.
After all this commitment you were not going to let this software go to waste. People would block out time in their schedule to just to sit down and learn how to use the software, going over every inch of the software, learning everything there is to learn.
I admit it. I have made many friends and family members’ ears bleed with my constant raving of a particular product once and again. When I fall in love with a product I make sure everyone around me knows. I form a complete disdain for the use of any other product. I have never understood why until recently. Beyond my comprehension, I have always loved Basecamp over Jira even though Jira does way more. It puzzles me why I love my Mac more than any other computer when Linux gives me all the control in the world. I always wondered why I am willing to pay up for a JetBlue flight when United will get me to the same place cheaper.
I stood in line for hours to be the first to buy the iPhone. The phone really was a game changer. After a year or two I dumped the iPhone and went all Android. I had this concept that I wanted more control over my phone. I did not want Apple telling me what to do with the hardware I paid for. After almost 2 years of using the Android I went back to the iPhone. I realized all the features, control, and freedom Android offered was at the cost of a shitty product. To me there was nothing engaging about using an Android. There was no emotional connection.
I think feature bloat in most products is nothing more than mind tricks. We get wrapped up in the fantasy of all the stuff we can do with those features. We feel a product is so much better because the feature list is longer. We feel if we have the control to hack away on our products they are somehow better.
So, when I say a product is no good, or better yet, another one is simply amazing, I can’t aways give you a bulleted list of the reasons for my affirmation. I can’t always define in words why one sucks me in while the other just sucks. You just sort of know when a product is top notch. You get the feeling great care and attention to detail was put into building it. You know because you find yourself engaged using it; you look forward to the next time you get to use it. It becomes a friend to you, rather than a utility.
Think of it this way. I can’t tell you every reason why I love my wife, I don’t really know. I am not completely sure why I chose to spend the rest of my life with her. There is something so engaging about her that it brings out all my passion. Products that don’t suck are the same way.