I’ve been kickstarting a bunch of small web apps lately. It seems like every time I start a new project, theres’s always something new that causes me to adjust my development principles. I thought it might be good to take a snapshot of what’s “in” today. I like to think of web development phases starting from idea to delivery… all of it backed by strong principles of how to build great apps.
The following are my core web development principles today:
- Designing for mobile first (even if you’re not building a mobile app)
- Build only single page apps
- Create and use your own REST API
- “Sex sells” applies to web apps
Most developers have their own rules about how they like to build stuff. These rules are pretty opinionated, but that’s ok, because they’re mine. Let me explain why each of these are core to how I build apps today.
Designing for mobile first
Last year, Luke Wroblewski popularized a the idea of building for “mobile first.” Much of his thinking was born from the rise of mobile web/app usage and the poor experience many sites and apps designed for desktops left for users. Mobile first design forces us to frame the features of our app on a smaller screen. It forces us to make the hardest decisions about our app right from the beginning. That is, it encourages us to throw out features up front and limit it to just the ones that matter.
When you design for a larger screen you have a lot more whitespace that’s itching to be filled with features. When you start with a smaller screen, you have the opposite problem. You end up designing a smaller set of features. With a smaller set of features, it’s easier to focus on the core of your application. We’re also forced to innovate on these smaller features in a way that we might not have done when designing for a larger screen.
Another upside to this design approach is that you end up thinking of performance up front. Do you know what the fastest web app is today? It’s not Google’s or some startup’s latest creation. It’s the blank page. Yes, a blank page counts as a web app. The more you add to a blank page, the slower it gets. Mobile first design keeps apps from getting bloated. It allows us to keep our apps small and fast.
A sibling to the mobile first design principle is Responsive Web Design (the brain child of Ethan Marcotte). Responsive web design was also born as a way to fix desktop sized web apps on mobile sized web browsers. Responsive web design is less a design principle and more of a technique for creating multiple size representations of your web app. The core technique uses a feature of CSS3 called media queries. Media queries allow you to apply alternative CSS rules matching the queries you’ve set. The most common media queries are used to determine the size of the “viewport” of the browser. Media queries make it easy to take an existing desktop web site/app and make it mobile friendly.
However, it’s important not to use media queries without knowing the implications. For example, if you take a large web page (i.e., large HTML) with large assets (JS/CSS), applying media queries won’t improve the download speed of that page on a mobile device.
Responsive web design is best used as a technique when you know you’re going to be building a web app that needs to scale according to the screen size. Go here to see some great example of responsive web sites.
Build only single page apps
Single page apps, or SPAs, aren’t new. Gmail popularized it back in 2004, but since then it’s had a bit of a sluggish adoption rate. In a nutshell, a single page app is a web app that operates entirely in a single page. Traditional web apps transition from page to page. Each page is generated dynamically on a remote server. Typically, the web page that’s delivered to your browser is fairly static and doesn’t have much programmatic logic to process the interactions and data that you feed to the page.
A single page app in contrast off loads most of the programmatic logic and computation to your browser. In a single page app, the server typically doesn’t assemble the web page for you. Instead the web app is essentially “running” entirely on your browser. The only interaction between the browser and the server is the exchange of data required to run the app. All of this happens without the page refreshing or reloading.
Single page apps have also made it possible to create “real-time” apps. A real-time app is an app that’s alive. It updates itself without the need for user interaction. In the last couple of years, browser vendors have rushed to create functionality to support real-time apps – creating a standard (web sockets) that’s made it increasingly easier to build real-time apps.
Create and use your own REST API
What’s the use of creating an API if you’re not going to use it yourself? The best APIs are the ones that are used for a purpose. If you build something for the sake of being able to say that you have it, it’s going to suck.
REST APIs itself are pretty opinionated. There are folks out there who believe that calling an API a REST API requires compliance with a strict set of principles. The problem is there are a lot of opinions on the principles itself.
Regardless of the core principles behind REST APIs, the one guiding principle I absolutely follow is that the API should be pragmatic. A pragmatic API means it was designed for a purpose and not for a general purpose.
Which is why you should build a REST API for your own use. If you’re not going to use it, how do you expect anyone else to use it?
For me, using my own REST API means using it to power my own “mobile first” designed single page web app. This means my web app uses my REST API as the M (model layer) in MVC. It becomes my interface for all data exchange between my single page app and the server.
“Sex sells” applies to web apps
To me this is obvious. There’s a reason it’s difficult to find great designers or UX people these days – everyone wants them. The first experience a user has with your app is the most important. As with most things, you want to put your best foot forward as first impressions are lasting.
Like it or not, the best looking apps get the most attention – even if your app is fundamentally better. But I’d also argue that an app can’t be fundamentally better if the experience is bad. As developers, we tend to downplay the importance of designing the experience. Developers who factor this in right from the beginning will have greater success with their products, period. If you suck at design, find someone to help you… now. This is one principle you can’t ditch.
Everyone has an opinion
My own opinion is my own. As developers, we’re entitled to that. In the end, it’s about the experience your app creates, not the implementation, that matters. Web development will continue to change. And if you’ve been around long enough, you’ve seen the same patterns appear over and over again. We will continue to evolve as developers. Our opinions and techniques will too. I’m excited when I’m forced to look at something in a different light. I’m sure I’ll have to revise this post the next time that happens.
How about you? Care to share your web development principles?