зачем нужно проектирование приложений
Проектирование приложений и кроссплатформенная разработк
WhatsApp, Telegram, Skype
Есть 4 важных момента из серии «как это делается», которые нужно подробно и при первой встрече разъяснить заказчику, желающему иметь собственное уникальное мобильное приложение для развития бизнеса.
1. Зачем необходимо проектирование приложений?
Проектирование приложений помогает разным специалистам, работающим над проектом (менеджер, руководитель, дизайнер, разработчик приложений), одинаково четко понимать задачи и представлять конечный продукт.
Создание прототипа позволяет структурировать идеи, предотвратить ошибки и избежать лишней работы на ранних стадиях разработки. А это, в свою очередь, ускорит процесс разработки мобильного приложения и уменьшит финансовые затраты.
2. Как происходит процесс написания мобильных приложений?
Любимый вопрос наших заказчиков: сколько времени занимает разработка и написание мобильных приложений? И мы отвечаем, что простое приложение для веба или мобильную версию сайта можно создать за месяц.
На сложное мобильное приложение, по максимуму использующее возможности конкретной ОС, оформленное в стиле определенного бренда, потребуется 60+ дней.
Этапы изготовления мобильных приложений
Процесс создания приложения охватывает цикл работ от составления ТЗ до публикации в онлайн-магазине и делится на 6 этапов:
Знакомство: поступает заявка, мониторим нишу рынка, оцениваем стоимость проекта, оформляем договор.
Проект: включает изучение задач, проектирование функционала, разработку интерфейса приложения, техническую реализацию, создание интерактивной модели приложения, составление технического задания, сметы и плана разработки, разработку дизайна.
На этом этапе заказчик может высказывать дополнительные пожелания и вносить правки.
Разработка: создаем графический дизайн, верстаем экраны приложения, программируем и тестируем приложение.
Сдача готового продукта заказчику.
Публикация в профильных магазинах приложений.
Поддержка, расширение и доработка функционала.
3. Как происходит прототипирование приложений?
В ходе работы над приложением приходится задействовать много разных инструментов, начиная от чистого листа бумаги и грифельного карандаша и заканчивая сложными программами для макетирования, прототипирования, программирования и др.
В процессе изготовления мобильных приложений мы:
добавляем дизайн с учетом гайдлайнов;
4. Кроссплатформенная разработка мобильных приложений
Мы разрабатываем мобильные приложения под ОС Android, iOS, Windows Phone.
Из личного опыта скажем, что:
Дешевле создавать приложения для устройств с ос Android, они занимают ¾ доли рынка в мире. И гайдлайны в Google Play – не такие строгие.
Престижно разрабатывать приложения под iOS. Платформа всегда на шаг впереди, есть регулярные обновления, усовершенствования, предъявляются высокие требования к качеству.
Выгодно для бизнеса – задействовать обе популярные платформы. И чтобы оптимизировать финансовые затраты, рекомендуем заказать кроссплатформенную разработку мобильных приложений.
Кроссплатформенная разработка мобильных приложений – это создание одного приложения, успешно работающего на нескольких платформах.
Хотите узнать все преимущества подхода? Задайте нам вопрос.
Проектируй и богатей: с чего начать разработку мобильного приложения
Зачем проектирование нужно проекту
У вас есть готовая система или бизнес-модель, и главная задача в создании мобильного приложения — придумать, как упаковать эту систему или модель в интерфейс с другими особенностями взаимодействия, как будет работать этот интерфейс и как будет реализован технически. Хорошо сделанная в этом направлении работа даёт хороший пользовательский опыт — такой, который помогает пользователю быстро и приятно решить его задачу, а значит, решить задачу вашего бизнеса.
На пути к эталонному UX стоит решение двух вопросов: как пользователь будет работать с вашим продуктом и как именно должно работать мобильное приложение. Эту работу нельзя провести по готовому сценарию. Создание мобильного приложения — это проектная работа. Здесь мы в подробностях рассказываем, как эта работа выглядит в Лайв Тайпинге.
Если вкратце, вас ждут семь этапов: знакомство и оценка, проектирование, дизайн, разработка, тестирование, поддержка и маркетинг. И для каждого проекта содержание и набор этапов разные, потому что каждый раз у проекта свои бизнес-цели, целевая аудитория, технические ограничения, ограничения по бюджету, особенности бизнес-процессов и так далее. Как бы то ни было, проект должен приносить максимальную пользу. Проектирование делать нужно как раз для того, чтобы разобраться в том, как это обеспечить.
Зачем проектирование нужно мне, клиенту?
Проектирование не даёт вам готовый продукт. «Почему тогда я должен платить за ваше понимание того, как вы будете делать проект?», — спросите вы. Ведь вы хотите платить за успешный запуск. Вопрос резонный. Теперь ответ. Во-первых, если мы не разберёмся, мы не сделаем проект успешным. Во-вторых, если вы не заплатите за то, что вам продают как проектирование, вы либо заплатите за него скрытым образом (например, за высокий процент издержек, заложенных на риски) либо вам придётся платить за то, что кто-то исправит последствия так себе сделанного проекта.
Правильный ответ: ни за то ни за другое.
Проектирование не нужно делать вообще только в том случае, если у вас во дворе бьёт фонтан из денег, а вашим партнёрам чихать на дедлайны. А когда вместо фонтана денег — частокол ограничений, тогда оно очень даже необходимо. Ограничения могут быть во времени, в бюджете, в программном обеспечении, в организации бизнеса или в платформе, на которой мы хотим это сделать.
Как проектирование помогает избежать рисков?
Повторимся: разработка мобильного приложения — это проектная работа. У проектной работы есть одна особенность: оценить стоимость проекта позволит понимание того, какой он по объёму. А чтобы понять объём, нужно посмотреть на проект изнутри, то есть уже начать его делать. Во время проектирования команда занимается именно этим: изучает проект и придумывает то, как он будет устроен.
Проектирование как сложносоставной процесс начинается с функционального проектирования: компания и клиент обсуждают и описывают функции, которые должны быть в приложении. Как эти функции будут реализованы, они не обсуждают. Это такое ТЗ без упоминания о языках программирования, технологиях и других специфических деталях. На этом этапе вы и исполнитель определяете, что будет создаваться, а как делать — определят уже разработчики и на другом этапе.
Затем студия вместе с вами думает, как это всё будет выглядеть. Для этого дизайнеры рисуют прототип интерфейса, который показывает основные окна приложения, расположение кнопок, взаимосвязь между ними.
Дальше, если есть необходимость прояснить рисковые технические моменты, делается техническое проектирование или, по-другому, исследование о том, возможно ли воплотить те или иные идеи в жизнь. Это делается, чтобы определить, как желаемая функциональность будет работать изнутри.
Например, вы хотите сделать мобильное приложения для интернет-магазина. Скорее всего, он работает на собственной CMS, в нём установлена система учёта товарных остатков, ИТ-система для работы с логистикой товаров, система бухгалтерии и не одна система оплаты. Чтобы всё это интегрировать в мобильное приложение, нужно разобраться, каким способом передавать данные от этих систем. А чтобы понять это, нужно исследовать имеющийся проект.
Изучить детали проекта, выяснить все ограничения, поговорить с Дайян.
Почему важно делать техническое проектирование? Потому что оно позволяет узнать больше про технические ограничения проекта, стоимость и риски. Технические ограничения могут повлиять и на функции, и на прототип, и на дизайн,поэтому чем раньше вы сделаете техническое проектирование, тем лучше. В процессе может выясниться, что вам придётся переутвердить или доделать какие-то бизнес-процессы, чтобы продукт получился таким, каким вы его хотите видеть.
Вывод
Чтобы понять, как упаковать ваш бизнес в форму мобильного приложения, нужно будет провести проектную работу.
Чтобы оценить и провести проектную работу максимально успешно в рамках ограничений бюджета и сроков, необходимо узнать проект изнутри, начать его делать. Проектирование помогает в этом. В процессе проектирования команда выясняет функциональные требования проекта, создаёт прототип и на его основе решает, как функциональность будет реализована. Начиная создание приложения с проектирования, вы узнаёте максимальное количество рисков проекта ещё до того, как начали разработку. Это намного дешевле и безопаснее для проекта, чем начать делать его вслепую. В этом случае вы можете столкнуться с проблемой, которая потребует серьёзной, а значит, дорогой доработки. С проектированием этого можно избежать.
Как проектируют приложения: разбираемся в архитектуре
Старший iOS-разработчик из «ВКонтакте» рассказывает, почему архитектура не главное в проекте и как сделать продукт поддерживаемым и масштабируемым.
Катя Павловская для Skillbox Media
Евгений Ёлчев
Старший iOS-разработчик во «ВКонтакте». Раньше был фулстеком, бэкендером и DevOps, руководил отделом мобильной разработки, три года преподавал iOS-разработку в GeekBrains, был деканом факультета. Состоит в программном комитете конференции Podlodka iOS Crew, ведёт YouTube-канал с видеоуроками по Flutter. В Twitter пишет под ником @tygeddar.
Я люблю спорить о том, какая архитектура лучше. Может, из-за своего внутреннего перфекциониста или диплома архитектора информационных систем, а может, потому, что мне лень копаться в плохих проектах.
Спойлер: больше всего я люблю архитектуру MVC. Дальше расскажу, как она работает и почему мне не нравятся всякие MVVM, MVP и VIPER. Кстати, недавно я разобрался во Flux и её имплементации Redux и понял, что их я тоже недолюбливаю.
В основе статьи — тред автора в Twitter.
Что такое архитектура MVC
Я тогда был студентом, делал курсовые и пет-проекты. У них была сложная вёрстка и непростая структура БД, но максимально простая логика. Код получался простым, но в целом меня такой подход устраивал.
Мне не приходило в голову, что можно делать не так, как написано в документации к инструментам и в примерах на форумах. Я был счастлив и не забивал голову чепухой.
Я пробовал поменять логику в своём проекте — перенёс её из одного файла в другой, но разницы не заметил. По факту ничего и не изменилось, только код теперь лежал в другом файле.
Изучая дискуссии в интернете и рассуждая самостоятельно, я понял, что «толстая» модель мне не нравится. Пусть лучше модель остаётся базой данных, а контроллер и дальше управляет логикой.
Со временем мои проекты становились всё сложнее, а контроллеры пухлее (правда, не как UIViewController в iOS). Я пробовал с этим бороться, выносил логику в сторонние файлы, которые включал в контроллеры, но это мало что меняло: архитектура сохранялась, просто код переносился из одного файла в другой.
Почему MVC не работала в моих проектах
В 2013 году я пересел на Laravel, разобрался с автозагрузкой классов в PHP, начал разбираться с ООП и прочитал «Совершенный код» Стива Макконнелла.
Стало ясно, что не стоит складывать всё в один файл — код и классы должны организовывать структуру, а некоторые фрагменты кода лучше убрать из MVC и выделить в самостоятельные части, которые можно переиспользовать.
С этого момента я начал писать проекты по-другому. В них появились иерархии классов, которые хранили логику, а контроллер сильно похудел — он получал данные от базы, передавал их в разные пакеты, получал от них результат и отправлял на HTML-страницу.
Архитектура проектов не была идеальной, потому что не подошла бы ни для одной сложной системы. Но для моих целей она была крутой и удобной: код получался читабельный, а все элементы проекта оставались довольно независимы.
Как я делал систему управления
VDS-сервером
В сложной системе нельзя передавать все данные через один контроллер, поэтому каждый плагин отдельно реализовывал веб- и API-интерфейсы, доступ к данным и бизнес-логику, вынесенную в пакеты для переиспользования.
Получилось так: HTML ⟷ JavaScript (модели, общение с API) ⟷ API ⟷ переиспользуемые пакеты ⟷ бизнес-логика и доступ к данным. Всё это не было похоже на MVC.
Почему архитектура не главное в проекте
Когда я увидел, как это реализуют в других компаниях, то осознал несколько важных нюансов.
Архитектура не даёт преимуществ. Ни одна продвинутая архитектура не была лучше того, что я делал в самом начале. За всё время я перепробовал разные подходы и поэтому мог оценить их пользу для проекта. Но между MVC и MVP не было разницы — кроме названий классов и правил вроде тех, когда элементы вызывают друг друга.
Компании понимают архитектуру по-разному. Одни говорят, что используют MVVM, у других то же самое называется MVC. Я видел пять MVVM-систем, и все были разными. Исключение — VIPER, у которой благодаря Егору Толстому есть подробная документация и много примеров. Но даже там были отличия.
Популярная архитектура не значит лучшая. Выбирать архитектуру из-за мейнстримности бесполезно. Кто-то решает использовать MVVM, но одни и те же компоненты кладёт в разные части проекта.
Архитектура не спасёт проект. Сама по себе она не решает проблемы и не гарантирует успеха.
Что же такое MVC на самом деле
Я постоянно изучал архитектуры, читал книги и спорил с коллегами, несколько раз пересматривал идею MVC в языке Smalltalk и несколько раз менял к ней отношение.
В итоге я понял, что MVC — это не три файла, и даже не несколько классов для каждого элемента. Модель — не про данные и не про бизнес-логику, а контроллер давно не нужен, и пора использовать MV.
Приложения с бизнес-логикой и доступом к данным были и до MVC, им не хватало только пользовательского интерфейса. Главная задача MVC — связать UI со всем остальным. Единственная рекомендация от создателя — при надобности создавать для каждой View свой фасад для Model и слушать его через паттерн-наблюдатель.
View — это и есть пользовательский интерфейс, Model — остальное приложение. Задача Controller — не быть прослойкой между V и M, а всего лишь принимать информацию от пользователя.
Принцип MVC — не мешать UI с бизнес-логикой, базой данных и другими частями приложения. А как это реализовать, уже пускай думает архитектор. Это не космическая инженерия.
Важно понимать, что MVP, MVVM или VIPER не заменяют MVC, а только дополняют её. Контроллер уже не нужен, потому что за ввод данных отвечает View, это стало его неотъемлемой частью.
Получается, что MVC в Apple, MVVM и другие варианты — это MV, где контроллер убрали за ненадобностью. Из всех современных MV(x) именно MVVM больше всего похожа на каноническую MVC.
Все эти термины усложняют общение. Иногда сложно понять, о чём тебе говорят, хотя задача архитектуры в том, чтобы всё было проще и понятнее.
Как разобраться в любой архитектуре
Может показаться, что все архитектуры одинаковые, и им вообще не стоит уделять внимания. Но это не так. У меня есть несколько правил.
Главное — реализация. Глобальная архитектура не так важна, как её воплощение. Всё зависит от того, как вы называете классы, где храните элементы и как классы общаются между собой. Все из команды должны соблюдать ваш стандарт, и тогда проект будет проще поддерживать.
Model — ваша ответственность. Архитектура MVC не даёт инструкций, как правильно написать основную часть приложения. Ваша ответственность в том, чтобы не устраивать в Model кашу, где половина классов — Service, а вторая половина — Helper.
Нужно разбираться в основах. Не стоит изучать конкретную архитектуру, лучше понять, из чего она логически следует. Тут поможет история, объектно-ориентированное и функциональное программирование, паттерны, SOLID и всё остальное. Обязательно надо прочитать «Совершенный код» Стива Макконнелла.
С какого-то момента я начал теряться в проекте. У меня появилась куча сущностей с похожими названиями и похожими данными, я создал миллиард экшенов. В итоге сам запутался, что, как и с чем взаимодействует.
Redux хороша для больших проектов, ориентированных на офлайн, где одновременно происходит куча асинхронных неблокируемых событий. Там этот бойлерплейт стоит терпеть, потому что он спасёт вам жизнь. Но в обычном тонком клиенте лучше использовать стандартную MV и не париться.
Вывод: что прочитать об архитектуре
На «Хабре» есть отличные статьи об MVC — «Охота на мифический MVC. Обзор, возвращение к первоисточникам и про то, как анализировать и выводить шаблоны самому» и «Охота на мифический MVC. Построение пользовательского интерфейса». Обязательно прочитайте их, если интересуетесь архитектурой — автор тщательно и на хороших примерах разобрал, что это такое.
Проектирование приложений: как стать ближе к пользователю?
В предыдущей статье («Не говорите мне, куда мне идти») мы рассмотрели вопрос структурирования информации в приложении и вытягивания важных блоков наверх с тем, чтобы сделать их более доступными для пользователя.
Как я писал, в современном мобильном мире особенно критично уметь одновременно решать две конфликтующие за место под солнцем задачи: 1) обеспечивать быстрый доступ к актуальной информации, самым важным действиям и в целом высокую скорость выполнения ключевых сценариев – и в то же время 2) позволять пользователям погружаться в детали, узнавать подробности и реализовывать важные, но все же вторичные действия.
Кто-то увидел в статье квадратики и информеры на картинках, но, я надеюсь, что от любопытного читателя не ускользнула и суть статьи.
В принципе, необходимость совмещения обозначенных выше задач родилась не сегодня — и обсуждать их, соответственно, начали довольно давно. Здесь я хочу сослаться на статью Susan Weinschenk “The psychologists view of UX design”:
People will do the least amount of work possible to get a task done. It is better to show people a little bit of information and let them choose if they want more details. The fancy term for this is progressive disclosure.
А тем, кто заинтересован в подробностях с точки зрения юзабилити, рекомендую соответствующую статью Якоба Нильсена – “Progressive Disclosure”.
Сегодня мы попробуем заглянуть в эту область еще с нескольких сторон – и я постараюсь показать, как идея вытягивания важной информации наверх может изменять UX и связанные интерфейсные решения, особенно в проекции на Windows 8.
Время
У всякой информации может быть много проекций, по которым она раскладывается в пользовательском опыте. Например, все, что мы рассматривали до этого, касалось семантической структуры информации и ее распределения по экранам.
Другой важной проекцией информации является ее временная составляющая: когда та или иная информация появляется в процессе взаимодействия с приложением.
Это в общем-то классический прием любых триальных ограничений, подсаживающих пользователя на работу с приложением, но требующих в какой-то момент выполнения дополнительного действия, выгодного авторам приложения. Однако нас в этой истории интересует совсем другой момент – как пользователь узнает об этом ограничении.
В первом варианте приложения это выглядело следующим образом: пользователь мог в волю работать с приложением, пока количество заполненных ящиков не достигало некоторого порогового значения, например, 15. После этого, как только он хотел добавить шестнадцатое яблоко, его «радовало» сообщение о том, что он должен сделать дальше:
Это — проблема, потому что произошедшее событие не является в полной мере предсказуемым для пользователя: у него нет контроля над происходящими действиями (или ощущения такого контроля). Также подобное сообщение, конечно, обескураживает в самый неподходящий момент.
У этой проблемы есть и классическое решение, о котором я расскажу чуть ниже, однако, на что я хочу обратить ваше внимание, так это на временную проекцию данной информации.
Надо начать с того, что наличие подобного порогового значения и его скорое приближение является важной информацией с точки зрения сценариев работы с приложением. Можно даже сказать, что она является критичной для как для пользователя, так и для авторов приложения. Поэтому возникает мысль о вытягивании этой информации ближе к пользователю, но уже не по иерархии экранов, а по временной шкале.
Чем раньше я об этом узнаю, тем лучше. Впрочем, когда это «раньше» должно наступить, требует внимательного изучения в каждом конкретном случае. Например, можно вести пользователя за ручку сразу, выводя некоторую полосу прогресса:
А можно вывести предупреждение за шаг или несколько до наступления события, заблокировав дальнейшие действия:
Или сделать и то, и другое сразу:
В любом случае подход остается тем же: выносим важную информацию ближе к пользователю, постаравшись при этом убрать раздражители. Пользователь получает дополнительный контроль над ситуацией.
Здесь также работает идея о том, что вместо того, чтобы выдавать пользователю сообщение об ошибке в его действиях (в нашем случае попытке добавить еще одно яблоко), лучше просто не разрешать подобное действие, если оно уже невозможно, сообщив, однако, что именно происходит в текущий момент.
Я не думаю, что описанное выше должно быть для вас большим откровением, тем не менее, надеюсь, мне удалось проиллюстрировать общую идею.
Отдельно отмечу, что вынося информацию выше (ранее во времени) по сценарию работы с приложением, важно не замусорить приложение кучей излишней информации. Это имеет смысл только для ключевых сценариев.
Контекст
Давайте рассмотрим еще один интересный пример и поговорим о географии, точнее о геопривязке. Тема эта известная, возможно, даже чуть-чуть поднадоевшая, но надеюсь, окажется тоже достаточно прозрачной.
Представьте, что вы решили предоставить пользователю доступ к каталогу каких-то географических объектов, скажем, кафе/ресторанов с живой музыкой или чего-то более зимнего, например, катков в г. М.
Вы можете начать с идеи вывести все объекты на карте города, дав возможность масштабировать и, к примеру, накладывать некоторые фильтры:
Далее по нажатию на любой из объектов можно показывать сопутствующую информацию (описание, адрес, средний размер чека, время работы и т.п.), либо непосредственно переводить на карточку объекта.
Это как бы базовая идея, отправная точка, которая, возможно, пришла вам в голову. Теперь надо забраться в голову к пользователю. Например, выяснить, насколько целевая аудитория в реальности ориентируется по карте, представляет себе те или иные районы города и говорит ли ей что-нибудь расположение конкретной метки, кроме «это примерно вот там»?
Может оказаться, что оптимальным способом представления информации и вовсе будет не карта, а самый настоящий список объектов. Список, понятное дело, нельзя выводить хаотично, нужна сортировка, фильтрации и т.п.
Дальше нужно копаться в детали и смотреть на сущность информации и пользовательские сценарии, стремясь достичь очень простого результата: релевантности выдачи, то есть по умолчанию большинство пользователей должно получить подходящий объект среди первых нескольких в списке, хотя сам список может содержать сотни позиций.
Одна из первых идей, которая приходит в голову, — это выводить список с учетом геопривязки устройства пользователя, то есть сортировать по расстоянию от устройства до объекта и показывать соответственно само расстояние. В списке это выводится просто текстом, например, «1.4 км». На карте достаточно обозначить текущее местоположение пользователя и прокладывать маршруты до выбранной точки.
В итоге мы получим географическую близость объектов к пользователю. Если расширить это понятие, то можно говорить о том, что мы ближе к пользователю вытаскиваем то, что ближе ему по текущему контексту.
Это может быть не только расстояние до объекта, но и, например, способ проезда к объекту: если мы из каких-то условий понимаем, что пользователь едет общественным транспортом, это одна ситуация и одни маршруты, если на машине или такси, это уже совсем другая ситуация. На карте проезда от текущего местоположения пользователя нужно показывать то, что соответствует запросам пользователя.
Далее, если мы продолжим думать о географической близости, то нам важно соотнести наши данные с мировосприятием пользователя. Например, нам обычно трудно воспринимать длинные списки, поэтому их имеет смысл разбивать на некоторые группы, позволяющие сориентироваться при принятии решения. В случае с расстоянием, это могут быть группы, выраженные в километрах и ориентировочным временем достижения (например, для машины с учетом пробок):
Разбивка также позволяет быстрой перейти к группе, которая меня устраивает больше всего: например, я не хочу идти в ресторан в округе, но и слишком далеко тоже не хочу – перешел к группе по середине, быстро сориентировавшись по заголовку.
Еще пример на контекстность: если заведение скоро закроется, об этом хорошо бы подсказывать пользователю, либо просто при сортировке по некоторой релевантности поднимать те, в которые пользователь потенциально еще может попасть и хорошо провести там время.
Это все хорошо, но полет мысли не заканчивается. Может оказаться так: в результате исследования пользователей выясняется, что расстояние для значительной группы любителей ресторанов с живой музыкой вообще не играет никакой роли! Например, они ездят в одни и те же избранные заведения, прислушиваются к рекомендациям друзей и вообще пользовательским отзывам и рейтингам ресторанов.
Тут ситуация переворачивается с ног наголову и наша карточная пирамида начинает разрушаться. (Да-да, именно поэтому так важно исследовать мотивацию пользователей и способы принятия решений.)
Это не отменяет, конечно, полностью наших предыдущих умопостроений, однако, заставляет переосмыслить, что же является главным в приложении для быстрого принятия решений. Например, им может оказаться контекст самого пользователя (личные предпочтения) и социальный контекст (друзья, другие пользователи) и только на третьем месте ближайшие в каком-либо другом смысле результаты.
В такой ситуации данные приложения расслаиваются по способам фильтрации и сортировки, но для каждого из них мы по-прежнему можем выносить основную информацию на первых хаб, предполагая, что информация в одной из выделенных порций информации окажется наиболее подходящей:
В такой ситуации мы как раз приходим к тому, что обсуждали в предыдущей статье: наверх в хаб выносится то, что является самым важным из нижележащих разделов, а в самом хабе сортировка происходит по приоритетности сценариев для пользователя – в данном случае на первое место выносится личная близость, на второе социальная, на третье географическая.
Конечно, это не мешает параллельно реализовать возможность переключения со списочного представления на представление в виде карты, с которого мы собственно говоря и начали.
Кстати, в каком-нибудь другом приложении, где исходя из важности сценариев, географическому списку будет отдан низкий приоритет, последний может вообще исчезнуть с хаба, переместившись полностью в поиск, где учет географии окажется наоборот имеющим весомое значение.
Действия
Возвращаемся к идее о том, что все вторичное должно быть убрано на задний план, а важное наоборот вынесено на поверхность. Если идея применима к контенту, как ее применить к управлению?
Первое, что приходит на ум, это, конечно, разнесение функциональности по уровням иерархии приложения. Основные действия нужно уметь делать быстро и сразу, а вторичные можно опустить на последующие экраны и состояния.
Например, в почтовом приложении (Mail) для Windows 8 на самом экране размещено не так много кнопок, но все они отвечают ключевым сценариям: чистый текст, отправить и удалить (или сохранить в черновиках):
Вторичные действия, имеющие смысл время от времени, вынесены на панели приложения, которые появляются по запросу пользователя:
Здесь мы легко найдем как управление шрифтом, так и, например, доступ к функциональности по прикреплению вложений. Это все важно, но вторично по отношению к основному сценарию: написанию письма и его отправке.
На первый уровень, или основное состояние экрана, выносится основная функциональность, вторичная – появляется по запросу пользователя.
Про друзей все просто – это системный контракт, который вызывается системной кнопкой, остальное размещаем на экране (корзину) и панели приложения (вторичные действия):
С этим экраном — понятно, особой магии тут нет. Давайте на минуту поднимемся на уровень выше: скорее всего, это был экран со списком товаров.
Дальше, анализируя пользовательские сценарии, мы можем выяснить, что иногда пользователь готов совершить то или иное действие, не погружаясь на уровень ниже. К примеру, ему достаточно названия, описания товара и рейтинга – он готов сразу добавить в корзину или в закладки. Или еще один важный сценарий, который мне вспомнился – добавить к сравнению, особенно актуальный в общем списке.
Можем ли мы вытянуть действия, находящиеся на уровне ниже наверх? Технически, да: мы могли бы рядом с каждым товаром поставить три-четыре кнопочки:
Постарайтесь так не делать. Вообще, подобный иконостас очень быстро превращается в помойку с большим количеством визуального шума. И самое главное — все это убивает контент, которому как раз должен отдаваться приоритет, и основной (прямой) способ взаимодействия с ним.
Тем не менее идея вынести возможность делать быстрые действия на уровень выше остается разумной. Что же делать?
Во-первых, возможно, можно не далеко уходя от представленной выше идеи, ограничиться несколькими товарами, для которых возможны быстрые действия:
Так, кстати, сделали в приложении «ЛитРес» — кнопка «читать книгу» сразу переводит к режиму чтения без промежуточных страниц описания:
Во-вторых, что можно также совмещать с первым, специально для таких случаев можно использовать выделение объектов списка, к которому подвешивается контекстная панель приложения, предоставляющая быстрый доступ к действиям относительно выделенных элементов:
Здесь, конечно, важно тоже расставлять приоритеты и выносить на уровень выше только ключевые действия, например, в данном случае за бортом оставлено закрепление на экран «Пуск».
В результате важные действия оказываются ближе к пользователю, но по-прежнему в массе своей доступны только по запросу: через выделение нужного элемента списка. И также они доступны при погружении к деталям, что соответствует традиционному решению.
Наконец, давайте вкратце рассмотрим еще один интересный срез.
Сущность
Предположим, вы действительно разнесли информацию по разным экранам согласно семантической иерархии и сценариям использования приложения, последовательно вытянув при этом наверх самое важное.
Понятно, что при этом может сокращаться уровень детализации информации, да и тащить наверх все описание пускай и самого важного объекта, как правило, бессмысленно. Сокращая уровень детализации, вы, например, можете последовательно ограничиться заголовком и кратким описанием или основным параметрами на втором уровне и только заголовком на первом:
Во многих случаях такое решение оказывается подходящим под задачу и в целом весьма хорошим.
Однако в некоторых случаях, особенно когда речь идет о каких-то процессах, имеет смысл задумываться и о качественном переходе: поднимаясь вверх по иерархии, не просто сужать объем предоставляемой информации, а делать ее представление более компактным, информационно насыщенным. От сырых данных на нижнем уровне, переходить к извлечению сущностного содержания данных на верхних.
Здесь уже начинают работать как в целом анализ данных, так и инфографика как способ визуализации данных.
Чем выше уровень, тем важнее даже не столько обобщение информации, сколько извлечение из нее сути происходящих процессов. В примере выше, речь может идти не просто о сумме перевозок, но и о динамике или оповещениях, позволяющим принять решение: нужно ли что-то срочно делать, погружаться в детали и изучать более полное представление данных.
Если бы мы говорили не о перевозках, а например, о наблюдении за серверными стойками, на первом уровне имело бы смысл выводить, скажем, не столько информацию о том, сколько места осталось на всех жестких дисках, а непосредственно инсайт о том, что места мало и исходя из статистики наблюдений завтра все место закончится и ай-ай-ай – нужно срочно что-то делать.
В конечном счете, вопрос в том, как сделать данные ближе и понятнее пользователю, чтобы он мог быстрее решать другие важные задачи и подсказать ему, когда нужно погрузиться в детали, чтобы, к примеру, вмешаться в процесс.
И, как вы уже, надеюсь, поняли, все это не о квадратиках и информерах, а о том, как сделать пользователя счастливее, удовлетворив его потребности, выраженные в ключевых сценариях и спроецированные на современный мобильных мир различных устройств и приложений для них.