Читаем Человеческий фактор в программировании полностью

Это приводит нас к важному правилу цвета в разработке пользовательских интерфейсов: никогда не полагайтесь только на цвет для обозначения важного различия между визуальными элементами. Например, если нужно отличать статическую связь классов от динамической связи экземпляров, то недостаточно отобразить одну связь краевым цветом, а другую — синим. Линии должны также разниться по толщине или по стилю (сплошная, пунктирная линия и т. д.).

Если цвет применяется как существенная часть пользовательского интерфейса, то скромный разработчик должен сохранить для конечного пользователя возможность выбора или, по крайней мере, последнего слова. В Windows вы можете менять цвет почти каждого элемента, но я никогда не мог сообразить, как изменить цвет текстового курсора в приложениях для Windows. Маленький, худосочный курсор, присутствующий в большинстве текстовых приложений, почти не виден, если он того же цвета, что и текст. В конце концов, я сделал цвет текста темно-синим. Текст стал читаться на белом фоне почти так же хорошо, как и черный, ко это намного облегчило поиск курсора.

Цветовые решения

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

Отчасти сложность состоит в том, что шаблоны разрабатывают либо программисты, которые не имеют никакого понятия об эстетике и мало разбираются (или совсем не разбираются) в вопросах передачи информации, либо графические дизайнеры, у которых есть чувство эстетики, но тоже нет глубокого понимания передачи информации. Первые производят все гот же пестрый мусор, который можно увидеть в палитре настраиваемых рабочих столов, а последние создают красивые шаблоны с сочными фоновыми цветами, которые отличают продукты высшего аудиовизуального класса. Типичная комбинация цветов представлена от глубокого пурпурного до ярко-синего, с голубыми заголовками и ярко-зелеными маркерами. Прекрасный вид и незабываемые ощущения! Единственная неувязка в том, что половина аудитории не может прочитать половину слайдов. На одной из недавних конференций почти каждый участник старше 40 лет признался мне, что не мог читать с этих великолепных проекционных дисплеев и вместо этого полагался на распечатки, которые, разумеется, были черно-белыми.

Ваши сотрудники, озабоченные хорошим «видом» и хорошим «ощущением», находятся на неверном пути. Восприятие формы зависит от контрастности. Как правило, чем больше контраст, тем легче читать. Уже давно известно, что при нормальном освещении текст удобнее всего читать, если он напечатан черным шрифтом на белом фоне. Светлое на темном (и другие сочетания цветов) читать значительно труднее.

Это поднимает другой вопрос: шрифты. По шрифтам пользовательского интерфейса иногда можно определить возраст людей, занимавшихся его разработкой. Слишком часто в программном обеспечении применяются или устанавливаются по умолчанию шрифты, которые я на» ываю «до 40», — небольшой размер символов и маленький междустрочный интервал. Эти шрифты могут читать только те, кому меньше 40! Проблема усугубляется дисплеями высокого разрешения, поскольку системные шрифты обычно являются растровыми. Не раз я был свидетелем того, как проваливалась демонстрация замечательного программного обеспечения, так как собравшиеся в демонстрационной кабине не могли прочитать текст меню и диаграмм; они только вежливо кивали головами, как будто понимали, что происходит.

Укрепляющаяся гегемония «презентационных пакетов» порождает и другие трудности. Такие пакеты создают, как я это называю, «шестизарядные слайды» — ну, вы знаете: маркер, маркер, маркер, маркер, маркер, маркер. Наглядные пособия должны быть именно наглядными пособиями. Они должны способствовать пониманию и запоминанию, визуально иллюстрировать, расширять или подкреплять комментарии докладчика. Шестизарядные визуальные материалы являются очень слабым и наименее эффективным методом применения потенциально мощного инструмента. От использования красивых цветов мало толку. Возможности цвета и графики необходимо применять для достижения конечной цели передачи информации, а не просто так, волей-неволей следуя дизайнерскому принципу сэра Эдмонда Хилари (Edmond Hillary) — раз уж они есть.

Подобно Сискелу (Siskel) и Эберту (Ebert), я убежден в том, что некоторые компоненты лучше всего воспринимаются в своей оригинальной, нецветной форме. Иногда цветной язык лучше всего переводить в простой чер-но-белый. А что касается цвета хлопка одной ладонью, я думаю, он может быть цвета окна.

Из журнала Software Development, том 1, № 1, январь 1993 г.

<p>38</p><p>Совершенствующиеся середнячки</p>
Перейти на страницу:

Похожие книги

Основы программирования в Linux
Основы программирования в Linux

В четвертом издании популярного руководства даны основы программирования в операционной системе Linux. Рассмотрены: использование библиотек C/C++ и стан­дартных средств разработки, организация системных вызовов, файловый ввод/вывод, взаимодействие процессов, программирование средствами командной оболочки, создание графических пользовательских интерфейсов с помощью инструментальных средств GTK+ или Qt, применение сокетов и др. Описана компиляция программ, их компоновка c библиотеками и работа с терминальным вводом/выводом. Даны приемы написания приложений в средах GNOME® и KDE®, хранения данных с использованием СУБД MySQL® и отладки программ. Книга хорошо структурирована, что делает обучение легким и быстрым. Для начинающих Linux-программистов

Нейл Мэтью , Ричард Стоунс , Татьяна Коротяева

ОС и Сети / Программирование / Книги по IT
97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

Успешная карьера архитектора программного обеспечения требует хорошего владения как технической, так и деловой сторонами вопросов, связанных с проектированием архитектуры. В этой необычной книге ведущие архитекторы ПО со всего света обсуждают важные принципы разработки, выходящие далеко за пределы чисто технических вопросов.?Архитектор ПО выполняет роль посредника между командой разработчиков и бизнес-руководством компании, поэтому чтобы добиться успеха в этой профессии, необходимо не только овладеть различными технологиями, но и обеспечить работу над проектом в соответствии с бизнес-целями. В книге более 50 архитекторов рассказывают о том, что считают самым важным в своей работе, дают советы, как организовать общение с другими участниками проекта, как снизить сложность архитектуры, как оказывать поддержку разработчикам. Они щедро делятся множеством полезных идей и приемов, которые вынесли из своего многолетнего опыта. Авторы надеются, что книга станет источником вдохновения и руководством к действию для многих профессиональных программистов.

Билл де Ора , Майкл Хайгард , Нил Форд

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT
Программист-прагматик. Путь от подмастерья к мастеру
Программист-прагматик. Путь от подмастерья к мастеру

Находясь на переднем крае программирования, книга "Программист-прагматик. Путь от подмастерья к мастеру" абстрагируется от всевозрастающей специализации и технических тонкостей разработки программ на современном уровне, чтобы исследовать суть процесса – требования к работоспособной и поддерживаемой программе, приводящей пользователей в восторг. Книга охватывает различные темы – от личной ответственности и карьерного роста до архитектурных методик, придающих программам гибкость и простоту в адаптации и повторном использовании.Прочитав эту книгу, вы научитесь:Бороться с недостатками программного обеспечения;Избегать ловушек, связанных с дублированием знания;Создавать гибкие, динамичные и адаптируемые программы;Избегать программирования в расчете на совпадение;Защищать вашу программу при помощи контрактов, утверждений и исключений;Собирать реальные требования;Осуществлять безжалостное и эффективное тестирование;Приводить в восторг ваших пользователей;Формировать команды из программистов-прагматиков и с помощью автоматизации делать ваши разработки более точными.

А. Алексашин , Дэвид Томас , Эндрю Хант

Программирование / Книги по IT