Coding For Dummies (2015)

Part III. Putting Together a Web Application

To see how to build your own app using geolocation, check out www.dummies.com/extras/coding.

In this part …

· Plan to bring your first web application to life.

· Meet the people who help build web applications.

· Research each component of your first web application.

· Build your web application with offers based on location.

· Debug the errors in your first web application.

Chapter 10. Building Your Own App

In This Chapter

Completing a case study using an app

Understanding the process of creating an app to solve a problem

Discovering the various people that help create an app

If you have a dream, you can spend a lifetime … getting ready for it. What you should be doing is getting started.

—Drew Houston

If you have read (or skimmed) the previous chapters you now have enough HTML, CSS, and JavaScript knowledge to write your own web application. To review, HTML puts content on the web page, CSS styles that content, and JavaScript allows for interaction with that content.

You may feel like you don’t have enough coding knowledge to create an app, but I promise that you do. Besides, the only way to know for certain is to get started and try. In this chapter, you come to better understand the app you are going to build, and the basic steps to create that app. Developers often begin with just the information presented in this chapter and are expected to create a prototype. After reading this chapter think about how you would build the app, and then refer to chapters that follow for more details on each step.

Building a Location-Based Offer App

Technology can provide developers (like you) one of the most valuable pieces of information about your users — their current location. With mobile devices, such as cell phones and tablets, you can even find a user’s location when they are on-the-go. Although you likely have used an app to retrieve the time, weather, or even driving directions, you may never have received an offer on your phone to come into a store while walking down the street or driving in a car. Imagine passing by a Mexican restaurant during lunch time and receiving an offer for a free taco. I’m hungry, so let’s get started!

Understanding the situation

The following is a fictitious case study. Any resemblance to real companies or events is coincidental.

The McDuck’s Corporation is one of the largest fast food restaurants in the world, specializing in selling hamburgers in a restaurant called McDuck’s. The company has 35,000 of these restaurants which serve 6.5 million burgers every day to 70 million people in over 100 countries. In September 2014, McDuck’s experienced its worst sales decline in over a decade. After many meetings, the executive team decided that the key to improving sales would be increasing restaurant foot traffic. “Our restaurant experience, with burger visuals and french-fry aromas, is the best in the industry — once a customer comes in it is a guaranteed sale,” says McDuck’s CEO Duck Corleone. To promote restaurant visits, McDuck’s wants a web application so customers can check-in to their favorite store, and receive an offer or coupon if they are close to a restaurant. “Giving customers who are 5 or 10 minutes away from a restaurant an extra nudge may result in a visit. Even if customers use this app while at the restaurant, this will allow us to maintain a relationship with them long after they have left,” says Corleone.

The McDuck Corporation wants to run a pilot to better understand whether location based offers will increase sales. Your task is to:

· Create an app that will prove whether location based offers are effective.

· Limit the app to work on just one McDuck’s store of your choice.

· Obtain the location of customers using the app.

· Show offers to those customers who are five or ten minutes from the store.

McDuck’s currently has a website and a mobile app, but both only show menu and store location information. If this pilot is successful, McDuck’s will incorporate your code into its website and mobile app.

Plotting your next steps

Now that you understand McDuck’s request, you likely have many questions:

· What will the app look like?

· What programming languages will I use to create the app?

· How will I write code to locate a user’s present location?

· What offer will I show to a user who is 5 to 10 minutes away?

These are natural questions to ask, and to make sure you are asking all the necessary questions upfront in an organized way you will follow a standard development process.

Following an App Development Process

Building an app can take as little time as an hour or as long as decades. For most startups, the development processes for the initial product prototype averages one or two months to complete, whereas enterprise development processes for commercial grade software takes six months to a few years to complete, depending on the industry and the project’s complexity. A brief overview of the entire process is described here, and then each step is covered in additional detail as you build the app for McDuck’s.

An app can be a software program that runs on desktop or mobile devices.

The four steps you will follow when building your app are:

· Planning and discovery of app requirements

· Researching of technology needed to build the app, and designing the app look and feel

· Coding your app using a programming language

· Debugging and testing your code when it behaves differently than you intended

In total, you should plan to spend between two to five hours building this app. As shown in Figure 10-1, planning and research alone will take more than half your time, especially if this is the first time you are building an app. You might be surprised to learn that actually writing code will take a relatively small amount of time, with the rest of your time spent debugging your code to correct syntax and logic errors.

App development processes have different names, and the two biggest processes are called waterfall and agile. Waterfall is a set of sequential steps followed to create a program, whereas agile is a set of iterative steps followed to create a program. Additional discussion can be found in Chapter 3.

Figure 10-1: Time allocated to complete the four steps in the app development process.

Planning Your First Web Application

You or your client has a web app idea, and planning is the process of putting those ideas down on paper. Documenting all the features that will go into the app is so important, because as the cartoon in Figure 10-2 shows for web development, and in computer science generally, it can be difficult to understand upfront what features are technically easy versus difficult to implement.

The planning phase also facilitates an upfront conversation around time, project scope, and budget, where a common saying is to “pick two out of the three.” In some situations, such as with projects for finance companies, timelines and project scope may be legally mandated or tied to a big client, and cannot be changed, and so additional budget may need to set aside to meet both. In other situations, such as projects for small startups, resources are scarce so it’s more common to adjust the project scope or extend the timeline than to increase the project’s budget. Before writing any code, it will be helpful to understand which dimensions can be flexed and which are fixed.

Finally, although you will likely play multiple roles in the creation of this web app, in real life teams of people help bring to life the web apps you use every day. You will see the roles people play, and how everyone works together.

Figure 10-2: It can be difficult to separate technically easy and difficult projects.

Exploring the Overall Process

The purpose of the planning phase is to:

· Understand the client goals: Some clients may want to be the first to enter an industry with an app, even if it means sacrificing quality. Other clients may require the highest standards of quality, reliability, and stability. Similarly, some others may prioritize retaining existing customers, while others want to attract new customers. All these motivations affect the product design and implementation in big and small ways.

If you are a developer in a large company, your client is usually not the end user but whoever in your internal team must greenlight the app before it is released to the public. At many companies, such as Google, Yahoo, and Facebook, most projects do not pass internal review and are never released to the public.

· Document product and feature requests: Clients usually have an overall product vision, a list of tasks the user must be able to complete with the app. Often, clients have features in mind that would help accomplish those tasks.

· Agree on deliverables and a timeline: Almost every client will imagine a much bigger product than you have time to build. For a developer, it is extremely important to understand what features are absolutely necessary and must be built, and what features are “nice to have” if there is time remaining at the end of the project. If every feature is a “must have” you need to either push the client to prioritize something, or make sure you have given yourself enough time.

Estimating the time to complete software projects is one of the most difficult project management tasks. There is greater variability and uncertainty than physical construction projects, like building a house, or intellectual projects, like writing a memo. The most experienced developers at the world’s best software companies routinely miss estimates, so don’t feel bad if completion takes longer than you think. Your estimation skill will improve with time and practice.

After separating the necessary features from the “nice to have,” you should decide which features are easy and which are complex. Without previous experience this might seem difficult, but think about whether other applications have similar functionality. You should also try searching the web for forum posts, or products that have the feature. If no product implements the feature, and all online discussion portray the task as difficult it would be worthwhile agreeing up-front on an alternative.

· Discuss tools and software you will use to complete the project, and your users will use to consume the project: Take the time to understand your client and user’s workflow to avoid surprises from incompatible software. Web software usually works across a variety of devices, but older operating systems and browsers can cause problems. Defining at the start of the project exactly which browser versions you will support (such as Internet Explorer 9 and later), and which devices (such as desktop and iPhone only) will save development and testing time. Usually, these decisions are based on how many existing users are on those platforms, and many organizations will support a browser version if used by a substantial amount of the user base — usually at least five percent.

Browser incompatibilities are decreasing as the latest desktop and mobile browsers updates themselves, and are now easier to keep up-to-date.

Meeting the People Who Bring a Web App to Life

You will be able to complete the app in this book by yourself, but the apps you build at work or use every day, like Google Maps or Instagram, are created by teams of people. Teams for a single product can vary in size, reaching upwards of 50 people, and each person plays a specific role across areas like design, development, product management, and testing. In smaller companies, the same person may perform multiple roles, while at larger companies the roles become more specialized and individual people perform each role.

Creating with designers

Before any code has been written, designers work to create the site look and feel through layout, visuals, and interactions. Designers answer simple questions like “should the navigational menu be at the top of the page or the bottom?” to more complex questions like “how can we convey a sense of simplicity, creativity, and playfulness?” In general, designers answer these types of questions by interviewing users, creating many designs of the same product idea, and then making a final decision by choosing one design. Good design can greatly increase adoption of a product or use of site, and products like Apple’s iPhone and Airbnb.com. (See Figure 10-3.)

When building a website or app, you may decide you need a designer, but keep in mind within design there are multiple roles that designers play. The following roles are complementary, and may all be done by one person or by separate people:

· User interface (UI) and user experience (UX) designers deal primarily with “look and feel” and with layout. When you browse a website, for example Amazon, you may notice that across all pages the navigation menus, and content are in the same place, and use identical or very similar font, buttons, input boxes, and images. The UI/UX designer thinks about the order in which screens are displayed to the user, along with where and how the user clicks, enters text, and otherwise interacts with the website. If you eavesdropped on UI/UX designers, you may hear conversation like, “his page is too busy with too many call to actions. Our users don’t make this many decisions anywhere else on the site. Let’s simplify the layout by having just a single Buy button so anyone can order in just one click.”

· Visual designers deal primarily with creating the final graphics used on a website, and is the role most closely associated with “designer”. The visual designer creates final versions of icons, logos, buttons, typography, images. For example, look at your Internet browser — the browser icon, the Back, Reload, and Bookmark buttons are all created by a visual designer, and anyone using the browser for the first time will know what the icons mean without explanation. If you eavesdropped on visual designers, you may hear conversation like, “The color contrast on these icons is too light to be readable, and if including text with the icon, let’s center-align the text below the icon instead of above it.”

· Interaction designers deal primarily with interactions and animations based on user input and situation. Initially, interaction design were limited to keyboard and mouse interactions, but today touch sensors on mobile devices have created many more potential user interactions. The interaction designer thinks about how to use the best interaction so the user is able to complete a task as easily as possible. For example, think about how you check your email on your mobile phone. For many years, the traditional interaction was to see a list of messages, click on a message, and then click on a button to reply, flag, folder, or delete the message. In 2013, interaction designers rethought the email app interaction, and created an interaction so users could swipe their finger left or right to delete or reply to email messages instead of having to click through multiple menus. If you eavesdropped on interaction designers, you may hear conversation like, “While users are navigating with our maps app, instead of letting us know they are lost by clicking or swiping, maybe they can shake the phone and we instantly have a location specialist call them.”

Figure 10-3: Jonathan Ive, SVP of Design at Apple, is credited for Apple’s design successes.

If creating an app was like making a movie, designers would be screenwriters.

Coding with front- and back-end developers

After the design is complete, the front-end and back-end developers make those designs a reality. Front-end developers, such as Mark Otto and Jacob Thornton (see Figure 10-4), code in HTML, CSS, and JavaScript, and convert the design into a user interface. These developers write the same code that you have been learning throughout this book, and ensure the website looks consistent across devices (desktop, laptop, and mobile), browsers (Chrome, Firefox, Safari, and so on), and operating systems (Windows, Mac, and so on). All these factors, especially increased adoption of mobile device, result in thousands of combinations that must be coded for and tested because every device, browser, and operating system renders HTML and CSS differently.

Figure 10-4: Mark Otto and Jacob Thornton created Bootstrap, the most popular front-end framework.

If creating an app was like making a movie, front-end developers would be the starring actors.

Back-end developers such as Yukihiro Matsumoto (see Figure 10-5) add functionality to the user interface created by the front-end developers. Back-end developers ensure everything that’s not visible to the user and behind the scenes is in place for the product to work as expected. Back-end developers use server-side languages like Python, PHP, and Ruby to add logic around what content to show, when, and to whom. In addition, they use databases to store user data, and create servers to serve all of this code to the users.

If creating an app was like making a movie, back-end developers would be the cinematographers, stunt coordinators, makeup artists, and set designers.

Figure 10-5: Yukihiro Matsumoto created Ruby, a popular server-side language used to create websites.

Managing with product managers

Product managers help define the product to be built, and manage the product development process. When engineering teams are small (such as fifteen people or less) communication, roles, and accountability are easily managed internally without much formal oversight. As engineering teams grows, the overhead of everyone communicating with each other also grows, and without some process can become unmanageable, leading to miscommunication and missed deadlines. Product managers serve to lessen the communication overhead, and when issues arise as products are being built decide whether to extend timelines, cut scope, or add more resources to the team. Product managers are often former engineers, who have a natural advantage in helping solve technical challenges that arise, but non-technical people are also assuming the role with success. Usually, no engineers report to the product manager, causing some to comment that product managers have “all of the responsibility, and none of the authority.” One product manager wielding great responsibility and authority is Sundar Pichai, who originally was a product manager for the Google toolbar, and recently was appointed to oversee many of Google’s products, including search, Android, Chrome, maps, ads, and Google+. (See Figure 10-6.)

Figure 10-6: Sundar Pichai oversees almost every major Google product.

Testing with quality assurance

Testing is the final step of the journey after an app or website has been built. As a result of the many hands that helped with production, the newly created product will inevitably have bugs. Lists are made of all the core app user tasks and flows, and human testers along with automated programs go through the list over and over again on different browsers, devices, and operating systems to find errors. Testers compile the newly discovered bugs, and send them back to the developers, who prioritize which bugs to squash first. Trade-offs are always made between how many users are affected by a bug, the time it takes to fix the bug, and the time left until the product must be released. The most important bugs are fixed immediately, and minor bugs are scheduled to be fixed with updates or later released. Today, companies also rely on feedback systems and collect error reports from users, with feedback forms and in some cases through automated reporting.