Глава 11: Модель данных
Возможно, вы уже слышали о модели данных от бородача-разработчика. Если да, то это прекрасно! Если же нет, тогда у вас появляется отличная возможность с ней познакомиться поближе.
Зачастую рядовой UI-дизайнер берёт в работу так называемые грубые wireframes либо нарисованную на клочке бумаги схему экрана. И дальше он наводит красоту и мимимишность. Но в период взросления он задумывается: «А почему всё именно так, а не так-то и так-то?» Прогрессивный UI-дизайнер может начать аргументированный спор с продакт-менеджером о том, что он бы сделал по-другому, а продакт-менеджер скажет ему, что все эти wireframes на клочке бумаги он родил на базе исследований и всяких там user story и, мол, иди лесом, не спорь со старшими. Возможен и другой исход — продакт-менеджер примет доводы UI-дизайнера, и они вместе всё поправят. Не так важно, чем дело кончится. Важно другое — UI-дизайнер должен проявлять инициативу и должен самостоятельно уметь создавать модель данных на радость себе и коллегам.
Фраза «модель данных» ясна абсолютно любому разработчику. Мы на самом деле тоже знаем, что это такое, только не осознаём этого. Пока.
А тем временем модель данных влияет на дизайн не то чтобы напрямую, а всецело определяет всё, что располагается на экране смартфона, компьютера, банкомата, терминала и торпедо автомобиля! Потому что все элементы на экране являются данными и берутся из модели данных.
———
Откуда появляется модель данных?
Вопрос, ответ на который может изменить сроки, стоимость и качество проекта в целом.
1. Если эта модель данных придумывается разработчиком на базе документации, ваших скринов и чьих-то ещё домыслов, то у меня для вас нет хороших новостей. Разработчик сделает по-своему, не беря во внимание дальнейшее расширение функционала. Потому что может, и потому что никто ему модель данных не дал. Итог: модель данных придётся переделать после первого же релиза приложения, а в дальнейшем её придётся всё время синхронизировать с дизайном экранов, дабы всё было едино. Такое себе упражнение, если честно.
2. Продакт-менеджер, составляя документацию, в теории, должен описывать модель данных. И в больших компаниях так и есть. А в маленькой компании или стартапе с вероятностью 90% до модели данных его руки никогда не доходят.
3. Модель данных формирует UX/UI-дизайнер, то есть вы, в процессе разработки дизайна интерфейса на базе невнятного ТЗ (технического задания) и хотелок команды либо заказчика.
Забавно то, что ваш дизайн экранов на самом деле содержит модель данных. Просто вы никогда об этом не задумывались и не знали куда смотреть.
———
И как её, модель данных, сделать?
Можно делать как раньше — брать ТЗ или мокапы и по ним рисовать красоту, забив на модель данных всецело.
А можно по-другому. Вы садитесь и начинаете с самого верха описывать модель данных.
Пример
Возьмём в качестве примера веб-камеру, к которой пользователь может дистанционно подключиться через мобильное приложение, чтобы лицезреть как любимый кот обдирает не менее любимые обои и диван.
Давайте быстренько опишем то, что мы знаем о камере, а точнее о месте её расположения.
1. Есть дом — Home. Это самая верхняя сущность. Выше может быть страна — Country (вдруг наш пользователь из Москвы, а по совместительству ещё и обладатель валютной ипотеки на Кипре. Who knows). У него может быть не один дом, ведь на даче камера не помешает, правда ведь? Поэтому мы даём дому имя (Label) и ID (уникальный номер, позволяющий отличить его от другого дома у другого пользователя).
2. Внутри дома есть комната — Room. И чтобы знать какая камера в какой комнате установлена, нам нужно как-то описать эту комнату. У комнаты есть уникальный ID и набор других свойств: имя и украшательства (фото / цвет / иконка). И у неё есть статус — в сети ли наша камера(ы) в этой комнате или вырубило пробки. А комната может быть и гаражом, и студией — то есть один дом и одна комната. Мы не знаем, как пользователь настроит камеру(ы), но эта абстрактная сущность комнатой в любом случае останется. Если камера одна, то всё равно у нас будет следующая вложенность: Home > Room > Camera.
3. Камера — Camera. Камера тоже имеет ID, имя, украшательства. А ещё у неё бывают разные статусы. Например: On / Off / Error (ошибка) / Фиксация движения / Режим ожидания / Ночной режим. И статус батареи! О да, вдруг производитель оснастил её аккумулятором на случай падения напряжения! Тогда у нас появляется статус батареи — Battery status — 100–10% заряда / Осталось менее 10% / Осталось менее 5% и скоро вырубится.
4. Вы также можете описать пользовательскую модель, если у вас есть регистрация. Например, если пользователь один и не зарегистрирован, тогда он может создать лишь один дом. А если он зарегистрирован, допустим, через Facebook, — создавай сколько хочешь домов, раздавай права доступа членам семьи. Вся эта логика и возможности пользователей в зависимости от роли и прав доступа точно также описываются в модели данных. Например, при наличии возможности регистрации у вас сразу же появляются следующие роли: Admin | User | Anonymous. У Admin есть все возможности — добавлять камеры, дома, пользователей. Тогда как у User набор сильно скуднее — добавление камер в существующие дома и комнаты и, в общем-то, всё.
Разумеется, продукты бывают разные и, как следствие, вместе с размером приложения растёт и модель данных.
Итоговая модель выглядит следующим образом:
1. Country
> Country name
2. Home
> Home name
> Home ID
> Home image (вдруг мы захотим добавить фото фазенды)
> Home device list (список камер, которые находятся в этом доме; потребуется для добавления доступа User к дому с камерами).
3. Room
> Room name
> Room ID
> Room color (например, красный цвет иконки)
> Room icon
> Room image
> Room status
—> On
—> Off
—> Error
—> Night mode (yes/no — автоматическая настройка, зависит от освещённости)
> Room battery status
—> No battery (yes/no)
—> Range 100-10%
—> Range 10-5%
—> Range 5-0%
—> Depleted (батарея села; этот сигнал может отправить камера на последнем издыхании)
4. User model (можно и даже проще нарисовать пользовательскую модель в виде таблицы, где колонки — имена ролей, а строки — доступные функции)
> Admin
> User
> Anonymous
Хочу подчеркнуть, что всё вышеописанное есть не что иное, как логическое мышление и выписывание в соответствующий столбик того, что пришло вам в голову. Единственное правило: всегда начинайте строить модель данных с самой верхней сущности, постепенно спускаясь уровень за уровнем вниз. Главное — не делайте наоборот, иначе велик шанс что-то забыть.
———
Как пользоваться моделью данных?
Самые внимательные читатели догадались, что сверху выписано достаточное количество информации, чтобы нарисовать экраны настройки дома, комнаты и устройства, включая все возможные состояния экранов. Вы просто кладёте эту бумажку рядом с клавиатурой и берёте всю нужную информацию для того экрана, который рисуете. Используя такой подход у вас резко снижается риск неконсистентности приложения, потому что все данные вы уже выписали. Даже если вы что-нибудь забыли, просто допишите это в нужный раздел и добавьте эту функцию в дизайн.
Прикольно, да? =))
Если бы мы начали с камеры и расписывали бы сначала User stories, то мы бы точно что-нибудь упустили. Я ни к чему вас не призываю, вероятно User story может оказаться вам ближе. Но исходя из своего опыта, я бы советовал начинать с модели данных, а затем проверил бы её через User stories.
———
Вывод
Прежде чем что-то рисовать, надо понять какие данные лежат в основе приложения. На примере выше мы поняли из каких кубиков будут состоять экраны камеры, комнаты и дома. Если модель проработать глубже, то можно раскурить многопользовательский режим : как люди будут одновременно работать с камерой; кто что может / не может делать; как приглашать пользователей и где и на каком экране их удалять.
Помимо простоты и удобства модель данных таит в себе ещё один прекрасный сюрприз. Вы передадите модель данных вместе с дизайном разработчикам, которые расцелуют вас — вы ведь с них сняли огромный пласт работы! =))