Планирование Вашего приложения

Введение

Если у вас есть идея для веб-приложения, вы должны тщательно спланировать его, прежде чем начать писать  него код или оформлять его дизайн. Конечно для большинства из Вас будет очевидным такой подход, но начать именно с данной отправной точки - очень важно, когда вы создаете приложение полностью с нуля, или же используете повторно уже существующее приложение.  В данной статье рассматриваются основные концепции  планирования и подготовки к реализации.

Обратите внимание, что это простой рабочий процесс общего назначения, разработанный для того, чтобы помочь людям начать; если вы опытный разработчик корпоративных систем, тогда, скорее всего, у Вас свое видение рабочих процессов и способов развертки Web-приложений и сможете самостоятельно выбрать лучший.

Утверждение намерений

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:

Функции

• Узнать расположение устройства как можно точнее
• Вывести расположение через Карты Google

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 what they are, mostly like outdoors/away from home

Вы должны сделать приложение как можно точнее; 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 summarise 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.

Делаем набросок Вашего приложения

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.

Может ли любая программа (быть преобразованной) работать как открытое веб приложение?

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.

Подумайте о технологиях, которые Вам понадобятся

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.

Тестирование плана

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.

Итог: моменты, которые нужно учесть

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.

Какая цель у Вашего приложения?

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.

Сконцентрируйтесь на основном функционале

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.

Как люди будут пользоваться Вашим приложением?

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.

Сконцентрируйтесь на нескольких ключевых характеристиках

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.

Сделайте набросок Вашего приложения

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.

Требуемые технологии

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

Тестирование плана

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.

Смотрите также

• Центр приложений
• Разработка Вашего приложения