На хабре уже присутствует некоторое количество статей, посвященных процессу прототипирования в разработке программного обеспечения. Есть достаточно фундаментальные статьи с обзорами стандартов и расчетами, есть статьи про прототипирование устройств, есть цикл из двух статей про процесс выбора инструмента для прототипирования. К сожалению, процесс создания прототипов мобильных приложений освещен очень скудно – в виде единственной статьи в 2010 году, и пара слов в статье Разработка мобильных приложений: с чего начать.
Хотелось бы исправить эту ситуацию, и предложить вашему вниманию большой обзор доступных инструментов для прототипирования мобильных приложений.
Прототипирование — это создание макета, модели будущего приложения для того, чтобы определить правильность структуры приложения, его функциональности и, в целом, концепции приложения. Если приложение разрабатывается по стороннему заказу, клиенту также может показываться прототип для того, чтобы он мог контролировать и вносить корректировки в свое приложение.
Типы макетов сайта. Верстка страницы по макету. Как верстать макеты
Прототип обладает чудесным свойством устранять недопонимания между различными специалистами (менеджер, руководитель, дизайнер, программист, клиент), вовлеченными в проект, структурировать мысли и предотвращать ошибки и выполнение лишней работы еще на ранних стадиях разработки. Можно тестировать будущее приложение, используя фокус-группу, это поможет получить полезную информацию от будущих пользователей.
В ритме сегодняшней жизни при достаточно высокой цене человеко-часов, очень важно работать быстро и, желательно, без потери качества. Для этого было введено понятие “быстрое прототипирование”. Что поможет нам перейти от простого прототипа к быстрому? Это развивающиеся технологии, наличие огромного количества сервисов и, конечно, собственные мозги.
Самый популярный инструмент создания быстрых прототипов.
Первый и самый любимый инструмент дизайнеров — это бумага и любой пишущий инструмент (карандаш, ручка, маркеры). Он позволяет накидать структуру приложения и сделать первые наброски интерфейса максимально быстро.
Можно рисовать на доске, стене, бумаге. Однако этот способ имеет и ряд недостатков:
- почерк должен быть разборчивым, чтобы его понимала вся рабочая группа, и чтобы самому потом не расшифровывать собственные записи
- при удаленной работе неудобно демонстрировать такой прототип
Конечно, можно сфотографировать все бумажки и отправить их, например, по почте или скайпу, но без пояснений все равно вряд ли удастся обойтись.
Как ускорить и упростить «бумажное» прототипирование
Скетчпад (SketchPad, Скетчбук, sketchbook)
это блокнот разлинованый макетами телефонов разных платформ. Имеет точечную сетку на «экране».
Вы можете распечатать аналог скетчпада самостоятельно по шаблонам: habrahabr.ru/post/152075
Corel Draw за 1 час | Обзор основных функций программы | Делаем обучающий макет для соц. сетей
UI – блокнот
это тот же самый скетчпад, только без привязки к платформе. На нем можно рисовать абсолютно любые приложения
Лекала.
Штампы
В российских магазинах тоже отсутствуют, но можно заказать у компании по изготовлению печатей, или сделать самому из куска резины, если руки достаточно прямые. К сожалению, чернила – вещь довольно маркая, поэтому лучше все-таки не пытаться экономить и купить или распечатать скетчпад.
www.cultofmac.com/224355/iphone-stamp-for-ui-sketching
На этом с обзором «бумажных» инструментов закончим, и перейдем к самому интересному:
Программные решения для создания быстрых прототипов
Keynotopia
keynotopia.com
Позволяет быстро создавать макеты с помощью базы шаблонов, добавлять ссылки на кнопки, комментировать и делиться с коллегами для тестирования результатов прототипирования. Приложение платное, стоимость зависит от ваших запросов.
POP
popapp.in
Инструмент для любителей рисовать руками. Рисуете, качаете приложение на iPhone, фоткаете, создаете раскадровку, тестируете и делитесь с коллегами. Все очень просто.
RATCHET
maker.github.io/ratchet
habrahabr.ru/post/157819
Создается прототип, максимально приближенный к реальному приложению. Может загружаться на компьютер или телефон, но без навыков HTML, CSS и JS не обойтись.
Proto.io
proto.io
SaaS решение для прототипирования. Сервис нам очень понравился, но в бесплатный пакет входит очень скудный набор функций, поэтому он фактически бесполезен. За действительно рабочий инструмент придется заплатить не менее 24$.
Codiqa
codiqa.com
Еще одно облачное решение. Та же модель монетизации, как и в proto.io. Кому-то этот сервис может показаться удобнее.
Mockingbird
gomockingbird.com
Ситуация противоположна Invision: имеется конструктор, но демонстрировать не очень удобно. Да и под мобильную разработку подходит плохо.
Lumzy
www.lumzy.com
Прошлый век. Под смартфоны тоже не удастся ничего создать.
iPhone Mockup Web App
iphonemockup.lkmc.ch
Отличительной особенностью является имитация рисунка приложения и самого телефона от руки, но это не оправдывает отсутствия возможности создавать связи между макетами.
Axure RP
www.axure.com
habrahabr.ru/post/101938
Программа достаточно функциональная, считается одним из лидеров на рынке. Подходит для прототипирования сайтов и приложений под iPhone и iPad.
AppGyver
www.appgyver.com
На выбор даются шаблоны Android, iPhone и iPad. Протестировать здесь вы сможете только логику приложения без дизайна, поскольку работа ведется с уже готовыми набросками приложений. В бесплатном статусе вы сможете протестировать сервис с 3 скриншотами. На мобильное устройство можно будет установить приложение, с помощью которого возможно оценить результат работы.
Fluid Ui
www.fluidui.com
Удивительно, но этот сервис обладает всеми необходимыми функциями. Может быть, он не так изящен, как другие, зато позволяет и самостоятельно собрать прототип в конструкторе, и залить уже готовые макеты, проставить связи между страницами приложения, отправить получившийся макет для просмотра друзьям и коллегам и протестировать его на телефоне. Сервис также поддерживает Windows Phone!
MockFlow
www.mockflow.com
Имеет десктопное приложение и онлайн сервис, что, несомненно, является преимуществом, но простой настолько, что даже скучно.
Mockingbot
www.mockingbot.com
Еще один очень неплохой инструмент, содержащий все необходимые функции, но, к сожалению, поддерживает только iPhone.
Prototypr
prototypr.com
Софт исключительно для владельцев яблочных девайсов. Пользоваться очень легко — просто перетаскиваем нужные элементы на макет и одним нажатием клавиши смотрим результат на телефоне.
Balsamiq Mockups for Desktop
www.balsamiq.com
Можно создать как простой схематичный прототип, так и очень детальный с точностью до пикселя. Рисованая стилистика делает серьезный инструмент веселой игрушкой.
iMockups for iPad
www.endloop.ca/imockups
Рисовать прототипы прямо на iPad? Легко! Для него самого и iPhone, конечно. Качаем приложение и получаем удовольствие от простоты и неплохого результата.
Interface 2
interface2.lesscode.co.nz
Создание динамических прототипов для iPhone и iPad непосредственно на самих устройствах всего за 10 долларов каждое.
Демонстрация дизайна на устройстве без программирования
Justinmind Prototyper
www.justinmind.com
Инструмент, позволяющий создавать интерактивные прототипы сайтов и приложений для iPhone, Android и iPad. Поддерживает множество возможностей, включая работу с жестами ( в прототипах можно реализовать Draghttps://habr.com/ru/articles/189524/» target=»_blank»]habr.com[/mask_link]
Что собой представляет макет интерфейса?
Макет интерфейса это документ содержащий в себе информацию о сайте, приложении или будущей программе.
В макете представлены страницы или окна будущего интерфейса, всё разложено по группам и слоям. Это сделано для того чтобы разработчик мог разобрать макет по частям, чтобы после воспроизвести его в коде.
Еще в макете могут быть страницы с адаптивом, то есть использование дизайна на экранах с разным разрешением или расположение элементов при вертикальной и горизонтальной ориентации экрана.
Также отдельным блоком могут быть вынесены повторяющиеся элементы интерфейса. К примеру, кнопки всегда показывают на отдельном слое в разных состояния. По умолчанию принято считать 4 основных состояния кнопки: активное, не активное, при наведении и при нажатии. Эти состояния должны быть отражены в макете, чтобы разработчик не думал, как ему показывать те или иные кнопки.
Если говорить об интерфейсе приложений, то верхняя и нижняя панель обычно не измены, поэтому их тоже принято выносить в отдельный слой. Связано это с тем, что разработчик единожды создает данные элементы, а после просто копирует их при верстке. Таким образом можно поступить со всеми повторяющимися элементами, что облегчит работу и дизайнеру и разработчику.
В идеале в макете должен быть представлен Style guide — это система стилей, которая использовалась при разработке интерфейса. В неё входят: цвета, шрифты, иконки и прочие стилеобразующие элементы, если таковые имеются.
В зависимости от направленности интерфейса помимо всех страниц и блоков в макете может быть показано взаимодействие. Современные программы разработки интерфейсов, такие как Figma, Sketch, Adobe XD, позволяют создать интерактивный прототип и умеют даже анимировать переходы экранов. Поэтому в макетах сделанных в данных программах может быть включены связи кнопок и экранов, что позволит разработчику быстрее ориентироваться во взаимодействии элементов.
Источник: yandex.ru
Разработка программ
При разработке больших программ, особенно по нисходящей методике, необходимость в тестировании и отладке возникает раньше, чем подготовлен текст программы. Макет программы — это некоторый предварительный ее текст, допускающий уточнение — доопределение.
Простейший макет может быть создан из небольшой коллекции тестов, иллюстрирующих поведение программы в наиболее важных точках. Выбор таких точек — необходимая работа, результаты которой многократно используются на всех фазах жизненного цикла программы: при конструировании алгоритмов, автономном тестировании компонентов программы, комплексной отладке программы, демонстрации программы всем заинтересованным лицам, при ее эксплуатации и развитии. Функционирование простых макетов особенно легко реализуется в языках, обладающих унификацией структур данных и функциональных объектов, таких как Lisp и Setl [ [ 75 ] , [ 49 ] ].
Setl — язык сверхвысокого уровня, представляет собой попытку активного использования теоретико-множественных понятий в практике программирования [ [ 49 ] ].
Согласно концепции этого языка, понятие «функция» обладает двойственной природой. Функция может быть представлена в алгоритмическом стиле — определением процедуры, выполнение которой сопоставляет результат допустимому аргументу. Но столь же правомерно представление функции в виде графика, отображающего аргументы в результаты.
Оба представления могут существовать одновременно — это всего лишь две реализации одной функции. Графическое понимание функции включает в себя и табличную реализацию подобно математическим таблицам Брадиса. Кроме того график функции не обязан быть линией — это может быть фигура произвольных очертаний.
Следовательно, аргументу может соответствовать множество результатов, лежащих на пересечении вертикали с этой фигурой — графиком функции. При такой трактовке нет ничего удивительного в постепенном накоплении или построении графика функции. Можно задать небольшое множество точек графика, а потом постепенно его пополнять.
По замыслу Дж. Шварца, автора языка SETL , такая методика может выполнять роль оптимизации особо сложных вычислений.
Более формальный макет может быть построен из спецификаций функций в виде типовых выражений , задающих описание типов аргументов и результатов. Такой макет может работать как «заглушка» для нереализованных компонентов. Вместо них может работать универсальная функция, проверяющая соответствие фактических аргументов предписанному типу данных и вырабатывающая в качестве результата произвольное данное, соответствующее описанию результата. Этот механизм будет более эффективен в паре с простым макетом из тестов, если результат выбирать из коллекции тестов.
Накопление результатов
Не менее ценные следствия из унификации структурных значений и функциональных объектов дает накопительный, кумулятивный эффект ряда сеансов обработки рекурсивных программ, содержащих общие компоненты. Допустимость совместного хранения функциональных определений и тестов для их проверки в общей структуре, например в списке свойств атома, именующего функцию, позволяет строить технологические макеты с множественными определениями, коллекциями тестов и спецификаций, а также с документацией. Такие макеты пригодны для поддержки полного жизненного цикла программы . Они позволяют организовывать оперативное сравнение результатов при обновлении системы функций. На такой основе возможно автоматическое тестирование программ. С практической точки зрения технологические макеты — универсальный инструмент динамической оптимизации прикладных систем.
Представим, что вычисление каждой рекурсивной функции сопровождается сохранением пары . После этого можно запустить в дело слегка измененное правило интерпретации функций. Изменение заключается в следующем: прежде чем применять функцию к фактическому аргументу, выполняется проверка, нет ли для этого аргумента уже вычисленного результата. Готовый результат и есть результат функции, а в противном случае все работает как обычно. Механизм сохранения насчитанных результатов функций назван » мемо-функции » [ [ 64 ] ]. Естественно, основанием для его применения является достаточная сложность и частота обработки [ [ 45 ] ]. Примечательная особенность данного метода — любая сложность очень частых вычислений стремится со временем к линейной.
Ряд особенностей такого инструментария выходит за привычные рамки стандартного программирования и обладает заметной трудоемкостью при расширении ряда используемых языков программирования.
Жизненный цикл
Проблема трудоемкости программирования ждет своего решения с давних пор. Ее сложность проявляется по мере накопления опыта обеспечения критических характеристик ИС, таких как надежность и производительность. Полезно совмещение восходящих и нисходящих методов разработки компонентов. Главное — пространство для маневра, возможность согласованного уточнения решений на всех уровнях определения компонентов.
Можно заметить, что основные трудности практического программирования связаны с неполнотой учета структуры ЖЦ программ, а предлагаемые пути являются разными формами наследования успешного опыта. Путь к надежному программированию лежит через достижение многократности использования важных решений, принимаемых на протяжении полного ЖЦ, а не только в процессе программирования [ [ 12 ] , [ 14 ] , [ 22 ] , [ 46 ] , [ 48 ] , [ 54 ] , [ 61 ] ]. Длительность ЖЦ программ зависит от его модели и связана с методами повышения уровня изученности решаемых задач.
Подробный обзор классических моделей жизненного цикла (ЖЦ) программ приведен в [ [ 61 ] ], где отражено соответствие детализации абстрактного пространства, в котором осуществляется управление проектами, сложности решаемых задач. Начиная с грубого упорядочения произвольной деятельности до весьма витиеватой спирали, позволяющей зрительно представлять эволюционные витки и версии развития ИС, менеджер может в принципе понять и на деле осуществить процесс постановки неочевидных вопросов, определяющих и усложняющих разработку информационных систем.
Практический выбор модели ЖЦ проектируемой программы требует конкретных оценок трудоемкости предлагаемых подходов, ее зависимости от доступной информации и квалификации программистов. Для обоснования таких оценок рассмотрим наиболее типичные особенности процесса разработки ИС и их компонентов. Обычно разработка ИС развивается примерно следующим чередом.
- Требуется организовать обработку множества определенных данных. Обработка понимается как класс процессов, порождаемый программами, соответствующими предварительно подготовленному проекту, спецификации, требованиям.
- Пишется версия программы и предпринимается ряд попыток с ее помощью осуществить отдельные процессы над небольшими образцами данных.
- Форсируется расширение программы, контролируемое тестированием на «представительном» наборе образцов.
- Демонстрируется работа с программой. Обнаруживается, что что-то необходимо доделать, пока не появится практичная версия.
- Практичная версия порождает более разнообразное применение программы. Время от времени предпринимается улучшение программы и возникают версии программы.
Вдруг оказывается, что очередное улучшение требует чрезмерных трудозатрат. Рост работоспособности программы исчерпан. Начинается новый виток с небольшими вариациями. Трудоемкость очередных витков возрастает, и восходящие линии в развитии ИС преимущественно обрываются. Эта картина смягчается (или затушевывается) вовлечением в процесс разработки программ вспомогательных СП и средств ведения проектов. Удобство, как критерий приемлемой трудоемкости, достигается ценой следующих уступок:
- обрабатываются лишь данные, легко представимые входным ЯП;
- нужными считаются понятия и действия, удобно реализуемые в СП;
- полезными признаются процессы, организация которых не влечет больших трудозатрат.
Если уступки по каким-то причинам невозможны, то СП признается неподходящей для применения в соответствующем классе задач. Если уступки возможны, то успешность разработки ИС в значительной мере определяется умением прогнозировать развитие требований пользователя, своевременно улучшать программу или производить новые ее версии, убедительно демонстрируя возрастание качества ИС.
Опыт применения ЯП и их конструирования показывает, что представления программ и соответственно требования к ЯП подвержены единой динамике, связанной с проявлением общих объектов и процессов при решении расширяемых задач (уровень изученности). Каждый уровень изученности достижим при соответствующем уровне организованности процессов и объектов. Динамику требований к качеству ИС можно описать следующими уровнями изученности решаемых задач и областей применения их решений.
- Концептуальный минимум. Достаточно любого демонстрационого образца с минимальной организованностью и работоспособностью, лишь бы он дал правильные ассоциации.
- Потенциальный максимум. Необходим максимальный уровень организованности и работоспособности без особых требований к производительности, так как главное — уяснить принципиальные возможности. Определяется максимально полный каркас будущей работы и фокусируется ее базис.
- Практичный компромисс. Допустим меньший уровень организованности, т.е. нужны не все возможные процессы, а лишь достаточно практичные. Возрастает потребность в эффективности, но не в ущерб удобству.
- Предельный баланс. Обнаруживается необходимость в организации некоторого класса процессов, даже если это потребует высоких трудозатрат. Требуемый уровень организованности может возрасти.
На каждом уровне изученности области применения ИС различны требования к дружелюбию интерфейса, его лексико-фразеологическому оформлению, к диагностичности, к полноте и улучшаемости реализованных решений и к другим свойствам. Можно параллельно реализовывать ИС, расширяя ее по мере готовности разработчиков и пользователей.
Переход от программ к компонентам позволяет фазы и модели ЖЦ сопоставить с характером изменения информации о компонентах. Такое сопоставление показывает истоки проблем организации разработки ИС. Классическим моделям ЖЦ присущи длинные интервалы локализованного уточнения информации на одном уровне, что затрудняет проверку отношений между уровнями. Подходы XP и FDD позволяют непрерывную проверку таких отношений — всегда существует обратная связь при развитии постановки задачи.
Исследование моделей ЖЦ компонентов дает перспективу единого подхода к развитию и согласованию разнородной информации о компонентах ИС и решаемых с их помощью задачах. Это может обеспечивать непрерывное согласование процессов разработки и сопровождения ИС.
Ряд практичных многоязыковых подходов к разработке программ предлагает Uml. [ [ 86 ] ] Хочется отметить следующее:
- инструментарий обратного проектирования,
- множественность представлений программ с разных точек зрения,
- сочетание образных диаграмм с языковыми средствами,
- возможность пошаговой детализации разносортных структур данных и управления.
Тенденция к многоязыковости отражает актуальность интеграции средств и методов, используемых на разных фазах ЖЦ программ, что ведет к парадигме полного жизненного цикла эволюционирующих компонент информационных систем.
Источник: intuit.ru