Deine App planen

Einführung

Wenn Du erst eine Idee für Deine Web-App hast, solltest Du sie sorgfältig planen, bevor mit dem Coden oder dem Design beginnst. Das ist den meisten von euch natürlich bewusst, aber diesen Punkt kann man nicht genug betonen, egal ob Du eine völlig neue App beginnst oder eine bestehende anpasst. Dieser Artikel beleuchtet die hauptsächlichen Konzepte, die Du während der Planung und Implementierungsvorbereitung im Hinterkopf haben solltest.

Beachte, dass das ein einfacher und allgemeiner Ablauf ist, der dazu entwickelt wurde, Leuten zu helfen anzufangen. Wenn Du ein erfahrener Entwickler bist, hast Du wahrscheinlich eigene Abläufe und Praktiken, die Du für die Web-App-Entwicklung benutzt, was natürlich in Ordnung ist.

Eine Absichtserklärung

Um anzufangen, solltest Du die beabsichtigte Funktion der App und das Zielpublikum so prägnant wie möglich aufschreiben. Außerdem solltest Du Dir über den Zusammenhang Gedanken machen, in welchem der Benutzer die App vermutlich benutzen wird. Für meine einfache Location Finder-App habe ich zwei Listen notiert:

Funktionalität

• bestimme den Gerätestandort so genau wie möglich
• zeichne diese Position auf einer Google-Karte

Benutzer

• Entwickler, die etwas über Web-App- und Firefox-OS-Entwicklung lernen wollen, wahrscheinlich in einem Büro oder einem Zug
• jemand, der herausfinden möchte, wo er ist, wahrscheinlich draußen oder unterwegs

Du solltest Deine App so einfach wie möglich gestalten. Konzentriere Dich darauf, genau eine Sache oder ein paar zusammenhängende Aufgaben zu erledigen. Wenn Du mehrere verschiedene Anwendungsfälle hast, willst Du sie vielleicht auf mehrere verschiedene Apps aufteilen. Deine App könnte verschiedene Bedienung auf verschiedenen Plattformen erfordern,  also wirst Du eventuell getrennte Listen für Desktop- und mobile Geräte (oder sogar Tablet, TV, etc.) benötigen.

Versuche als nächstes, eine benutzerfreundliche Zusammenfassung Deiner App zu schreiben, die die Leute einlädt, die App herunterzuladen und auszuprobieren. Wenn Du deine Idee in einem Satz zusammenfassen kannst, ist sie vermutlich gut für eine App! Für den Location Finder habe ich aufgeschrieben:

Location Finder benutzt Geolocation, um herauszufinden, wo Du bist, und zeichnet eine Karte Deiner Umgebung unter Benutzung der Google-Maps-API.

OK, für eine App, die ausschließlich auf Endanwender abzielt, hätte ich normalerweise nicht die Namen der verwendeten Technologien erwähnt, es würde vermutlich so aussehen:

Location Finder findet heraus, wo Du bist, und zeichnet eine Karte mit Deiner Umgebung.

Aber weil die App dazu gedacht ist, Entwickler beim Lernen zu helfen, habe ich entschieden, dass diese Informationen sinnvoll sind.

Die App skizzieren

Wenn Du Dich für den Zweck und die Zielgruppe entschieden hast, ist es meist eine gute Idee, mit Skizzen auf Papier weiter zu machen. Versuche, grob verschiedene Bildschirmansichten zu zeichnen, die zeigen, wie die App aussehen könnte und wie der Ablauf sein würde, wenn Deine App benutzt wird. Wahrscheinlich willst Du verschiedene Skizzensätze für den Desktop, Mobile, Tablet, TV u.s.w. anfertigen, wenn es Deine Funktionsliste von oben erfordert.

Füge den Skizzen auf jeden Fall Notizen über benötigte graphische Elemente, Funktionen hinzu, die in den einzelnen Abschnitten benötigt werden, das wird Dich unterstützen, wenn Du zu den Design- und Entwicklungsabschnitten gelangst und sicherstellen, dass Du bestimmt nichts vergisst. Für den Location Finder war die Funktionalität so einfach, dass ich mich für nur eine Skizze entschieden habe:

Für kompliziertere Apps wirst Du vermutlich mehrere Bildschirmskizzen benötigen, die den Hauptbildschirm und die verschiedenen Ansichten zeigen, die die verschiedenen Abläufe repräsentieren, wenn der Benutzer die App verwendet.

Kann jedes Programm auch als App funktionieren?

Fast jede Seite oder Programm funtioniert als App, so lange Du an den Rat denkst, den wir schon oben gegeben haben: halte es vor allem einfach. Ist eine App besonders kompliziert (so wie eine Textverarbeitung oder eine große e-commerce-Plattform), wird sie nicht unter allen Umständen funktionieren, deshalb musst Du Dir Gedanken machen über verschiedene Bedienungen z.B. für mobile Geräte oder Tablets. eBay's Desktop-Seite hat zum Beispiel Werbung, verschiedene Suchmöglichkeiten und eine Menge anderer Features. Die mobile Version dieser Seite dagegen versteckt die meisten dieser Features und die Werbung und präsentiert nur die wichtigsten Funktionen oben in der Ansicht und minimiert die benötigte Tipparbeit.

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 is possible that you cannot include all the tasks on your list in your goal statement. That is ok, because awesome apps do one thing well. If your app is trying to do too many things, then think about splitting up the functionality over multiple apps.

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 little features, but too many.

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