Joel on Software

Joel on Software Джоэл о программном обеспечении

 

Руководство по UI дизайну для программистов
Глава1
Глава2
Глава3
Глава4
Глава5
Глава6
Глава7
Глава8
Глава9

Другие статьи сайта "Joel on Software" на русском языке

Другие статьи сайта "Joel on Software" на английском языке

Адрес электронной почты автора (пожалуйста, пишите только по-английски)

 

Руководство по UI дизайну для программистов
Глава7: Как создать дизайн для людей, которым есть, чем заняться в этой жизни. Часть 2.


Автор: Джоэл Сполски
Переводчик: Наталья Лунева
Техническая поддержка и моральная помощь: Алексей Матюшкин
Редактор: Евгений Дурцев
27. 4. 2000

Когда компания Microsoft еще только делала свои первые шаги, Bruce "Tog" Tognazzini вел в журнале для разработчиков Apple колонку о дизайне интерфейсов. В ней обсуждались многие интересные проблемы UI дизайна. Колонка живет и по сей день: на его личной веб-странице, а также -- в скомпанованном виде -- в блистательных книгах Тога. Одна из них -- «Tog on Software Design» -- увлекательное и полезное введение в науку UI дизайна. (Собрание «Tog on Interface» еще лучше, но к сожалению, в печатном виде не издавалось.)

Тог придумал концепцию «панель меню высотой в километр» для того, чтобы объяснить преимущество панели меню Macintosh перед той же панелью в Windows. В Windows панель появляется внутри каждого нового окна приложения. Чтобы открыть пункт меню (например, File), нужно прицелиться и поймать мышью прямоугольничек размером полтора сантиметра на сантиметр. От пользователя требуется аккуратное и точное позиционирование стрелки мыши как по вертикали, так и по горизонтали.

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

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

Принцип панели высотой в километр достаточно известен, но, похоже, не совсем очевиден, поскольку команда разработчиков Windows 95 ухитрилась его совершенно неверно интерпретировать. Кнопку «Старт» они расположили в самом нижнем левом углу экрана, но -- почти в самом нижнем левом углу экрана. Отступ снизу составляет два пикселя, отступ слева -- тоже два пикселя. Из-за какой-то несчастной пары пикселей Microsoft «вырвал поражение из клыков победы», как образно выразился Тог, и вынудил пользователей терять больше времени на то, чтобы кликнуть по кнопке «Старт». Кнопка могла бы быть квадратным километром, абсолютно тривиально достижимым мышью. Но ради чего-то -- мне не известного -- этим пренебрегли.

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

Пользователи не в состоянии идеально контролировать движения мыши.

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

  1. Иногда приходится пользоваться не самыми оптимальными манипуляторами -- трэкболами, трэкпадами, или, если совсем не повезло, крошечными красненькими пимпочками на ThinkPad’ах, -- которые сложнее контролировать, чем обычную мышь.
  2. Иногда приходится пользоваться мышью не в самых благоприятных условиях: стол завален бумагами, мышь давно не чищена, или сама мышь -- не мышь, а клон ее, купленный за 50 рублей на рынке, который находится с курсором в натянутых отношениях.
  3. Иногда человек, сидящий за компьютером,-- новичок, моторные навыки которого еще не достаточно развиты для совершенного владения мышью.
  4. Некоторые люди никогда не смогут развить эти самые навыки, по разным причинам: с вашей программой будут работать в том числе и люди, страдающие от артрита, тремора, кистевого туннельного синдрома, инвалиды, маленькие дети или старики.
  5. Многим просто не удается дважды щелкнуть мышью, не передвинув ее при этом на пару сантиметров. В результате они часто таскают окна по экрану, хотя на самом деле просто хотели запустить приложение. Экраны их компьютеров похожи на свалку мусора, потому что в пяти случаях из десяти попытка запустить приложение заканчивается перемещением ее иконки на экране.
  6. Некоторые люди считают, что постоянное применение мыши замедляет работу. Если вы заставите их выполнять многошаговую операцию с помощью мыши, они могут почувствовать, что темп их работы снизился, и решить в итоге, что созданная вами программа медленно реагирует. К чему это приводит? Надеюсь, что вы уже знаете ответ на вопрос. Да, к чувству неудовлетворения.

 

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

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

Когда вы щелкаете по черной стрелочке, список раскрывается:

А теперь подумайте, сколько точно выверенных манипуляций мышью вам понадобится, чтобы выбрать Times New Roman, например. Сначала нужно щелкнуть мыщью по стрелочке, указывающей вниз. Затем, аккуратно перемещая квадратик управления полосы прокрутки, просматривать список до тех пор, пока не появится нужный шрифт. Многие подобные выпадающие списки бездумно разработаны таким образом, что показывают лишь два или три элемента списка. Поэтому прокручивание превращается в довольно кропотливую процедуру, особенно когда в списке десятки шрифтов. Вариантов немного: нужно либо осторожно тащить бегунок вниз по полосе прокрутки, либо постоянно щелкать мышью по нижней стрелке. Или же пытаться щелкать в пространстве между бегунком и нижней стрелкой -- что под конец, когда бегунок уже почти добрался до нижней стрелки, перестает работать. Раздражение в вас нарастает. Если вам удалось добраться до Times New Roman, нужно щелкнуть еще и по нему. Если вы промахнулись, придется начать сначала. А теперь умножьте результат на десять, если вам захотелось, чтобы каждая новая глава начиналась щеголеватой заглавной буквой, к примеру. Что вы чувствуете? Вы уже по-настоящему раздражены.

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

Обратимся к еще одной проблемной зоне «мышеведения»: поля для редактирования текста (edit boxes). Возможно, вы заметили, что в любом поле редактирования на Macintosh используется широкий, жирный, крупный шрифт под названием Chicago. Выглядит он несколько грубовато и безмерно раздражает дизанейров. Обычных дизайнеров (не путать с дизайнерами графических интерфейсов!) учат тому, что пропорциональные шрифты более элегантны, изящны, и, к тому же, легче читаются. Что верно, то верно. Только все это применимо к бумаге, а не к экрану. При редактировании текста преимущество получают моноширинный шрифты: такие узкие буквы как «l» и «i» в них более различимы, и их легче выбрать. Этот урок мне преподал шестидесятилетний человек, который в процессе usability-тестирования мучительно пытался отредактировать название своей улицы, что-то типа Fillmore Street. Мы использовали тогда шрифт Arial 8, и поле для редактирования выглядело так:

Обратите внимание, ширина букв «L» и «I» составляет буквально один пиксел. Разница между маленькими «l» и «i» тоже в один пиксел. (Аналогично: уловить разницу между прописными «RN» и «M» почти невозможно, поэтому в поле редактирования могло быть написано и Fillrnore.)

Очень немногие могут заметить, что они неправильно напечатали Flilmore, Fiilmore или Fillrnore. Заметив, они потратят прорву времени на то, чтобы с помощью мыши выбрать неверно напечатанную букву и исправить ее. Проблемы возникнут и с мигающим курсором, ширина которого два пикселя, если нужно выбрать одну букву. А теперь посмотрите, насколько легче это сделать, если используется крупный шрифт (в данном случае Courier Bold):

Да, но он занимает больше места и не выглядит стильно, скажут ваши дизайнеры. Убедите их! Подобные шрифты удобнее использовать, и это чувствуется: при наборе текста вы видите, как он приобретает форму, объем и ясность, и его гораздо легче редактировать.


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

Поэтому программисты склонны думать, например, что если приложение позволяет открывать более чем один документ, то оно должно позволять открывать бесконечное количество документов (в пределах памяти процессора), или, по меньшей мере, два в тридцать второй степени документа (единственное магическое число, которое программист способен допустить). Программист с презрением отнесется к программе, которая ограничит число открытых документов до 20. Что такое 20? Почему 20? 20 нельзя получить возведением двойки в степень!

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

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

Программисты в Nullsoft, создатели WinAmp, каким-то образом смогли избежать этой ловушки программистского мышления, в которой все остальные просидели десятилетие. У WinAmp есть замечательная функция. Когда вы, перемещая окно, оказываетесь на расстоянии нескольких пикселей от границы экрана, окно автоматически приклеивается к границе экрана. А это, скорее всего, как раз то, что вам было нужно, поскольку 0 гораздо более вероятен чем 2. (У главного окна Juno есть подобная функциональность: это единственное приложение из всех мною виденных, которое «заперто в прямоугольник» на экране так, что его нельзя перетащить за границу прямоугольника.)

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



> Глава8

В английском оригинале статья называется User Interface Design for Programmers Chapter 7: Designing for People Who Have Better Things To Do With Their Lives, Part Two  

Джоель Спольски - основатель Fog Creek Software, небольшой компании по
разработке программного обеспечения, расположенной в Нью-Йорке.
Окончил Йельский Университет, работал программистом и управляющим в
Microsoft, Viacom и Juno.


Содержимое этих страниц представляет собой мнение одного человека.
Всё содержимое Copyright ©1999-2005  by Joel Spolsky. All Rights Reserved.

FogBUGZ | CityDesk | Fog Creek Software | Joel Spolsky