Джефф Раскин. Интерфейс: новые направления в проектировании компьютерных систем
Страница 2 из 2
Страница 2 из 2 • 
1, 2
Re: Джефф Раскин. Интерфейс: новые направления в проектировании компьютерных систем
автор Gudleifr Пн Май 10, 2021 12:41 am
ГЛАВА 7. ПРОБЛЕМЫ ЗА ПРЕДЕЛАМИ ПОЛЬЗОВАТЕЛЬСКОГО ИНТЕРФЕЙСА
Утверждение, что следует развивать привычку думать о том, что мы делаем, часто повторяется в учебниках и в речах известных людей и является абсолютно ошибочной избитой фразой. Верно совершенно обратное. Развитие цивилизации связано с увеличением числа важных операций, которые мы можем выполнять не задумываясь.
/Альфред Норф Уайтхед/
В этой главе будет представлено попурри из случаев применения нестандартного мышления (или не-мышления), которые могут быть полезными для разработчиков в разных областях технологии. В разделе 7.1 будет затронута проблема, связанная с тем, что среды программирования имеют, наверное, самые худшие интерфейсы в компьютерной индустрии. Мы рассмотрим два аспекта, в которых могут быть сделаны улучшения. Один из них заключается в том, что сложность системного окружения и сред программирования достигла таких высоких уровней, что это отбивает у начинающего программиста стремление к экспериментированию и изучению среды в процессе работы. Второй аспект связан с тем, что хотя всем известно, что документирование является полезным, оно по большей части не выполняется. Небольшое изменение в языках программирования могло бы позволить упростить весь процесс.
В разделе 7.2 рассматривается проблема изобилия кабелей (или шнуров), которые растут из наших компьютеров подобно змеям из головы медузы Горгоны. Зачастую оказывается трудно подобрать кабель требуемого типа, с необходимым переходником, вилкой или разъемом. Эту проблему можно было бы решить, если бы кабели не имели разные концевые соединения типа "папа" и "мама", а каждый кабель, предназначенный для определенной функции, соединялся бы с любым другим кабелем или разъемом в компьютере, что вполне осуществимо.
В разделе 7.3 рассматриваются вопросы этики. При создании интерфейсов разработчик находится в близком и продолжительном контакте с разумом и телом пользователя. Это влечет за собой определенную ответственность. В учебных программах и тренингах для специалистов в области разработки интерфейсов уже много было сказано о том, что должно быть предусмотрено для защиты интересов пользователей. Но мало кто говорит о том, какие охранные меры и какая социальная защита требуются для того, чтобы дать возможность компетентному разработчику делать свою работу хорошо.
7.1. БОЛЕЕ ЧЕЛОВЕКООРИЕНТИРОВАННЫЕ СРЕДЫ ПРОГРАММИРОВАНИЯ
7.1.1. СИСТЕМНОЕ ОКРУЖЕНИЕ И СРЕДА РАЗРАБОТКИ
Исследования в области когнетики для сред программирования нашли еще меньшее применение, чем для пользовательских интерфейсов. Нечего и говорить, что современные системы становятся все более сложными и что инструменты программирования должны соответствовать этой сложности. Простые вещи стали излишне сложными, и мы не смогли пока создать достаточно хорошие инструментальные программные средства для облегчения этих сложностей работы в современных компьютерных средах.
Я начну с простого примера. В давно исчезнувшем компьютере Apple II для того, чтобы написать программу сложения двух чисел, требуется включить компьютер (время загрузки не заметно!) и нажать "Control"+"b", после чего вы переходите в BASIC. Если вы теперь наберете PRINT 3+4 и нажмете "Return", то сразу же и без трудностей получите 7. С момента запуска BASIC до получения результата прошло 5с. Как хорошо известно, в компьютерной промышленности простота использования достигается с помощью довольно больших ресурсов памяти и скорости. Поэтому мы понимаем, что компьютер Apple II способен выполнять вычисления с такой быстротой и простотой именно потому, что он обладает мощнейшими ресурсами: имея 2-мегагерцовый 8-битный процессор, 48 Кбайт памяти (и это все, что можно вместить!) и 400 килобайтовый диск, машина работает как зверь. В 1999 году на выполнение этой операции у компьютера с 400-мегагерцовым 32-битным процессором, 192 мегабайтовый RAM-памяти и несколькими гигабайтами памяти на жестком диске уходит более 3 минут. Судя по разрядности системной шины и тактовой частоте процессора, новая машина работает приблизительно в 1500 раз быстрее, чем старая. Если же оценивать по времени, которое требуется для написания программы, новая машина оказывается медленнее приблизительно в 36 раз.
Я попросил двух профессиональных программистов написать программу на Visual Basic (VB), которая бы выполняла сложение 3+4 и выдавала результат на экран. Первый программист начал жаловаться, что у машины всего только 8 Мбайт памяти и что у нее устаревший 75-мегагерцовый 32-битовый процессор. Не считая времени загрузки (2мин.), среда программирования была открыта через 54с. После этого требовалось открыть модуль вставки (Insert Module), потом открыть окно опций (Option Box) и установить соответствующие настройки, создать кнопку и рабочую форму, после чего программист должен был набрать среднюю строку из следующего текста:
Private sub Command1_Click ()
MsgBox 3 + 4
End Sub
Для того чтобы воспользоваться этой программой, ее нужно было сначала запустить, а потом нажать кнопку для ее включения. В течение этого процесса, который занял 3мин. 40с (опять же, не считая времени начальной загрузки), было сделано всего только две или три ошибки.
Другой программист, работавший на 64-битовом процессоре с тактовой частотой 75Мгерц и 40Мбайт памяти, запустил VB и выполнил ту же задачу за 28с (что приблизительно в 5 раз медленнее, чем на компьютере Apple II). Программа, созданная несколько иным способом, была следующей:
Private sub Form_Load ()
MsgBox Str (3 + 4)
End Sub
Я спросил у этого программиста, почему он не написал вторую строку так же, как ее написал первый программист:
MsgBox 3 + 4
Он ответил, что не был уверен, что это будет работать. Другими словами, он не знал точно, как VB будет работать в этом случае. Здесь нет ничего странного: как и другие современные компьютерные языки, VB имеет довольно сложное и непоследовательное построение. Оправданием его громоздкости может быть то, что он позволяет сделать большие проекты проще, однако это не может быть оправданием для того, чтобы делать простые вещи сложными. Большие вещи состоят из множества малых, поэтому чем проще сделаны составные задачи, тем проще становится вся задача в целом. Именно плохая организация системы и языка является причиной того, почему один опытный программист допустил ошибки, а другой - не был уверен в правильности синтаксиса простой программы. Те же самые результаты я получил и с тремя другими программистами, работающими со Smalltalk; это показывает, что данные проблемы относятся не только к VB. Очевидно, что каждый из этих языков обладает множеством преимуществ, но если бы они и особенно их среды были хорошо разработаны с точки зрения человеческих факторов, эти преимущества достигались бы с меньшими неудобствами и меньшим числом ошибок со стороны человека.
Таким образом, было утрачено нечто удивительно непосредственное, в частности, немедленная обратная связь, в которой человек нуждается для того, чтобы иметь возможность быстро создавать эффективные программы. Я не настолько наивен, чтобы думать, что мы можем вернуться к прежней простоте и достичь того уровня сложности, который требуется от современных программ. Но я уверен, что мы можем сделать в этом много улучшений.
7.1.2. ВАЖНОСТЬ ВЕДЕНИЯ ДОКУМЕНТАЦИИ ПРИ СОЗДАНИИ ПРОГРАММ
Во многих источниках сообщается, что для программистов важно подробно документировать машинный код, который они пишут. Для этого обычно приводятся две причины: во-первых, чтобы помочь понять программу при ее чтении (Knuth, 1992, с.99), и, во-вторых, чтобы упростить адаптацию программы к новым условиям (Weinberg, 1971, с.164). Обычно в программе рядом со строками кода можно встретить комментарии (чаще однострочные). Многие программы бывают почти полностью лишены комментариев.
Как отметил Кнут (Knuth), написание комментария ДО или во время создания кода может помочь процессу написания, улучшить структуру алгоритмов, снизить число ошибок и повторных написаний программы, необходимых для завершения проекта, а также дает другие преимущества, которые обычно упоминаются по поводу комментариев. По всей видимости, правильность выводов Кнута имеет основания с точки зрения когнетики.
Когда мы как опытные программисты разрабатываем алгоритмы и пишем код, этот процесс отчасти происходит на бессознательном уровне. Как уже было отмечено, эта ментальная область может быть подвержена противоречиям. Предполагаю, что причина некоторых программных ошибок заключается в том, что когнитивное бессознательное переживает противоречие между тем, что мы хотим сделать, и тем, что должен сделать компьютер в соответствии с нашим кодом.
Однако для того, чтобы ясно выразить свои намерения на естественном языке, нам следует сделать процесс мышления сознательным, и именно в когнитивном сознательном эти противоречия быстро становятся очевидными. Даже если эта гипотеза неправильна, написание комментариев вынуждает нас тщательнее обдумывать решаемую задачу для разных условий и с разных точек зрения.
К сожалению, среды программирования были разработаны таким образом, что вносить комментарии в создаваемые программы не просто. Например, комментарии во многих языках программирования ограничиваются одной строкой, а если многострочные комментарии допустимы, то в них часто не используется перенос текста или другие возможности, которые должны быть в простейших текстовых редакторах (исключения составляют UCSD Pascal и Oberon). Чтобы в языке Visual Basic, появившемся в 90-х годах, написать комментарий размером с абзац, вам приходится вручную делать перенос текста. По легендам, программисты не особенно грамотно умеют писать, поэтому проверка орфографии должна быть включена в каждую среду программирования, однако в программных средах эта служба почти никогда не встречается. В существующей версии Mathematica, которая является в общем превосходной программой для работы с математическими выражениями, комментарии были убраны из программ и помещены в специальное окно, что является совершенно неправильным шагом. Только некоторые системы (как, например, созданная Кнутом программа WEB (1992)) были разработаны таким образом, чтобы способствовать ведению документации. Другой, менее сложный, но достаточно эффективный метод, был использован автором этой книги (Lammers, 1986, с.226).
Для сохранения работоспособности программы любым вносимым в нее изменениям должны предшествовать изменения в сопровождающих ее комментариях. Аналогично тому, как нет необходимости разделять разные формы использования компьютера в виде приложений, программирование не должно как-то особенно отличаться от других видов работы, которые пользователь выполняет с помощью компьютера. Опыт показывает, что большинство пользователей компьютеров с неохотой относятся даже к попыткам программирования. Наверное, некоторые преимущества программирования были бы более понятны, если бы процесс программирования был настолько интегрирован со средой, что отдельные программные структуры могли бы использоваться без необходимости учить весь язык или среду программирования. Было бы также полезно иметь возможность комбинировать функции из разных языков, однако это не должно быть смесью, подобной PL/I, но, скорее, должен использоваться метод слияния, предложенный в этой книге для приложений. Вероятно, весьма ценным был бы вариант, в котором комбинировались бы структуры LISP для обработки списков, структуры APL (или разновидности этого языка J) для обработки массивов, мощные методы обработки строк из языка SNOBOL, механизмы наследования и объекты из Smalltalk и т.д.
Разработчики языков программирования и эксперты по интерфейсам слишком редко работают вместе, и хотя когнетика позволяет усовершенствовать компьютерные интерфейсы, следует в максимальной степени использовать также сочетание современных методов разработки языков программирования с нашими знаниями о человеческих фактоpax. Этот вопрос, до сих пор сохраняющий свою актуальность, был рассмотрен в одной из самых ранних книг Вейнберга в области разработки интерфейсов человек-машина "Психология компьютерного программирования" (Weinberg, "Psychology of Computer Programming", опубликована в 1971г.), которая намного опередила свое время и до сих пор остается для нас откровением.
7.2. РЕЖИМЫ И КАБЕЛИ
Программное обеспечение работает на основе аппаратного обеспечения. Если вы не можете определить, как соединить между собой блоки аппаратного обеспечения, программное обеспечение превращается в бесполезные биты информации. Кабель - несколько проводов или волоконно-оптических линий, соединенных вместе и имеющих на каждом конце по разъему,- является одним из простейших элементов аппаратного обеспечения. Кабели должны присоединяться и отсоединяться от компьютера независимо от того, включен он или нет (кабели, которые нельзя заменять без выключения питания ("not hot-swappable"), являются модальными!). У пользователя не должна возникать необходимость изменять конфигурацию устройств, как это требуется при использовании SCSI-соединений. В стандартах USB и FireWire эти проблемы учитываются. Однако есть другие проблемы интерфейсов, которые не учитываются даже в новых стандартах. Например, ситуация, когда кабель имеет неподходящий "пол" разъема, вызывает раздражение. Поскольку кабели могут иметь разные разъемы ("папа" и "мама"), и так как некоторые части оборудования могут иметь соединители или для одного типа разъема ("папа"), или для другого ("мама"), это приводит к тому, что каждый тип кабеля может иметь огромное число модификаций. Многие владельцы компьютеров покупают адаптеры для инверсии "пола", поскольку они дешевле и меньше по размеру, чем кабели. Допустим, что у вас есть только кабель с двумя типами разъемов ("папа-мама"), а вам требуется соединить два устройства, в которых есть разъемы только одного типа ("мама"). В этом случае вы можете либо приобрести кабель с двумя разъемами соответствующего типа ("папа-папа"), либо купить адаптер типа "папа-мама" и присоединить его к одному из концов ("мама") кабеля, который у вас уже есть. В результате вы получите кабель ("папа-папа"), который будет подходить для соединения двух устройств с симметричными разъемами ("мама-мама").
Эту проблему можно избежать, но методы, которые обычно предлагаются, не работают. Одно из решений, о котором я слышал, заключается в том, чтобы на оборудовании устанавливать разъемы одного типа (скажем, "мама"), а на кабелях все разъемы сделать другого типа (соответственно, "папа"). Но даже в этом случае будут нужны адаптеры типа "мама-мама" для соединения двух коротких кабелей в один длинный, или же производители должны будут подумать о выпуске кабельных шнуров типа "папа-мама", чтобы их можно было использовать для удлинения. Следуя этой логике, можно прийти к ситуации, в которой потребуется использовать все возможные комбинации между соединениями "папа" и "мама" на кабелях и адаптерах, даже если по стандарту все соединения на оборудовании будут иметь разъемы типа "мама".
Обычная соединительная пара состоит из штекерного разъема ("папа") и гнездового разъема ("мама"). В результате появляется набор из следующих восьми типов деталей, которые могут использоваться как соединители для оборудования и кабельных шнуров:
- соединитель "папа" для оборудования;
- соединитель "мама" для оборудования;
- соединитель "папа" для кабельных шнуров;
- соединитель "мама" для кабельных шнуров;
- адаптеры "папа-мама";
- адаптеры "мама-папа";
- адаптеры "папа-папа";
- адаптеры "мама-мама".
При использовании гермафродитных соединителей любые два кабеля можно соединить вместе и любой кабель может быть присоединен к любому разъему в оборудовании. Таким образом, весь набор типов соединителей сводится к следующим двум типам:
- соединитель для оборудования;
- соединитель для кабельных шнуров.
С точки зрения электротехники для каждого вида сигнала требуется использовать свой тип кабеля, но в каждом классе кабелей ни с точки зрения электротехники, ни с точки зрения производства ничто не мешает использовать гибридные (так называемые гермафродитные) соединители, не разделяющиеся на тип "папа" или "мама". Любые два соединителя- гермафродита данного класса могут быть соединены вместе. Более того, любой вид соединения для проведения электронного сигнала или питания может быть выполнен с помощью гермафродитных соединителей. Они могут использоваться в качестве многоштекерных соединителей, разъемов питания, а также для коаксиальных кабелей [Некоторые кабели, используемые для соединения оборудования, расположенного на больших расстояниях друг от друга (например, фотографические стробоскопические источники света), снабжены соединителями-гермафродитами. Другой пример - это вышедшие из употребления коаксиальные радиочастотные соединители питания для регистра общего назначения].
Если имеются два гермафродитных соединителя данного класса, вы можете их использовать как два разных кабеля или соединить их в один длинный кабель. В некоторых случаях соединитель-гермафродит мог бы быть не сложнее и не дороже соединителя с определенным "полом". Однако это не всегда будет так. Во многих случаях гермафродитный соединитель будет несколько сложнее и дороже в производстве, но это будет оправдываться следующими факторами:
- большее удобство для пользователя;
- более простые инструкции;
- меньший объем производственной наладки;
- меньшее количество деталей, которые нужно складировать продавцам и распространителям.
На рис.7.1 показана схема четырехпроводного линейного гермафродитного соединителя. При линейном расположении n проводов требуется минимум 2n-1 контактов. По схеме проводов на рис.7.2 можно понять, каким образом работают такие соединители. На рис.7.3 показаны выходы из гермафродитного коаксиального соединителя. Эту идею можно использовать и для многожильных редакторакоаксиальных проводов. Для того чтобы получить более удобные интерфейсы человек-машина, мы готовы платить за более сложные компьютеры. Этот же принцип должен быть применен к сумасшедшему клубку проводов и кабелей, которым вечно опутан компьютер и пользователь. Может показаться, что нужна какая-то линейная схема с меньшим, чем 2n-1, числом контактов, но здесь следует учесть возможность использования кабелей для удлинения.
Рис.7.1. Гермафродитный четырехпроводный соединитель. Четыре провода обозначены как а, b, с и d
Рис.7.2. Гермафродитные кабели могут использоваться для соединения компонентов оборудования (см. нижнюю и верхнюю части каждой колонки), а также для удлинения кабелей (см. правую колонку)
Рис.7.3. Выходы в гермафродитном коаксиальном соединителе. Внешняя изолирующая оболочка с четырьмя зубцами, аналогичными изображенным, но с увеличенными концами и соединительным расширением снизу (не показаны), служит для сцепления
Утверждение, что следует развивать привычку думать о том, что мы делаем, часто повторяется в учебниках и в речах известных людей и является абсолютно ошибочной избитой фразой. Верно совершенно обратное. Развитие цивилизации связано с увеличением числа важных операций, которые мы можем выполнять не задумываясь.
/Альфред Норф Уайтхед/
В этой главе будет представлено попурри из случаев применения нестандартного мышления (или не-мышления), которые могут быть полезными для разработчиков в разных областях технологии. В разделе 7.1 будет затронута проблема, связанная с тем, что среды программирования имеют, наверное, самые худшие интерфейсы в компьютерной индустрии. Мы рассмотрим два аспекта, в которых могут быть сделаны улучшения. Один из них заключается в том, что сложность системного окружения и сред программирования достигла таких высоких уровней, что это отбивает у начинающего программиста стремление к экспериментированию и изучению среды в процессе работы. Второй аспект связан с тем, что хотя всем известно, что документирование является полезным, оно по большей части не выполняется. Небольшое изменение в языках программирования могло бы позволить упростить весь процесс.
В разделе 7.2 рассматривается проблема изобилия кабелей (или шнуров), которые растут из наших компьютеров подобно змеям из головы медузы Горгоны. Зачастую оказывается трудно подобрать кабель требуемого типа, с необходимым переходником, вилкой или разъемом. Эту проблему можно было бы решить, если бы кабели не имели разные концевые соединения типа "папа" и "мама", а каждый кабель, предназначенный для определенной функции, соединялся бы с любым другим кабелем или разъемом в компьютере, что вполне осуществимо.
В разделе 7.3 рассматриваются вопросы этики. При создании интерфейсов разработчик находится в близком и продолжительном контакте с разумом и телом пользователя. Это влечет за собой определенную ответственность. В учебных программах и тренингах для специалистов в области разработки интерфейсов уже много было сказано о том, что должно быть предусмотрено для защиты интересов пользователей. Но мало кто говорит о том, какие охранные меры и какая социальная защита требуются для того, чтобы дать возможность компетентному разработчику делать свою работу хорошо.
7.1. БОЛЕЕ ЧЕЛОВЕКООРИЕНТИРОВАННЫЕ СРЕДЫ ПРОГРАММИРОВАНИЯ
7.1.1. СИСТЕМНОЕ ОКРУЖЕНИЕ И СРЕДА РАЗРАБОТКИ
Исследования в области когнетики для сред программирования нашли еще меньшее применение, чем для пользовательских интерфейсов. Нечего и говорить, что современные системы становятся все более сложными и что инструменты программирования должны соответствовать этой сложности. Простые вещи стали излишне сложными, и мы не смогли пока создать достаточно хорошие инструментальные программные средства для облегчения этих сложностей работы в современных компьютерных средах.
Я начну с простого примера. В давно исчезнувшем компьютере Apple II для того, чтобы написать программу сложения двух чисел, требуется включить компьютер (время загрузки не заметно!) и нажать "Control"+"b", после чего вы переходите в BASIC. Если вы теперь наберете PRINT 3+4 и нажмете "Return", то сразу же и без трудностей получите 7. С момента запуска BASIC до получения результата прошло 5с. Как хорошо известно, в компьютерной промышленности простота использования достигается с помощью довольно больших ресурсов памяти и скорости. Поэтому мы понимаем, что компьютер Apple II способен выполнять вычисления с такой быстротой и простотой именно потому, что он обладает мощнейшими ресурсами: имея 2-мегагерцовый 8-битный процессор, 48 Кбайт памяти (и это все, что можно вместить!) и 400 килобайтовый диск, машина работает как зверь. В 1999 году на выполнение этой операции у компьютера с 400-мегагерцовым 32-битным процессором, 192 мегабайтовый RAM-памяти и несколькими гигабайтами памяти на жестком диске уходит более 3 минут. Судя по разрядности системной шины и тактовой частоте процессора, новая машина работает приблизительно в 1500 раз быстрее, чем старая. Если же оценивать по времени, которое требуется для написания программы, новая машина оказывается медленнее приблизительно в 36 раз.
Я попросил двух профессиональных программистов написать программу на Visual Basic (VB), которая бы выполняла сложение 3+4 и выдавала результат на экран. Первый программист начал жаловаться, что у машины всего только 8 Мбайт памяти и что у нее устаревший 75-мегагерцовый 32-битовый процессор. Не считая времени загрузки (2мин.), среда программирования была открыта через 54с. После этого требовалось открыть модуль вставки (Insert Module), потом открыть окно опций (Option Box) и установить соответствующие настройки, создать кнопку и рабочую форму, после чего программист должен был набрать среднюю строку из следующего текста:
Private sub Command1_Click ()
MsgBox 3 + 4
End Sub
Для того чтобы воспользоваться этой программой, ее нужно было сначала запустить, а потом нажать кнопку для ее включения. В течение этого процесса, который занял 3мин. 40с (опять же, не считая времени начальной загрузки), было сделано всего только две или три ошибки.
Другой программист, работавший на 64-битовом процессоре с тактовой частотой 75Мгерц и 40Мбайт памяти, запустил VB и выполнил ту же задачу за 28с (что приблизительно в 5 раз медленнее, чем на компьютере Apple II). Программа, созданная несколько иным способом, была следующей:
Private sub Form_Load ()
MsgBox Str (3 + 4)
End Sub
Я спросил у этого программиста, почему он не написал вторую строку так же, как ее написал первый программист:
MsgBox 3 + 4
Он ответил, что не был уверен, что это будет работать. Другими словами, он не знал точно, как VB будет работать в этом случае. Здесь нет ничего странного: как и другие современные компьютерные языки, VB имеет довольно сложное и непоследовательное построение. Оправданием его громоздкости может быть то, что он позволяет сделать большие проекты проще, однако это не может быть оправданием для того, чтобы делать простые вещи сложными. Большие вещи состоят из множества малых, поэтому чем проще сделаны составные задачи, тем проще становится вся задача в целом. Именно плохая организация системы и языка является причиной того, почему один опытный программист допустил ошибки, а другой - не был уверен в правильности синтаксиса простой программы. Те же самые результаты я получил и с тремя другими программистами, работающими со Smalltalk; это показывает, что данные проблемы относятся не только к VB. Очевидно, что каждый из этих языков обладает множеством преимуществ, но если бы они и особенно их среды были хорошо разработаны с точки зрения человеческих факторов, эти преимущества достигались бы с меньшими неудобствами и меньшим числом ошибок со стороны человека.
Таким образом, было утрачено нечто удивительно непосредственное, в частности, немедленная обратная связь, в которой человек нуждается для того, чтобы иметь возможность быстро создавать эффективные программы. Я не настолько наивен, чтобы думать, что мы можем вернуться к прежней простоте и достичь того уровня сложности, который требуется от современных программ. Но я уверен, что мы можем сделать в этом много улучшений.
7.1.2. ВАЖНОСТЬ ВЕДЕНИЯ ДОКУМЕНТАЦИИ ПРИ СОЗДАНИИ ПРОГРАММ
Во многих источниках сообщается, что для программистов важно подробно документировать машинный код, который они пишут. Для этого обычно приводятся две причины: во-первых, чтобы помочь понять программу при ее чтении (Knuth, 1992, с.99), и, во-вторых, чтобы упростить адаптацию программы к новым условиям (Weinberg, 1971, с.164). Обычно в программе рядом со строками кода можно встретить комментарии (чаще однострочные). Многие программы бывают почти полностью лишены комментариев.
Как отметил Кнут (Knuth), написание комментария ДО или во время создания кода может помочь процессу написания, улучшить структуру алгоритмов, снизить число ошибок и повторных написаний программы, необходимых для завершения проекта, а также дает другие преимущества, которые обычно упоминаются по поводу комментариев. По всей видимости, правильность выводов Кнута имеет основания с точки зрения когнетики.
Когда мы как опытные программисты разрабатываем алгоритмы и пишем код, этот процесс отчасти происходит на бессознательном уровне. Как уже было отмечено, эта ментальная область может быть подвержена противоречиям. Предполагаю, что причина некоторых программных ошибок заключается в том, что когнитивное бессознательное переживает противоречие между тем, что мы хотим сделать, и тем, что должен сделать компьютер в соответствии с нашим кодом.
Однако для того, чтобы ясно выразить свои намерения на естественном языке, нам следует сделать процесс мышления сознательным, и именно в когнитивном сознательном эти противоречия быстро становятся очевидными. Даже если эта гипотеза неправильна, написание комментариев вынуждает нас тщательнее обдумывать решаемую задачу для разных условий и с разных точек зрения.
К сожалению, среды программирования были разработаны таким образом, что вносить комментарии в создаваемые программы не просто. Например, комментарии во многих языках программирования ограничиваются одной строкой, а если многострочные комментарии допустимы, то в них часто не используется перенос текста или другие возможности, которые должны быть в простейших текстовых редакторах (исключения составляют UCSD Pascal и Oberon). Чтобы в языке Visual Basic, появившемся в 90-х годах, написать комментарий размером с абзац, вам приходится вручную делать перенос текста. По легендам, программисты не особенно грамотно умеют писать, поэтому проверка орфографии должна быть включена в каждую среду программирования, однако в программных средах эта служба почти никогда не встречается. В существующей версии Mathematica, которая является в общем превосходной программой для работы с математическими выражениями, комментарии были убраны из программ и помещены в специальное окно, что является совершенно неправильным шагом. Только некоторые системы (как, например, созданная Кнутом программа WEB (1992)) были разработаны таким образом, чтобы способствовать ведению документации. Другой, менее сложный, но достаточно эффективный метод, был использован автором этой книги (Lammers, 1986, с.226).
Для сохранения работоспособности программы любым вносимым в нее изменениям должны предшествовать изменения в сопровождающих ее комментариях. Аналогично тому, как нет необходимости разделять разные формы использования компьютера в виде приложений, программирование не должно как-то особенно отличаться от других видов работы, которые пользователь выполняет с помощью компьютера. Опыт показывает, что большинство пользователей компьютеров с неохотой относятся даже к попыткам программирования. Наверное, некоторые преимущества программирования были бы более понятны, если бы процесс программирования был настолько интегрирован со средой, что отдельные программные структуры могли бы использоваться без необходимости учить весь язык или среду программирования. Было бы также полезно иметь возможность комбинировать функции из разных языков, однако это не должно быть смесью, подобной PL/I, но, скорее, должен использоваться метод слияния, предложенный в этой книге для приложений. Вероятно, весьма ценным был бы вариант, в котором комбинировались бы структуры LISP для обработки списков, структуры APL (или разновидности этого языка J) для обработки массивов, мощные методы обработки строк из языка SNOBOL, механизмы наследования и объекты из Smalltalk и т.д.
Разработчики языков программирования и эксперты по интерфейсам слишком редко работают вместе, и хотя когнетика позволяет усовершенствовать компьютерные интерфейсы, следует в максимальной степени использовать также сочетание современных методов разработки языков программирования с нашими знаниями о человеческих фактоpax. Этот вопрос, до сих пор сохраняющий свою актуальность, был рассмотрен в одной из самых ранних книг Вейнберга в области разработки интерфейсов человек-машина "Психология компьютерного программирования" (Weinberg, "Psychology of Computer Programming", опубликована в 1971г.), которая намного опередила свое время и до сих пор остается для нас откровением.
7.2. РЕЖИМЫ И КАБЕЛИ
Программное обеспечение работает на основе аппаратного обеспечения. Если вы не можете определить, как соединить между собой блоки аппаратного обеспечения, программное обеспечение превращается в бесполезные биты информации. Кабель - несколько проводов или волоконно-оптических линий, соединенных вместе и имеющих на каждом конце по разъему,- является одним из простейших элементов аппаратного обеспечения. Кабели должны присоединяться и отсоединяться от компьютера независимо от того, включен он или нет (кабели, которые нельзя заменять без выключения питания ("not hot-swappable"), являются модальными!). У пользователя не должна возникать необходимость изменять конфигурацию устройств, как это требуется при использовании SCSI-соединений. В стандартах USB и FireWire эти проблемы учитываются. Однако есть другие проблемы интерфейсов, которые не учитываются даже в новых стандартах. Например, ситуация, когда кабель имеет неподходящий "пол" разъема, вызывает раздражение. Поскольку кабели могут иметь разные разъемы ("папа" и "мама"), и так как некоторые части оборудования могут иметь соединители или для одного типа разъема ("папа"), или для другого ("мама"), это приводит к тому, что каждый тип кабеля может иметь огромное число модификаций. Многие владельцы компьютеров покупают адаптеры для инверсии "пола", поскольку они дешевле и меньше по размеру, чем кабели. Допустим, что у вас есть только кабель с двумя типами разъемов ("папа-мама"), а вам требуется соединить два устройства, в которых есть разъемы только одного типа ("мама"). В этом случае вы можете либо приобрести кабель с двумя разъемами соответствующего типа ("папа-папа"), либо купить адаптер типа "папа-мама" и присоединить его к одному из концов ("мама") кабеля, который у вас уже есть. В результате вы получите кабель ("папа-папа"), который будет подходить для соединения двух устройств с симметричными разъемами ("мама-мама").
Эту проблему можно избежать, но методы, которые обычно предлагаются, не работают. Одно из решений, о котором я слышал, заключается в том, чтобы на оборудовании устанавливать разъемы одного типа (скажем, "мама"), а на кабелях все разъемы сделать другого типа (соответственно, "папа"). Но даже в этом случае будут нужны адаптеры типа "мама-мама" для соединения двух коротких кабелей в один длинный, или же производители должны будут подумать о выпуске кабельных шнуров типа "папа-мама", чтобы их можно было использовать для удлинения. Следуя этой логике, можно прийти к ситуации, в которой потребуется использовать все возможные комбинации между соединениями "папа" и "мама" на кабелях и адаптерах, даже если по стандарту все соединения на оборудовании будут иметь разъемы типа "мама".
Обычная соединительная пара состоит из штекерного разъема ("папа") и гнездового разъема ("мама"). В результате появляется набор из следующих восьми типов деталей, которые могут использоваться как соединители для оборудования и кабельных шнуров:
- соединитель "папа" для оборудования;
- соединитель "мама" для оборудования;
- соединитель "папа" для кабельных шнуров;
- соединитель "мама" для кабельных шнуров;
- адаптеры "папа-мама";
- адаптеры "мама-папа";
- адаптеры "папа-папа";
- адаптеры "мама-мама".
При использовании гермафродитных соединителей любые два кабеля можно соединить вместе и любой кабель может быть присоединен к любому разъему в оборудовании. Таким образом, весь набор типов соединителей сводится к следующим двум типам:
- соединитель для оборудования;
- соединитель для кабельных шнуров.
С точки зрения электротехники для каждого вида сигнала требуется использовать свой тип кабеля, но в каждом классе кабелей ни с точки зрения электротехники, ни с точки зрения производства ничто не мешает использовать гибридные (так называемые гермафродитные) соединители, не разделяющиеся на тип "папа" или "мама". Любые два соединителя- гермафродита данного класса могут быть соединены вместе. Более того, любой вид соединения для проведения электронного сигнала или питания может быть выполнен с помощью гермафродитных соединителей. Они могут использоваться в качестве многоштекерных соединителей, разъемов питания, а также для коаксиальных кабелей [Некоторые кабели, используемые для соединения оборудования, расположенного на больших расстояниях друг от друга (например, фотографические стробоскопические источники света), снабжены соединителями-гермафродитами. Другой пример - это вышедшие из употребления коаксиальные радиочастотные соединители питания для регистра общего назначения].
Если имеются два гермафродитных соединителя данного класса, вы можете их использовать как два разных кабеля или соединить их в один длинный кабель. В некоторых случаях соединитель-гермафродит мог бы быть не сложнее и не дороже соединителя с определенным "полом". Однако это не всегда будет так. Во многих случаях гермафродитный соединитель будет несколько сложнее и дороже в производстве, но это будет оправдываться следующими факторами:
- большее удобство для пользователя;
- более простые инструкции;
- меньший объем производственной наладки;
- меньшее количество деталей, которые нужно складировать продавцам и распространителям.
На рис.7.1 показана схема четырехпроводного линейного гермафродитного соединителя. При линейном расположении n проводов требуется минимум 2n-1 контактов. По схеме проводов на рис.7.2 можно понять, каким образом работают такие соединители. На рис.7.3 показаны выходы из гермафродитного коаксиального соединителя. Эту идею можно использовать и для многожильных редакторакоаксиальных проводов. Для того чтобы получить более удобные интерфейсы человек-машина, мы готовы платить за более сложные компьютеры. Этот же принцип должен быть применен к сумасшедшему клубку проводов и кабелей, которым вечно опутан компьютер и пользователь. Может показаться, что нужна какая-то линейная схема с меньшим, чем 2n-1, числом контактов, но здесь следует учесть возможность использования кабелей для удлинения.
Рис.7.1. Гермафродитный четырехпроводный соединитель. Четыре провода обозначены как а, b, с и d
Рис.7.2. Гермафродитные кабели могут использоваться для соединения компонентов оборудования (см. нижнюю и верхнюю части каждой колонки), а также для удлинения кабелей (см. правую колонку)
Рис.7.3. Выходы в гермафродитном коаксиальном соединителе. Внешняя изолирующая оболочка с четырьмя зубцами, аналогичными изображенным, но с увеличенными концами и соединительным расширением снизу (не показаны), служит для сцепления
Последний раз редактировалось: Gudleifr (Вс Янв 09, 2022 5:32 pm), всего редактировалось 1 раз(а)
Gudleifr- Admin
- Сообщения : 3244
Дата регистрации : 2017-03-29
Re: Джефф Раскин. Интерфейс: новые направления в проектировании компьютерных систем
автор Gudleifr Пн Май 10, 2021 12:42 am
7.3. ЭТИКА И УПРАВЛЕНИЕ РАЗРАБОТКОЙ ИНТЕРФЕЙСОВ
Разумный человек приспосабливает себя к миру. Неразумный человек стремится приспособить мир к себе. Следовательно, весь прогресс зависит от людей неразумных.
/Бернард Шоу/
Трудно создать хороший интерфейс, если руководство не понимает, что разработка интерфейса является достаточно важным этапом. В краткосрочной перспективе тщательный подход к разработке интерфейса может увеличить расходы и время на создание продукта. Мой опыт показывает, что краткосрочный подход является неверным даже в краткосрочном периоде, поскольку улучшение пользовательского интерфейса часто упрощает разработку. Тщательное проектирование и детальное определение технических и других требований не замедляют, а, наоборот, ускоряют процесс разработки. Создание качественного интерфейса полезно и с точки зрения долгосрочной перспективы, поскольку в результате приводит к:
- большей продуктивности работы пользователя;
- большему удобству для пользователя;
- большей ценности в глазах покупателя;
- уменьшению расходов на поддержку покупателей;
- ускорению и упрощению процесса внедрения;
- преимуществу перед конкурентами на рынке;
- лояльности к данной марке;
- упрощению инструкций и онлайновой помощи;
- более безопасным продуктам.
Разработчики интерфейсов редко когда имеют возможность контролировать, в какой момент в процессе разработки проекта начнется создание интерфейса и какое значение будет придаваться его проблемам. В тех случаях, когда созданию интерфейса отдается главенствующая роль, как это было в проекте Macintosh, это дает поразительные результаты.
Если не учитывать, что данная область является довольно новой, и поэтому мало кто из специалистов в этой области пока поднялся до управляющих должностей, другой проблемой является то, что разработчики интерфейсов имеют небольшое влияние. Однако идет некоторая работа по решению этой проблемы с помощью предложения образовательных стандартов и тестов. Тем не менее, обладание такого сертификата у специалиста еще не является гарантией его компетентности. Здесь речь идет о другой стороне этой проблемы. Даже если разработчик является достаточно компетентным, от него (или нее) часто требуют создавать плохие интерфейсы. В этом отношении можно только позавидовать врачам, потому что для них предусмотрены юридические защитные меры, которые позволяют им выполнять свою работу правильно. Например, врач может предъявить судебный иск за незаконное увольнение при отказе выполнять действия, угрожающие состоянию здоровья пациентов. Строительные инженеры могут обращаться в суд в случае увольнения за отказ нарушить каноны, принятые в их профессии.
Специалисты по разработке интерфейсов работают в области, в которой неправильные решения могут вызвать физические поражения и способствовать психологическим расстройствам. Например, если интерфейс создает необходимость слишком часто нажимать на клавиши или кнопку мыши, это может привести к возникновению или обострению хронического стрессового нарушения (repetitive stress injuries). Плохой интерфейс может вызывать психологические расстройства. Таким образом, требуется создание основы для установления юридических норм защиты добросовестных специалистов. Другой необходимостью является установление определенных профессиональных стандартов (речь идет не о стандартах разработки интерфейсов). Меры, упомянутые в этой книге, а также те, которые будут разработаны в будущем, могут помочь установить количественные, объективные нормы. Например, инженер-строитель должна показать, что она спроектировала мост, который отвечает установленным стандартам, в соответствии с которыми этот мост должен выдерживать нагрузку, скажем, в два раза превышающую минимально возможный уровень. Выбросы из автомобиля должны содержать не более 0.2% CO для того, чтобы этот автомобиль мог быть сертифицирован. Аналогичным образом, мы могли бы установить, что интерфейс текстового процессора не может быть принят, если, скажем, его общая информационно-теоретическая эффективность меньше 0.7 или если общая символьная производительность является меньше 0.8, а отдельные элементы имеют эффективность меньше 0.5.
Критерии могут быть также подобраны таким образом, что для некоторого числа наиболее часто используемых задач средневзвешенное время выполнения, а значит, и количество нажатий на клавиши, движений с помощью ГУВ и нажатий на его кнопку в новом текстовом процессоре не должно превышать значений, которые достигнуты в любом предыдущем или современном коммерческом продукте, предназначенном для аналогичной цели. Продукты, которые удовлетворяют данным критериям, могут получать какую-то форму сертификации. Эти критерии будут автоматически изменяться по мере развития интерфейсной технологии. В настоящее время новые продукты часто оказываются сложнее в использовании, чем старые, но это нельзя понять до тех пор, пока вы не попробуете это проверить на собственном опыте. Поскольку эти критерии касаются эффективности, т.е. в конечном счете определяют итоговый результат работы пользователя, то руководители проекта должны уделять им особое внимание. От публикации объективных нормативов качества интерфейсов выиграют не только разработчики и руководители проекта, но также и покупатели.
Стив Уайлдстром (Steve Wildstrom), который публикует свои статьи в еженедельнике Business Week, указывает, что "производители компьютеров и, в особенности, разработчики программного обеспечения, часто думают, что требования Единого коммерческого кодекса (Uniform Commercial Code) касаются не их, а кого-то другого" (частный разговор, октябрь 1998г.). Многие современные лицензии на программное обеспечение, навязываемые покупателям, не гарантируют им даже того, что это программное обеспечение будет выполнять задачу, о которой сообщалось в рекламе. Во многих таких документах прямым образом отрицается понятие merchantability (годности для продажи), которое означает буквально следующее: продажа данного продукта автоматически предполагает, что этот продукт способен выполнять задачу, для которой он, по заявлению продавца, предназначен. В некоторых штатах США были приняты законы, запрещающие отказ от подтверждения "годности к продаже" для продуктов компьютерного производства. Все верховные власти должны поступить так же.
Система оценки качества интерфейсов, осуществляемая независимой организацией, может быть полезной для покупателей тех продуктов, в которых интерфейсный компонент выполняет значительную роль. Сама разработка пользовательского интерфейса не должна как-то регулироваться или ограничиваться. Следует избегать применения принципов, основанных на использовании конкретных интерфейсных механизмов, чтобы не подавлять стремление к нововведениям. Однако введение относительных количественных нормативов продуктивности для продуктов одного типа побудит разработчиков двигаться в правильном направлении.
Нужно найти тонкий баланс между созданием настолько нового продукта, что опытные пользователи, привыкшие к обычным интерфейсам, почувствуют неудобство в его использовании, и созданием продукта с интерфейсом, который настолько не отличается от стандартного графического пользовательского интерфейса, что его никак нельзя считать результатом нашего желания в максимальной степени помочь пользователю. С одной стороны, мы должны избежать новизны как таковой, хотя с другой стороны, мы не должны терять ценную возможность выиграть на рынке из-за того, что декалькируем аналогичные существующие продукты.
В бизнесе разработки интерфейсов давно существует миф о том, что "расширение функциональности и сохранение простоты использования не могут быть совмещены в одном интерфейсе" (Microsoft, 1995, с.8 ). Действительно, добавление множества специальных, созданных именно для данного случая сервисов, уменьшает простоту использования. Но как раз это является плохой разработкой. Часто, но не всегда, возможно увеличить функциональность, не увеличивая степень сложности интерфейса. Добавление нового сервиса, как правило, может быть сделано таким образом, что это не прибавит сложности в интерфейсе (здесь следует отметить разницу между сложностью интерфейса и сложностью задачи). Если добавляемая функция позволяет объединить в единое целое разрозненные элементы интерфейса, то такой интерфейс может стать проще.
"Одним из способов сохранить простоту заключается в сокращении объема предъявляемой информации до того минимума, который необходим для адекватного взаимодействия" (Microsoft, 1995, с.8 ). Это действительно так, за исключением того, что слово "адекватного" следует заменить словом "нормального". Однако в этой компании ошибаются, когда утверждают: "Например, не используйте словесных описаний командных имен или сообщений" (Microsoft, 1995, с.8 ). Здесь возникает вопрос: что же можно считать минимумом для нормального взаимодействия? В большинстве современных интерфейсов акцент делается на краткость в ущерб ясности. Почему мы должны заниматься расшифровкой непонятного названия "Список" в выпадающем меню в текстовом процессоре, когда можно было бы использовать более понятное "Создать указатель или оглавление"? (Необходимо учесть, что выпадающее меню не занимает места в документе, поскольку оно исчезает сразу же, как только вы уводите от него курсор или выбираете какую-то из опций). Не следует путать простой внешний вид экрана с простотой использования интерфейса.
НАВИГАЦИЯ ПРОТИВ СВОБОДНОГО ПРОСТРАНСТВА
Кажется, что мы просто боимся отображать информацию в наших интерфейсах. Известно, что чем меньше группа вещей, тем легче найти в ней нужный предмет. Однако из этого не следует, как это может некоторым показаться, что чем меньше элементов на экране, тем лучше. Если сотни элементов разбросаны в десятках экранов, то вы больше времени потеряете на перемещения между ними, чем на сам поиск конкретного элемента, даже если этот элемент находится среди моря других аналогичных. Поиск чего-то в длинных, однообразных списках не всегда может быть трудным.
Если бы люди не могли быстро находить короткие элементы в длинных списках, журнал "Уолл стрит джорнал" уже давно бы разорился. Предпочли бы вы, чтобы котировки акций печатались по 15 строк на странице, каждая их которых оформлена наподобие экрана из современного интерфейса, в придачу даже со схемой поиска нужной страницы вроде:
Ценные бумаги - Страница
AA-AD - 1
AD-AS - 2
AT-AZ - 3
ВА-ВК - 4
и так далее.
Такая схема показалась бы несерьезной, неэкономной и странной. Однако иногда мы используем больше экранных пикселов на то, чтобы сделать аккуратные рамки с тенями, чем на отображение полезной информации. Если человек имеет мотив (обусловленный личным интересом или зарплатой) для того, чтобы искать какие-то нудные данные, длинные списки не могут представлять для него никакой проблемы. Визуальный дизайнер Эдвард Тафт (Edward Tufte, 1983, с.105) разработал принципы отображения информации, среди которых первыми тремя являются следующие:
- данные следует показывать прежде всего остального;
- следует максимально увеличивать долю чернил, используемых для отображения данных;
- следует максимально уменьшать долю чернил, которые не используются для отображения данных.
Для того чтобы приложить эти принципы к устройствам с дисплеями, требуется всего лишь заменить в них слово ЧЕРНИЛА на слово ПИКСЕЛЫ. Серьезный, профессиональный пользователь желает, чтобы экраны были до отказа заполнены полезным содержанием. Экраны должны быть хорошо обозначены, снабжены простыми механизмами для осуществления поиска и получения информации, отражающей суть данного экрана. (В конце концов, раз уж мы сели за компьютер, мы должны извлечь из этого максимальную пользу).
Сегодня существует множество исследований о дизайне экранных изображений. Многие ранние, но до сих пор не утратившие свою ценность исследования, рассмотрены в обзоре Туллиса (Tullis, 1984). Некоторые из результатов до сих пор могут быть использованы (например, время поиска в списке элементов составляет приблизительно 30мс на каждый элемент (с. 126)). Основные результаты, полученные Туллисом, относились к 24*80 алфавитно-цифровым дисплеям и позволяли дать количественные оценки [Критерии, предложенные Туллисом, не учитывают качества содержания, но только его внешний вид. Можно построить такие образцы изображений, которые по этим критериям будут иметь высокие оценки, но будут сложны в использовании]. Если эти результаты применить к современным растровым дисплеям и получить критерий оценки времени поиска целевого объекта, то это позволило бы не только оптимизировать отдельные, изолированные безоконные экранные изображения (в соответствии с ограничениями Туллиса), но также достичь более глобальной оптимизации, связанной с оценкой навигационной структуры. Как отмечает Туллис (с.132), почти всегда необходимо искать компромисс между сложностью экрана и сложностью навигации. Этот компромисс зависит от скорости и простоты работы навигации и от структуры данных. Когда для выполнения внутриэкранного поиска вместо визуального сканирования используется поисковое устройство (как, например, функция LEAP), то для оценки эффективности должны быть разработаны другие виды критериев. Здесь имеется широкая область для дальнейших исследований.
В любом случае, если довести до логического конца популярную философию экранного дизайна, которая сводится к принципу, что "чем больше пустого пространства, тем легче читать", то мы увидим, что тогда на каждом экране должен помещаться только лишь один элемент данных. В этом случае пользователь уж точно сможет визуально распознать этот элемент с наименьшим возможным усилием.
Имея опыт улучшения множества продуктов с помощью сокращения количества экранов и увеличения доли информации на оставшихся экранах,- или, другими словами, с помощью улучшения логической структуры дизайна, приводящего к такому сокращению,- я пришел к выводу, что почти во всех коммерческих программах мы допускаем ту ошибку, что помещаем на экраны слишком мало информации.
ЛУЧШИЙ СПОСОБ ЗАСТАВИТЬ ИНТЕРФЕЙС ВАШЕГО ПРОДУКТА ОТЛИЧАТЬСЯ - ЭТО СДЕЛАТЬ ТАК, ЧТОБЫ ОН РАБОТАЛ. В книге Нормана "Невидимый компьютер" (Norman, "The Invisible Computer", 1998 ) можно найти хорошо написанное и убедительное обоснование важности вопросов разработки интерфейсов, которое в большой степени обращено к тем, кто осуществляет руководство проектами.
Разумный человек приспосабливает себя к миру. Неразумный человек стремится приспособить мир к себе. Следовательно, весь прогресс зависит от людей неразумных.
/Бернард Шоу/
Трудно создать хороший интерфейс, если руководство не понимает, что разработка интерфейса является достаточно важным этапом. В краткосрочной перспективе тщательный подход к разработке интерфейса может увеличить расходы и время на создание продукта. Мой опыт показывает, что краткосрочный подход является неверным даже в краткосрочном периоде, поскольку улучшение пользовательского интерфейса часто упрощает разработку. Тщательное проектирование и детальное определение технических и других требований не замедляют, а, наоборот, ускоряют процесс разработки. Создание качественного интерфейса полезно и с точки зрения долгосрочной перспективы, поскольку в результате приводит к:
- большей продуктивности работы пользователя;
- большему удобству для пользователя;
- большей ценности в глазах покупателя;
- уменьшению расходов на поддержку покупателей;
- ускорению и упрощению процесса внедрения;
- преимуществу перед конкурентами на рынке;
- лояльности к данной марке;
- упрощению инструкций и онлайновой помощи;
- более безопасным продуктам.
Разработчики интерфейсов редко когда имеют возможность контролировать, в какой момент в процессе разработки проекта начнется создание интерфейса и какое значение будет придаваться его проблемам. В тех случаях, когда созданию интерфейса отдается главенствующая роль, как это было в проекте Macintosh, это дает поразительные результаты.
Если не учитывать, что данная область является довольно новой, и поэтому мало кто из специалистов в этой области пока поднялся до управляющих должностей, другой проблемой является то, что разработчики интерфейсов имеют небольшое влияние. Однако идет некоторая работа по решению этой проблемы с помощью предложения образовательных стандартов и тестов. Тем не менее, обладание такого сертификата у специалиста еще не является гарантией его компетентности. Здесь речь идет о другой стороне этой проблемы. Даже если разработчик является достаточно компетентным, от него (или нее) часто требуют создавать плохие интерфейсы. В этом отношении можно только позавидовать врачам, потому что для них предусмотрены юридические защитные меры, которые позволяют им выполнять свою работу правильно. Например, врач может предъявить судебный иск за незаконное увольнение при отказе выполнять действия, угрожающие состоянию здоровья пациентов. Строительные инженеры могут обращаться в суд в случае увольнения за отказ нарушить каноны, принятые в их профессии.
Специалисты по разработке интерфейсов работают в области, в которой неправильные решения могут вызвать физические поражения и способствовать психологическим расстройствам. Например, если интерфейс создает необходимость слишком часто нажимать на клавиши или кнопку мыши, это может привести к возникновению или обострению хронического стрессового нарушения (repetitive stress injuries). Плохой интерфейс может вызывать психологические расстройства. Таким образом, требуется создание основы для установления юридических норм защиты добросовестных специалистов. Другой необходимостью является установление определенных профессиональных стандартов (речь идет не о стандартах разработки интерфейсов). Меры, упомянутые в этой книге, а также те, которые будут разработаны в будущем, могут помочь установить количественные, объективные нормы. Например, инженер-строитель должна показать, что она спроектировала мост, который отвечает установленным стандартам, в соответствии с которыми этот мост должен выдерживать нагрузку, скажем, в два раза превышающую минимально возможный уровень. Выбросы из автомобиля должны содержать не более 0.2% CO для того, чтобы этот автомобиль мог быть сертифицирован. Аналогичным образом, мы могли бы установить, что интерфейс текстового процессора не может быть принят, если, скажем, его общая информационно-теоретическая эффективность меньше 0.7 или если общая символьная производительность является меньше 0.8, а отдельные элементы имеют эффективность меньше 0.5.
Критерии могут быть также подобраны таким образом, что для некоторого числа наиболее часто используемых задач средневзвешенное время выполнения, а значит, и количество нажатий на клавиши, движений с помощью ГУВ и нажатий на его кнопку в новом текстовом процессоре не должно превышать значений, которые достигнуты в любом предыдущем или современном коммерческом продукте, предназначенном для аналогичной цели. Продукты, которые удовлетворяют данным критериям, могут получать какую-то форму сертификации. Эти критерии будут автоматически изменяться по мере развития интерфейсной технологии. В настоящее время новые продукты часто оказываются сложнее в использовании, чем старые, но это нельзя понять до тех пор, пока вы не попробуете это проверить на собственном опыте. Поскольку эти критерии касаются эффективности, т.е. в конечном счете определяют итоговый результат работы пользователя, то руководители проекта должны уделять им особое внимание. От публикации объективных нормативов качества интерфейсов выиграют не только разработчики и руководители проекта, но также и покупатели.
Стив Уайлдстром (Steve Wildstrom), который публикует свои статьи в еженедельнике Business Week, указывает, что "производители компьютеров и, в особенности, разработчики программного обеспечения, часто думают, что требования Единого коммерческого кодекса (Uniform Commercial Code) касаются не их, а кого-то другого" (частный разговор, октябрь 1998г.). Многие современные лицензии на программное обеспечение, навязываемые покупателям, не гарантируют им даже того, что это программное обеспечение будет выполнять задачу, о которой сообщалось в рекламе. Во многих таких документах прямым образом отрицается понятие merchantability (годности для продажи), которое означает буквально следующее: продажа данного продукта автоматически предполагает, что этот продукт способен выполнять задачу, для которой он, по заявлению продавца, предназначен. В некоторых штатах США были приняты законы, запрещающие отказ от подтверждения "годности к продаже" для продуктов компьютерного производства. Все верховные власти должны поступить так же.
Система оценки качества интерфейсов, осуществляемая независимой организацией, может быть полезной для покупателей тех продуктов, в которых интерфейсный компонент выполняет значительную роль. Сама разработка пользовательского интерфейса не должна как-то регулироваться или ограничиваться. Следует избегать применения принципов, основанных на использовании конкретных интерфейсных механизмов, чтобы не подавлять стремление к нововведениям. Однако введение относительных количественных нормативов продуктивности для продуктов одного типа побудит разработчиков двигаться в правильном направлении.
Нужно найти тонкий баланс между созданием настолько нового продукта, что опытные пользователи, привыкшие к обычным интерфейсам, почувствуют неудобство в его использовании, и созданием продукта с интерфейсом, который настолько не отличается от стандартного графического пользовательского интерфейса, что его никак нельзя считать результатом нашего желания в максимальной степени помочь пользователю. С одной стороны, мы должны избежать новизны как таковой, хотя с другой стороны, мы не должны терять ценную возможность выиграть на рынке из-за того, что декалькируем аналогичные существующие продукты.
В бизнесе разработки интерфейсов давно существует миф о том, что "расширение функциональности и сохранение простоты использования не могут быть совмещены в одном интерфейсе" (Microsoft, 1995, с.8 ). Действительно, добавление множества специальных, созданных именно для данного случая сервисов, уменьшает простоту использования. Но как раз это является плохой разработкой. Часто, но не всегда, возможно увеличить функциональность, не увеличивая степень сложности интерфейса. Добавление нового сервиса, как правило, может быть сделано таким образом, что это не прибавит сложности в интерфейсе (здесь следует отметить разницу между сложностью интерфейса и сложностью задачи). Если добавляемая функция позволяет объединить в единое целое разрозненные элементы интерфейса, то такой интерфейс может стать проще.
"Одним из способов сохранить простоту заключается в сокращении объема предъявляемой информации до того минимума, который необходим для адекватного взаимодействия" (Microsoft, 1995, с.8 ). Это действительно так, за исключением того, что слово "адекватного" следует заменить словом "нормального". Однако в этой компании ошибаются, когда утверждают: "Например, не используйте словесных описаний командных имен или сообщений" (Microsoft, 1995, с.8 ). Здесь возникает вопрос: что же можно считать минимумом для нормального взаимодействия? В большинстве современных интерфейсов акцент делается на краткость в ущерб ясности. Почему мы должны заниматься расшифровкой непонятного названия "Список" в выпадающем меню в текстовом процессоре, когда можно было бы использовать более понятное "Создать указатель или оглавление"? (Необходимо учесть, что выпадающее меню не занимает места в документе, поскольку оно исчезает сразу же, как только вы уводите от него курсор или выбираете какую-то из опций). Не следует путать простой внешний вид экрана с простотой использования интерфейса.
НАВИГАЦИЯ ПРОТИВ СВОБОДНОГО ПРОСТРАНСТВА
Кажется, что мы просто боимся отображать информацию в наших интерфейсах. Известно, что чем меньше группа вещей, тем легче найти в ней нужный предмет. Однако из этого не следует, как это может некоторым показаться, что чем меньше элементов на экране, тем лучше. Если сотни элементов разбросаны в десятках экранов, то вы больше времени потеряете на перемещения между ними, чем на сам поиск конкретного элемента, даже если этот элемент находится среди моря других аналогичных. Поиск чего-то в длинных, однообразных списках не всегда может быть трудным.
Если бы люди не могли быстро находить короткие элементы в длинных списках, журнал "Уолл стрит джорнал" уже давно бы разорился. Предпочли бы вы, чтобы котировки акций печатались по 15 строк на странице, каждая их которых оформлена наподобие экрана из современного интерфейса, в придачу даже со схемой поиска нужной страницы вроде:
Ценные бумаги - Страница
AA-AD - 1
AD-AS - 2
AT-AZ - 3
ВА-ВК - 4
и так далее.
Такая схема показалась бы несерьезной, неэкономной и странной. Однако иногда мы используем больше экранных пикселов на то, чтобы сделать аккуратные рамки с тенями, чем на отображение полезной информации. Если человек имеет мотив (обусловленный личным интересом или зарплатой) для того, чтобы искать какие-то нудные данные, длинные списки не могут представлять для него никакой проблемы. Визуальный дизайнер Эдвард Тафт (Edward Tufte, 1983, с.105) разработал принципы отображения информации, среди которых первыми тремя являются следующие:
- данные следует показывать прежде всего остального;
- следует максимально увеличивать долю чернил, используемых для отображения данных;
- следует максимально уменьшать долю чернил, которые не используются для отображения данных.
Для того чтобы приложить эти принципы к устройствам с дисплеями, требуется всего лишь заменить в них слово ЧЕРНИЛА на слово ПИКСЕЛЫ. Серьезный, профессиональный пользователь желает, чтобы экраны были до отказа заполнены полезным содержанием. Экраны должны быть хорошо обозначены, снабжены простыми механизмами для осуществления поиска и получения информации, отражающей суть данного экрана. (В конце концов, раз уж мы сели за компьютер, мы должны извлечь из этого максимальную пользу).
Сегодня существует множество исследований о дизайне экранных изображений. Многие ранние, но до сих пор не утратившие свою ценность исследования, рассмотрены в обзоре Туллиса (Tullis, 1984). Некоторые из результатов до сих пор могут быть использованы (например, время поиска в списке элементов составляет приблизительно 30мс на каждый элемент (с. 126)). Основные результаты, полученные Туллисом, относились к 24*80 алфавитно-цифровым дисплеям и позволяли дать количественные оценки [Критерии, предложенные Туллисом, не учитывают качества содержания, но только его внешний вид. Можно построить такие образцы изображений, которые по этим критериям будут иметь высокие оценки, но будут сложны в использовании]. Если эти результаты применить к современным растровым дисплеям и получить критерий оценки времени поиска целевого объекта, то это позволило бы не только оптимизировать отдельные, изолированные безоконные экранные изображения (в соответствии с ограничениями Туллиса), но также достичь более глобальной оптимизации, связанной с оценкой навигационной структуры. Как отмечает Туллис (с.132), почти всегда необходимо искать компромисс между сложностью экрана и сложностью навигации. Этот компромисс зависит от скорости и простоты работы навигации и от структуры данных. Когда для выполнения внутриэкранного поиска вместо визуального сканирования используется поисковое устройство (как, например, функция LEAP), то для оценки эффективности должны быть разработаны другие виды критериев. Здесь имеется широкая область для дальнейших исследований.
В любом случае, если довести до логического конца популярную философию экранного дизайна, которая сводится к принципу, что "чем больше пустого пространства, тем легче читать", то мы увидим, что тогда на каждом экране должен помещаться только лишь один элемент данных. В этом случае пользователь уж точно сможет визуально распознать этот элемент с наименьшим возможным усилием.
Имея опыт улучшения множества продуктов с помощью сокращения количества экранов и увеличения доли информации на оставшихся экранах,- или, другими словами, с помощью улучшения логической структуры дизайна, приводящего к такому сокращению,- я пришел к выводу, что почти во всех коммерческих программах мы допускаем ту ошибку, что помещаем на экраны слишком мало информации.
ЛУЧШИЙ СПОСОБ ЗАСТАВИТЬ ИНТЕРФЕЙС ВАШЕГО ПРОДУКТА ОТЛИЧАТЬСЯ - ЭТО СДЕЛАТЬ ТАК, ЧТОБЫ ОН РАБОТАЛ. В книге Нормана "Невидимый компьютер" (Norman, "The Invisible Computer", 1998 ) можно найти хорошо написанное и убедительное обоснование важности вопросов разработки интерфейсов, которое в большой степени обращено к тем, кто осуществляет руководство проектами.
Gudleifr- Admin
- Сообщения : 3244
Дата регистрации : 2017-03-29
Re: Джефф Раскин. Интерфейс: новые направления в проектировании компьютерных систем
автор Gudleifr Вт Май 11, 2021 12:15 am
ЗАКЛЮЧЕНИЕ
Он почувствовал жалость к псу, которому по окончании долго действовавшего "Распоряжения о мордах" сняли намордник, и он теперь плохо понимает, что же ему делать.
/К.Г.Грей (из справочника Джейн "Все самолеты мира", 1919)/
Если вы стремитесь сделать интерфейсы как можно более простыми в использовании с учетом человеческих возможностей и ограничений, следует выполнить следующие два действия. Первое - понять, что мы можем делать и чего не можем, изучить карту человеческого мышления на основе когнитивной психологии и проследить ее влияние с точки зрения такой прикладной дисциплины, как когнетика. В данной книге было рассмотрено одно из основных направлений на этой карте - исследования показывают, что наши способности разделяются между когнитивным сознательным и когнитивным бессознательным; что мы обладаем только одним локусом внимания; и что формирование привычек играет центральную роль в том, как мы реагируем на те или иные виды функционирования интерфейсов. Мы также узнали, что индивидуальные отличия при формировании привычек невелики по сравнению с теми отличиями, которые существуют между индивидуумами в других отношениях.
С помощью науки когнетики мы изучили, что режимы (или модальности), которые, как это давно известно, являются нежелательными, становятся причиной некоторых наиболее неприятных проблем в современных компьютерных интерфейсах. Для решения этих проблем требуется, чтобы интерфейс был немодальным и в максимально возможной степени обладал характеристикой монотонности. Следует учитывать имеющееся единообразие между пользователями. Повысить производительность можно за счет уменьшения времени выполнения задачи, что приводит к использованию классического метода исследования - количественного GOMS-анализа в приложении к интерфейсам. GOMS-анализ позволяет определить, какие детали интерфейса замедляют или ускоряют его работу, и приводит нас к вопросу о том, насколько же быстрым и эффективным может быть интерфейс, а также к необходимости установления количественных критериев эффективности.
Пройдя по дороге понимания человеческих способностей, мы затем рассмотрели современное компьютерное оборудование и способы его использования. В результате был определен набор элементарных действий и методов, которые могут быть применены к широкому и разнообразному кругу приложений. Эту форму единообразия также следует использовать.
Наши исследования вели нас в незнакомом направлении, которое оказалось лучшим путем к созданию удобного в использовании интерфейса. Ускорение работы достигается с помощью быстрых методов поиска в сочетании с устранением таких ненужных механизмов, как файловые имена и URL, иерархичные файловые структуры и приложения. Масштабируемая ZIP-среда позволяет нам "лететь" над содержанием, больше видеть и быстро перемещаться в необходимое место внутри него. Мы также затронули некоторые побочные направления, например способы упрощения использования соединительных кабелей.
Эта книга содержит много пробелов. Например, наверняка я мог пропустить какую-то из существующих работ, которую мне следовало бы прочитать, и, возможно, при описании не моих собственных идей я мог неправильно назвать имена их авторов. В некоторых местах этой книги рассматриваются области, в которых при наличии соответствующих ресурсов я бы хотел провести эксперименты, чтобы протестировать мои выводы и предположения. Читателям предлагается рассматривать эти области как поле для дальнейших исследований.
Спасибо за то, что прочитали эту книгу и вместе со мной пытались найти решения для создания более гуманных интерфейсов. В тех случаях, когда наше путешествие заходило в неисследованные земли, я мог в том или другом месте сделать поворот в неверную сторону. Тем не менее, я убежден, что мой компас работает верно, и что главное направление, которое я избрал, является правильным.
На основе наших знаний о познавательной человеческой способности мы пришли к необходимости фундаментального изменения интерфейсов "человек-машина". Все другие методы здесь будут бесполезны.
ПРИЛОЖЕНИЯ
A. ОДНОКНОПОЧНАЯ МЫШЬ: ИСТОРИЯ И БУДУЩЕЕ
Разнообразье любят люди тоже.
/Чосер "Рассказ Сквайра"/
[Men loven of propre kynde newefangelnesse - строфа 610 из второй части стиха "Рассказ Сквайра", поэма "Кентерберийские рассказы" ("Canterbury Tales") Джеффри Чосера (1340-1400), перевод О.Румера (БВЛ, серия 1 т.30, изд-во "Художественная Литература" М., 1973).- Примеч. науч. ред.]
За создание однокнопочной мыши и некоторых основных методов ее использования я получал как критику, так и одобрения. Вопросы читателей черновика этой книги показали, что, на их взгляд, система, разработанная в Macintosh, работала аналогично системе с использованием мыши, которая была ранее создана в исследовательском центре PARC компании Xerox. В данном приложении будут описаны системы с использованием мыши, которые я видел в исследовательском центре Palo Alto Research Center (PARC) компании Xerox. Еще ранее мышь была использована исследовательской группой под руководством Дугласа Инглбарта (Douglas Englebart) из Станфордского исследовательского института для создания системы, которая во многих отношениях на несколько десятилетий опередила свое время. Эта система содержала в себе ценные идеи, которые до сих пор не нашли широкого применения. Однако программное обеспечение, созданное Инглбартом, часто было модальным и иногда являлось неэффективным при подсчете нажатий на клавиши.
Немногие пользователи современных персональных компьютеров помнят, через что надо было пройти, чтобы сделать операцию "выделения" в системе, созданной в исследовательском центре PARC, (например, в их самом популярном текстовом редакторе BRAVO). Далее нажатия на каждую из трех кнопок мыши системы PARC будут обозначены буквами L, М и R (левая, средняя и правая). В текстовом редакторе BRAVO квазирежимы для кнопок мыши не использовались.
- Для выделения символа: указать на нужный символ, нажать L.
- Для выделения слова: указать на нужное слово, нажать M.
- Для выделения произвольной строки символов: указать на первый символ строки, нажать L; указать на последний символ строки, нажать R.
- Для выделения строки слов: указать на первое слово, нажать M; указать на последнее слово, нажать R.
Обычной ошибкой было нажатие на кнопку L, а потом на кнопку M, что приводило только лишь к повторному началу процесса выделения в том месте, которое, как вам казалось, будет концом требуемой вам выборки. Это очень раздражало, особенно если выборка была большого размера. Тем не менее, обратите внимание, что вам никогда не требовалось "отменять" выборку - в любой момент вы могли свободно начинать новую. Это было действительным преимуществом в сравнении с другими современными системами, в которых перед тем, как сделать другую выборку, требовалось сначала нажать на кнопку ESC или совершить другое действие для отмены текущей выборки.
В исследовательском центре PARC ранее был разработан и другой редактор, о котором я в то время еще не знал. Для выделения текста в нем использовался метод click-and-drag (щелкнуть и перетащить). Используя систему обозначений, описанную в разделе 3.1, для выделения какого-то текста, требовалось выполнить следующие действия: указать на верхнюю точку текста, L+, указать на нижнюю точку текста, L-. Однако эта идея не была распространена на другие типы выделения.
В компании Apple я показал, каким образом можно более широко использовать одну кнопку мыши для выделения. Для выделения любой сплошной области на экране, независимо от того, является ли она текстом или нет, нужно указать на один угол области, L+, и указать на другой край, L-. Этот метод стал называться "щелкнуть и перетащить".
Другие методы в текстовом редакторе BRAVO были более сложными, чем те, которые использовались в компьютере Macintosh.
Для удаления текста: выделить текст и нажать d. Проблема здесь заключается в том, что вам требуется знать о том, что выделен какой-то текст, перед тем как нажимать клавишу с буквой d. В компьютере Macintosh я решил использовать клавишу Delete для удаления текста как во время набора, так и при редактировании.
Для вставки текста: указать на точку вставки и нажать L; нажать клавишу с буквой i; ввести новый текст и нажать клавишу ESC. Нажатие клавиши ESC снимает режим вставки. В компьютере Macintosh не использовался режим вставки, и метод, который был применен в нем, стал общераспространенным: для вставки текста указать и щелкнуть мышью в точке, где необходимо сделать вставку, т.е. L; ввести новый текст. В этом случае вместо использования явного разделителя для начала ввода текста, как в редакторе BRAVO, вы сразу же начинаете вводить нужный текст вставки. Вам не требуется в конце ввода вставки нажимать клавишу ESC или другую кнопку - начало выполнения новой задачи автоматически заканчивает предыдущую. Замена текста в текстовом редакторе BRAVO происходила следующим образом: выделить текст, нажать клавишу с буквой r, ввести новый текст, нажать клавишу ESC. Для замены текста в компьютере Macintosh: выделить текст, нажать на клавишу Delete и ввести новый текст. Этот метод отличается от того, который теперь используется в системах Macintosh и Windows для замены текста и который является проще: выделить текст, ввести новый текст.
Однако, как пользователям известно, этот последний метод часто приводит к случайной потере текста. В предыдущем способе требуется на одно нажатие клавиши больше, но он никогда не вызывает потери данных, и поэтому текстовый редактор является более безопасным и пользователь ощущает его именно таким. Следовательно, одно дополнительное нажатие на клавишу здесь оказывается весьма полезным.
В отличие от текстового редактора BRAVO и некоторых других редакторов, разработанных в исследовательском центре PARC, в компьютере Macintosh и, в значительной степени, в более поздних системах ввод простой буквы никогда не действует как команда. Сейчас уже очевидно, что так и должно быть, но в то время так не казалось. Мой проект интерфейса, основанного на использовании однокнопочной мыши, уточнялся и расширялся во время обсуждений с моими коллегами, чаще с Брайеном Хоурдом (Brian Howard) и Биллом Аткинсом (Bill Atkinson), и, конечно, многие изменения были сделаны на основе наблюдений, сделанных во время пользовательских тестирований и дальнейшего процесса разработки. Для некоторых пользователей оказалось сложным одновременно удерживать кнопку и двигать графическое устройство ввода, но это отчасти зависит от его конструкции, а также от того, используется ли мышь или другое устройство. В проекте Macintosh эта проблема была облегчена тем, что на мышь была установлена одна большая кнопка, требующая небольшого усилия для нажатия и хорошо воспринимаемая на ощупь. (Некоторые из последних моделей сенсорных панелей, особенно переносные, имеют плохие кнопки, и поэтому с их помощью трудно делать перетаскивание, что часто приводит к ошибкам). Кроме того, общее улучшение и сокращение ошибок, достигаемое путем устранения режимов, часто перевешивает ошибки, возникающие во время перетаскивания, даже если используются не совсем оптимальные графические устройства ввода.
В то время, однако, я не понимал еще, что мышь может работать нормально даже со множеством кнопок ПРИ УСЛОВИИ, ЧТО ОНИ КАК-ТО ОБОЗНАЧЕНЫ. Если бы мышь Macintosh была снабжена множеством кнопок, и если бы кнопки имели постоянные обозначения и использовались только лишь для обозначенной функции, такая мышь могла бы стать более совершенным вариантом. Улучшенная мышь могла бы иметь сверху две кнопки, обозначенные как Select (Выделить) и Activate (Активизировать), и сбоку кнопку, управляемую большим пальцем руки. Эта последняя кнопка могла бы быть обозначена как Grab (Схватить). На некоторых современных мышах есть сверху колесо, которое в основном используется для прокрутки. Было бы лучше, если бы в этом месте находился небольшой трекбол. Таким образом, с помощью мыши контролировалась бы позиция курсора, а трекбол использовался бы, например, для перемещения объектов или для выбора элементов из плавающих меню.
B. ТЕОРИЯ РАБОТЫ ИНТЕРФЕЙСА ДЛЯ SWYFTCARD
Некоторые из принципов, рассмотренных в этой книге, впервые были опубликованы в 1984 году в руководстве для SwiftCard. Система SwiftCard, предназначенная для довольно успешного в то время Apple II, была (по сегодняшним стандартам) простой. Приложение к ее руководству имело необычное содержание. Вместе с обычным, традиционным изложением принципа работы электронной начинки этого устройства предлагалось теоретическое описание работы программного обеспечения, а также информация о теории работы пользовательского интерфейса. Это, пожалуй, был первый случай, когда информация такого рода сопровождала коммерческий продукт. В некотором смысле то приложение можно считать началом этой книги. Нижеследующий материал взят из второго издания руководства (Alzofon и Raskin, 1985).
Подходы, на основе которых была создана SwiftCard, разрабатывались с целью решения целого ряда проблем, которыми страдают почти все современные системы. Большинство из этих проблем сами по себе являются довольно небольшими, но в совокупности они приводят к тому, что процесс изучения и использования существующего программного обеспечения чрезмерно замедляется, что вызывает раздражение и усталость от использования компьютеров.
Например, мы всегда удивлялись, почему пользователю приходится форматировать диски. Разве компьютер не способен самостоятельно определить, форматирован диск или нет, и при необходимости выполнить форматирование? Кроме того, нам кажется, что клавиши для управления курсором работают слишком медленно, а если учесть то количество дополнительных команд, которое они требуют (для перемещения к следующему/предыдущему слову, предложению, абзацу, странице; для перемещения к началу или концу строки, документа или файла), то, на наш взгляд, они являются также и слишком сложными. ГУВ существенного улучшения не приносит, поскольку большая часть этих устройств заставляет пользователя убирать руки с клавиатуры, а также требует много экранного пространства для меню, полос прокрутки и других механизмов, связанных с использованием ГУВ. Необходимость работать с меню вместо того, чтобы сразу делать то, что нам необходимо, вызывает раздражение, а огромное число команд, которое используется в большинстве систем, ставит нас в затруднительное положение. Мы ненавидим дисковые системы, которые могут допустить потерю информации из-за обычных человеческих ошибок. Нас удивляет, что многие текстовые процессоры не успевают воспринимать информацию, вводимую с клавиатуры человеком.
SwiftCard демонстрирует собой, что хороший проект позволяет решить все эти, а вместе с ними и многие другие вопросы и проблемы, которые беспокоили нас в течение многих лет. Эта система способна работать на недорогом компьютере, имеющем только один диск, и требует минимальных ресурсов памяти. Наш продукт выполняет то, что требуется для большинства пользователей, однако без помощи операционной системы, без ценника с большими цифрами, без капризов в работе.
Основные принципы разработки включают много новшеств и учитывают опыт, использованный в других продуктах.
1. Концепция курсора с функцией LEAP, которая позволяет перемещаться к целевому объекту со скоростью, в среднем в три раза превышающей скорость работы самого лучшего общераспространенного устройства типа мышь.
2. Сам курсор состоит из двух частей, которые точно показывают места, где будет появляться вводимый текст и где будет происходить удаление. Этот же курсор сворачивается при перемещении так, чтобы было удобно удалять.
3. Ограниченный набор основных операций позволяет легко выполнять широкий диапазон задач.
4. Отказ от использования операционной системы позволяет выполнять все операции непосредственно из редактора без необходимости переходить в различные режимы.
5. Устранение режимов в целом способствует формированию привычек, поскольку пользователю не приходится задумываться, в каком состоянии находится система, чтобы определить доступные в этом состоянии команды. Это свойство называется безмодальностью.
6. Отказ от использования множества способов выполнения той или иной задачи - опять же для того, чтобы пользователю не приходилось задумываться о том, какой способ выполнения задачи выбрать. Этот принцип мы называем монотонностью. Так же как и безмодальность, монотонность способствует формированию привычек в использовании.
7. Акцент на формирование привычек сам по себе является основополагающим принципом, однако разработчики зачастую его неоправданно не учитывают. Мы считаем важным, чтобы после короткого периода обучения пользователь мог использовать систему, не задумываясь о ее работе.
8. Команда DISK позволяет снять сложности, которые обычно возникают при использовании дисковой операционной системы (DOS). Используется только одна простая команда. Она же позволяет защитить данные от наиболее частых ошибок, приводящих к потере информации. Возможность для создания такой команды дает метод, при котором один диск соответствует одному Тексту.
9. Создание зависимости скорости работы от частоты использования (чаще используемые задачи выполняются быстрее, реже используемые - медленнее).
10. "То, что вы видите, то вы и получите" (What you see is what you get). Другими словами, изображение на экране будет выглядеть так же и на бумаге. (Из-за ограничений в оборудовании Apple этот принцип, тем не менее, был нарушен для операции подчеркивания).
11. Построение команд по методу "существительное-глагол". Сначала пользователь определяет, с чем он собирается работать (что дает время на проверку и при необходимости исправление), и затем применяет некоторое действие к выбранному объекту. В некоторых системах используется обратная последовательность ("глагол-существительное") или даже смешиваются оба метода, что еще хуже.
12. Другой общий принцип заключается в том, что в системе трудно что-либо испортить или стереть. Это возможно, но очень трудно. Ошибки не происходят случайно или по невнимательности пользователя.
13. Включение средств программирования и коммуникации в среду общего назначения, внутри которой выходные данные помещаются в область редактирования или поиска.
14. Необходимость учета в плане работы времени на проведение длительных (в течение нескольких месяцев) тестирований и наладки. Покупатели системы не должны использоваться в качестве субъектов тестирования.
Вышеизложенное является только упрощенным наброском (описание системы насчитывает около 50 страниц), но мы надеемся, что это даст вам некоторое представление о том, что привело нас к идее сделать систему SwiftCard такой, какая она есть.
БИБЛИОГРАФИЯ
Где-то я мог неправильно интерпретировать или понять смысл цитируемых мной работ. Заранее прошу меня извинить за любые ошибки такого рода.
- Accot, Johnny, and Shumin Zhai. "Beyond Fitts' Law: Models for Trajectory-Based HCI Tasks" (www.dgp.toronto.edu/~accot/Common/Articles/CHI97/chi.html, 1997).
- Alzofon, David, David Caulkins, Jef Raskin, and James Winter. Canon Cat How-To Guide (Tokyo: Canon, 1987).
- Alzofon, David, and Jef Raskin. SwyftCard , 2d ed. (Menlo Park, CA: Information Appliance, 1985).
- Anderson, J.R. Rules of the Mind (Hillsdale, NJ: Lawrence Erlbaum Associates, 1993).
- Apple Computer. Inside Macintosh , Vol.1 (Cupertino, CA: Apple Computer, 1985).
- Apple Computer. Human Interface Guidelines: The Apple Desktop Interface (Reading, MA: Addison-Wesley, 1987).
- Ashlar. Vellum 3D Manual (Sunnyvale, CA: Ashlar, 1995).
- Asimov, Isaac. I Robot (New York: Bantam Books, 1977).
- Baars, Bernard J. A Cognitive Theory of Consciousness (Cambridge, U.K: Cambridge University Press, 1988 ).
- Business Week. "Special Report on Information Appliances" (22 Nov. 1993), p.110.
- Buxton, William. "Chunking and Phrasing and the Design of Human-Computer Dialogs," Information Processing 86: Proceedings of the IFIP 10th World Computer Congress (Amsterdam: North-Holland, 1986).
- Card, Stuart K., Thomas P.Moran, and Allen Newell. The Psychology of Human-Computer Interaction (Hillsdale, NJ: Lawrence Erlbaum Associates, 1983).
- Cohen, Jonathan D., and Jonathan W.Schooler, eds. Scientific Approaches to Consciousness (Hillsdale, NJ: Lawrence Erlbaum Associates, 1997).
- Collins, Richard. Flying 121:10, p.67 (October 1994).
- Cooper, Alan. About Face (Foster City, CA: IDG Books Worldwide, 1995).
- Dennett, Daniel C. Consciousness Explained (Boston: Little, Brown, 1991).
- Dijksterhuis, E.J. The Mechanization of the World Picture (London: Oxford University Press, 1961).
- Drori, Offer. "The User Interface in Text Retrieval Systems," SigCHI Bulletin 30:3 (1998 ).
- Eriksson, H., and P. Magnus. UML (Unified Modeling Language) Toolkit (New York: John Wiley & Sons, 1998 ).
- Garrison, Peter. Flying 121:12, p.112 (December 1994).
- Garrison, Peter. "Drifting Off Centerline," Flying 122:1, p.43 (January 1995).
- Gray, Wayne D., Bonnie E. John, and Michael E. Atwood. "Project Ernestine: Validating a GOMS Analysis for Predicting and Explaining Real-World Task Performance," Human-Computer Interaction , 8:3, pp.237-309 (1993).
- Grudin, J. "The Case Against User Interface Consistency," Communications of the ACM , pp. 1164-1173 (1989).
- Hewlett-Packard. User Interface Design Rules for the New Wave Office System (Cupertino, CA: Hewlett-Packard Personal Software Division, 1987).
- Hotchkiss, B. "The Car Column," Pacifica Tribune , 12 Nov. 1997, p.14A.
- Horton, William. The Icon Book (New York: John Wiley, 1994).
- IBM. System Application Architecture, Common User Access, Panel Design and User Interaction (Boca Raton, FL: IBM, 1988 ).
- Jacobson, Robert, ed. Information Design (Cambridge, MA: MIT Press, 1999).
John, Bonnie E. "Why GOMS?" Interactions : pp.80-89 (October 1995).
- Johnson, J., and G.Englebeck. "Modes Survey Results," SigCHI Bulletin 20:4, pp.38-50 (1989).
- Kaplan, Justin, ed. Bartlett's Familiar Quotations , 16th ed. (Boston: Little, Brown, 1992).
- Knuth, Donald E. Literate Programming (Stanford, CA: Center for the Study of Language and Information, 1992).
- Lammers, Susan. Programmers at Work (Redmond, WA: Microsoft Press, 1986).
- Landauer, Thomas K. The Trouble with Computers (Cambridge, MA: MIT Press, 1995).
- Laurel, Brenda, ed. The Art of Human-Computer Interface Design (Reading, MA: Addison- Wesley, 1990).
- Lewis, C., and D. A. Norman. "Designing for Error," in D. Norman and S. Draper, eds... User Centered System Design (Hillsdale, NJ: Lawrence Erlbaum Associates, 1986).
- Linzmayer, Owen. Apple Confidential (San Francisco: No Starch Press, 1999).
- Loftus, Elizabeth F. Eyewitness Testimony (Cambridge, MA: Harvard University Press, 1979).
- Loftus, Elizabeth F. Memory (Reading, MA: Addison-Wesley, 1980).
- Mackenzie, I.S. "Movement Time Prediction in Human-Computer Interfaces," in R.M.Baecker, W.A.S. Buxton, J.Grudin, and S.Greenberg, eds., Readings in Human-Computer Interaction , 2d ed., pp.483-493 (Los Altos, CA: Kaufmann, 1995).
- Malone, Michael S. Infinite Loop (Chicago: Doubleday, 1999).
- Mayhew, Deborah. Principles and Guidelines in Software User Interface Design (Englewood Cliffs, NJ.: Prentice-Hall, 1992).
- Microsoft. The Windows Interface Guidelines for Software Design (Redmond, WA: Microsoft Press, 1995).
- Miller, George A. "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information," Psychological Review 63, pp.81-97 (1956).
- Moore, J.S., and R.S.Boyer. "A Fast String Searching Algorithm," Communications of the Association for Computing Machinery 20:10, pp.762-772 (1977).
- Norman, Donald A. "Categorization of Action Slips," Psychology Review 88:1, pp.1-15 (1981).
- Norman, Donald A. "Design Rules Based on Analyses of Human Error," Communications of the ACM 26:4, p.255 (1983).
- Norman, Donald A. The Psychology of Everyday Things (New York: Basic Books, 1988 ).
- Norman, Donald A. The Invisible Computer (Cambridge, MA: MIT Press, 1998 ).
- Penrose, Roger. The Emperor's New Mind (London: Oxford University Press, 1989).
- Raskin, Jef. "Looking for a Humane Interface: Will Computers Ever Become Easy to Use?" Communications of the ACM 40:2, p.98 (Feb. 1997).
- Raskin, Jef. "The Quick-Draw Graphics System." Ph.D. diss. (State College, PA: Pennsylvania State University, 1967).
- Raskin, Jef. "FLOW: A Teaching Language for Computer Programming," Computers and the Humanities 8:4 pp. (July 1974).
- Raskin, Jef. "Computers by the Millions," SIGPC Newsletter 5:2 (1982).
- Raskin, Jef. "Systemic Implications of an Improved Two-Part Cursor," Proceedings of CHI 89: Human Factors in Computing Systems, Austin: 30 April 1989, pp.167-170 (New York: ACM Press, 1989).
- Raskin, Jef. "Down with GUIs," Wired pp. (December 1993).
- Raskin, Jef. "Intuitive Equals Familiar," Communications of the ACM 37:9, pp. (September 1994).
- Raskin, Jef, and James Winter. U.S. Patent No. 5,019,806, Method and Apparatus for Control of an Electronic Display, 1991.
- Reason, James. Human Error (Cambridge, U.K.: Cambridge University Press, 1990).
- Shneiderman, Ben. Designing the User Interface (Reading, MA: Addison-Wesley, 1987, 1998 ).
- Sellen, A., G.Kurtenbach, and W.Buxton. "The Prevention of Mode Errors Through Sensory Feedback," Human Computer Interaction 7:2, pp.141-164 (1992).
- Shannon, Claude E., and Warren Weaver. The Mathematical Theory of Communication (Urbana: University of Illinois Press, 1949, reprinted 1963).
- Smith, S.F., and D.J.Duell. Clinical Nursing Skills, 3rd ed. (East Norwalk, CT: Appleton & Lange, 1992).
- Stallman, Richard. GNU Emacs Manual, 9th ed. (Cambridge, MA: Free Software Foundation, 1993).
- Tesler, Larry. "The Smalltalk Environment," Byte (August 1981).
- Tesler, Larry, and Timothy Mott. Report on the Xerox Palo Alto Research Center Gypsy Typescript System (Palo Alto, CA: Xerox, 20 April 1975).
- Thomas, Lewis. The Lives of a Cell (New York: Viking Press, 1974).
- Tognazzini, Bruce. Tog on Interface (Reading , MA: Addison-Wesley, 1992).
- Tolkien, J.R.R. (Douglas Anderson, ed.) The Annotated Hobbit (Boston: Houghton Mifflin, 1988 ).
- Tufte, Edward. The Visual Display of Quantitative Information (Cheshire, CT: Graphics Press, 1983).
- Tullis, Thomas S. "Predicting the Usability of Alphanumeric Displays," Ph.D diss., Rice University, 1984.
- de Unamuno y Jugo, Miguel. The Tragic Sense of Life , Chapter 9 (1913).
- Weinberg, Gerald M. The Psychology of Computer Programming (New York: Van Nostrand Reinhold, 1971).
Он почувствовал жалость к псу, которому по окончании долго действовавшего "Распоряжения о мордах" сняли намордник, и он теперь плохо понимает, что же ему делать.
/К.Г.Грей (из справочника Джейн "Все самолеты мира", 1919)/
Если вы стремитесь сделать интерфейсы как можно более простыми в использовании с учетом человеческих возможностей и ограничений, следует выполнить следующие два действия. Первое - понять, что мы можем делать и чего не можем, изучить карту человеческого мышления на основе когнитивной психологии и проследить ее влияние с точки зрения такой прикладной дисциплины, как когнетика. В данной книге было рассмотрено одно из основных направлений на этой карте - исследования показывают, что наши способности разделяются между когнитивным сознательным и когнитивным бессознательным; что мы обладаем только одним локусом внимания; и что формирование привычек играет центральную роль в том, как мы реагируем на те или иные виды функционирования интерфейсов. Мы также узнали, что индивидуальные отличия при формировании привычек невелики по сравнению с теми отличиями, которые существуют между индивидуумами в других отношениях.
С помощью науки когнетики мы изучили, что режимы (или модальности), которые, как это давно известно, являются нежелательными, становятся причиной некоторых наиболее неприятных проблем в современных компьютерных интерфейсах. Для решения этих проблем требуется, чтобы интерфейс был немодальным и в максимально возможной степени обладал характеристикой монотонности. Следует учитывать имеющееся единообразие между пользователями. Повысить производительность можно за счет уменьшения времени выполнения задачи, что приводит к использованию классического метода исследования - количественного GOMS-анализа в приложении к интерфейсам. GOMS-анализ позволяет определить, какие детали интерфейса замедляют или ускоряют его работу, и приводит нас к вопросу о том, насколько же быстрым и эффективным может быть интерфейс, а также к необходимости установления количественных критериев эффективности.
Пройдя по дороге понимания человеческих способностей, мы затем рассмотрели современное компьютерное оборудование и способы его использования. В результате был определен набор элементарных действий и методов, которые могут быть применены к широкому и разнообразному кругу приложений. Эту форму единообразия также следует использовать.
Наши исследования вели нас в незнакомом направлении, которое оказалось лучшим путем к созданию удобного в использовании интерфейса. Ускорение работы достигается с помощью быстрых методов поиска в сочетании с устранением таких ненужных механизмов, как файловые имена и URL, иерархичные файловые структуры и приложения. Масштабируемая ZIP-среда позволяет нам "лететь" над содержанием, больше видеть и быстро перемещаться в необходимое место внутри него. Мы также затронули некоторые побочные направления, например способы упрощения использования соединительных кабелей.
Эта книга содержит много пробелов. Например, наверняка я мог пропустить какую-то из существующих работ, которую мне следовало бы прочитать, и, возможно, при описании не моих собственных идей я мог неправильно назвать имена их авторов. В некоторых местах этой книги рассматриваются области, в которых при наличии соответствующих ресурсов я бы хотел провести эксперименты, чтобы протестировать мои выводы и предположения. Читателям предлагается рассматривать эти области как поле для дальнейших исследований.
Спасибо за то, что прочитали эту книгу и вместе со мной пытались найти решения для создания более гуманных интерфейсов. В тех случаях, когда наше путешествие заходило в неисследованные земли, я мог в том или другом месте сделать поворот в неверную сторону. Тем не менее, я убежден, что мой компас работает верно, и что главное направление, которое я избрал, является правильным.
На основе наших знаний о познавательной человеческой способности мы пришли к необходимости фундаментального изменения интерфейсов "человек-машина". Все другие методы здесь будут бесполезны.
ПРИЛОЖЕНИЯ
A. ОДНОКНОПОЧНАЯ МЫШЬ: ИСТОРИЯ И БУДУЩЕЕ
Разнообразье любят люди тоже.
/Чосер "Рассказ Сквайра"/
[Men loven of propre kynde newefangelnesse - строфа 610 из второй части стиха "Рассказ Сквайра", поэма "Кентерберийские рассказы" ("Canterbury Tales") Джеффри Чосера (1340-1400), перевод О.Румера (БВЛ, серия 1 т.30, изд-во "Художественная Литература" М., 1973).- Примеч. науч. ред.]
За создание однокнопочной мыши и некоторых основных методов ее использования я получал как критику, так и одобрения. Вопросы читателей черновика этой книги показали, что, на их взгляд, система, разработанная в Macintosh, работала аналогично системе с использованием мыши, которая была ранее создана в исследовательском центре PARC компании Xerox. В данном приложении будут описаны системы с использованием мыши, которые я видел в исследовательском центре Palo Alto Research Center (PARC) компании Xerox. Еще ранее мышь была использована исследовательской группой под руководством Дугласа Инглбарта (Douglas Englebart) из Станфордского исследовательского института для создания системы, которая во многих отношениях на несколько десятилетий опередила свое время. Эта система содержала в себе ценные идеи, которые до сих пор не нашли широкого применения. Однако программное обеспечение, созданное Инглбартом, часто было модальным и иногда являлось неэффективным при подсчете нажатий на клавиши.
Немногие пользователи современных персональных компьютеров помнят, через что надо было пройти, чтобы сделать операцию "выделения" в системе, созданной в исследовательском центре PARC, (например, в их самом популярном текстовом редакторе BRAVO). Далее нажатия на каждую из трех кнопок мыши системы PARC будут обозначены буквами L, М и R (левая, средняя и правая). В текстовом редакторе BRAVO квазирежимы для кнопок мыши не использовались.
- Для выделения символа: указать на нужный символ, нажать L.
- Для выделения слова: указать на нужное слово, нажать M.
- Для выделения произвольной строки символов: указать на первый символ строки, нажать L; указать на последний символ строки, нажать R.
- Для выделения строки слов: указать на первое слово, нажать M; указать на последнее слово, нажать R.
Обычной ошибкой было нажатие на кнопку L, а потом на кнопку M, что приводило только лишь к повторному началу процесса выделения в том месте, которое, как вам казалось, будет концом требуемой вам выборки. Это очень раздражало, особенно если выборка была большого размера. Тем не менее, обратите внимание, что вам никогда не требовалось "отменять" выборку - в любой момент вы могли свободно начинать новую. Это было действительным преимуществом в сравнении с другими современными системами, в которых перед тем, как сделать другую выборку, требовалось сначала нажать на кнопку ESC или совершить другое действие для отмены текущей выборки.
В исследовательском центре PARC ранее был разработан и другой редактор, о котором я в то время еще не знал. Для выделения текста в нем использовался метод click-and-drag (щелкнуть и перетащить). Используя систему обозначений, описанную в разделе 3.1, для выделения какого-то текста, требовалось выполнить следующие действия: указать на верхнюю точку текста, L+, указать на нижнюю точку текста, L-. Однако эта идея не была распространена на другие типы выделения.
В компании Apple я показал, каким образом можно более широко использовать одну кнопку мыши для выделения. Для выделения любой сплошной области на экране, независимо от того, является ли она текстом или нет, нужно указать на один угол области, L+, и указать на другой край, L-. Этот метод стал называться "щелкнуть и перетащить".
Другие методы в текстовом редакторе BRAVO были более сложными, чем те, которые использовались в компьютере Macintosh.
Для удаления текста: выделить текст и нажать d. Проблема здесь заключается в том, что вам требуется знать о том, что выделен какой-то текст, перед тем как нажимать клавишу с буквой d. В компьютере Macintosh я решил использовать клавишу Delete для удаления текста как во время набора, так и при редактировании.
Для вставки текста: указать на точку вставки и нажать L; нажать клавишу с буквой i; ввести новый текст и нажать клавишу ESC. Нажатие клавиши ESC снимает режим вставки. В компьютере Macintosh не использовался режим вставки, и метод, который был применен в нем, стал общераспространенным: для вставки текста указать и щелкнуть мышью в точке, где необходимо сделать вставку, т.е. L; ввести новый текст. В этом случае вместо использования явного разделителя для начала ввода текста, как в редакторе BRAVO, вы сразу же начинаете вводить нужный текст вставки. Вам не требуется в конце ввода вставки нажимать клавишу ESC или другую кнопку - начало выполнения новой задачи автоматически заканчивает предыдущую. Замена текста в текстовом редакторе BRAVO происходила следующим образом: выделить текст, нажать клавишу с буквой r, ввести новый текст, нажать клавишу ESC. Для замены текста в компьютере Macintosh: выделить текст, нажать на клавишу Delete и ввести новый текст. Этот метод отличается от того, который теперь используется в системах Macintosh и Windows для замены текста и который является проще: выделить текст, ввести новый текст.
Однако, как пользователям известно, этот последний метод часто приводит к случайной потере текста. В предыдущем способе требуется на одно нажатие клавиши больше, но он никогда не вызывает потери данных, и поэтому текстовый редактор является более безопасным и пользователь ощущает его именно таким. Следовательно, одно дополнительное нажатие на клавишу здесь оказывается весьма полезным.
В отличие от текстового редактора BRAVO и некоторых других редакторов, разработанных в исследовательском центре PARC, в компьютере Macintosh и, в значительной степени, в более поздних системах ввод простой буквы никогда не действует как команда. Сейчас уже очевидно, что так и должно быть, но в то время так не казалось. Мой проект интерфейса, основанного на использовании однокнопочной мыши, уточнялся и расширялся во время обсуждений с моими коллегами, чаще с Брайеном Хоурдом (Brian Howard) и Биллом Аткинсом (Bill Atkinson), и, конечно, многие изменения были сделаны на основе наблюдений, сделанных во время пользовательских тестирований и дальнейшего процесса разработки. Для некоторых пользователей оказалось сложным одновременно удерживать кнопку и двигать графическое устройство ввода, но это отчасти зависит от его конструкции, а также от того, используется ли мышь или другое устройство. В проекте Macintosh эта проблема была облегчена тем, что на мышь была установлена одна большая кнопка, требующая небольшого усилия для нажатия и хорошо воспринимаемая на ощупь. (Некоторые из последних моделей сенсорных панелей, особенно переносные, имеют плохие кнопки, и поэтому с их помощью трудно делать перетаскивание, что часто приводит к ошибкам). Кроме того, общее улучшение и сокращение ошибок, достигаемое путем устранения режимов, часто перевешивает ошибки, возникающие во время перетаскивания, даже если используются не совсем оптимальные графические устройства ввода.
В то время, однако, я не понимал еще, что мышь может работать нормально даже со множеством кнопок ПРИ УСЛОВИИ, ЧТО ОНИ КАК-ТО ОБОЗНАЧЕНЫ. Если бы мышь Macintosh была снабжена множеством кнопок, и если бы кнопки имели постоянные обозначения и использовались только лишь для обозначенной функции, такая мышь могла бы стать более совершенным вариантом. Улучшенная мышь могла бы иметь сверху две кнопки, обозначенные как Select (Выделить) и Activate (Активизировать), и сбоку кнопку, управляемую большим пальцем руки. Эта последняя кнопка могла бы быть обозначена как Grab (Схватить). На некоторых современных мышах есть сверху колесо, которое в основном используется для прокрутки. Было бы лучше, если бы в этом месте находился небольшой трекбол. Таким образом, с помощью мыши контролировалась бы позиция курсора, а трекбол использовался бы, например, для перемещения объектов или для выбора элементов из плавающих меню.
B. ТЕОРИЯ РАБОТЫ ИНТЕРФЕЙСА ДЛЯ SWYFTCARD
Некоторые из принципов, рассмотренных в этой книге, впервые были опубликованы в 1984 году в руководстве для SwiftCard. Система SwiftCard, предназначенная для довольно успешного в то время Apple II, была (по сегодняшним стандартам) простой. Приложение к ее руководству имело необычное содержание. Вместе с обычным, традиционным изложением принципа работы электронной начинки этого устройства предлагалось теоретическое описание работы программного обеспечения, а также информация о теории работы пользовательского интерфейса. Это, пожалуй, был первый случай, когда информация такого рода сопровождала коммерческий продукт. В некотором смысле то приложение можно считать началом этой книги. Нижеследующий материал взят из второго издания руководства (Alzofon и Raskin, 1985).
Подходы, на основе которых была создана SwiftCard, разрабатывались с целью решения целого ряда проблем, которыми страдают почти все современные системы. Большинство из этих проблем сами по себе являются довольно небольшими, но в совокупности они приводят к тому, что процесс изучения и использования существующего программного обеспечения чрезмерно замедляется, что вызывает раздражение и усталость от использования компьютеров.
Например, мы всегда удивлялись, почему пользователю приходится форматировать диски. Разве компьютер не способен самостоятельно определить, форматирован диск или нет, и при необходимости выполнить форматирование? Кроме того, нам кажется, что клавиши для управления курсором работают слишком медленно, а если учесть то количество дополнительных команд, которое они требуют (для перемещения к следующему/предыдущему слову, предложению, абзацу, странице; для перемещения к началу или концу строки, документа или файла), то, на наш взгляд, они являются также и слишком сложными. ГУВ существенного улучшения не приносит, поскольку большая часть этих устройств заставляет пользователя убирать руки с клавиатуры, а также требует много экранного пространства для меню, полос прокрутки и других механизмов, связанных с использованием ГУВ. Необходимость работать с меню вместо того, чтобы сразу делать то, что нам необходимо, вызывает раздражение, а огромное число команд, которое используется в большинстве систем, ставит нас в затруднительное положение. Мы ненавидим дисковые системы, которые могут допустить потерю информации из-за обычных человеческих ошибок. Нас удивляет, что многие текстовые процессоры не успевают воспринимать информацию, вводимую с клавиатуры человеком.
SwiftCard демонстрирует собой, что хороший проект позволяет решить все эти, а вместе с ними и многие другие вопросы и проблемы, которые беспокоили нас в течение многих лет. Эта система способна работать на недорогом компьютере, имеющем только один диск, и требует минимальных ресурсов памяти. Наш продукт выполняет то, что требуется для большинства пользователей, однако без помощи операционной системы, без ценника с большими цифрами, без капризов в работе.
Основные принципы разработки включают много новшеств и учитывают опыт, использованный в других продуктах.
1. Концепция курсора с функцией LEAP, которая позволяет перемещаться к целевому объекту со скоростью, в среднем в три раза превышающей скорость работы самого лучшего общераспространенного устройства типа мышь.
2. Сам курсор состоит из двух частей, которые точно показывают места, где будет появляться вводимый текст и где будет происходить удаление. Этот же курсор сворачивается при перемещении так, чтобы было удобно удалять.
3. Ограниченный набор основных операций позволяет легко выполнять широкий диапазон задач.
4. Отказ от использования операционной системы позволяет выполнять все операции непосредственно из редактора без необходимости переходить в различные режимы.
5. Устранение режимов в целом способствует формированию привычек, поскольку пользователю не приходится задумываться, в каком состоянии находится система, чтобы определить доступные в этом состоянии команды. Это свойство называется безмодальностью.
6. Отказ от использования множества способов выполнения той или иной задачи - опять же для того, чтобы пользователю не приходилось задумываться о том, какой способ выполнения задачи выбрать. Этот принцип мы называем монотонностью. Так же как и безмодальность, монотонность способствует формированию привычек в использовании.
7. Акцент на формирование привычек сам по себе является основополагающим принципом, однако разработчики зачастую его неоправданно не учитывают. Мы считаем важным, чтобы после короткого периода обучения пользователь мог использовать систему, не задумываясь о ее работе.
8. Команда DISK позволяет снять сложности, которые обычно возникают при использовании дисковой операционной системы (DOS). Используется только одна простая команда. Она же позволяет защитить данные от наиболее частых ошибок, приводящих к потере информации. Возможность для создания такой команды дает метод, при котором один диск соответствует одному Тексту.
9. Создание зависимости скорости работы от частоты использования (чаще используемые задачи выполняются быстрее, реже используемые - медленнее).
10. "То, что вы видите, то вы и получите" (What you see is what you get). Другими словами, изображение на экране будет выглядеть так же и на бумаге. (Из-за ограничений в оборудовании Apple этот принцип, тем не менее, был нарушен для операции подчеркивания).
11. Построение команд по методу "существительное-глагол". Сначала пользователь определяет, с чем он собирается работать (что дает время на проверку и при необходимости исправление), и затем применяет некоторое действие к выбранному объекту. В некоторых системах используется обратная последовательность ("глагол-существительное") или даже смешиваются оба метода, что еще хуже.
12. Другой общий принцип заключается в том, что в системе трудно что-либо испортить или стереть. Это возможно, но очень трудно. Ошибки не происходят случайно или по невнимательности пользователя.
13. Включение средств программирования и коммуникации в среду общего назначения, внутри которой выходные данные помещаются в область редактирования или поиска.
14. Необходимость учета в плане работы времени на проведение длительных (в течение нескольких месяцев) тестирований и наладки. Покупатели системы не должны использоваться в качестве субъектов тестирования.
Вышеизложенное является только упрощенным наброском (описание системы насчитывает около 50 страниц), но мы надеемся, что это даст вам некоторое представление о том, что привело нас к идее сделать систему SwiftCard такой, какая она есть.
БИБЛИОГРАФИЯ
Где-то я мог неправильно интерпретировать или понять смысл цитируемых мной работ. Заранее прошу меня извинить за любые ошибки такого рода.
- Accot, Johnny, and Shumin Zhai. "Beyond Fitts' Law: Models for Trajectory-Based HCI Tasks" (www.dgp.toronto.edu/~accot/Common/Articles/CHI97/chi.html, 1997).
- Alzofon, David, David Caulkins, Jef Raskin, and James Winter. Canon Cat How-To Guide (Tokyo: Canon, 1987).
- Alzofon, David, and Jef Raskin. SwyftCard , 2d ed. (Menlo Park, CA: Information Appliance, 1985).
- Anderson, J.R. Rules of the Mind (Hillsdale, NJ: Lawrence Erlbaum Associates, 1993).
- Apple Computer. Inside Macintosh , Vol.1 (Cupertino, CA: Apple Computer, 1985).
- Apple Computer. Human Interface Guidelines: The Apple Desktop Interface (Reading, MA: Addison-Wesley, 1987).
- Ashlar. Vellum 3D Manual (Sunnyvale, CA: Ashlar, 1995).
- Asimov, Isaac. I Robot (New York: Bantam Books, 1977).
- Baars, Bernard J. A Cognitive Theory of Consciousness (Cambridge, U.K: Cambridge University Press, 1988 ).
- Business Week. "Special Report on Information Appliances" (22 Nov. 1993), p.110.
- Buxton, William. "Chunking and Phrasing and the Design of Human-Computer Dialogs," Information Processing 86: Proceedings of the IFIP 10th World Computer Congress (Amsterdam: North-Holland, 1986).
- Card, Stuart K., Thomas P.Moran, and Allen Newell. The Psychology of Human-Computer Interaction (Hillsdale, NJ: Lawrence Erlbaum Associates, 1983).
- Cohen, Jonathan D., and Jonathan W.Schooler, eds. Scientific Approaches to Consciousness (Hillsdale, NJ: Lawrence Erlbaum Associates, 1997).
- Collins, Richard. Flying 121:10, p.67 (October 1994).
- Cooper, Alan. About Face (Foster City, CA: IDG Books Worldwide, 1995).
- Dennett, Daniel C. Consciousness Explained (Boston: Little, Brown, 1991).
- Dijksterhuis, E.J. The Mechanization of the World Picture (London: Oxford University Press, 1961).
- Drori, Offer. "The User Interface in Text Retrieval Systems," SigCHI Bulletin 30:3 (1998 ).
- Eriksson, H., and P. Magnus. UML (Unified Modeling Language) Toolkit (New York: John Wiley & Sons, 1998 ).
- Garrison, Peter. Flying 121:12, p.112 (December 1994).
- Garrison, Peter. "Drifting Off Centerline," Flying 122:1, p.43 (January 1995).
- Gray, Wayne D., Bonnie E. John, and Michael E. Atwood. "Project Ernestine: Validating a GOMS Analysis for Predicting and Explaining Real-World Task Performance," Human-Computer Interaction , 8:3, pp.237-309 (1993).
- Grudin, J. "The Case Against User Interface Consistency," Communications of the ACM , pp. 1164-1173 (1989).
- Hewlett-Packard. User Interface Design Rules for the New Wave Office System (Cupertino, CA: Hewlett-Packard Personal Software Division, 1987).
- Hotchkiss, B. "The Car Column," Pacifica Tribune , 12 Nov. 1997, p.14A.
- Horton, William. The Icon Book (New York: John Wiley, 1994).
- IBM. System Application Architecture, Common User Access, Panel Design and User Interaction (Boca Raton, FL: IBM, 1988 ).
- Jacobson, Robert, ed. Information Design (Cambridge, MA: MIT Press, 1999).
John, Bonnie E. "Why GOMS?" Interactions : pp.80-89 (October 1995).
- Johnson, J., and G.Englebeck. "Modes Survey Results," SigCHI Bulletin 20:4, pp.38-50 (1989).
- Kaplan, Justin, ed. Bartlett's Familiar Quotations , 16th ed. (Boston: Little, Brown, 1992).
- Knuth, Donald E. Literate Programming (Stanford, CA: Center for the Study of Language and Information, 1992).
- Lammers, Susan. Programmers at Work (Redmond, WA: Microsoft Press, 1986).
- Landauer, Thomas K. The Trouble with Computers (Cambridge, MA: MIT Press, 1995).
- Laurel, Brenda, ed. The Art of Human-Computer Interface Design (Reading, MA: Addison- Wesley, 1990).
- Lewis, C., and D. A. Norman. "Designing for Error," in D. Norman and S. Draper, eds... User Centered System Design (Hillsdale, NJ: Lawrence Erlbaum Associates, 1986).
- Linzmayer, Owen. Apple Confidential (San Francisco: No Starch Press, 1999).
- Loftus, Elizabeth F. Eyewitness Testimony (Cambridge, MA: Harvard University Press, 1979).
- Loftus, Elizabeth F. Memory (Reading, MA: Addison-Wesley, 1980).
- Mackenzie, I.S. "Movement Time Prediction in Human-Computer Interfaces," in R.M.Baecker, W.A.S. Buxton, J.Grudin, and S.Greenberg, eds., Readings in Human-Computer Interaction , 2d ed., pp.483-493 (Los Altos, CA: Kaufmann, 1995).
- Malone, Michael S. Infinite Loop (Chicago: Doubleday, 1999).
- Mayhew, Deborah. Principles and Guidelines in Software User Interface Design (Englewood Cliffs, NJ.: Prentice-Hall, 1992).
- Microsoft. The Windows Interface Guidelines for Software Design (Redmond, WA: Microsoft Press, 1995).
- Miller, George A. "The Magical Number Seven, Plus or Minus Two: Some Limits on Our Capacity for Processing Information," Psychological Review 63, pp.81-97 (1956).
- Moore, J.S., and R.S.Boyer. "A Fast String Searching Algorithm," Communications of the Association for Computing Machinery 20:10, pp.762-772 (1977).
- Norman, Donald A. "Categorization of Action Slips," Psychology Review 88:1, pp.1-15 (1981).
- Norman, Donald A. "Design Rules Based on Analyses of Human Error," Communications of the ACM 26:4, p.255 (1983).
- Norman, Donald A. The Psychology of Everyday Things (New York: Basic Books, 1988 ).
- Norman, Donald A. The Invisible Computer (Cambridge, MA: MIT Press, 1998 ).
- Penrose, Roger. The Emperor's New Mind (London: Oxford University Press, 1989).
- Raskin, Jef. "Looking for a Humane Interface: Will Computers Ever Become Easy to Use?" Communications of the ACM 40:2, p.98 (Feb. 1997).
- Raskin, Jef. "The Quick-Draw Graphics System." Ph.D. diss. (State College, PA: Pennsylvania State University, 1967).
- Raskin, Jef. "FLOW: A Teaching Language for Computer Programming," Computers and the Humanities 8:4 pp. (July 1974).
- Raskin, Jef. "Computers by the Millions," SIGPC Newsletter 5:2 (1982).
- Raskin, Jef. "Systemic Implications of an Improved Two-Part Cursor," Proceedings of CHI 89: Human Factors in Computing Systems, Austin: 30 April 1989, pp.167-170 (New York: ACM Press, 1989).
- Raskin, Jef. "Down with GUIs," Wired pp. (December 1993).
- Raskin, Jef. "Intuitive Equals Familiar," Communications of the ACM 37:9, pp. (September 1994).
- Raskin, Jef, and James Winter. U.S. Patent No. 5,019,806, Method and Apparatus for Control of an Electronic Display, 1991.
- Reason, James. Human Error (Cambridge, U.K.: Cambridge University Press, 1990).
- Shneiderman, Ben. Designing the User Interface (Reading, MA: Addison-Wesley, 1987, 1998 ).
- Sellen, A., G.Kurtenbach, and W.Buxton. "The Prevention of Mode Errors Through Sensory Feedback," Human Computer Interaction 7:2, pp.141-164 (1992).
- Shannon, Claude E., and Warren Weaver. The Mathematical Theory of Communication (Urbana: University of Illinois Press, 1949, reprinted 1963).
- Smith, S.F., and D.J.Duell. Clinical Nursing Skills, 3rd ed. (East Norwalk, CT: Appleton & Lange, 1992).
- Stallman, Richard. GNU Emacs Manual, 9th ed. (Cambridge, MA: Free Software Foundation, 1993).
- Tesler, Larry. "The Smalltalk Environment," Byte (August 1981).
- Tesler, Larry, and Timothy Mott. Report on the Xerox Palo Alto Research Center Gypsy Typescript System (Palo Alto, CA: Xerox, 20 April 1975).
- Thomas, Lewis. The Lives of a Cell (New York: Viking Press, 1974).
- Tognazzini, Bruce. Tog on Interface (Reading , MA: Addison-Wesley, 1992).
- Tolkien, J.R.R. (Douglas Anderson, ed.) The Annotated Hobbit (Boston: Houghton Mifflin, 1988 ).
- Tufte, Edward. The Visual Display of Quantitative Information (Cheshire, CT: Graphics Press, 1983).
- Tullis, Thomas S. "Predicting the Usability of Alphanumeric Displays," Ph.D diss., Rice University, 1984.
- de Unamuno y Jugo, Miguel. The Tragic Sense of Life , Chapter 9 (1913).
- Weinberg, Gerald M. The Psychology of Computer Programming (New York: Van Nostrand Reinhold, 1971).
Gudleifr- Admin
- Сообщения : 3244
Дата регистрации : 2017-03-29
Страница 2 из 2 • 1, 2
Страница 2 из 2
Права доступа к этому форуму:
Вы не можете отвечать на сообщения|
|
|