Этих проблем. Другими словами, он заставляет вас иметь дело с реальностью. Getting Real отказывается от функциональных спецификаций и подобных эфемерных документов в пользу реальных экранов. Функциональная спецификация – это притворство, иллюзия договоренности, тогда как действительная веб страница

Скачать 1.06 Mb.

Название	Этих проблем. Другими словами, он заставляет вас иметь дело с реальностью. Getting Real отказывается от функциональных спецификаций и подобных эфемерных документов в пользу реальных экранов. Функциональная спецификация – это притворство, иллюзия договоренности, тогда как действительная веб страница
страница	9/17
Дата публикации	15.09.2014
Размер	1.06 Mb.
Тип	Документы

100-bal.ru > Философия > Документы

1 ... 5 6 7 8 9 10 11 12 ... 17

Создание интерфейса

Сначала – интерфейс

Создавайте дизайн интерфейса до того как начнете программировать

Слишком много приложений создаются с подходом «сначала программируем». Это неудачная идея. Программирование – самое сложное в создании приложения, а это значит, что и самое дорогое. И, создав код, вам будет сложно его изменить. Вместо этого начинайте с дизайна интерфейса.

Дизайн относительно легко изменять. Бумажный набросок дешев и его легко изменить. html наброски тоже довольно просто изменить или просто выбросить. Но в отношении программирования это неверно. Подход «сначала дизайн» позволит вам быть гибкими. Подход «сначала программирование» ограничивает вас и приводит к дополнительным затратам.

Другая причина для того, чтобы начинать с дизайна в том, что интерфейс и есть продукт. Вы продаете людям то, что они видят. И если вы оставите интерфейс «на потом», огрехи будут заметны.

Мы начинаем с интерфейса, и можем «пощупать» приложение с самого начала. И интерфейс постоянно пересматривается в процессе разработки. Понятен ли он? Прост ли в использовании? Позволяет ли легко решить проблему? Верно ответить на эти вопросы вы можете только если уже имеете реальный интерфейс. Подход «сначала дизайн» позволяет вам оставаться гибкими и подталкивает к ответам на эти вопросы как можно раньше, вместо того что бы оставлять их «на потом».

Оранжевая ручка, с которой начался Blinksale

Как только я понял, что готовые приложения для выставления счетов меня не устраивают, я решил нарисовать на бумаге, как я представляю такое приложение. Я взял оранжевую ручку, потому что больше в тот вечер было нечем рисовать, и через несколько часов три четверти будущего приложения были готовы. Я показал всё своей жене, Рейчл, которая как раз гладила и спросил её, что она думает по этому поводу. И она ответила с улыбкой: «Тебе надо сделать это. Правда.»

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

Как только html макеты были готовы, мы рассказали идею нашему разработчику, Скотту. То, что большая часть дизайна была уже создана, было весьма кстати. Во первых, это дало Скотту реальной представление о направлении, в котором мы движемся, и вовлекло его. Это было больше чем идея, это была реальность. Во вторых, это помогло нам подсчитать, сколько усилий и времени потребуется от Скотта, чтобы превратить дизайн в работающее приложение. Когда вы финансируете проект с самого начала, то чем раньше вы сможете предсказать бюджет тем лучше. Дизайн пользовательского интерфейса стал нашим мерилом для границ проекта. И последнее – дизайн интерфейса служил нам для того, чтобы напомнить нам о том, для чего предназначено приложение, по мере того, как продвигалась разработка. Каждый раз как появлялся соблазн добавить новые возможности, мы не могли просто сказать «А давайте ка добавим вот это и ещё это!». Мы должны были бы вернуться к дизайну и спросить себя, где надо добавить новую возможность, и если для неё не было места, мы её не добавляли

– Josh Williams, основатель, Blinksale^¹⁶

Дизайн от эпицентра

Начинайте с самого важного на странице и двигайтесь вширь

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

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

Только когда эпицентр готов, можно подумать о втором по критичности элементе на странице. После второго вы можете перейти к третьему и так далее. Это и есть дизайн «от эпицентра».

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

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

Три состояния программы

Делайте дизайн для обычного, пустого, и ошибочного состояния страницы.

Для каждого экрана вы должны рассмотреть три состояния:
Обычное

Экран, который люди видят каждый день при работе с приложением, заполненным данными.
Пустое

Экран, который люди видят при первом запуске, и ещё не успели ввести данные.
Ошибка!

Экран, который люди видят, когда что то идёт не так.
Обычное состояние – это элементарно :) Это экран, где вы проводите бОльшую часть вашего времени. Но не забывайте инвестировать время и в другие состояния (читайте следующие эссе, чтобы узнать больше об этом).

С самого начала

Создавайте ожидания, продумав то, какой опыт получит пользователь при первом запуске

Игнорировать состояние «чистого листа» – одна из самых больших ошибок, которую вы можете сделать. «Чистый лист» – это первое впечатление от вашего приложения, и у вас не будет второго шанса его создать... ну, вы знаете.

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

Однако обычное состояние приложения – когда оно не не набито данными. Когда кто то регистрируется, он начинает с чистого листа. Более похоже на блог, который надо заполнить – общий вид неясен, пока люди не введут свои данные: посты, ссылки, комментарии, часы, информацию на сайдбаре, или ещё что то.

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

Пока бОльшая часть дизайнеров и разработчиков всё ещё принимает это состояние за само собой разумеющееся. Они не могут разработать состояние «чистого листа», потому что когда они разрабатывают или пользуются приложением, оно полно данных, которые они ввели для тестирования. Они даже не встречаются с состоянием «чистого листа». Конечно, они могут войти в качестве нового пользователя пару раз, но бОльшая часть их времени проходит в плавании по приложению, заполненному данными.
Что вы должны включать в действительно полезный «чистый лист»?

* Используйте его как возможность вставить краткий обучающий курс и подсказки по использованию приложения.

* Дайте снимок экрана, заполненного данными, чтобы люди знали чего ожидать (и с чем им придётся иметь дело).

* Объясните, с чего начать, на что будет похож экран и так далее.

* Отвечайте на основные вопросы тех, кто пришёл первый раз: Что это за страница? Что я сейчас делаю? Как будет выглядеть заполненный экран?

* Создавайте ожидания, помогите избежать разочарования, страхов и смущения.
Первые впечатления жизненно важны. Если вам не удаётся создать продуманное состояние «чистого листа», вы создадите негативное (и неверное) впечатление от вашего приложения или сервиса.

У вас никогда не будет второго шанса...

Ещё один аспект интерфейса Mac OS X, на который, я думаю, сильно повлияло мнение Стива Джобса (Steve Jobs) – это установка и первый запуск системы. Я думаю, Джобс в курсе важности первого впечатления. Я думаю, Джобс смотрит на то как выглядит первый запуск системы и обдумывает его. Это, возможно, одна тысячная общего опыта работы с машиной, но это самая важная тысячная, потому что это первая тысячная и она создаёт ожидания и начальное впечатление.

– John Gruber^¹⁷, автор и разработчик (из интервью с John Gruber^¹⁸)

Защищайтесь

Продумайте дизайн для нештатных ситуаций

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

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

Мы могли бы многое рассказать об оборонительном дизайне – хватило бы на отдельную книгу. Собственно, мы ее уже написали. Книга называется «Оборонительный дизайн для сети» (Defensive Design for the Web ), и послужит хорошей подмогой любому, кто хочет улучшить сообщения об ошибках и другие критические точки.

Помните: ваше приложение может работать отлично в 90% случаев. Но если вы бросаете пользователей на произвол судьбы там, где ваша помощь им нужна – они вряд ли это забудут.

Содержание важнее целостности

То, что имеет смысл «здесь», может потерять его «там»

Должны ли действия задаваться кнопками или ссылками? Это зависит от действия. Должны ли даты выбираться из списка или из сетки календаря? Это зависит от того, где будут показаны даты и какой временной период они задают. Нужны ли все линки навигации на каждой странице? Нужна ли всюду строка поиска? Нужно ли повторять колонтитул на каждой странице? Правильный ответ: «смотря по обстоятельствам.»

Вот почему содержание гораздо важнее целостности. Это нормально – сделать дизайн непоследовательным, если в этом есть смысл. Давайте людям то, что имеет смысл. Давайте то, что им нужно, и избавьте от того, что лишнее. Уместность лучше последовательности.

Разумное непостоянство

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

В Creative Good, мы называем это «разумным непостоянством»: на каждой странице пользователи видят именно то, что им нужно на том шаге, на котором они находятся. Добавлять избыточные элементы навигации лишь для того, чтобы сохранить целостность сайта, просто глупо.

– Mark Hurst, основатель Creative Good^¹⁹ и создатель Goovite.com^²⁰ (из The Page Paradigm^²¹)

Дизайн интерфейсов – это копирайтинг

Каждая буква имеет значение

Дизайн интерфейсов – это копирайтинг. Лучшие интерфейсы написаны. Если вы думаете что каждый пиксель, каждая иконка, каждый шрифт имеет значение, вы поверите и в значимость каждой буквы. Когда вы описываете свой интерфейс, всегда смотрите на него глазами пользователей. Что они должны знать? Как это объяснить лаконично и доходчиво?

Назовёте ли вы кнопку «ОК» или «Сохранить» или «Обновить»? «Добавить» или «Создать»? Это копирайтинг. Напишите ли вы три предложения или пять? Объясните ли вы на общих примерах или со всеми подробностями? Пометите ли вы записи как «Новые», «Недавно обновлённые» или «Измененные». «Всего новых сообщений: 5» или «5 новых сообщений»? «5» или «пять»? «сообщений» или «постов»? Всё имеет значение.

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

Хорошая документация – это хороший дизайн. Это редкое исключение когда слова не соответствуют дизайну. Иконки, названия, формы примеров, надписи на кнопках, пошаговые инструкции, понятное объяснение правил возврата денег – все это дизайн интерфейсов.

Единый интерфейс

Объединяйте настройки с основным интерфейсом

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

Не создавайте отдельного интерфейса для настроек, просто встройте его функции в основной.

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

Нет разделению интерфейсов

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

– Эдвард Ниттел, Директор по продажам и маркетингу, KennelSource^²²