Процесс проектирования приложений для Windows Store
Процесс проектирования приложений заключается в определение внутренних свойств системы и детализации её внешних (видимых) свойств на основе выданных заказчиком требований к приложению. Все требования к приложению указываются в техническом задании на разработку программного обеспечения. Как уже отмечалось выше, от качества реализации технического задания зависит качество всего приложения.
Процесс проектирования приложения основывается на техническом задании. В основе любой программы её содержимое, т.е. предметная область. При разработке приложений анализ требований к системе сводится к разработке моделей этой системы. Моделью системы (или какого-либо другого объекта или явления) является формальное описание системы, в котором выделены основные объекты, составляющие систему, и отношения между этими объектами. Построение моделей - широко распространенный способ изучения сложных объектов и явлений. В модели опущены многочисленные детали, усложняющие понимание. Моделирование широко распространено и в науке, и в технике.
При проектировании приложений для Windows Store, программная система представляется в виде трех взаимосвязанных моделей:
- объектной модели, которая представляет статические, структурные аспекты системы, в основном связанные с данными;
- динамической модели, которая описывает работу отдельных частей системы;
- функциональной модели, в которой рассматривается взаимодействие отдельных частей системы (как по данным, так и по управлению) в процессе ее работы, в том числе интерфейс.
Эти три вида моделей позволяют получить три "взаимно-ортогональных" представления системы в одной системе обозначений. Совокупность моделей системы может быть проинтерпретирована на компьютере (с помощью инструментального программного обеспечения), что позволяет продемонстрировать заказчику (будущему пользователю, тестеру) характер работы с будущей системой и существенно упрощает согласование предварительного проекта системы.
Модели, разработанные и отлаженные на первой фазе жизненного цикла системы, продолжают использоваться на всех последующих его фазах, облегчая программирование системы, ее отладку и тестирование, сопровождение и дальнейшую модификацию. Модели системы не связаны с языком программирования, на котором будет реализована система.
При разработке эскизного проекта WinRT программа, первоначально, рассматривается как чёрный ящик. Ход процесса проектирования и его результаты зависят не только от состава требований, но и выбранной модели процесса, опыта проектировщика. Модель предметной области накладывает ограничения на логику приложения, структуры данных и интерфейс.
В российской практике проектирование ведется поэтапно в соответствии со стадиями, регламентированными ГОСТ 2.103-68: Техническое задание, Техническое предложение, Эскизный проект, Технический проект, Рабочий проект. На каждом из этапов формируется свой комплект документов, называемый проектом (проектной документацией). В зарубежной практике регламентирующими документами, например, являются Software Architecture Document, Software Design Document. При разработке приложений для Windows Store накладываются дополнительные требования к архитектуре ПО, компонентам и интерфейсу.
На этапе эскизного проектирования осуществляется разработка предварительных проектных решений как по приложению в целом, так и по частям. На данном этапе осуществляется планирование приложения. Основываясь на техническом задании, разработчик должен ответить на целый ряд вопросов:
- Для чего нужно приложение?
- Что особенного в приложении?
- Чего сможет достичь пользователь благодаря приложению?
- Определить набор функций, реализуемых в приложении.
- Определить возможности персонализации.
- Как организовать содержимое пользовательского интерфейса (навигация)?
- Как организовать команды?
Результатом эскизного проекта является прототип приложения. Прежде чем погрузиться в детальную разработку (рабочий проект), необходимо проверить проект или прототип на соответствие требованиям, нормативам и ожиданиям пользователей во избежание необходимости впоследствии все переделывать. В рассматриваемой предметной области существуют нормы качества и рекомендации, соблюдение которых поможет значительно улучшить качество приложения. Кроме того, существуют средства для оценки качества продукта с точки зрения разработчика, такие как комплект сертификации приложений для Windows.
Оценка качества прототипа осуществляется в два этапа:
Этап 1: Собственная оценка.
Этап собственной оценки - это первый уровень оценки восприятия разрабатываемого приложения пользователями, который основан на поставленных ранее целях. Цель этого метода оценки - обеспечить разработку проекта в соответствии с поставленными задачами. Время затрачиваемое на этап - индивидуально для каждого приложения и зависит от количества основных сценариев в нем. Метод оценки можно использовать как при эскизном проектировании, так и в любой другой момент разработки.
К оценке привлекается один или несколько проектировщиков или разработчиков.
Суть метода: перечисление основных механизмов или задач, которые в соответствии с замыслом должны быть предоставлены пользователям в создаваемом приложении. Например, в приложении "Составь слово" задачей может быть набор и отправка одного слова.
В полученном списке задач расставляются приоритеты: от наиболее важной задачи, до наименее важной. Выполняются задачи из списка в приложении. Выполняя задачи, сравниваются полученные результаты с шаблоном планирования, который создан в процессе постановки целей на самых первых этапах проектирования. Оценивается степень решения первоначальных задач. Если первоначальные задачи не решены, то в каком состоянии находится приложение? Что нужно сделать, чтобы обеспечить достижение целей?
Когнитивный анализ - это метод оценки, в рамках которого пользователи выполняют в приложении определенные задачи и предоставляют обратную связь от приложения к разработчику в процессе выполнения. Этот метод имеет явное преимущество перед методом собственной оценки, так как обратная связь предоставляется реальными пользователями приложения. Важнейшим аспектом метода является то, что по ходу выполнения поставленных задач пользователи могут выступать с любыми замечаниями и предложениями.
Время, затрачиваемое на анализ, индивидуально для каждого приложения и зависит от количества основных сценариев в нем. Метод используется на любом этапе разработки.
К оценке привлекаются один или несколько пользователей приложения, принадлежащих к целевой аудитории. При наличии конкретного заказчика-потребителя, целевая аудитория - это сотрудники заказчика. Если программная система направлена широкую аудитория, например для реализации через Windows Store, то необходимо определите целевую аудиторию. Для этого необходимо поставить перед собой ряд вопросов и ответить на них, например:
- Кто будет использовать мое приложение?
- Каков возраст аудитории?
- Что отличает эту аудиторию от других?
При реализации этапа, как и в случае Собственного анализа, осуществляется перечисление основных механизмов или задач, которые в соответствии с замыслом должны быть предоставлены пользователям. Задачи выстраиваются в соответствии с приоритетами каждым пользователем в отдельности. Пока пользователи оценивают приложение, осуществите собственную оценку. Поставьте перед собой ряд вопросов, например:
- Достигнуты ли в приложении цели, которые я первоначально запланировал?
- Справляются ли пользователи с каждой задачей?
- С какими проблемами они сталкиваются при выполнении задачи?
- Соответствует ли их опыт выполнения задач целям, которые я изначально поставил для своего приложения?
- В каком состоянии находится мое приложение?
- Что нужно сделать, чтобы обеспечить достижение целей?
Результаты анализа всегда следует документировать, делать выводы, выставлять оценки.
Понятие интерфейса
Как отмечалось выше, пользовательский интерфейс является одним из основных отличий приложений для магазина Windows. Ошибочно думать, что пользовательский интерфейс - это всего лишь представление приложения в виде "живой плитки" вместо старых иконок на рабочем столе. На самом деле стиль включает много концепций и принципов организации интерфейса приложения.
Как было отмечено в данной лекции, концепции и принципы реализуются на этапах проектирования. Рассмотрим основные отличия в проектировании интерфейсов от "старых" типов приложений.
Содержание прежде всего
Старые типы приложений могли содержать не только рамку окна, но и дополнительные панели инструментов, меню, строки состояния и т.д. Все эти элементы казались неотъемлемой частью любого интерфейса. Очень часто эти элементы занимали достаточно много места на экране, и, в большинстве случаев, не подходили для работы с жестами и касаниями.
Использование стиля предполагает, что пользователь сосредоточен лишь на работе с контентом. Все подобные приложения ориентированы на работу в полноэкранном режиме, а дополнительные элементы управления появляются лишь тогда, когда действительно необходимы.
Среди стандартных элементов можно выделить панель приложения (Application Bar), которая появляется при нажатии правой кнопки мыши или при выполнении жеста, направленного от нижней границы планшета к центру. Примером реализации такой панели может служить приложение Internet Explorer 10 для Windows Store. Здесь присутствуют сразу две панели приложения, обеспечивающие взаимодействие пользователя с окнами и предоставляющие механизм навигации, но только тогда, когда это необходимо пользователю. В остальное время пользователь работает только с контентом страницы.
Быстрый и отзывчивый
Следующий принцип, на котором основывается интерфейс, - это отзывчивость при взаимодействии пользователя с интерфейсом. Это достигается путем вставки анимации, которая запускается при взаимодействии пользователя с тем или иным элементом интерфейса (контентом). Важно то, что пользователь может взаимодействовать с приложением при помощи как мыши, так и пальца. Если взаимодействие осуществляется с помощью мыши, то статичность интерфейса еще допустима (по крайней мере, курсор мыши движется). Но в случае взаимодействия с интерфейсом с помощью пальцев может возникать ощущение "подвисшего" приложения для статического интерфейса. Ведь не любое взаимодействие с контентом приводит к каким-то конкретным действиям (переход на другую страницу, прокрутка и т. д.). Поэтому необходимо стараться сделать интерфейс динамичным и отзывчивым по отношению к действиям пользователя.
С другой стороны, не следует излишне перегружать анимацией свой интерфейс, необходимо стараться сохранять баланс.
Масштабируемый
Многие устройства, поступающие сегодня на рынок, поддерживают большой набор разрешений и различные варианты ориентации. Именно поэтому необходимо разрабатывать интерфейс таким образом, чтобы он хорошо работал в любых типах разрешений экрана и с поддержкой альбомной и книжной ориентации.
Ориентация на прикосновения и жесты
При работе над несколькими приложениями для Windows 8 удалось увидеть много примеров того, что приложение может успешно работать с мышью, но быть совершенно неприспособленным для работы с жестами. В качестве примера можно взять приложение, отображающее на экран журнал или книгу. Возникает желание реализовать перелистывание страниц так, как это происходит в обычной книге. Пользователь берет мышь, тянет за край страницы, и она успешно переворачивается. Но как только пользователь начинает работать с жестами, вместо переворота страниц у него появляется панель управления системы или приложение переключается на другое. Все дело в том, что система также реализует свои действия в ответ на жесты, и это необходимо учитывать.
В целом, создавая приложение для Windows Store, нужно помнить о следующих вещах:
- работа с помощью касаний и жестов будет преобладать среди пользователей приложения. Поэтому необходимо тщательно тестировать приложение;
- реализовать механизмы взаимодействия с контентом следует таким образом, чтобы они не пересекались со стандартными механизмами, заложенными в операционной системе.
Контракты
Предположим, что разрабатывается специализированное приложение, которое позволяет создавать изображения. Создав изображение, необходимо иметь возможность опубликовать его в Facebook, Twitter и других социальных сетях. Чтобы это сделать, можно реализовать функциональность клиентов Facebook, Twitter и т.д., что не очень правильно, так как потребует изрядных усилий, и подобная функциональность уже присутствует на машине у пользователя.
Кроме того, социальных сетей много, и заранее не известно, в какой из них пользователь будет публиковать свои данные. Поэтому логично было бы задействовать уже существующие приложения, предоставив всем программам по работе с социальными сетями специализированный источник данных приложения.
Естественно, чтобы одно приложение могло предоставлять данные, а второе - использовать, необходимо, чтобы они работали по заранее сформированным правилам или контрактам. И такие контракты есть, Windows 8 предоставляет их в большом количестве.
Плитки (Tiles)
Плитки и оповещения внутри них не только придают уникальность приложению и создают первое впечатление у пользователя, но и позволяют пользователю создать его собственный уникальный рабочий стол. Именно поэтому уделяйте плиткам как можно больше внимания и попытайтесь определить, можно ли что-то новое показать пользователю (последнюю фотографию, количество непрочитанных сообщений и т.д.). При этом существует два режима отображения плиток: стандартный и расширенный. Поэтому если в какой-то момент информация будет не интересна пользователю, он просто уменьшит размер плитки приложения.
Обратите внимание на то, что плитки на основном экране можно создавать и из самого приложения. Это необходимо в том случае, когда пользователь хочет определить быстрый механизм доступа к какой-либо из частей приложения. В этом случае наряду с основной плиткой на экране может располагаться и второстепенная плитка. Естественно, разработчик должен позаботиться о том, чтобы предоставить пользователю возможность создать второстепенную плитку.
Всегда готов к работе
Сегодня многие устройства оснащены не только передатчиками WiFi, но и 3G-модемами и большую часть времени находятся в сети. Несмотря на это, при проектировании собственного приложения необходимо учитывать и возможность работы после разъединения. Иными словами, приложение должно работать даже при отключении от сети.
Независим от устройства
В современном мире пользователь может иметь более чем одно устройство. Задача разработчика при проектировании приложений для Windows Store состоит в том, чтобы сделать использование приложения "родным" на любом из устройств. Для этого Windows 8 предлагает множество механизмов, которые позволяют сохранить настройки в облаке и использовать их на любой другой машине пользователя.
Краткие итоги
В лекции определены особенности проектирования приложений для Windows Store. Приведены этапы процесса проектирования программного обеспечения. Определены задачи каждого этапа.
Вопросы
- Стадии проектирования программного обеспечения.
- Этапы разработки технического задания.
- Что такое объектная модель?
- Что такое динамическая модель?
- Что такое функциональная модель?
- Назначение эскизного проекта.
- Этапы оценки прототипа
- Назначение рабочего проекта.
- Для чего необходимо сопровождение программного продукта?