Lesson 1: The Basics of Mobile Apps and App Design

Speaking the Language of Apps

If you've ever used an iPhone, an Android phone, a Blackberry, or any other smartphone or tablet, you know what I mean when I say "app." App is short for application, and on a mobile device (such as a smartphone or a tablet computer), it means a piece of software that allows the device to do something it couldn't do before. You might have an app for getting driving directions, reading and sending email, playing solitaire, finding restaurants, and many other tasks.

People who create these apps are mobile app developers. They may work alone or in a team. Their tools include computer code, text, graphics, and sound. Some apps come preinstalled on mobile devices. You can download others from the Web or from an app store.

Two examples of app stores

We typically divide apps into two broad categories—native and Web—depending on which tools the developers used to create the app and how it's distributed.

Native Mobile Apps

You download native mobile apps from an app store and install them on your mobile device. Programmers build them using the native programming language of the device's operating system (OS). An OS is the program that allows all the other programs on a computer to run smoothly without interfering with each other. Some examples of programming languages are Objective C (for Apple iOS, which is Apple's mobile operating system) or Java (for Android).

Native apps can talk directly to the operating system, camera, calendar, contacts database, and various other capabilities of your phone. Some of them function when the device is in offline mode (unconnected to the Web), and they may include sophisticated graphics, sound, and interactivity.

My favorite native mobile apps include Angry Birds, Words with Friends, Kindle, Audible, and RunKeeper.

You can use a native app on only one type of device, although developers often create versions of native apps for each of the popular mobile device operating systems. For example, native apps developed for Apple iOS run solely on the iPhone, iPod, and iPad. Native apps developed for Android run on Google Android devices only.

Mobile Web Apps

Web apps run inside a device's Web browser, and mobile app developers build them using Web standards such as HTML, CSS, and JavaScript.

Like native apps, Web apps can operate in offline mode, and they can feature sophisticated graphics, sound, and interactivity. They are increasingly capable of accessing native device operating systems and hardware.

Because they use standard Web languages, Web apps can run on any device with a Web browser. This includes smartphones and desktop computers.

My favorite mobile Web apps include YouTube, Gmail, Twitter, and Financial Times. Interestingly, in each of these cases, the developers created a Web app after developing a native one. In each case, the Web app is at least as good as (and usually better than) the native.

Several popular mobile Web apps

This table shows the main differences between native apps and Web apps:

Native apps	Web apps
Downloaded and installed on mobile device	Run in Web browser
Specific to one operating system	Cross-platform—can run on any device with a Web browser
Can access device functions directly	Can access device functions through the browser
Written using "native" programming language, such as Java or Objective C	Written using HTML, CSS, JavaScript, or some combination of these

Now that we have our basic definitions down, let's talk about why so many people and companies are certain that mobile Web apps, rather than native ones, are the future.

Think for a moment about the history of computing over the last few decades. (Don't worry, we're not going to go over all of that here . . . you can Google it if you're interested!) Before the Web came along, everything you wanted to do on your computer required you to insert a disk of some sort and install software.

Remember this?

Before Google Maps, Wikipedia, Mint.com, Facebook, and Priceline, there were physical stores where you'd buy boxes containing CDs and manuals. Every so often, the software's author would release an upgrade, and you'd buy a new disk and install it.

Because vendors distributed the software on CD-ROM, it was difficult to update, and it was usually out of date. This could be an occasional inconvenience in the case of map software, but it was expensive and a major hassle in the case of accounting software.

Part of the price of the software you purchased went to the store that sold you the software, part went to the distributor, and part went toward the fancy packaging. When you got home with your new software, you'd put the disk in your disk drive and run or install the software, and then you'd put the disk and manuals on a shelf.

It's clear now that this sort of installable, native software that you buy is on its way out for most day-to-day computing applications. What's replacing it is the concept of software as a service.

Software as a Service (or SaaS) treats software as something that you pay for when you need it (or that advertisers or someone else pays for) and that you access using a Web browser. You might log into websites to get your email, to organize your photos, to chat with friends, to manage your finances, and to do so many other tasks.

In the business, we call this cloud computing. Perhaps the greatest part of all of our computing moving to the "cloud" is that you can access your data anywhere and on any computer, and the software is always up to date.

Cloud computing: for networks, desktop machines, and mobile devices

On smartphones, however, we're still mostly downloading apps from a centrally controlled source, such as Apple's app store, and we have to keep going back to that store to install updates. The distributor takes a huge cut of the action (30%, in the case of the Apple app Store!), and your "shelf" space on your phone is limited. If you're like me, you run out of storage space on your smartphone regularly and have to delete pictures of your cats so that you can fit the latest updates to your apps.

So far, browser-based apps haven't achieved the same sort of success they've had on desktop and laptop computers. That's because of technical limitations, such as a shortage of bandwidth and computing power, along with a lack of agreed-upon standards. But this situation has been changing rapidly in the last couple of years because of two factors—HTML5 and the WebKit browser engine.

HTML5 and WebKit

HTML5 is the latest version of the language of the Web. This version features built-in support for video and audio, great new ways to do animation, offline browsing, better handling of errors, and more. Perhaps most importantly, HTML5 is easier to write than previous versions of HTML. The creators of HTML5 have tried to make it adapt to the people who are writing it, rather than forcing authors to adapt their style to it.

When the people at Apple decided to include their own Web browser with their computers, they decided it would be faster and less expensive to modify an existing open-source browser than to build their own from scratch. (Open source means the computer code is available to anyone to use, modify, and redistribute for free.)

After evaluating the possibilities, they settled on a browser known as KHTML to serve as the foundation of their Safari and Mobile Safari Web browsers.

Apple eventually released its expanded version of KHTML, called WebKit, as open source, which the KHTML license agreement requires. Because of the popularity of the iPhone and the quality of WebKit (not to mention that it's free), almost every mobile Web browser manufacturer put it at the heart of their Web browsers. These manufacturers include Google, Palm, Nokia, Amazon, Opera, and Blackberry.

In 2013, Google announced that it is creating its own browser engine, called Blink, which is based on WebKit.

The same browser engine runs on iOS, Android, Blackberry, and others. So you can be pretty sure that anything that runs in Mobile Safari, for example, will run (with a few nips and tucks, of course) in the Android browser.

The combination of HTML5 and the rapid adoption of WebKit (and other HTML5-compliant browsers) on mobile devices is exciting news for mobile app developers because it means that we have to learn to code in fewer languages and do less work in order to make our apps available to more people.

Once you have your idea and your list, move on to the next chapter. We'll talk about what makes mobile applications special and what makes a good mobile app.

The Four Principles of App Design

When you think up an idea for an app and then figure out how to make it a reality, you are designing an app. Just as with any type of design—automotive, graphic, or industrial, among others—people have come up with ways of doing things that result in a better product. These are best practices.

In this chapter, we'll start looking at some fundamental ideas about how to design Web apps and some of the best practices that app developers follow.

At the end of the last chapter, I asked you to list things people do with their smartphones. Here's what I came up with:

People use their smartphones for . . .

• making phone calls
• checking email
• getting maps or directions
• playing games while sitting in a waiting room
• finding nearby restaurants
• sending messages (text messages, Twitter, Facebook)
• taking pictures or video
• making and checking lists

I also asked you to jot down your idea for an app. Here's mine:

Sandwich Time is an app that detects your current location and gives you just one nearby lunch selection per day. The app chooses the restaurant based on user reviews and preferences you specify (such as price range, types of food you like, and how long your lunch break is). You never need to think about what to have for lunch again when you're on the go or busy at work.

What Makes a Great Mobile App?

What you learn about design of mobile apps may surprise you. Do you have experience designing websites for desktop browsers? If so, designing for mobile devices requires that you put aside much of what you've learned about Web design. If you have an idea for an app, this chapter may cause you to rethink it.

Here are the four rules I follow when designing apps:

1. Design with mobility in mind. Mobile app users are on the go. They might be at the grocery store, waiting for the bus, in a restaurant, jogging, or doing any of the things that people do where they're not at a desktop or laptop computer. Think about how people use mobile apps versus how they use desktop applications. When people use a mobile app, it usually doesn't have their full attention.

Using a map app

For example, you might pull up a tip calculation app while digging around in your wallet. Another time, you might do a quick search on your phone to settle a dispute with a coworker about which mountains are taller. Or you might stop while on your morning walk to take a picture of a duck and upload it to a social networking site.

In all these cases, using the mobile app isn't the primary thing you're doing. The best mobile apps exist to help you do the primary thing you're doing. Desktop apps, on the other hand, often are the primary thing that you're doing.

2. Design for simplicity. We often measure desktop applications by the number of features they contain. A painting program that can only make blue squares is inferior to an illustration program that has hundreds of advanced features.

On mobile devices, however, full-featured applications simply don't work. There's no way that someone using a three-inch touch screen can select options from a complex menu, use multiple tools, and keep track of large numbers of options and preferences. The best mobile apps have very specific functions.

3. Design for people. Never forget that actual humans will use your app. In fact, it's quite possible that all your app's users will be human.

You're creating an app because you think your idea is something people will want or need. But have you thought about who will want or need it? Do you have a clear picture of this person?

Creating a clear picture of your target user and of the scenarios in which that person will use your app is user-centric design.

4. Design for different devices. People use mobile apps, and especially mobile Web apps, on a variety of devices. Even if you develop Web apps for the iPhone only, you'd still need to contend with different screen resolutions, amounts of storage space, Internet connection speeds, and device capabilities, among other things. That's a lot to think about!

Fortunately, as you'll see in future lessons, some great tools are available to help you optimize your apps and find out how well they work on different devices.

Mobile devices of many shapes and sizes

Now that you know the unique challenges of mobile Web design, let's look at some of the ideas and techniques that app developers use to meet these challenges.

Why Graceful Degradation Doesn't Cut It Anymore

In the old days of Web design, mobile devices were an afterthought. It was difficult to add new functionality to a mobile phone, and mobile Web browsers couldn't do much. Most mobile websites were just lists of links and text, because that's just about all the typical phone could handle.

When Web developers decided to support mobile phones, they generally thought of them as stripped-down versions of the "real" website. Starting with a desktop version of a site and scaling it down to create the mobile version is graceful degradation.

This "desktop first" design technique was popular and useful in the days before smartphones with advanced Web browsers. The idea was that you should design your Web app for the latest desktop Web browser, but in such a way that it still worked (at least a little bit) when someone viewed it on a device that didn't support all the latest techniques and plug-ins.

This sounds good in theory. But in practice, graceful degradation often results in mobile devices having to download way too much data in order to display something that's barely functional.

I'm sure you've tried to view your favorite site on a mobile phone, only to find that it takes five minutes to download and then doesn't work. This is too often the result when developers take a desktop-first approach to design.

Today, people are increasingly surfing the Web with highly capable mobile devices, and our approach to Web design is shifting to reflect this fact.

Mobile First and Progressive Enhancement

Mobile first Web design means that you think about Web applications as mobile Web apps first and as sites in a desktop browser second.

The Web browsers on our mobile phones are, in many respects, more advanced than our desktop computer browsers. They feature support for multi-touch gestures, geolocation (finding your location anywhere on Earth), interaction with device hardware such as cameras and accelerometers, and support for many more of the latest technologies that aren't available on most desktop computers.

More people are using mobile devices. If you're designing Web applications today but not thinking about mobile users, you're leaving behind a sizable community of people who would like to use your app.

The specific technique people use to implement the idea of mobile first is progressive enhancement.

The most basic idea behind progressive enhancement is layering. The idea is to start with the most important part of your app—the bare-bones content and functionality that defines what the app is—and make it functional on a basic mobile device. Then, for devices that are more feature-rich or with larger screens, you can build on that foundation.

Instead of designing for full-featured browsers and making sure that your site is still usable on mobile devices, people are making apps that look good on mobile devices with limited capabilities. Then they're layering additional features on top of that for devices and browsers that are more capable.

Why use a progressive enhancement approach to design? Well, that way mobile devices don't need to download a full-featured site to find out whether they can display it.

The Cupcake Rules of Web Development

Desktop-first Web development is like trying to make a cupcake out of a wedding cake. You can only do it by creating a lot of waste, and your cupcake probably isn't going to look right.

Mobile-first Web development is like making cupcakes. Once you have the cupcakes, you can build a wedding cake out of them if you need to.

Mobile first vs. desktop first

What do you think about what we've covered so far? Are you envisioning app development in new ways?

I've thrown a lot of terms and concepts at you in this chapter. When you're ready, please move on to Chapter 5. We'll review what you've learned, and I'll explain different features within the course that will help you reinforce and expand your learning.

Summary

You came a long way in this chapter. We started out with learning about the two broad categories of mobile apps: native and Web. You learned that Web developers can use the same languages to create desktop websites and mobile apps, and we talked about why this is such a worthwhile and forward-thinking idea.

You discovered the factors that make designing great mobile apps different from designing traditional desktop websites and Web applications. Also, you found out about progressive enhancement, which makes it possible to design Web apps for maximum compatibility between desktop and mobile devices.

What's next? In Lesson 2, you'll start getting your hands dirty with some code. By the end of the lesson, you'll have built an actual, functioning, and maybe even somewhat useful mobile Web app!

But before we get to that, you still have a quiz and an assignment to complete. Let me explain the different features of this course.

Supplementary Material

3 Trends Shaping Mobile Development in 2016 -- ADTmag

LukeW Mobile First

HTML5 mythbusting – Mozilla Hacks – the Web developer blog

Lesson 1 FAQs

Q: Will Web apps really replace all native apps?

A: That's unlikely. The core apps that come with mobile devices (such as those related to the phone, calculator, camera, and voicemail) and that make an Android phone different from an iPhone will likely remain as native apps.

Q: Are people creating games in HTML5?

A: Some people are. (Check out my favorite, Canvas Rider, at www.canvasrider.com.) But HTML5 games are currently more challenging to write than native ones. Right now there aren't pre-built code libraries for HTML5, and because it's still a new technology, different browsers have different levels of support for some of its most cutting-edge features.

Q: I don't know much about computers. How much technical expertise do I need to do well in this course?

A: I'm assuming that you have a basic knowledge of how the Internet works and that you've used mobile apps on a smartphone or tablet computer. I'm also assuming that you know at least some HTML or have worked with it in the past. That's all you need!

Lesson 1 Assignment

Part 1

Review the four rules of mobile app design that you learned in Chapter 3: design for mobility, design for simplicity, design for people, and design for different devices. Think up your own way to remember these four rules. It might be an acronym, or a sentence that begins with the first letters of each design rule, or a song, for example.

Part 2

Take a look at the app idea you wrote down at the end of Chapter 2. Reevaluate that idea, keeping in mind the four rules that you now have committed to memory. Is there anything you'd change about your app to make it more mobile-friendly?