Текст книги "Getting Real"
Автор книги: 37signals
Жанр:
Программирование
сообщить о нарушении
Текущая страница: 5 (всего у книги 8 страниц)
Три состояния программы
Делайте дизайн для обычного, пустого, и ошибочного состояния страницы.
Для каждого экрана вы должны рассмотреть три состояния:
Обычное
Экран, который люди видят каждый день при работе с приложением, заполненным данными.
Пустое
Экран, который люди видят при первом запуске, и ещё не успели ввести данные.
Ошибка!
Экран, который люди видят, когда что-то идёт не так.
Обычное состояние – это элементарно :) Это экран, где вы проводите бОльшую часть вашего времени. Но не забывайте инвестировать время и в другие состояния (читайте следующие эссе, чтобы узнать больше об этом).
С самого начала
Создавайте ожидания, продумав то, какой опыт получит пользователь при первом запуске
Игнорировать состояние «чистого листа» – одна из самых больших ошибок, которую вы можете сделать. «Чистый лист» – это первое впечатление от вашего приложения, и у вас не будет второго шанса его создать... ну, вы знаете.
Проблема в том, что когда вы разрабатываете интерфейс, он обычно заполнен данными. Дизайнеры всегда заполняют шаблоны данными. Каждый список, каждый пост блога, каждое поле, все тёмные углы и щелки в шаблонах заполнены данными. И это значит, что экран выглядит и работает великолепно.
Однако обычное состояние приложения – когда оно не не набито данными. Когда кто-то регистрируется, он начинает с чистого листа. Более похоже на блог, который надо заполнить – общий вид неясен, пока люди не введут свои данные: посты, ссылки, комментарии, часы, информацию на сайдбаре, или ещё что-то.
К сожалению, пользователь решает, достойно ли приложение внимания, на этапе «чистого листа» – на этапе, когда количество информации, дизайн и содержимое по которым судят полезность приложения в целом, минимальны. Если вам не удаётся создать адекватное состояние «чистого листа», люди не знают, чего им не хватает, потому что им не хватает всего.
Пока бОльшая часть дизайнеров и разработчиков всё ещё принимает это состояние за само собой разумеющееся. Они не могут разработать состояние «чистого листа», потому что когда они разрабатывают или пользуются приложением, оно полно данных, которые они ввели для тестирования. Они даже не встречаются с состоянием «чистого листа». Конечно, они могут войти в качестве нового пользователя пару раз, но бОльшая часть их времени проходит в плавании по приложению, заполненному данными.
Что вы должны включать в действительно полезный «чистый лист»?
* Используйте его как возможность вставить краткий обучающий курс и подсказки по использованию приложения.
* Дайте снимок экрана, заполненного данными, чтобы люди знали чего ожидать (и с чем им придётся иметь дело).
* Объясните, с чего начать, на что будет похож экран и так далее.
* Отвечайте на основные вопросы тех, кто пришёл первый раз: Что это за страница? Что я сейчас делаю? Как будет выглядеть заполненный экран?
* Создавайте ожидания, помогите избежать разочарования, страхов и смущения.
Первые впечатления жизненно важны. Если вам не удаётся создать продуманное состояние «чистого листа», вы создадите негативное (и неверное) впечатление от вашего приложения или сервиса.
У вас никогда не будет второго шанса...
Ещё один аспект интерфейса Mac OS X, на который, я думаю, сильно повлияло мнение Стива Джобса (Steve Jobs) – это установка и первый запуск системы. Я думаю, Джобс в курсе важности первого впечатления. Я думаю, Джобс смотрит на то как выглядит первый запуск системы и обдумывает его. Это, возможно, одна тысячная общего опыта работы с машиной, но это самая важная тысячная, потому что это первая тысячная и она создаёт ожидания и начальное впечатление.
Защищайтесь
Продумайте дизайн для нештатных ситуаций
Посмотрим правде в глаза: неполадки обязательно будут происходить. Как бы тщательно вы не проектировали приложение, сколько бы времени не посвятили тестированию, у клиентов все равно будут случаться проблемы. Так как вы будете обрабатывать эти поломки? С помощью оборонительного дизайна.
Оборонительный дизайн похож на контраварийное вождение. Так же, как водителям всегда нужно быть начеку – бывают скользкие дороги, безрассудные водители и другие опасные сценарии, – создатели сайтов должны постоянно следить за источниками проблем, которые могут приводить к растерянности и расстройству посетителей . Хорошая защищенность сайта определяет, насколько успешным для клиентов будет опыт использования сайта.
Мы могли бы многое рассказать об оборонительном дизайне – хватило бы на отдельную книгу. Собственно, мы ее уже написали. Книга называется «Оборонительный дизайн для сети» (Defensive Design for the Web), и послужит хорошей подмогой любому, кто хочет улучшить сообщения об ошибках и другие критические точки.
Помните: ваше приложение может работать отлично в 90% случаев. Но если вы бросаете пользователей на произвол судьбы там, где ваша помощь им нужна – они вряд ли это забудут.
Содержание важнее целостности
То, что имеет смысл «здесь», может потерять его «там»
Должны ли действия задаваться кнопками или ссылками? Это зависит от действия. Должны ли даты выбираться из списка или из сетки календаря? Это зависит от того, где будут показаны даты и какой временной период они задают. Нужны ли все линки навигации на каждой странице? Нужна ли всюду строка поиска? Нужно ли повторять колонтитул на каждой странице? Правильный ответ: «смотря по обстоятельствам.»
Вот почему содержание гораздо важнее целостности. Это нормально – сделать дизайн непоследовательным, если в этом есть смысл. Давайте людям то, что имеет смысл. Давайте то, что им нужно, и избавьте от того, что лишнее. Уместность лучше последовательности.
Разумное непостоянство
Целостность не обязательна. Годами студентам твердят, что целостность интерфейса – одно из важнейших правил дизайна интерфейсов. Возможно, это справедливо для традиционного ПО, но не для веб, где каждый сайт отличается от другого и посетители могу легко и быстро перемещаться по ним.
В Creative Good, мы называем это «разумным непостоянством»: на каждой странице пользователи видят именно то, что им нужно на том шаге, на котором они находятся. Добавлять избыточные элементы навигации лишь для того, чтобы сохранить целостность сайта, просто глупо.
Дизайн интерфейсов – это копирайтинг
Каждая буква имеет значение
Дизайн интерфейсов – это копирайтинг. Лучшие интерфейсы написаны. Если вы думаете что каждый пиксель, каждая иконка, каждый шрифт имеет значение, вы поверите и в значимость каждой буквы. Когда вы описываете свой интерфейс, всегда смотрите на него глазами пользователей. Что они должны знать? Как это объяснить лаконично и доходчиво?
Назовёте ли вы кнопку «ОК» или «Сохранить» или «Обновить»? «Добавить» или «Создать»? Это копирайтинг. Напишите ли вы три предложения или пять? Объясните ли вы на общих примерах или со всеми подробностями? Пометите ли вы записи как «Новые», «Недавно обновлённые» или «Измененные». «Всего новых сообщений: 5» или «5 новых сообщений»? «5» или «пять»? «сообщений» или «постов»? Всё имеет значение.
Вы должны говорить тем же языком, что и ваша аудитория. Тот факт, что вы пишете приложение для веб, еще не значит что будет уместен технический жаргон. Думайте о своих клиентах и о том, что значат для них эти кнопки и слова. Не используйте малознакомых сокращений или слов. Не выражайтесь словами директора на совещании. Будьте кратки и вежливы. Скажите главное, и не более.
Хорошая документация – это хороший дизайн. Это редкое исключение когда слова не соответствуют дизайну. Иконки, названия, формы примеров, надписи на кнопках, пошаговые инструкции, понятное объяснение правил возврата денег – все это дизайн интерфейсов.
Единый интерфейс
Объединяйте настройки с основным интерфейсом
Страницы, содержащие системные настройки, списки пользователей и т.п., зачастую крайне неудобны и ужасно выглядят. Всё потому, что большая часть времени тратится на разработку основного интерфейса.
Не создавайте отдельного интерфейса для настроек, просто встройте его функции в основной.
Поддерживая сразу два интерфейса вы делаете лишнюю работу. Всё равно, что платить один и тот же налог дважды. Чем чаще вы вынуждены повторяться, тем выше шансы ошибиться. Напротив, чем меньше страниц вам приходиться поддерживать, тем легче и проще для вас и тем лучше для вашего клиента.
Нет разделению интерфейсов
Приложение – единое целое. Всё что может быть изменено, добавлено или настроено, должно изменяться, добавляться и настраиваться напрямую из приложения. Когда мы видим именно то, что видят наши клиенты – нам гораздо проще разобраться в любых возникших проблемах. Нашему клиенту не нужно пользоваться несколькими разными интерфейсами. В данную секунду он работает с деловым расписанием, в следующую он захочет создать учётную запись для нового сотрудника. Зачем ему переключаться в другое приложение? Пользуясь одним понятным и последовательным интерфейсом он освоится гораздо быстрее.
Код
Меньший объем программы
Сохраняйте код как можно более простым
Вам кажется, что имея в два раза больше кода, ваша программа будет только вдвое сложнее. На самом деле, каждый раз, когда вы увеличиваете объем кода, сложность программы возрастает экспоненциально. Каждое маленькое дополнение, каждое изменение, каждая взаимозависимость и каждое предпочтение имеют каскадный эффект. Продолжайте безбоязненно добавлять код, и вы получите страшный Большой Ком Грязи – до того, как это заметите.
Как бороться с этой сложностью – уменьшением объема программы. Уменьшение объема программы значит меньше функций, меньше кода, меньше отходов.
Главное здесь – переформулировать любую сложную задачу, требующую много кода, в простую задачу, которая требует кода намного меньше. Возможно, вы уже не будете решать в точности ту же задачу – это нормально. Решить 80% первоначальной задачи, затратив 20% усилий – это большой выигрыш. Первоначальный вариант задачи обычно никогда не является настолько важным, чтобы затрачивать в пять раз больше времени на ее решение.
Меньший объем программы значит, что вам не придется теряться в догадках. Вместо попыток предугадать проблемы в будущем, вы решаете только сегодняшние проблемы. Почему? Страхи, которые вы питаете по поводу будущего, как правило, не оправдываются. А потому не толкайте себя в болото, пытаясь бороться с призраками.
С самого начала, мы проектировали наши продукты в соответствии с концепцией меньшего объема кода. При малейшей возможности мы разделяем сложные задачи на простые. Мы нашли решения простых задач, которые легче не только воплощать или поддерживать, но и понимать, и использовать. Все это – часть того, как мы отличаемся от конкурентов; вместо того, чтобы разрабатывать продукты, которые делают больше, мы разрабатываем те, которые делают меньше.
* Меньшим объемом программы легче управлять.
* Меньший объем программы – меньше кода, а это значит
* Меньше скучной работы по сопровождению (и более счастливый персонал).
* Меньший объем программы снижает стоимость изменений – так что вы можете быстрее адаптироваться к обстоятельствам. Вы можете менять свои решения без того, чтобы менять мегабайты кода.
* Меньше кода – меньше ошибок.
* Меньше кода – меньше техподдержки.
Какие функции оставить, а какие исключить – тут решение тоже связано с уменьшением объема программы. Не бойтесь отказать в выполнении запроса, который слишком труден. Если функция не является абсолютно критичной – вы сэкономите время и усилия, уменьшите путаницу тем, что откажетесь от нее.
Тише едешь – дальше будешь. Появилась идея – подождите неделю, прежде чем ее воплощать, посмотрите, будет ли она казаться такой же хорошей, когда шум спадет. Помаринуйте идею – и, может быть, за это время вам в голову придет еще более простое решение.
Поощряйте контрпредложения от программистов.
Вот что хорошо было бы от них слышать: «Если делать это как вы предлагаете – на это уйдет 12 часов. Но я могу сделать это за час. В таком случае программа будет делать x и не будет делать y.» Почувствуйте, как программа сопротивляется добавлению лишних функций. Научите программистов отстаивать свою точку зрения на то, как лучше написать программу.
Также ищите обходные пути вокруг необходимости написания большего количества кода. Можете ли вы изменить экран так, что он предложит клиентам альтернативный путь – без того, чтобы менять модель программы? Например, можно ли предложить пользователям загружать картинки только определенного размера – без того, чтобы производить обработку изображений на сервере?
Для каждой функции, которая попадает в вашу программу, спрашивайте себя: а нет ли другого способа ее добавить, используя меньшее количество кода? Пишите только тот код, который вам нужен, и не более того. Ваше приложение будет более поджарым – и более здоровым.
Нет кода более гибкого, чем отсутствие кода!
«Секрет» хорошего программирования совсем не в том, что именно воплотить в коде – а в том, что оставить за его рамками. В том, чтобы определить, где сильные и слабые места программы, и решить, где нужно просто оставить свободное место, вместо того чтобы заполнять его функциональностью.
Сложность растет не пропорционально размеру
Самое важное правило разработки программного обеспечения – еще и наименее известное. Сложность программы растет не пропорционально ее размеру... И программа из 2000 строк потребует не в два раза больше времени, а гораздо больше, чем программа в половину этого размера.
Оптимизируйте для счастья
Выбирайте инструменты, которые заинтересовывают и стимулируют вашу команду
Счастливый программист – продуктивный программист. Вот почему мы оптимизируем удовлетворенность работой, и вам тоже стоит это делать. Выбирайте инструменты, базируясь не только на стандартах отрасли или производительности. Смотрите на неосязаемые факторы: чувствуется ли в инструменте страсть, гордость и мастерство? Будете ли вы по-настоящему счастливы, работая в этой среде восемь часов в день?
Это особенно важно при выборе языка программирования. Вопреки общему мнению, языки программирования не равноценны. В то время как на любом языке можно написать практически любую программу, хороший язык сделает вашу задачу не просто возможной и терпимой, а радостной и дающей силы. Мы о том, что маленькие детали ежедневной работы должны приносить радость.
Счастье заразительно. Счастливые программисты поступают правильно. Они пишут простой, читабельный код. Они придерживаются ясных, выразительных, читабельных подходов. Им нравится то, что они делают.
Мы нашли наше программистское счастье в языке Ruby – и мы поделились им с другими разработчиками через нашу платформу Rails. И Ruby, и Rails проповедуют идею оптимизации для людей и их счастья. Мы приглашаем вас опробовать эту комбинацию.
В общем, вашей команде нужно использовать инструменты, которые станут любимыми. Мы говорили тут о языках программирования, но то же верно для программ, платформ и всего остального. Выберите инструменты, которые не оставят разработчиков равнодушными. Вы получите мотивацию, и, как следствие, лучший продукт.
Какие инженеры вам нужны
Причина того, что я хотел создавать наше приложение на Ruby on Rails, в том, что эта платформа элегантна, продуктивна и красиво спроектирована. Она привлекает инженеров, которые заботятся именно об этом... а это именно такого рода инженеры, какие вам нужны, потому что они создают именно такие красивые, элегантные и продуктивные программы, которые вам нужны, чтобы завоевать рынок.
Говорит код
Слушайте, когда ваш код сопротивляется
Прислушивайтесь к своему коду. Он будет высказывать предложения. Он будет сопротивляться. Он расскажет, где стоят ловушки. Он предложит новые пути решений. Он поможет вам держаться модели меньшего объема программы.
Что, добавление новой функции требует недель времени и тысяч строк кода? Это код говорит вам, что, возможно, существует более легкий способ. Нашли более простое решение, которое можно воплотить за час вместо десяти? Это код вам подсказывает. Прислушайтесь.
Ваш код подскажет вам решения, которые дешевы и легки. Замечайте, когда появляется более простой путь. Разумеется, функция, которую легко сделать, может быть не в точности такой, какую вы себе представляли вначале – ну и что? Если она работает достаточно хорошо и оставляет вам больше времени на другие дела – оставьте ее.
Послушайте
Не беспокойтесь о дизайне; если вы прислушиваетесь к своему коду, хороший дизайн появится сам... Прислушивайтесь к техническому персоналу. Если сотрудники жалуются на то, как трудно вносить изменения – отнеситесь к этому серьезно и дайте им достаточное количество времени на исправления.
Если бы программистам платили за то, чтобы убирать код...
Если бы программистам платили за то, чтобы убирать код из программы вместо того, чтобы добавлять его, программы были бы намного лучше.
Разберитесь с долгами
Расплачивайтесь по долгам вашего кода и дизайна
Мы обычно говорим о долгах в денежном выражении, но долги могут принимать и другие формы. Вы можете быстро обрасти долгами кода и дизайна.
Наваяли блок кода, который функционален, но все еще неопрятен – вот вы и набрали долгов. Набросали дизайн по принципу «и так сойдет» – ваши долги выросли опять.
Время от времени так поступать можно. Часто такая техника помогает поскорее довести проект в стиле Get Real до конца. Но все равно нужно признать эти долги и рано или поздно расплатиться с ними – вычистить неопрятный код, переделать ту страницу, которая была сделана так себе.
Точно так же, как вы откладываете часть дохода, чтобы заплатить налоги, регулярно выделяйте время на то, чтобы расплатиться с долгами по коду и дизайну. Если этого не делать, придется платить проценты (исправлять кривой код), вместо того, чтобы платить основную сумму (и двигаться вперед).
Открытые двери
Выпустите данные в мир через RSS, API и т.п.
Не пытайтесь запереть ваших клиентов. Позвольте им получить принадлежащую им информацию когда они хотят и как они хотят. Для этого вам придется отказаться от идеи запечатать данные. Выпустите их. Дайте людям доступ к их информации через RSS. Обеспечьте API, позволяющие другим разработчикам подсоединяться к вашей программе. Поступая так, вы облегчаете жизнь клиентам и расширяете возможности своей программы.
Раньше к RSS-фидам относились как к хорошему способу следить за обновлениями блогов и новостных сайтов. Но у них есть и другие сильные стороны. Они также позволяют клиентам быть в курсе изменяющегося контента приложения без того, чтобы постоянно в него входить. С фидами Basecamp пользователи могут ввести адрес в новостную ленту и быть в курсе того, что делается с проектом: сообщения, списки задач, этапы – без того, чтобы постоянно проверять все это на сайте.
API позволяют разработчикам создавать добавки к вашим продуктам – которые, в свою очередь, могут оказаться неоценимыми. Например, Backpack предоставляет API, которыми Chipt Productions воспользовался для построения программы Mac os x Dashboard. Программа позволяет добавлять и редактировать напоминания, списки и другое на рабочем столе. Клиенты с большим одобрением оценили эту программу, многие даже сказали, что благодаря ей они стали пользователями Backpack.
Вот еще примеры компаний, выпускающих данные наружу и получающих в результате эффект бумеранга:
Google Maps API положило начало интересной тенденции смешанных сайтов, когда люди получают информацию из других источников (например, объявления о квартирах) и наносят их на карту.
Linkrolls предлагает клиентам способ получить новейшие закладки del.icio.us, показанные на их сайтах.
Flickr предоставляет другим продавцам доступ к своим коммерческим API, так что клиенты могут покупать фотоальбомы, запасные хранилища данных для dvd, плакаты и марки. «Цель – открыть все по максимуму и дать вам наибольшее разнообразие выбора того, что вы можете сделать со своими фотографиями», – говорит Стюарт Баттерфилд из Flickr.
Программка, которая меняет дело
Когда компания 37signals выпустила Backpack, мое первое впечатление было...э-э.
Так что, когда Chipt Productions выпустили программку для Backpack для Tiger – и невозможно было ее не попробовать – я посмотрел на Backpack во второй раз. Результат? Совсем другое дело.
Сейчас, когда мне приходит в голову новая идея, я запускаю программку, печатаю, отправляю сообщение – готово. По электронной почте приходит нечто, что я хочу посмотреть? Запускаю программку, печатаю, отправляю – готово. Эта программка установлена – на каждом компьютере Mac, который я использую. И благодаря тому, что программка сетевая – не нужно заботиться о контроле версий или синхронизации – можно просто вводить информацию, не задумываясь, куда она пойдет или как получить к ней доступ позднее.
