Производительность компьютера против производительности человека

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

Увеличение производительности компьютера обычно приводит к увеличению производительности человека, но есть и исключения.

Во-первых, для этого нужно увеличить производительность всего компьютера, а не только одной его части. За последние 20 лет сложилась странная ситуация - в то время как мощность компьютеров увеличилась в несколько тысяч раз, скорость работы пользователя в некоторых случаях даже замедлилась из-за непомерно раздутых операционных систем и программ. (В 1978 году мне требовалось три с половиной минуты, чтобы загрузить систему и приложения с кассетного магнитофона на мой Apple II. Сейчас мой Maк загружается пять минут).

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

К счастью, существует много способов повысить производительность человека, не затрагивая аппаратную часть компьютера.

Производительность человека

Существуют два метода, которые ведут к значительному увеличению производительности человека:

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

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

Три операции, которые можно упростить

Работая на компьютере, пользователи выполняют три основных операции:

• Принимают решения на основе информации, касающейся текущей задачи
• Собирают данные, необходимые для выполнения текущей задачи
• Манипулируют компьютером с помощью элементов управления

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

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

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

Уменьшение числа манипуляций

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

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

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

Некоторые задачи могут представлять собой сложную смесь манипуляций и принятия решений. Например, 35-мм профессиональная фотокамера имеет два кольца вокруг объектива. Одно кольцо устанавливает диафрагму – чем шире отверстие, тем больше света попадает в камеру. Другое кольцо устанавливает выдержку – чем больше время, тем больше света попадает в камеру. Для того, чтобы получить хорошую фотографию, вы должны установить такую диафрагму и время выдержки, чтобы в камеру попало оптимальное количество света. Однако таких “правильных” комбинаций может быть много.

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

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

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

Что можно вынести из этого примера? Разделяйте все операции на "манипуляции с механизмом", и более абстрактные, сообщающие машине то, чего она знать не может.

После этого:

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

Уменьшение необходимости ввода данных

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

• Автоматически заполняйте поля новой записи значениями предыдущей.
• Минимизируйте, либо полностью устраните необходимость ввода информации. Можно ли получить информацию на основе логического вывода? Действительно ли данная информация необходима для выполнения этой задачи?
• Исследуйте другие способы получения информации.

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

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

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

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

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

Ограничение принятия решений

Необходимость принятия решений можно снизить следующим образом:

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

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

На втором шаге удостоверьтесь, что оставшиеся решения действительно относятся к задаче пользователя, а не машины. Если пользователь должен решить, выполнять запрос или нет - это относится к задаче. Но решение о том, какой метод использовать для выполнения запроса - А или Б, лучше оставить машине.

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

Цель такого подхода – предоставить пользователям выбирать наиболее удобный для них способ работы. Этот метод значительно отличается от ситуации, когда пользователь, достигнув очередной развилки на дороге, постоянно решает куда повернуть теперь.

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

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

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

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

Не задавайте также пользователю вопрос о какой-нибудь настройке, смысл которой неясен. Чтобы ответить на этот вопрос и решить, нужна ему эта настройка или нет, пользователю придется узнать все о ней. Спрячьте такую настройку в раздел "advanced".

Используйте фоновый режим выполнение задач

Выполняя все асинхронные операции в фоновом режиме, можно отделить задачи пользователя от задач компьютера, позволяя пользователю работать без перерывов.

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

• Печать отнимает много времени
• Печать не требует вмешательства пользователя
• Общее время выполнения задачи предсказать нельзя
• Следующее задача пользователя обычно не связана с результатами печати

Если принтер подключен к высокоскоростной сети и в очереди печати нет заданий, все происходит довольно быстро. Однако, если кто-то только что начал печатать 300-страничный документ, то компьютер может оказаться "замороженным" на длительный период времени.

Та же самая ситуация сложилась сейчас с Интернет’ом. Загрузка страниц занимает длительное время, не требуя вмешательства пользователя в этот процесс, и предугадать, будет ли она длиться 5 секунд или минуту, невозможно.

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

Уменьшайте субъективное время восприятия

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

Классический пример произошел в Нью-Йорке в 1930 году, когда пользователи нового офисного здания постоянно жаловались на долгое время ожидания лифтов. Когда пригласили инженеров для консультации, выяснилось, что нет никакой возможности ни ускорить лифты, ни увеличить их число или вместимость. Тогда пригласили дизайнера, который смог решить проблему.

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

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

Все пользователи выполнили задание с помощью мыши примерно на 50% быстрее. Но что интересно, все высказались, что они выполнили задание гораздо быстрее с помощью клавиатуры.

Таким образом, нужно всегда принимать во внимание субъективные убеждения пользователей о том, насколько быстрым или медленным является процесс. Не принимайте решение на основе только своего собственного мнения. Тестируйте программу на пользователях.

Основная стратегия уменьшения субъективного времени восприятия: Пользователи должны быть постоянно заняты

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

Приемы для уменьшения субъективного восприятия

Индикаторы

Все приводимые указания зависят от использования индикаторов. Следующие типы индикаторов приведены в порядке от наиболее до наименее желаемого:

• Индикатор оставшегося времени. Поместите его либо в модальный диалог, либо в строку статуса.
• Индикатор "Система жива". Когда оставшееся время предугадать невозможно, покажите анимированный объект, который даст пользователям понять, что система не зависла.
• Индикатор "Слышу и понимаю". Когда ожидаемая задержка менее 2 секунд, показывать оставшееся время бессмысленно, поэтому просто измените форму курсора на "песочные часы".

Для задержек от 0,1 секунды до 10 секунд:

• Подтвердите щелчок мыши или нажатие клавиши в течение 0,1 секунды.
• Измените форму курсора на "песочные часы" или другой анимированный указатель для любой задержки более 0,5 секунды.
• Покажите, когда пользователь может продолжать.

Для задержек от 10 секунд до 1 минуты:

• Подтвердите щелчок мыши или нажатие клавиши в течение 0,1 секунды.
• Привлеките внимание пользователя
• Укажите время ожидания точно или приблизительно.
• Выведите индикатор
• Покажите, когда пользователь может продолжать.

Для задержек от минуты до целой ночи:

• Подтвердите щелчок мыши или нажатие клавиши в течение 0,1 секунды.
• Привлеките внимание пользователя. Индикатор, который трудно заметить, может и не существовать.
• Сообщите пользователю, насколько долгим будет ожидание. Если не знаете – предположите диапазон значений. Даже довольно широкого диапазона (от 3 до 15 минут) пользователю может быть достаточно для принятия решения – переключиться на другую задачу, или же пойти попить кофе.
• Выведите индикатор.
• Четко и ясно сообщите пользователю, когда он может продолжать. Это не значит, что вы должны вывести сообщение шрифтом 96 размера. Это значит, что изменения на экране должны быть значительными, для того чтобы их можно было визуально различить.

Автор: Bruce Tognazzini

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

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

Я считаю, что основывать дизайн пользовательского интерфейса на метафоре не только бесполезно, но и иногда даже вредно. Идея того, что хороший пользовательский интерфейс должен быть обязательно построен на основе метафоры, - один из самых коварных мифов, проникших в компьютерное сообщество.

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

Три парадигмы интерфейсов

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

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

Технологическая парадигма

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

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

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

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

Метафорическая парадигма

Современный графический интерфейс пользователя был изобретен в Исследовательском Центре Пало Альто фирмы Хerox (PARC) и был сразу же подхвачен промышленностью. Но что он из себя представляет на самом деле? Графический интерфейс пользователя, разработанный в PARC состоял из различных объектов: окна, кнопки, мыши, иконки, метафоры, меню. Некоторые были хороши, а некоторые не очень, но все они достигли статуса непреложных истин. В частности, идея того, что дизайн пользовательского интерфейса должен быть жестко основан на метафоре - заблуждение. Это все равно, что поклоняться 5.25" дискетам, потому что на них было записано много хороших программ.

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

Метафоры плохо "масштабируются".

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

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

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

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

Идиоматическая парадигма

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

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

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

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

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

Тайленол - бессмысленное слово, но компания МакНейл'а потратила миллионы, чтобы вы ассоциировали это слово с безопасным, простым, и надежным избавлением от боли. Конечно, идиомы могут быть и визуальными. Золотые арки МакДональдс, три алмаза Мицубиси, пять пересекающихся Олимпийских колец и даже летящее окно Майкрософт - не метафорические идиомы, которые наполнены внутренним смыслом и опознаются сразу же.

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

Проблемы

Ранее мы уже упомянули о некоторых проблемах, которые возникают, если зависеть от метафор при создании интерфейса. Главных же проблем две:

• метафоры сложно найти
• они ограничивают наше мышление

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

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

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

Нет ничего плохого в использовании метафоры, если она выглядит подходящей для данной ситуации. Вот передо мной на тротуаре лежит 20-долларовая бумажка. Конечно я подниму ее, было бы глупо не поднять. Но если бы я решил зарабатывать себе на жизнь поиском случайно оброненных денег, это было бы еще большей глупостью. Вот так и с метафорами: используйте их, если найдете, но не делайте свой интерфейс "заточенным" под какую-нибудь стандартную метафору.

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

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

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

Автор: Alan Cooper

Как-то в предыдущих статьях я уже упоминал о прекрасной (и полезной!) возможности операционной системе линукс, суть которой заключается в том, что можно окну любого приложения придать статус "Поверх всех". Казалось бы мелочь, но в реальной жизни очень удобно. И очень жаль, что в Windows такой возможности нет. Даже подумываю утилитку написать, которая будет это реализовывать.

Сегодня возникла еще одна идея, реализовав которую, microsoft смогла бы заработать нехилую благодарность, как от пользователей, так и от программистов. Особенно от программистов.

Дело в том, что рано или поздно перед разработчиками прикладных программ встает проблема проверки этого самого правописания в вводимом пользователями тексте. Вот и я тоже наступил на эти грабли.

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

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

Наилучшим решением в данной ситуации является использование механизма из уже упомянутого microsoft Office. Как ни странно, но офисный алгоритм от майкрософта справляется с русским гораздо лучше всяких сторонних изобретений. Даже странно как-то. Но факт.

Ну что ж, офис, так офис! Тем более, что большинство разработчиков именно его модули и использует.

Начинаю копать. Первым делом естественно MSDN. Попытка найти нужное решение "в лоб" терпит крах (как обычно), потому начинаю думать головой.

Теоретически к офису обратиться можно через технологию COM (Component Object Model), значит роем MSDN на тему привязки COM-объектов к C#-коду. И тут же получаем готовый пример именно проверки правописания в свобственной программе, используя механизм из microsoft Word. Вот это удача!

Правда без косяков не обошлось. Пример, описанный во всех деталях в MSDN, у меня просто не откомпилировался. :)

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

Замеченные в первые минуты неудобства:

• Проверка осуществляется только над всем текстом целиком и состоит в вызове стандартного окна замены неверно написанных слов. Следствие – очень ограниченная функциональность.
• При каждой проверке запускается сам Word (хоть и в фоне в невидимом окне) и по окончании проверки убивается. Следствие – тормоза.
• После окончания проверки и перед тем как окно Ворда будет убито, оно странным образом появляется на экране, хотя при создании ему ясно указали быть невидимым. Следствие – моргание полноэкранного окна ворда поверх вашей программы при каждой проверке орфографии.
• Для связи с вордом используется промежуточная сборка (в умных книжках ее зовут RCW – Runtime COM Wrapper или "COM-оболочка времени выполнения" - на мой взгляд весьма жудкое название). Т.е. связь с вордом устанавливается еще в момент запуска программы (ранне связывание) и, если на машине клиента вдруг ворда не кажется или окажется, но другой версии, то ваша программа покажет пользователю большую фигу в виде фолта. А пользователи фиг очень не любят. Следствие – катастрофическая зависимость от наличия определенной версии ворда в системе.
• Сама RCW представляет собой не что иное как DLL-файл, который придется таскать вместе с программой (без него тоже получите фолт, причем уже вне зависимости от наличия ворда на машине клиента). Размер у этой библиотеки ни много, ни мало, а целых пол-мегабайта. И это лишь для передачи вызовов из NET в COM и обратно. Стоит задуматься.

Короче, предлагаемый майкрософтом вариант меня полностью не устроил. Мне бы хотелось, чтоб выполнялись следующие условия:

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

Согласитесь, требования весьма скромные. Значит и реализация должна быть достаточно простой. А вот собственно и она:

/*********************************/
/* Simple Spell Checker          */
/* Copyright (C) FIT-Media, 2008 */
/* http://fit-media.com          */
/*********************************/

using System;
using System.Collections.Generic;
using System.Text;
using System.Reflection;

public class SpellChecker : IDisposable
{
	System.Type TWord = null; object com_app = null;

	private static SpellChecker Checker = new SpellChecker();
	private SpellChecker()
	{
		try {
			TWord = Type.GetTypeFromProgID("Word.Application");
			com_app = Activator.CreateInstance(TWord); 
		}
		catch { com_app = null;}
	}

	public static SpellChecker GetChecker() { return Checker; }
	public void Dispose()
	{
		if (com_app != null) {
			object[] arg = { null, null, null };
			TWord.InvokeMember("Quit", BindingFlags.InvokeMethod, 
				null, com_app, arg);
			com_app = null;
		}
	}
	public bool CheckWord(string word)
	{
		object[] arg = { word };
		return (bool)TWord.InvokeMember("CheckSpelling",
			BindingFlags.InvokeMethod, null, com_app, arg);
	}
}

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

Единственное, на что стоит обратить внимание, это необходимость вызова метода SpellChecker.Dispose() при завершении работы вашей программы. Иначе запущенная копия ворда останется в памяти (привет нормальным пацанам из microsoft и их гениальному сборщику мусора) и будет болтаться там до перезапуска системы.

А-а-а, сейчас глянул на начало статьи и понял, что начал об одном, а потом как-то незаметно пришел совсем к другому. :)

Если вы не против, то я все же вернусь к рассказу о моей идее и лени мелко-мягких.

Суть идеи сводится к "глобализации" системы проверки правописания, которая уже встроена в microsoft Office. Прикол в том, что практически 100% программ используют для ввода текста элементы управления, встроенные в операционную систему.

Так вот, достаточно встроить механизм проверки орфографии в саму ОС и подключить его к двум основным средствам ввода текста (в терминах NET Framework это TextBox и RichTextBox), как абсолютно все программы, без какого бы то ни было вмешательства разработчиков, приобретут возможность отображения неверно написанных слов. А перед счастливыми программистами больше никогда не встанет задача реализации в своих программах этой самой "проверки грамотности ввода".

Кстати, при таком подходе словари тоже окажутся глобальными, т.е. добавили вы в словарь слово в ворде и его уже опознают все остальные программы. Здорово? Конечно!

Вот только дети дяди Билла толи сильно ленивые, толи очень жадные (что скорее всего) и ни за что не хотят дать нам всем такую замечательную возможность. :(