MDN’s new design is in Beta! A sneak peek: https://blog.mozilla.org/opendesign/mdns-new-design-beta/

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

Перевод не завершен. Пожалуйста, помогите перевести эту статью с английского.

Введение

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

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

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

 Начнем с того, что вы должны записать предполагаемую функциональность и целевую аудиторию приложения максимально кратко, и вам следует подумать о контексте / ситуации, в которой целевая аудитория может использовать приложение. Для моего простого приложения Location Finde я записал два списка:

    Функции

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

 Разработчики, желающие узнать об открытом веб-приложении и разработке ОС Firefox, возможно, в офисе или на поезде
Любой, кто хочет узнать, что это такое, в основном, на улице или вдали от дома

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

 Затем попробуйте написать удобную для пользователя краткую информацию о вашем приложении, которая заставит людей загружать ее и попробовать. Если вы можете суммировать его в предложении, то ваша идея, вероятно, соответствует  для данного приложения! Для Location Finder я написал:

Поиск местоположения использует геолокацию, чтобы узнать, где вы находитесь, и создает карту вашего окружения с помощью Google Maps API.

ОК, для приложения, предназначенного исключительно для конечных пользователей, я обычно не включал бы имена технологий;

Поисковик обнаруживает, где вы находитесь, а затем строит карту вашего окружения.

Но так как это приложение в основном предназначено для обучения разработчиков, я решил, что эта информация будет полезна.

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

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

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

Drawing of an app window, which includes a title bar containing the title Location Finder, and an install button, plus a map covering the res tof the window Для более сложного приложения вы можете захотеть включить многоразовые экранные эскизы чтобы показать основное представление, а затем различные представления, представляющие разные рабочие процессы, когда пользователь использует приложение.

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

 Практически любая страница, программа или сайт может работать как открытое веб-приложение, если вы помните о совете, который мы уже приводили выше; держите его простым превыше всего. Если приложение является особенно сложным (например, текстовым процессором или большой платформой для электронной коммерции), оно не будет работать в качестве приложения во всех контекстах, поэтому вам нужно подумать о создании другого опыта, скажем, мобильных или планшетных устройств , Например, на рабочем столе eBay's есть рекламные объявления, различные механизмы поиска и целый ряд других функций. В отличие от этого, мобильная версия сайта скрывает большинство функций и рекламных объявлений, представляя только самые популярные функции в верхней части интерфейса и сводя к минимуму необходимый объем взаимодействия с клавиатурой ..

screenshot of the ebay desktop site containing lots of adverts and controls                     screenshot of the ebay mobile site, with a much simpler interface than the desktop version

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

The google docs desktop site, which looks like a standard word processor                     The google docs mobile site, which is more of a document reader than a word processor

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

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

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

 Некоторые люди сворачивают этот этап в этап «Заявление о намерениях» выше, но, возможно, часто лучше рассматривать вашу функциональность / компоновку полностью отдельно от вашей технологии. Вы должны думать о своей функциональности исключительно с точки зрения того, что лучше для ваших пользователей в первую очередь, вместо того, чтобы пытаться загнать технологию в проект, потому что это последняя, самая крутая, самая блестящая игрушка. Обычно самый простой подход он же  лучший..

 Мы обсуждаем эти соображения более подробно в разделе Developing Web Apps, но в целом вам следует подумать об основных функциональных возможностях / требованиях вашего приложения и технологиях, которые, вероятно, будут лучше всего использовать их. Примеры вопросов, которые вы должны задать:

  • Нужно ли вам автономное хранилище? Если вашему приложению необходимо сохранять данные, вы обычно используете язык и базу данных на стороне сервера. Если вы хотите продолжать использовать его в автономном режиме / установленном на устройстве, возможно, вам придется хранить данные в механизме хранения на стороне клиента, таком как  IndexedDB или localStorage
  • Вы хотите играть или манипулировать медиа? Возможно, вам понадобятся функции HTML5, такие как <canvas>, <video> или <audio>.
  • Вы хотите получить информацию от устройства и его окружения? Вам нужно будет использовать один из многих доступных API-интерфейсов устройств, таких как Battery Status API, Proximity API, или Device Orientation API.

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

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

  • После того, как вы написали заявление о функциональности и целевой аудитории вашего приложения, поделитесь им с рядом коллег, друзей и семьи. Это звучит как хорошая идея с самого начала, или это звучит смешно? Нужно ли просто подгонять или умеренно скопировать?
  • Поделитесь своими  черновиками для обратной связи, а также. Что-то явно отсутствует? Может ли что-нибудь еще добавить к опыту?
  • Далее, часто неплохо создать функциональный прототип, который позволяет людям тестировать ключевые функциональные возможности и взаимодействия. Получите подборку реальных пользователей за пределами команды разработчиков, чтобы протестировать эти взаимодействия и посмотреть, насколько они оправдали себя. Если вы не можете позволить себе профессиональную настройку пользовательского тестирования, то неважно, выбор друзей и семьи часто почти столь же хорош, если вы управляете правильными вопросами и тестами..
  • По мере разработки приложения повторите процедуру тестирования пользователя столько раз, сколько это разумно. Теперь вы работаете с настоящим приложением, проверяйте как можно больше разнообразных браузеров и устройств, начиная с основных целей поддержки и заканчивая работой за пределами.Подумайте, что является приемлемым опытом для каждого браузера и устройства, и не просто проверяйте обычное использование - посмотрите, как приложение работает в условиях стресса, а также с такими крайними случаями, как вредоносный ввод данных и действительно старые браузеры.
  • Ближе к концу проекта, поставили тщательный раунд тестирования QA, чтобы отсеять любую последнюю минуту "злые" ошибки; те, которые всегда кусают вас за шею, когда вы меньше всего этого ожидаете.

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

Надеемся, эта статья даст вам большую часть того, что вам нужно рассмотреть, прежде чем создавать успешное открытое веб-приложение. Ниже приводится сводка.

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

Создайте список задач, идею для вашего приложения и тип пользователя, на который вы нацеливаетесь, а затем напишите утверждение цели: если возможно, определите цель вашего приложения и наиболее важный пользователь в одном предложении. Пример: инструмент создания списка пожеланий для людей, которые никогда не делают импульсивных покупок.

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

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

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

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

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

Посмотрите на свой список задач еще раз. Отфильтруйте свой список с помощью цели. Если задачи не соответствуют вашему заявлению цели, исключите их из своего приложения. Опишите каждую основную задачу как функцию, а затем спросите себя, действительно ли эта особенность важна? Или это хорошо, чтобы иметь, но не требуется для целевого пользователя для выполнения определенной задачи? Будь честен с собой. Если у вас есть короткий список функций, вы на правильном пути. Помните, что лучшие приложения обычно хорошо работают. Приложения часто проигрывают не потому, что у них слишком мало функций, но слишком много.
Однако, если вам просто нужно предоставить большой набор функций для достижения своей цели, подумайте о том, чтобы сделать desktop Web app основным приложением, а затем предложить дополнительное мобильное приложение с функциями и функциями, которые могут понадобиться пользователю, находясь вдали от своего рабочего стола.

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

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

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

Посмотрите на свой список функциональных возможностей и сделайте несколько замечаний о том, какие технологии вы, вероятно, будете использовать для создания этих требований.

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

Составьте разумный план тестирования в план вашего проекта, чтобы снизить вероятность попадания в результате дорогостоящих неожиданных неожиданностей на этапах внедрения.

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

Метки документа и участники

 Внесли вклад в эту страницу: AlexeyVasilievE, SergeMozillian, iVAN2002, Neir, bilazikboy
 Обновлялась последний раз: AlexeyVasilievE,