TightWind is written by Kyle Baxter. Stay Hungry. Stay Foolish.

In desktop applications, the user interface dominated the screen. The buttons to click, the bars to drag, the windows. The actual stuff we were working on—text, images, video, whatever—was largely secondary, and that made sense, because the only way to do anything was through the interface. It worked, but it was always clear that it was artificial, something entirely created that didn’t work how our brains do. We had to force our brains to work how the computer worked, contorting ourselves around it.

In a sense, desktop applications could be designed without context in mind, because there really was only one context: the user is sitting at a desk working on the computer. In this context, and because the PC only worked using abstractions upon abstractions, it was okay for the user interface to dominate what we were doing. Everything was artifice anyway, so it only made sense for artifice to dominate.

That isn’t the case with mobile devices. What’s powerful about mobile devices is that they exist to complement what we are already doing, rather than be our primary focus. Whereas users mold themselves around how PCs work—users only work on PCs while their focus is entirely on them—mobile devices are used while doing other things. They’re used while waiting in line at the grocery store, when out to dinner, watching television, driving somewhere (by passengers!), or walking somewhere. Mobile devices are used almost entirely while doing something else, for relatively short periods of time, and usually, to accomplish a very specific task. What groceries do I need to buy? What time does the movie start? How do I get to that restaurant? What’s the weather going to be like? etc.

What this means is that designing applications for mobile means that context—for what purpose it will be used, how, and where—should be the first and primary consideration. It must define everything about how the application is designed, from the application’s concept to the physical design itself. It also means, though, that mobile applications are tools, a means of accomplishing a task and getting on with what the user is doing. Mobile applications should be cogs which seamlessly fit into an existing process—say, finding a restaurant to eat at—and make it better.

That’s precisely what a tool is: something which requires very little explanation for how to use it, because it is designed so precisely for its purpose, that how to use it is obvious. If you’re trying to dig a hole with your hands, you don’t need much explanation for how to use a shovel. “This is the handle” is about the extent of it.

There is no interface, in other words. There are no complicated concepts to learn first, no keyboard commands—just something which makes immediate sense, because it was designed precisely for what the user is trying to do. The application’s underlying concept should match the user’s.

Of course, there are cases where this really isn’t possible. Some purposes are so complex that even the best solutions are too sophisticated to be immediately understood, and even in simpler cases, it’s difficult to achieve. But that should be the goal.

What we should be trying to create are applications that are designed so specifically to the user’s context that the application ceases to feel like software—a finicky piece of artifice that we have to strain to understand and play with to get it to do what we want—and begins to feel like a physical object, something that just is and just works a certain way and we know will work that way.