Книги по разным темам Pages:     | 1 |   ...   | 20 | 21 | 22 | 23 | 24 |   ...   | 27 |

используйте индикацию видом курсора во всех случаях, когда вы можете сделать это эстетически привлекательно; в остальных случаях о курсорах даже и не думайте.

Но что вообще входит в понятие красивого курсора Это, по преимуществу, все внешние курсоры, неважно, откуда они приходят, из ОС для ПО или CSS для сайта (набор курсоров в обоих источниках практически совпадают). Можно, конечно, нарисовать и собственные курсоры, но я не рекомендую это делать, поскольку все хорошие курсоры уже были кем то нарисованы, так что вы можете легко нарушить чьи то авторские права.

Если же вы всё таки решитесь рисовать собственные курсоры, старайтесь придерживаться двух правил: избегайте цвета и делайте курсоры такими, чтобы активная точка курсора (которая указывает) была возможно ближе к верхнему левому краю курсора.

Пожалуй, ни одна тема не вызывает у дизайнеров такого интереса и Цвет воодушевления, как цвет. Извечные споры какой колёр лучше не утихают и не утихнут, похоже, никогда. Однако в рамках этой книги нет места для этих споров, так что мы ограничимся малым.

Во первых, следует сразу сказать, что цветами невозможно передавать пользователям сколько нибудь сложную информацию. Как правило, схемы типа лэтот объект тёмный, значитЕ не работают, поскольку требуют от пользователей длительной тренировки. С другой, стороны, люди хорошо способны замечать и анализировать взаимосвязи цветов, так, строки в таблице, окрашенные в разные цвета, подсознательно будут группироваться пользователями по цветовому признаку. Обратите внимание, что работать это будет только при очень ограниченном числе используемых цветов (как можно догадаться, максимальное число цветов равно объему кратковременной памяти). Однако на практике, всё, что можно передать цветом, умещается в одно предложение: для всех красный цвет обозначает нельзя или лосторожно, для многих людей зеленый обозначает поехали (от умения пользоваться светофором; интересно, что желтый цвет не работает, хотя должен). Реально актуальна только первая половина предложения, поскольку в нашем деле фраза для многих людей часто значит ни для кого.

Не используйте кодирование цветом без крайней необходимости, когда же вы всё таки его используете, добавляйте дополнительные способы индикации ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ОСТАЛЬНОЕ Во вторых, восприятие цвета индивидуально, при этом порой слишком сильно. Я не имею в виду дальтоников (хотя и их тоже), просто достаточно большое количество людей использует старые мониторы, на которых цвета поехали, и, что более важно, с возрастом зрение слабеет, при этом види мые цвета темнеют и выцветают. Это значит, что нельзя использовать цвет как единственный индикатор чего либо, обязательно должен быть и другой признак. Из за этой индивидуальности восприятия цветов происходит другое правило: позволяйте пользователю самому выбрать цвета, поскольку цвет, нравящийся одному человеку, возможно, будет вызывать омерзение у другого (желательно делать это системными средствами).

Звук, как и цвет, в интерфейсе не есть вещь абсолютно необходимая.

Звук Скажем так, он практически не может делать что либо полезное, помимо индицирования конца какого либо процесса (благодаря которому пользователь освобождается от необходимости поминутно поглядывать на экран). Это происходит вовсе не потому, что звук плох, но лишь потому, что очень незначительное количество компьютеров имеет работающие звуковые подсистемы. Только в играх можно рассчитывать на наличие звука, исходящего из компьютера пользователя. Таким образом, звука мы оказываемся лишены. В то же время и о звуке есть что сказать, хотя и не много.

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

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

ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ОСТАЛЬНОЕ Часть i Процесс В этой части описана методология дизайна интерфейса, обеспечивающая достаточное качество работы, её простоту, и, что немаловажно, соблюдение сроков её выполнения.

ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: Три шага к красоте В процессе дизайна интерфейса можно выделить три основных этапа, а именно первоначальное проектирование (часто оказывающееся и окончательным), создание прототипа и тестирование/модификация прототипа.

Фактически процесс дизайна, чтобы быть успешным и безусловным, всегда стремится происходить в этой последовательности: проекти рование, затем создание прототипа, затем тестирование/модификация, затем опять тестирование/модификация, затем опять тестирование/ модификация, затем опять тестирование/модификация, затем нечеловеческие крики начальства Хоре волынку тянуть, чтоб через пять минут усё было!. Т.е. основным этапом оказывается не проектирование (т.е. собственно дизайн), но полировка уже сделанного дизайна. С другой стороны, при тщательном проектировании длительного тестирования обычно удается избежать - но, с другой стороны, при этом проектирование становится достаточно длительным, так что неизвестно еще, что лучше сокращать.

Этап проектирования сам по себе состоит из нескольких составляющих, причем количество этих составляющих довольно велико. Радует, однако, то, что существует очень мало работ, при которых нужно выполнять все составляющие (собственно говоря, если выполнять всё таки придется, это должны делать разные специалисты). Поскольку объем книги ограничен, здесь описываются только самые необходимые.

При этом важно понимать, что здесь описываются только методы создания новой системы. Модернизация старой требует совершенно других методов и усилий, поскольку при этом приходится еще и безболезненно исправлять имеющиеся недостатки (что чаще всего вообще невозможно по организационным причинам). Как это ни печально, но в настоящее время не найдено сколько нибудь универсального метода радикального улучшения существующих систем. Зачастую вместо полноценного дизайна приходится удовлетворяться наведением общего глянца, что, в лучшем случае, придает системе сомнительный шарм молодящегося старика.

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

Необходимо также отметить еще и следующее. В процессе проектиро вания вам понадобится незаслуженно забытые инструменты - а именно ручка и бумага. Дело в том, что использование компьютера само по себе медленно, во первых, поскольку интерфейс программ несовершенен, а во вторых, из за того, что, используя компьютер, вы будете подсознательно стараться сделать работу красиво, а не просто будете фиксировать свою ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ТРИ ШАГА К КРАСОТЕ мысль. Известно, например, что текстовые процессоры не принесли ускорения письма - человек, пишущий на компьютере тратит уйму времени на полировку фраз. Владелец же печатающей машинки полирует фразы в голове, что гораздо быстрее. Более того, почти постоянно приходится делать много вариантов одного и того же - так зачем полировать до блеска вариант, который вы отбросите через пять минут Тем более что после получения устраивающего результата всегда можно перенести его в компьютер. Бумага имеет еще и то преимущество, что её можно с успехом показывать руководству в качестве доказательств своей активности.

Практика показывает, что вид сколотых скрепкой мятых исчерканных листов почти всегда производит на руководящий состав исключительное впечатление (мы то с вами знаем, что внутрь этой пачки для толщины можно класть всё что угодно).

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

Первым человеком, которого плохой интерфейс приводит в трепет, Роль технического является отнюдь не конечный пользователь, но технический писатель - писателя если интерфейс понятен, от писателя требуется мало работы, если непонятен - много. Это делает технических писателей лучшими друзьями дизайнеров интерфейсов, более того, писатели могут очень много дать дизайнерам.

Дело в том, что множество систем ни при каких обстоятельствах не могут быть используемы без подготовки, независимо от качества их интерфейса. Система автоматизации, например, может быть эффективно использована только в том случае, когда пользователь этой системы понимает суть автоматизируемых процессов. Обязанность же технического писателя, прежде всего, заключается в том, чтобы снабдить пользователя этим пониманием. Это значит, что концепции и суть сложной системы могут быть безболезненно вынесены из интерфейса в документацию, освобождая ресурсы дизайнера. С другой стороны, зачастую описание концепций влияет на их реализацию в системе, особенно в ситуациях, когда качество обучения работе с системой является важнейшей составляющей общего качества. Это наблюдение вполне подтверждается опытом. Напри мер, Джеф Раскин, Отец Макинтоша, изначально был начальником отдела документации. После того, как он обнаружил, что имеющуюся систему невозможно приемлемо описать, он создал новую, описывающуюся хорошо. Побочным свойством новой системы, компьютера Макинтош, было то, что его интерфейс был понятен и удобен в работе.

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

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

ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ТРИ ШАГА К КРАСОТЕ Неудивительно, что средний уровень отечественных писателей, мягко говоря, невысок, что не позволяет рассчитывать на какую либо помощь от них.

С другой стороны, хорошие технические писатели есть. И если вы нашли такого, смело считайте, что ваша работа будет легче и получится качественней. А если не нашли - ищите, не покладая рук.

ВЛАД В. ГОЛОВАЧ | ДИЗАЙН ПИ: ТРИ ШАГА К КРАСОТЕ Первоначальное проектирование Важность этого этапа трудно переоценить. На нем закладываются основ ные концепции системы, влияющие абсолютно на все показатели качества её интерфейса. Как будет описано в главе о тестировании, структурные проблемы практически не могут быть обнаружены и решены на остальных этапах (для их обнаружения нужно слишком много везения, а для исправле ния - денег). Это значит, что чем больше внимания будет уделено проек тированию, тем выше будет общее качество.

Собственно проектирование состоит из следующих этапов:

1 определение необходимой функциональности системы 2 прилив вдохновения 3 создание пользовательских сценариев 4 проектирование общей структуры 5 конструирование отдельных блоков 6 создание глоссария 7 сбор и начальная проверка полной схемы системы.

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

На первом этапе необходимо определить функциональность будущей Определение системы. Это исключительно важный этап, поскольку именно функцио необходимой нальность будет определять весь интерфейс.

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

Pages:     | 1 |   ...   | 20 | 21 | 22 | 23 | 24 |   ...   | 27 |    Книги по разным темам