Planning your app

Introduction

Once you have an idea for a Web app, you should carefully plan it before you start to do any coding or design. This will be amazingly obvious to most of you, but it's a point that cannot be overstated, whether you're creating a completely new app, or repurposing an existing application. This article covers the main concepts to keep in mind as you plan an application and prepare for implementation.

Note that this is a simple, general purpose workflow, designed to help people get started; if you're an experienced enterprise developer then you'll probably have a workflow and practices of your own to apply to open Web app development, which is fine.

A statement of intent

To start with, you should write down the app's intended functionality and target audience as concisely as possible, and you should think about the context/situation in which the target audience might use the app. For my simple Location Finder app, I wrote down two lists, as follows:

Functionality

• Get device location as accurately as possible
• Plot that location on a Google map

User groups

• Developers wanting to learn about open Web app and Firefox OS development, probably in an office or on a train
• Anyone wanting to find out where they are, mostly like outdoors/away from home

You should make the app as simple as possible; focus on getting it to do one thing—or a few closely related things—well. If you have loads of different use cases you want to achieve, you might want to split them across different apps. Your app that may require a different experience on different platforms, so you may have to have separate lists for desktop and mobile (or even tablet, TV, etc.)

Next, try to write a user-friendly summary of your app, which will entice people to download it and try it. If you can summarize it in a sentence, then your idea is probably a good fit for an app! For Location Finder, I wrote:

Location finder uses geolocation to find out where you are, and plots a map of your surroundings using the Google Maps API.

OK, for an app purely aimed at end users, I normally wouldn't include the names of the technologies; it would turn out more like this:

Location finder finds out where you are, then plots a map of your surroundings.

But since this app is largely aimed at teaching developers, I decided this information would be useful.

Sketching out your app

Once you have decided on your app's intent and target audience, it is always a good idea to start with paper sketches—try drawing out different rough screens to show what the app could look like, and what the workflow will be as the user uses your app. You'll probably want to do a separate set of sketches for desktop, mobile, tablet, TV, etc, if your functionality lists from above require it.

In any case, include notes on what graphic assets, functions, etc. are needed at each stage, as this will inform your choices when you get to the design and development stages, and ensure that you are less likely to miss something. For Location Finder, the functionality is very simple, so I decided I only needed one sketch:

For a more complicated app, you may want to include multiple screen sketches to show the main view, and then different views representing different workflows as the user uses the app.

Can any program (be converted to) work as an open Web app?

Just about any page, program or site can work as an open Web app, as long as you keep in mind the advice we've already given above; keep it simple above all else. If an app is particularly complicated (such as a word processor or a large e-commerce platform), then it will not work as an app in all contexts, therefore you need to think about creating a different experience for say, mobile or tablet devices. For example, eBay's desktop site has advertisements, different search mechanisms, and a whole host of other features. The mobile version of the site, in comparison, hides most of the features and adverts, presenting just the most popular functions at the top of the interface, and minimizing the amount of keyboard interaction needed.

Google Docs is another interesting example to consider. The desktop site is a fully-functional word processor with lots of controls available, but this would be a nightmare to use on a mobile site, therefore the mobile version simply lets you read your documents, with a simple interface.

At this stage, have a think about how you will present the different versions. In most situations you will be able to use media queries to optimize the layout and functionality of your project for different browsers. However, if you have been given the task of creating a mobile app version of a heavy, legacy, enterprise desktop web site—or if the desktop and mobile experiences prove too radically different—bear in mind that you might be better off creating a separate mobile/tablet site or app.

Think about the technologies you need

Some people will fold this stage into the "Statement of Intent" stage above, but arguably it's often better to consider your functionality/layout completely separately from your technology. You should think about your functionality purely in terms of what's best for your users in the first instance, rather than trying to shoehorn a technology into a project because it's the latest, coolest, shiniest toy. Usually the simplest approach is the best.

We discuss such considerations in much more detail in our Developing Web Apps section, but in general you should think about the main functionality/requirements your app has, and the technologies that are likely to be best for implementing them. Examples of questions you should ask include:

• Do you need offline storage? If your application needs to persist data, you'd normally use a server-side language and database. If you want to continue using it when offline/installed on a device, you may well have to store data in a client-side storage mechanism, such as IndexedDB or localStorage.
• Do you want to play or manipulate media? You will probably need HTML5 features such as <canvas>, <video>, or <audio>.
• Do you want to obtain information from the device and its surroundings? You'll need to use one of the many available device APIs, such as the Battery Status API, Proximity API, or Device Orientation API.

Testing plan

Another thing that is usually considered obvious but often gets overlooked is testing. You should test as early and as often as possible, as fundamental mistakes discovered early on can save a lot of time and money further on in the project when a lot of development have been done. A general testing plan is as follows:

• Once you have written your app's statement of functionality and target audience, share it with a number of colleagues, friends and family. Does it sound like a good idea from the outset, or does it sound ridiculous? Does it just need tweaking or moderate rescoping?
• Share your rough sketches for feedback as well. Is anything obvious missing? Would anything else add significantly to the experience?
• Next, it is often a good idea to create a functional prototype that allows people to test key functionality and interactions. Get a selection of real users outside the development team to test these interactions and see how well they fared. If you can't afford a professional user testing setup, then no matter—a selection of friends and family is often nearly as good, provided you administer the right questions and tests.
• As you work through developing the app, repeat the user testing procedure as many times as is sensible. Now you are working with the real app, test on as many varied browsers and devices as you can, starting with the primary support targets and working outwards. Consider what is an acceptable experience on each browser and device, and don't just test normal usage—see how the app performs under stress, and with edge cases such as malicious data entry and really old browsers.
• Near the end of the project, put a rigorous round of QA testing in to weed out any last minute evil bugs; the ones that always bite you on the neck when you least expect it.

Conclusion: points to consider

Hopefully this article will have given you most of what you need to consider before creating a successful open Web app. The list below provides a summary.

What is the purpose of your app?

Create a list of tasks, an idea for your app and the type of user you are targeting, and then write a goal statement: Define your app's purpose and the most important user in one sentence if possible. Example: A wish list creation tool for people who never do impulse shopping.

Focus on one main use case

It's possible that you cannot include all the tasks on your list in your goal statement. That is OK, because awesome apps — especially those for mobile — do one thing well. If your app is trying to do too many things, then think about splitting up the functionality over multiple apps. Although, if your application needs a lot of features to deliver its value, remember that you could consider delivering a Web app to desktop PCs only.

How will people use your app?

By now, you've identified your main use case, target users, and key features. Your main scenario should also consider the user environment in which your app is used. For example, a young mom with her baby at daycare might use your app to note a nice stroller (potential multi-tasking, pausing and continuing the task later). A different user might plan her next laptop purchase at home, in an armchair, without interruptions.

Concentrate on a few key features

Look at your task list again. Filter your list through the goal statement. If the tasks do not align with your goal statement, exclude them from your app. Describe each core task as a feature and then ask yourself, is this feature essential? Or is it nice-to-have but not required by the target user to complete the defined task? Be honest with yourself. If you end up with a short list of features, you are on the right track. Remember, the best apps usually do one thing well. Apps often fail not because they have too few features, but too many.

However, if you simply have to deliver a large feature set to reach your goal, consider making a desktop Web app your primary app and then offer a complementary mobile app with just the features and functions a user may need while away from their desk.

Sketch out your app

Once you have a few key interactions in mind, you can translate those steps into screens. You can sketch out the user flow, that is, what do your users go from one screen to another to complete a task. Think about the functionality of your app, and put the user interface elements that correspond to the most important interactions in the most prominent places. Think about how the screens will look on desktop versus tablet/mobile.

Required technologies

Look at your list of functionality, and make some notes about what technologies you will likely use to build those requirements.

Testing plan

Build a reasonable testing plan into your project plan, to reduce the chance of being hit by expensive unexpected surprises later on in the implementation stages.

See also

• Open Web apps
• Developing your Web app