23 апреля 2013 в 04:40

Тест на фиттспригодность перевод

Статье 14 лет. Но, что удивительно, перевода этой классики на Хабре нет. Значит, будет.

Итак, вы называете себя «проектировщиком интерфейсов»? Если не сможете на все вопросы ответить быстро и обоснованно — вон из профессии!

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

А если вы не знаете, что такое «закон Фиттса», просто пройдите тест, не подсматривая в ответы. Это прояснит, какими стереотипами вы руководствовались. В ответах — подробный разбор задействованных принципов, и вы можете сравнить свои стереотипы с моими ответами. И не пугайтесь плохих результатов: большинство людей, даже давно знакомых с компьютерами, в первый раз проходит тест очень плохо. Зато во второй раз ответы получаются правильные, и большинство считает эту статью самой ценной на моём сайте: одно её прочтение улучшит все интерфейсы, спроектированные в дальнейшем.

Эти вопросы предполагают, что всё экранное пространство под вашим полным контролем. Просто представьте себе, что вы главный дизайнер в Microsoft или Apple.


Вопросы



Возможно, вам захочется сначала прочитать все вопросы, чтобы ознакомиться. Как вам угодно — только не лезьте в ответы. И обязательно проговорите ответ. А если вы этого не сделали, засчитывайте ответ как неправильный. Это не тот тест, где нужно сказать: «Да, я знаю»,— и перейти на следующий вопрос.

В вопросах нет никаких закавык, всё только по делу. Но ответы могут показаться неинтуитивными и даже неверными, так что не стоит говорить: «Это очевидно».
  1. Панели инструментов Microsoft позволяют подписывать каждую кнопку. Назовите хотя бы одну причину, почему подписанная кнопка нажимается быстрее. Считаем, что пользователь знает, для чего кнопка предназначена, и подписи не нужны, чтобы опознать кнопку.
  2. К левому краю экрана прижата панель инструментов 2×8 кнопок. Каждый инструмент — иконка 16×16 пикселей. Не передвигая панель и не изменяя размер иконок, как бы вы уменьшили время доступа к «типичному» инструменту?
  3. Перед большим монитором (1600×1200) правша, курсор мыши в центре экрана (±10 пикселей). Укажите пять однопиксельных «мишеней», до которых пользователь может добраться быстрее всего. Дополнительные баллы, если перечислите их от быстродоступных до труднодоступных.
  4. Панель задач Windows располагается вдоль кромки экрана (верхней, нижней или боковой) и позволяет быстро переключиться на скрытое окно. Панель может быть спрятана (и показываться, когда курсор подходит к кромке), а может отображаться всегда. Опишите как минимум две причины, почему скрывать панель задач крайне неудобно.
  5. Объясните, почему меню Apple в пять раз быстрее, чем меню Microsoft. Дополнительные баллы — за объяснение, почему в Microsoft пришли к такому «дурацкому» решению.
  6. Укажите узкое место в многоуровневых меню. Как его можно обойти?
  7. Назовите хотя бы одну причину, почему круговые локальные меню удобнее привычных линейных.
  8. Что можно сделать с линейными меню, чтобы сбалансировать время доступа ко всем их пунктам?
  9. Промдизайнеры, которым дали полную свободу, уменьшили клавиатуру Macintosh на полкнопки, обрезав функциональные клавиши. Почему такое решение невообразимо глупое?
  10. Что общего между всеми этими вопросами?

Если вы не можете ответить на последний вопрос, вам, скорее всего, и с остальными будет тяжело. Вы не один такой: опыт говорит, что никто в Microsoft и всё меньше людей в Apple могут на эти вопросы ответить.

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

Что было в Apple — чуть менее понятно. Ошибки в промдизайне понятны: когда дело доходит до человеческого фактора, дизайнеры-аутсорсеры то недопонимают, то открыто сопротивляются. Но, начиная с недавнего времени, и внутри Apple допускают изрядные ляпы — например, превращают меню Labels в иерархическое, замедляя доступ к нему в 5–10 раз.

Ответы



Начнём с предварительного ответа на 10-й вопрос. Всё закручено вокруг закона Фиттса из «Основных принципов дизайна».

Время, необходимое, чтобы достичь цели, зависит от расстояния до цели и её размера.

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

А вы, упрямые и прозорливые читатели Хабра, теперь знаете, что такое закон Фиттса. Или, по крайней мере, узнаете, когда перед сном займётесь чтением. Закон Фиттса прост и нерушим, и не имеет исключений. Посмотрим, как он связан с нашими вопросами.

Вопрос 1. Панели инструментов Microsoft позволяют подписывать каждую кнопку. Назовите хотя бы одну причину, почему подписанная кнопка нажимается быстрее. Считаем, что пользователь знает, для чего кнопка предназначена, и подписи не нужны, чтобы опознать кнопку.

Вот два ответа, могут найтись и другие.

А. Подпись становится частью цели. А значит, цель становится больше. Чем больше цель, тем её проще достичь. Закон Фиттса.
Б. Без подписей пиктограммы инструментов расположены слишком тесно.

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

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

Кроме подписей, есть и другой способ сделать цель больше: крупные иконки. Жалок тот «умелый пользователь», который ставит иконки 4×4 и заявляет, что так работа быстрее.

Вопрос 2. К левому краю экрана прижата панель инструментов 2×8 кнопок. Каждый инструмент — иконка 16×16 пикселей. Не передвигая панель и не изменяя размер иконок, как бы вы уменьшили время доступа к «типичному» инструменту?

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

А. Расположить кнопки колонкой 1×16, чтобы все были прижаты к левому краю экрана.
Б. Убедиться, что левая колонка пикселей, у самого края, тоже активна. Никакой буферной зоны быть не должно.

Второй шаг тоже нужен, но его часто пропускают.

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

А теперь посмотрим на край экрана. Насколько глубока цель? Будь она 1 пиксель в длину, щёлкнуть её было бы очень сложно. Но край экрана для нас «бесконечно глубок»: независимо от скорости, курсор ударится в край и остановится. Поэтому попасть в мишень в двух пикселях от края сложнее, чем в мишень у самого края. Край — ваш друг, не забывайте о нём!

Вопрос 3. Перед большим монитором (1600×1200) правша, курсор мыши в центре экрана (±10 пикселей). Укажите пять однопиксельных «мишеней», до которых пользователь может добраться быстрее всего. Дополнительные баллы, если перечислите их от быстродоступных до труднодоступных.

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

Самый главный пиксель находится прямо под курсором. Этим пользуются контекстные меню, которые появляются у самого курсора. Мышь вообще никуда не надо вести, и этот пиксель — «бесконечная мишень», мимо которой просто не промахнёшься. [Статья 1999 года, у механических мышей было поменьше разрешение и побольше трение покоя.]

Остальные четыре пикселя, как ни странно, расположены на предельном удалении от курсора. Но и размер у них бесконечен в двух измерениях, так что расстояние меньше, чем кажется. Это — четыре угла экрана. Толкни мышь в любом направлении, и не промахнёшься: если толчок был достаточно сильным, курсор остановится в углу. Конечно, подразумевается правильно настроенное ускорение курсора.

Ответ на дополнительный вопрос связан с праворукостью пользователя. Для правши порядок таков.

А. Пиксель под курсором (самый простой). Щёлкни мышью, и всё.
Б. Правый нижний угол.
В. Левый верхний угол.
Г. Правый верхний угол.
Д. Левый нижний угол (самый трудный).

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

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

Теперь уже проще.

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

Вопрос 5. Объясните, почему меню Apple в пять раз быстрее, чем меню Microsoft. Дополнительные баллы — за объяснение, почему в Microsoft пришли к такому «дурацкому» решению.

Apple расположила строку меню вверху экрана, а Microsoft Sun и другие — под заголовком окна. Есть как минимум две причины этому.
А. Apple обзавелась копирайтом и патентом на такую строку меню.
Б. А все остальные решили, что меню можно расположить ближе к пользователю и этим ускорить работу.

Первый пункт много раз обсуждали армии юристов. Поговорим о втором пункте. Меню Apple намного быстрее, чем меню в окне. Почему? А потому, что оно у верхнего края экрана и поэтому имеет бесконечную высоту. В результате пользователь Macintosh может просто толкнуть мышь вверх — конечно, при условии, что курсор не выскочит наружу и не пропадёт.

«При условии», конечно, и подобные условия я иногда отрабатываю. Однажды в Apple я поставил два монитора друг на друга, со строкой меню на нижнем экране. Чтобы зайти на верхний экран, надо было пройти через строку меню.

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

Второе «преимущество», приписываемое меню в окне, в том, что пользователь всегда знает, где искать пункты, связанные с его задачей. Это глупо. Пользователь может делать с окном что угодно, и пункты меню могут меняться. К тому же, особенно у Sun, есть извращённые программы, в которых строка меню даже не в рабочем окне!

Программы Microsoft начинают в полноэкранном режиме размещать меню наверху. Как-нибудь попробуйте это в Word или Excel, это быстрее. А в Microsoft Visual Studio облажались: между кромкой и меню есть однопиксельный барьер. Хотели, как лучше, а получилось…

Вопрос 6. Укажите узкое место в многоуровневых меню. Как его можно обойти?

Узкое место — переход между меню первого и второго уровня. Сначала пользователь подводит курсор к пункту первого уровня. Затем он должен осторожно провести его — горизонтально — на подменю.

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

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

Когда я разрабатывал в 80-х алгоритм иерархических меню на Mac, я предложил буферную зону в форме сектора (<): чем дальше он ушёл вправо, тем больше допуск. Пока пользователь ведёт мышь горизонтально (с некоторой погрешностью), меню будет оставаться открытым, независимо от того, насколько медленно он действует. Отказаться от подменю тоже просто: сдвинуть мышь вверх или вниз. Конечно, иерархические меню Apple были медленнее одноуровневых из-за промежуточной «мишени», но по крайней мере я сделал их не такими тяжёлыми, как типичная видеоигра.

К сожалению, люди из NeXT, когда пришли в Apple, скопировали Windows, а не Mac. Поэтому сейчас в OSX иерархические меню такие же неудачные, как в Windows.[возможно, к 2013 году и исправили, не знаю.]

Закон Фиттса не только о размере и расстоянии; он и о количестве целей. Чем больше целей, если все они одинаковы, тем дольше действие. Иерархия автоматически добавляет одну «мишень». Трудности с доступом — ещё одну мишень, само подменю.

На классическом Mac’е в большинстве случаев даже не приходилось специально целиться в подменю. Подменю открывалось, и пользователь вёл мышь по прямой к нужному пункту. Специально в подменю целиться нужно было только если подменю большое, а нужен первый или последний пункт. Но даже тогда мышь можно провести по кривой, а не как сейчас, по ломаной линии на манер старой игрушки «Нарисуй сам»[также известна под названиями «Волшебный экран», «Etch-a-sketch»].

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

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

Когда пункты расположены по кругу, надо сдвинуть мышь на пару пикселей, чтобы попасть в нужный сектор. Меньше пробег, больше размер мишени. Хороший дизайн.

А ещё такое меню задействует нашу память на движения. Пока пунктов немного, мы приучиваемся сдвигать мышь вверх и влево для печати, вниз и вправо для отправления факса. Когда эти жесты заучены, даже меню выводить не надо — пока пользователь не замешкается, что означает: он не уверен. (Это мы выяснили в Apple в конце 1980-х годов, работая над проектом Fabrik).

Вопрос 8. Что можно сделать с линейными меню, чтобы сбалансировать время доступа ко всем их пунктам?

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

Можно ещё сделать «гравитационные дыры», притягивающие курсор, когда он близко к цели. Можно наладить барьеры: когда мышь попадает на объект, вытащить её наружу будет непросто. Но с этим надо быть осторожным; ошибёшься — получишь тяжёлый интерфейс. Можно придумать мышь, чувствительную к давлению — медленную, когда на неё давят, и быструю, когда нужно «убежать».

Читатель Виктор Замбано придумал ещё одно решение: поставить подменю по центру. Нужный пункт окажется на расстоянии не более n/2 пунктов.



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

Вопрос 9. Промдизайнеры, которым дали полную свободу, уменьшили клавиатуру Macintosh на полкнопки, обрезав функциональные клавиши. Почему такое решение невообразимо глупое?

Чем дальше цель, тем крупнее она должна быть, чтобы добираться до неё с той же скоростью. Дизайнеры не просто уменьшили цель, они уменьшили её по наиболее критичному измерению. Глупо, глупо, глупо. Им надо было загнуть клавиатуру под углом: чуть приподнял палец — и получаешь доступ к цифровым и функциональным клавишам. Глубина та же, точность и скорость выше.

Вопрос 10. Что общего между всеми этими вопросами?

Теперь вы знаете, что такое закон Фиттса, и можете применять его в повседневной разработке, будь это личная страница или новая ОС. Если кнопка «OK» из двух символов окажется маловата, добавьте пробелов в начале и в конце. Когда вы разрабатываете панель инструментов (и контролируете все нюансы ваших окон), научитесь прикреплять окна к краю экрана, пользователь доберётся до них быстрее. Если меню можно расположить у верхнего края, делайте это! Такое меню компактнее, чем куча иконок, и нужный пункт находится быстрее. А если вы работаете в Microsoft или Apple, всё-таки послушайте понимающих людей. Они есть, я разговаривал с ними. Обратитесь и вы к ним.

Я благодарен Фрэнку Лудольфу и Крэйгу Ошиме за то, что прошли тест и нашли оригинальные, но правильные ответы, которые я тоже попытался привести тут.

Если хотите больше прочитать о законе Фиттса, я рекомендую статью:
Walker, Neff and Smelcer, John (1990). «A Comparison of Selection Time from Walking and Bar Menus.» Proceedings of CHI’90, Addison-Wesley, Reading, Mass., pp. 221-225.

Сколько у вас баллов? Впрочем, неважно. Если сейчас вы можете ответить на 10 из 10 и готовы применить эти знания на практике — значит, тест пройден не зря.

От переводчика. Статья большая, от переводов я как-то отвык, и переводил долго, в течение месяца, по паре абзацев за раз. А потом были дела и поважнее, забросил почти готовую и забыл. Так вот, 5 сентября из-за особенностей клавиатуры старого ноутбука IBM неготовая статья провисела на главной странице в течение минуты. Простите уж, закон Фиттса в действии.
Перевод: Bruce Tognazzini
Mercury13 @Mercury13
карма
89,2
рейтинг 0,0
Программист на «си с крестами» и не только
Самое читаемое Дизайн

Комментарии (145)

  • +40
    Ответ на дополнительный вопрос связан с праворукостью пользователя. Для правши порядок таков.

    Б. Правый нижний угол.

    У меня рука быстрее всего едет в правый верхний угол — отталкивается от тела как бы.
    • 0
      Скорее всего вы орудуете мышью всей рукой, а не пальцами покоящейся кисти.
      • +11
        Т.е. Вам легче подгибать пальцы чем выпрямлять? (Я согласен с arvitaly)
      • 0
        Как раз двигая пальцами для движения к нижнему краю приходится «подсовывать» мышь под ладонь. Неудобно!
      • +1
        Я тоже попадаю в левый верхний намного легче. Всё потому, что двигаю мышь пальцами, а уже потом кистью, если пальцев не хватило. Но хватка у меня, видимо, такая, что на выпрямление пальцев у меня буфер больше, чем на сгибание. Скажем так, где-то на 2\3 я уже их согнул и дистанции от центра экрана до угла при 1920 разрешении уже не хватает. Именно по этой причине мне, видимо, и удобно панель задач в Windows держать сверху.

        PS: Причем из четырёх углов самый неудобный это нижний правый для меня.
    • 0
      может дело в разрешении монитора? мне на ноуте тоже проще в правый верхний перевести курсор, не двигая руку.
    • –2
      Мышцы-сгибатели всегда работают быстрее, чем мышцы-разгибатели, поэтому движение «к себе» быстрее, чем «от себя». Проверяется легко — коснитесь пальцем чего-нибудь горячего и посмотрите, в какую сторону Ваш организм постарается убрать руку. :-)
      • +8
        Может быть и быстрее… Но пример Вы привели не очень удачный :D Не долго бы выжил организм, который когда касается чего-то горячего еще сильнее в него упирается ;)))
        • –2
          Это классический пример из теории эргономики. А касаться чего-то горячего можно и на горизонтальной поверхности.

          Ну и, если тянет на эксперименты, попробуйте коснуться чего-то горячего, ограничив движение руки «к себе». «Глупый» организм все равно дернется именно в эту сторону, увы.
          • +8
            Это потому, что в дикой природе (миллионы лет назад, когда формировались все эти рефлексы) организмы будущих людей гораздо чаще попадали в ситуацию «пальцы коснулись чего-то горячего, достаточно отдёрнуть их», нежели в ситуацию «пальцы коснулись чего-то горячего, но ограничено движение руки "к себе"».
            • –5
              Бог с ней, с историей происхождения видов.
              Глупо спорить с очевидным — движение мышкой к себе (т.е. курсор вниз) быстрее, чем обратное. Другое дело, что это совершенно не принципиально в плане компьютерной эргономики:
              1. Движения мышкой — сознательные (т.е. решение принимает головной мозг, а не спинной).
              2. Скорость сознательной реакции (порядка 0.2 секунды) чуть ли не на порядок медленнее, чем скорость мышечного движения.
              Т.е., условно говоря, между 0.21с и 0.23с разница настолько ничтожная, что учитывать ее просто нет смысла.
              • +13
                Глупо спорить с очевидным — движение мышкой к себе (т.е. курсор вниз) быстрее, чем обратное.

                Глупо спорить с очевидным — когда мышку держишь пальцами и опираешься на стол подушечкой большого пальца (большой палец горизонтален), то движению мыши «на себя» сопротивляется и упомянутая подушечка («многомяс») и общая упругость ладони.

                Из такого положения «выкинуть» мышку вправо-вверх намного легче, чем «воткнуть» глубже в ладонь.
                • +1
                  Поддерживаю, пространство для движения мыши вверх свободно, а чтобы двинуть мышь вниз — надо либо сильно скрючивать пальцы, либо приподнимать кисть.
                • 0
                  Это все-таки зависит от эргономичности мыши: image
                  • 0
                    Сдаётся мне, в данном случае тянуть к себе не сгибая локоть ещё сложнее, но соглашусь: от мышки и хвата многое может поменяться.
                  • 0
                    Это больше зависит от хвата мыши ( ладонь, пальцы, коготь) больше чем от эргономичности
          • +4
            что общего между спазмами и мышью?
    • +1
      У меня тоже так — более легкие углы правый верхний и левый нижний.
      Потому как движение делаю только кистью и предплечьем (как бы круговое).
      Для движения по диагонали левый верх — правый низ уже задействовано плечо, возможно отрывается локоть от стола и т.д.
      • 0
        Простите, а как именно Вы это замеряли?
        Ну там разница реально в сотых долях секунды.
        • 0
          Разница в том, перемещаю я только кисть+предплечье или кисть+предплечье+плечо.
          Второй случай — больше мышц задействовано в перемещения более инерционной «конструкции».
        • +3
          Мне кажется, это случай, когда «быстрее != удобнее».
          Поддерживаю мысль про «легче в верхний-правый».
      • +1
        У меня так же. Туда переместить курсор мышки у меня получается исключительно пальцами.
        А вот в правый нижний угол нужно отрывать руку.
    • +2
      | Б. Правый нижний угол.
      Правша. Самый не удобный для меня угол. Пользовался пальцами.
      Просто на хватает запаса хода мышки, что бы туда долететь.
    • +3
      Поставил сейчас 600 dpi. Получилось всё почти наоборот:
      Б) Левый нижний угол. Достаточно немного повернуть мышь по часовой стрелке.
      В) Правый верхний угол. Мышь двигается туда двумя пальцами по достаточно ровной траектории.
      Г) Правый нижний угол. Мышь также двигается двумя пальцами, но попадаю менее точно, то в правый край, то в нижний, то в дату.
      Д) Левый верхний угол. Мышь тоже двигается двумя пальцами, но по сильно загнутой дуге, поэтому попадаю в левую стенку на большом расстоянии от верхнего края. Приходится либо двигать с усилием, либо докатывать.

      Видимо сказывается то, что я использую Windows и часто открываю меню «Пуск», и проводник у меня самый левый на панели задач.

      Вывод: меню надо делать справа, а кнопку «закрыть» — слева и желательно с отступом.
      • 0
        Б) Левый нижний угол. Достаточно немного повернуть мышь по часовой стрелке.

        Вы хотели сказать «против часовой»?
        По часовой если, то будет правый угол.
        • +1

          У меня датчик чуть позади центра.
          • 0
            Против часовой — это если датчик впереди центра. На моей мыши можно и против часовой, но надо двигать дальше.
            • 0
              Понял теперь о каком движении речь. Мудрено как-то. У меня при таком правый нижний угол в ладонь упирается и курсор недалеко уходит. Может разрешение у мышки маловато. Мне проще синхронно всеми пальцами мышку двинуть без ее поворота.
          • 0
            у меня вообще предплечье упирается в угол стола, поэтому мне удобнее брать мышку подушечками пальцев (1 палец упирается в левый борт, два в левый (мизинец и безымянный), указательный и срёдний уже над кнопками). Локоть т.о. находится уже ниже стола, а ладонь нависает над мышкой. Так что мышку я двигаю даже не рукой а пальцами, благодаря чему траектория скорее напоминает ломаную, а не дугу.
    • 0
      Левая сторона всегда предпочтительней, в право тяжелее. Затем идет верх, потом низ. В качестве доказательства могу привести мемуары военных летчиков, которые все как один, при необходимости разворота, заваливались на левое крыло. Ну и, в конце концов, читать мы привыкли с левого верхнего угла.
      • 0
        Слева от мышки часто впритык клавиатура, ограничивающая свободу движения.
    • +1
      Надо будет на досуге написать программу, которая замеряет время перемещения мыши из центра экрана во все углы и усредняет статистику. Пока интуитивно кажется, что вы правы
    • –1
      Это вообще самый бредовый момент в статье. Мне, например, намного легче завести мышь в левый нижний угол. После него легче всего в верхний правый, так как для этих двух движений нужно всего лишь согнуть-разогнуть руку в локтевом суставе.
      • +1
        Я это кистью делаю :) в верхний правый мне проще :)
    • 0
      Зависит не только от хвата, но и от мышки. На большой высокой мыши, которая хорошо лежит в руке правый нижний угол самый неудобный, мышь в руку упирается; левый верхний самый простой — пальцами мышь выталкивается; остальные углы — примерно одинаково запястье повернуть. С маленькой нетбучной мышкой во все углы нормально.
  • +11
    Если кнопка «OK» из двух символов окажется маловата, добавьте пробелов в начале и в конце.

    Размер кнопки, если она маленькая, нужно задать явно. Подбирать размер пробелами, наверно, не стоит.
    • +3
      Наверно, имеется в виду визуальный пробел, пустое место, а не символ пробела. А каким путём он получается — уже не важно: пробелами, отступом, фиксированным размером (это уже дело локализации, какой ширины делать кнопки) — главное, чтобы было какое-то место для нажатия.
  • +2
    Насчет функциональных клавиш на маке — немного не соглашусь: во-первых, в современных условиях они крайне редко используются, поэтому в них, вроде как, не нужно часто попадать. Нет необходимости нажимать на них вслепую, при печати десятипальцевым методом. Во-вторых, в них человек целится все-таки руками, а не мышкой, а это значительно проще. При этом они (в любом исполнении клавиатуры и при любой своей размерности) находятся на таком расстоянии, что попасть в них вслепую невозможно, поэтому человек посмотрит на клавиатуру, и попасть в клавишу не составит труда.

    То есть, если принимать во внимание баланс между частотой возникновения необходимости нажатия данных клавиш и преимуществ от уменьшения этих клавиш, то решение, видимо, оправдано.
    • +3
      При этом они (в любом исполнении клавиатуры и при любой своей размерности) находятся на таком расстоянии, что попасть в них вслепую невозможно, поэтому человек посмотрит на клавиатуру, и попасть в клавишу не составит труда
      Как раз они разделены на группы по 4 клавиши для того, чтобы ими было удобно пользоваться вслепую.
      • 0
        На момент написания оригинальной статьи они действительно были разделены на группы по 4 (сейчас — нет). Но, по-моему, с попаданием вслепую это никак не связано, т.к. тогда у человека должно быть три руки (над основной частью клавиатуры 12 функциональных клавиш). Скорее, разделение сделано, чтобы визуально было легче найти нужную группу, а уже потом лучше прицелиться в соответствующей группе.
        • 0
          Сейчас — нет? Может у вас еще стрелки прижаты к основной части клавиатуры, между Shift и Z находится \(обычно этим грешат Логитеки), а Home/End/PgUp/PgDown распределены рандомно по оставшемуся месту?
          Мой совет тогда — купить нормальную клавиатуру.

          Отдельную руку над функциональными не надо — туда просто перемещается ближняя рука, вслепую.
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        А какие команды ос висят на этих клавишах? все что я знаю контекстны для приложения, и да иногда это Explorer или браузер.
        • НЛО прилетело и опубликовало эту надпись здесь
          • +1
            Все что вы описали (кроме alt+f4, пожалуй) — контекст приложения. никто не мешает разработчику использовать эти клавиши по своему усмотрению, например дать пользователю все настроить. Visual Studio — отличный пример, когда на функциональные клавиши вынесены функции, и пользователь сам все может настроить
  • +17
    Когда я разрабатывал в 80-х алгоритм иерархических меню на Mac, я предложил буферную зону в форме сектора (<)


    Только недавно читал статью на хабре о таком меню на Амазоне, и мне показалось это инновацией, а оно вон как получается…
    • +4
      Я тоже вспомнил об этой статье ( habrahabr.ru/post/171905/ ) когда проходил тест, так что и в голову не пришло назвать это «узким местом».
      Да и вообще из текста непонятно, о каких меню идёт речь, например, в 5-м пункте я подумал о меню «Пуск» VS док и не мог понять, чем это он быстрее.
      • 0
        Док «быстрее» всё-таки тем, что там меньше пунктов.
        По умолчанию, в «Пуск» ставится много ярлыков на программу (сама программа, uninstall, мануалы и т.п.), а в Док прилетают только собственно линки на программу.
  • +6
    Прекрасная статья с точки зрения теории.
    Однако на практике выясняется, что за один рабочий день человек совершает максимум пару десятков ошибок позиционирования курсора, что дает в самом плохом случае минуту непродуктивно потраченного времени. При этом на процессы ожидания (получение почты, компиляция программы, запуск приложения, выслушивание гудков в телефоне и т.д.) тратится на пару порядков больше.
    Поэтому современная эргономика призвана в большей степени не уменьшать время попадания в цель, а снижать отрицательную эмоциональную нагрузку от ошибок. Самый простой пример: в случае запуска какого-либо длительного процесса лучше преднамеренно увеличить время, необходимое для старта (двойной щелчок вместо одинарного, запрос подтверждения), чем дать пользователю максимально быстро запустить долгий процесс ошибочно и материться после этого. :-)
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Option+ПКМ -> «Завершить принудительно» помогает мне в подобных ситуациях.
  • +15
    Вопрос 5. Объясните, почему меню Apple в пять раз быстрее, чем меню Microsoft.

    Я, конечно, не модный дизайнер, но меня меню в стиле Apple (в Unity так) раздражает очень сильно. Это, по сути, единственная вещь в Unity, которая меня бесит. Я даже к идиотскому расположению кнопок, слева на заголовке, привык. Радует только то, что меню используется крайне редко.

    А причина одна. Я вижу перед носом окно. И все, что относится к этому окну, я расчитываю найти на нем. И постоянно забываю, что модный дизайнер ухреначил меню на второй 25" монитор и меню находится почти в метре от окна (я сейчас утрирую, но все же...).

    В 99 году, на одном 15" мониторе, когда приложение почти всегда было развернуто на весь экран, это, наверно, было хорошей идеей. Но не сейчас.
    • 0
      Имхо это косяк именно Unity. В родном OSX меню более продумано и удобно, Unity до этого еще работать и работать. И что ведь характерно, все никак не могу уловить, чего же конкретно не хватает)

      > А причина одна. Я вижу перед носом окно. И все, что относится к этому окну, я расчитываю найти на нем. И постоянно забываю, что модный дизайнер ухреначил меню на второй 25" монитор и меню находится почти в метре от окна (я сейчас утрирую, но все же...).

      Ну это все-таки виндовый стереотип к принадлежности меню окну. а про меню на втором экране — лично у меня тоже 2 монитора и Ubuntu и меню работает на том экране, на котором отображается само окно.
      • 0
        «Ну это все-таки виндовый стереотип к принадлежности меню окну»
        Я бы не сказал. Я уже 4 года винду вижу только на картинках и на тестовой виртуалке иногда.

        «а про меню на втором экране...»
        Ну я же написал, что утрирую немного, хорошо хоть до этого маразма не дошли :)
        Но, тем не менее, если у вас 2.5к монитор и окошко размером 300*200 пикселей висит в правом нижнем углу экрана, искать меню в левом верхнем углу несколько нелогично, я считаю.

        Ведь по обсуждаемому «закону»:
        «Время, необходимое, чтобы достичь цели, зависит от расстояния до цели и её размера.»
        Зачем же расстояние увеличивать?
        • +1
          Видимо, из принципа, что у меню вверху экрана бесконечная высота, что нивелирует расстояние до него. Но я сам с этим не согласен. Может, после Windows, но нелогичным смотрится отрыв от приложения его функционального меню.
      • 0
        > В родном OSX меню более продумано и удобно
        Наверное OSX вы не пользовались, потому как там меню только одно и на одном мониторе. И выше описанная проблема очень сильно достает
        • 0
          Неправда ваша, пользовался в свое время, работал на Mac Pro со снежным барсом на борту. Может, характер работы был такой (аудио-постпродакшн), или (что более правдоподобно) софт был грамотно написан, но неудобств замечено не было. Да, и работать приходилось аж с 3 мониторами. Тут скорее всего дело в другом — в софте были грамотные хоткеи, и 70% работы выполнялось ими.
    • +4
      А меня сильно раздражает близость расположения меню и кнопки закрытия. Ну это ж кашмар какой то.
      За такое дизайнерм нужно руки отрывать.
      • –1
        За такое дизайнеров нужно отрывать с руками
        • 0
          Это вы так толсто троллите или серьёзно не понимаете проблемы случайно закрыть браузер после набора статьи на тысячу-другую символов, потянувшись зайти в меню, но промахнувшись?
          • –1
            На полном серьезе: во-первых, благодаря тому, что мышка упирается в верхний край экрана, в меню попасть очень просто, а в кнопку закрытия окна — тяжело, т.к. она относительно маленькая. А во-вторых, я стараюсь не писать больших текстов в браузере, для этого есть текстовые редакторы с массой полезных функций для работы с текстом, одна из которых — возможность сохранить. А кроме того, мне не очень понравился тон комментария: дизайнерам, которые создали интерфейс макоси с массой очень удобных и красивых решений, оказывается, нужно оторвать руки. Почему? — потому что кому-то не понравилось, где сделаны кнопки работы с окнами.
            • 0
              За хорошее — награждать, за плохое — руки отрывать. Одно другому не мешает =) Тем более, что вы не знаете, одни и те же это были дизайнеры или нет.
              Ну, и, опять же, логического обоснования переноса кнопки «закрыть» влево я так до сих пор и не видел. Понимаю ещё перенести остальные кнопки управления окном вдаль от [ X ], чтобы не путались, но уж положение кнопки в дальнем от всех остальных (кнопок и меню) углу, правом, на мой взгляд, самое логичное.
              • 0
                Тогда бы при раскрытии окна на полный экран кнопки оказались в системном трее, и попробуй их там найди.

                В левом же углу они ни с чем не путаются.

                Как можно вместо меню попасть в кнопку закрытия — не понимаю, ведь между ними ещё минимизация и максимизация.
                • 0
                  Не понимайте дальше, я попадал.
                  А ещё почти каждый день наблюдаю обратную картину, когда люди хотят закрыть, а попадают в меню.
      • 0
        Кстати да, бесит адски. НО! Никто не мешает переконфигачить это основное меню вправо. Или вниз. Другое дело, что в любом случае оно будет мешать тонюсенькому скроллу справа в окне. В общем нет совершенства
      • 0
        Я куда больше хочу оторвать руки тем «гениям», чьими стараниями команды «закрыть таб» и «закрыть приложение» оказались на соседних клавишах (Cmd+W и Cmd+Q).
    • 0
      «Принадлежность к окну» — вопрос по большей части привычки. А вот ситуация в Юнити, когда открыто два окна, и чтобы имея активным первое ткнуть в главное меню второго, надо сначала на него явно переключиться, ткнув в него (середина экрана), а потом уже по меню (край экрана) — очень неудобна. Еще хуже, если два монитора, и окна открыты на полный экран — тогда не переключившись даже заголовка окна и кнопок «свернуть/максимизировать/закрыть» не видно.
    • 0
      Прочитав 5-й вопрос, я подумал ровно то же. Бесит это меню на отлете при работе на двух и более мониторах. Очень неудобно.
  • +12
    По статье видно, что ей 14 лет. Сейчас некоторые пункты критически устарели из-за развития технологий, некоторые с головой выдают эппловского интерфейсщика, и, скажем так, немного спорны.
    • +5
      слишком категорично :) человек за 14 лет не сильно изменился, а правила просты как дверь, не вижу причин, почему они не работают сегодня
      • +1
        Скажем так: к тексту, который писался в эпоху широкого распространения 17-дюймовых ЭЛТ-мониторов разрешения 1024х768 (и, соответственно, полноэкранных приложений), шариковых мышей и Windows 98, в современных условиях нужно относиться критически. Ибо 24-дюйма ЖК FullHD (и, соответственно, несколько одновременно открытых окон на экране), лазерные мыши с высоким dpi, и Windows 7 с риббонами.

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

          Тач-интерфейсы, кстати, тоже подчиняются этим правилам
        • 0
          И ещё интересный момент, мне кажется, что современные смартфоны с очень большим экраном немного теряют в удобстве, тк очень сложно с ними работать одной рукой. И да, именно по этой причине tab bar в iOS удобнее аналогичного контрола в Android, только потому, что он находится внизу экрана :)
          • 0
            Современные смартфоны «для огорода» — во многом жертвы гонки мощностей. Над миллиметрами в айфоне не смеется только ленивый, но повторить пока не может никто. Один из первых лопатофонов — HTC Desire HD ругали за размер практически все. Однако, в итоге все же смирились и даже придумали достоинства.
        • 0
          Что ж вы остановились на Windows 7? Тогда уж продолжайте до Windows 8 с одним-двумя окнами метро-приложения на 24" FullHD и контекстными меню внизу экрана. В этих условиях статья уже не выглядит устаревшей.
          • 0
            Прежде всего потому, что неясно, обретут ли полноэкранные приложения в Win8 сколько-нибудь значимую популярность за пределами планшетных устройств. Пока что есть информация, что полноэкранным IE10 пользуется 5,4% от пользователей Windows 8. Которых, в свою очередь, 2% от общего числа. И тенденции к тому, чтобы таких пользователей стало существенно больше, как-то не наблюдается. Вполне вероятно, что как раз потому, что следование рекомендациям, придуманным для маленьких экранов и неточных устройств позиционирования, на современных десктопах не очень актуально.
    • 0
      Согласен, сильно чувствуется привязка для работы мышью.
      большинство ответов будет другими если Вы будет управлять не мышью а рукой/пальцем/телом.
      • 0
        капитан-очевидность с вами не согласен :) палец/рука/тело менее точны, чем движения мышью. в конце концов, многолетнее использование мышки хорошо развивает мелкую моторику. например, после 8ми лет работы с графическими редакторами, я могу идеально точно выделить любую область с точностью до пикселя. а тач интерфейсы менее требовательны к точности попадания, что полностью соотвествует закону Фиттса :)
    • +1
      Но Тоньяццини и есть эппловский интерфейсщик.
  • 0
    Спасибо за перевод. Не посоветуете ли что-нибудь подобное по touch-интерфейсам?
    • +1
      Просто поймите смысл закона Фиттса, и никакой тест на пригодность вашего UI не будет нужен :)
      • 0
        Закон Фиттса, думаю, не формулировался с оглядкой на современные мобильные интерфейсы, поэтому определенно должны быть какие-то отличия/особенности.
        • +6
          Законы Фиттса и Хика вообще никак не привязаны именно к компьютерному интерфейсу. Их можно применять к кнопкам лифта, ручкам плиты, меню микроволновки и т.д.
          • 0
            Хорошо, тогда не посоветуете ли какие-нибудь статьи/книги по touch-интерфейсам и их особенностям? Мне не нужно ничего тестировать, мне интересно почитать об этом. В духе этой статьи и статьи о выпадающем меню Амазона.
  • 0
    Так как знал закон Фиттса, то в целом ответил на тест неплохо. Хотя открыл для себя несколько полезных идей, например, про буферную зону не догадывался (хотя интуитивно, наверное, понимал).
  • –4
    Скрывающееся меню пуск на порядок удобнее обычного, так как не занимает драгоценное место на экране.
    • +1
      О да, холиварщики подтянулись. Между прочим из-за неудобства постоянно отображаемого меню, Apple даже вынуждены были придумать специальный полноэкранный режим. Так как эта гадость, называемая доком, занимает кучу места на экране, при этом практически никогда не нужна. Все переключения происходят без его использования.
      • 0
        Док можно сделать автоскрывающимся. Кстати, работает лучше, чем в «Виндоуз», т.к. в винде время от времени перестает автоматически отображаться при переводе мышки в нижнюю часть экрана. Помогает вин-кей.
        В Мак-Оси невозможно скрыть панель с меню (сверху) без полноэкранного режима. А вообще, в полноэкранке есть еще несколько плюшек помимо отсутствия панели с меню.
    • +1
      На самом деле, на мой взгляд панель в windows убога настолько, что лучше бы её вовсе не было. Начиная с XP она начала жиреть за счет экрана, а механизм отображения скрытой панели действительно обычно срабатывает тогда, когда это не нужно и не работает нормально тогда, когда ты этого хочешь. У всевозможных дока в OSX и слизанных с неё присутствует та же проблема (при том, что сам по себе элемент не сильно нужный).

      В моем понимании идеальная панель — тонкая и все свободное место на ней занимают кнопки окон (не маленькие кнопки, как на доке, а реально прямоугольники занимающие всё место), кнопка для вызова меню на панели не нужна вовсе, это действие гораздо лучше смотрится в контекстом меню, пусть даже оно и никак не относится к текущему контексту.
  • –4
    Такк вот кто виноват в рождении ублюWindows 8
  • 0
    Собственно конкретно по статье, основная идея которой это закон Фикса:
    «Время, необходимое, чтобы достичь цели, зависит от расстояния до цели и её размера.»

    Из этой фразы не понятно самое важное — как время зависит от расстояния и размера цели. Например, для меня, человека слабо связанного с интерфейсами, не очевидно, что чем больше цель — тем больше время (из статьи).
    • +1
      Вот здесь есть интерактивная демонстрация закона Фиттса: fww.few.vu.nl/hci/interactive/fitts/
    • +1
      Не стоит гадать, когда можно немного погуглить :)

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

      В одномерном случае, при котором размер объекта вдоль линии перемещения курсора обозначается как S, а дистанция от начальной позиции курсора до объекта — как D, закон Фитса формулируется следующим образом:

      image

      Время (мс) = a + b \log_2(D/S+1)

      Константы a и b устанавливаются опытным путем по параметрам производительности человека.


      Оригинал вот тут — raskin-interface.narod.ru/interface/chapter4.htm#s4.1, листаем до 4.4.1.
    • 0
      1. Спасибо всем откликнувшимся к моему комментарию, но я собственно о том, что не плохо бы в самой статье кратко объяснить этот момент.
      2. Извиняюсь за «Фикса», поздно заметил, редактировать уже не могу.
    • 0
      Наоборот. Там должна быть обратная пропорциональность.
  • –1
    Надо было этой статьей потыкать в нос разработчикам интерфейса Metro для ПК!
    • +1
      А что не так с метро на ПК? Большие плитки, в них легко попасть как пальцем, так и мышкой. Не понял сути притензии
      • 0
        В том то и дело что они черезчур большие! И страшноватые!
        • +1
          И что? По статье выйдет разве что «слишком удобно».
          • 0
            Ну в статье говорится об объективности оценки интерфейса а не о субъективном его восприятии пользователем, конечно некоторые влюбились в плиточки и не запускают по пять программ в полноэкранном режиме одновременно и не перемещаются между ними щелкая мышкой. Таким образом я боюсь как бы от многозадачности в будущих версиях этой ОС не отказались (
  • +1
    Когда-то делали одну софтину для телевизионной аппаратной, так с удивлением оказалось, что людям там было полностью наплевать на её интерфейс. Они мне объяснили, что по ходу эфира ни у кого не будет времени рассматривать иконки и пытаться тыкать их мышкой, какие бы понятные и большие они не были, в каком бы месте экрана не находились. Попросили вынести 2 десятка основных функций на хоткеи, причём (внимание!) таким образом, чтобы их было можно нажимать не глядя на клавиатуру человеку, не владеющему слепым набором (человек — спец в телевидении, а не машинистка, смотрит по ходу дела на картинку с камер, а не на клавиатуру).

    В итоге основные фичи были повешены на кнопки Esc, F1, F4/F5, F8/F9, F12, угловые CTRL, тильду (~), бекспейс, пробел, стрелки. Эти кнопки можно нажать вслепую, просто потому что рука «чувствует» их, даже если вы не владеете «слепым» набором. Получилось, по отзывам, очень удобно.
    • +1
      Кнопки Esc, F1 и т.д. — это тоже интерфейс :)
      • 0
        Минусующим. Будете спорить с определением интерфейса?
        • 0
          Вы бы мысль развили, тогда бы стало понятно, спорить с Вами или нет.

          Upd: кажись дошло со второй попытки. Вы имеет в виду, что «наплевать на интерфейс» — не совсем верно, потому что кнопки на клавиатуре — тоже «интерфейс». Да, может быть не совсем верно сказано. Я имел в виду графический интерфейс программы, т.е. то, что нарисовано в окне.
          • 0
            Вы сказали, что людям плевать на интерфейс программы. Я говорю, что клавиатура — часть интерфейса программы, просто она вынесена за пределы экрана компьютера
  • +3
    В Visual Studio 2010 всё ещё есть один пиксель в полноэкранном режиме между меню и краем экрана, та же проблема в опере, фейспалм
    • 0
      Какая проблема в Опере в полноэкранном режиме?..
      • 0
        Там вообще вкладок нет.
        • +1
          Там нет ПАНЕЛИ вкладок. Вкладки всё так же переключаются через ПКМ+скролл и Ctrl+Tab.
          Собственно, в Опере интерфейс заточен как раз на то, чтобы практически все действия можно было сделать вообще не перетаскивая мышь ни на какую фиксированную позицию — через жесты и модификаторы. Все панельки и кнопочки можно рассматривать как легаси «Для тех, кто не хочет переучиваться» + как визуальные индикаторы.
          • 0
            Я когда хочу переключать вкладки, то хочу на конкретную. Панель вкладок позволяет мышкой сделать именно это. Мотать их скроллами не хочу: они ужасно моргают и надо искать нужную — это долго.
            • 0
              Вы Оперу ни с чем не путаете? Нет там никакого «они ужасно моргают и надо искать нужную — это долго.»
              Картинка: habrastorage.org/storage2/ab0/29b/587/ab029b587acbbfec831dbf00087f7f6c.png
              • 0
                Не путаю. Вкладки всегда на экране, и в памяти уже отложилось что где находится, относительное положение. Надписи расположены в ряд и быстро считываются. На панели надо заново соображать, читать каждую строчку, искать. Мне она даже больше мешала, потому я её отключил.
      • 0
        в опере в обычном режиме
        • +1
          Это полоска для перетаскивания/активации окна — режим же не полноэкранный. Кстати, её ширина задаётся здесь: opera:config#UserPrefs|ChromeIntegrationDragAreaMaximized
          • 0
            Количество случайных перетаскиваний всё же куда больше, и всегда можно воспользоваться горячими клавишами для восстановления окна или прикрепления вправо, влево или на другой монитор.
  • 0
    >> Время, необходимое, чтобы достичь цели, зависит от расстояния до цели и её размера.

    Вопрос 3 наглядно демонстрирует, почему это неверно (или как минимум неполное утверждение). В первую очередь время зависит от расположения цели, а потом уже все остальное. В угловой пиксель я попаду быстрее всего с любого расстояния.
    • +2
      Просто там размер равен бесконечность. Так что все верно
      • 0
        Здесь дело не в размере цели, а в том, что я могу использовать другие элементы (границы экрана к примеру), чтобы быстрее достичь ее. Возьмите, скажем, кнопку в углу, но с отступом в 100 px от границ. Бесконечный размер ей сложно приписать :) но в нее я попаду все равно быстрее, чем в ту же кнопку посередине экрана, так как просто загоню курсор в угол и немного потяну его обратно.
  • +1
    > Вопрос 6. Укажите узкое место в многоуровневых меню. Как его можно обойти?

    Ответ в статье неправильный. Самый простой способ обойти узкое место — выбросить мышку и сделать меню командной строкой.

    Тогда и остальные вопросы теряют смысл, кстати. Идеальное решение.
    • 0
      Мышка выигрывает по скорости. Даже при том что клавиши нажимаются немного быстрее надо их нажать на порядок больше чем совершить действий мышкой. Исключения крайне редки.
      • +1
        Не соглашусь. Хорошая командная строка имеет не плохое автодополнение. Поэтому набрать что-нибудь вроде ink<tab> проще, чем найти мышкой меню, в нем Graphics а в нем уже Inkscape.
        • 0
          Вот только для того, чтобы начать набирать в командной строке надо перенести руку с мыши на клавиатуру. Скорость же набора одной рукой довольно низка.
          • 0
            Знаете, все с точностью наоборот — чтобы начать что-то делать мышью надо перенести на неё руку с клавиатуры. Это кстати одна из причин, по которой я полностью отказался от мыши в пользу тачпада — руки тянуть не надо, только пальцы, а с трекпоинтом вообще сказка, очень жалею, что сейчас на моей клавиатуре его нет.
            • 0
              Видимо это сильно зависит от основного интерфейса программы. Если набирать код, то да — руки на клавиатуре. Если же вы с графикой работаете, то «по умолчанию» рука на мышке.
        • 0
          Это скорее исключение. И пока вы будете набирать Ink, нажимать Tab, проверять правильность автодополнения, мышкой вполне можно успеть. И кто вам так далеко его засунул?
          • 0
            А зачем проверять правильность автодополнения? Сработает — прога запустится, не сработает — не велика проблема.

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

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

            На самом деле, это дело привычки, пока не попробуешь работать с хорошей консолью (и пока не узнаешь мелкие фишки, которые не всегда очевидны, но которыми начинаешь пользоваться на уровне рефлексов), этого не поймешь.
            • 0
              Если сработало автодополнение, то команда существует — запустится что-то другое.
              С мышкой идет последовательность: Перенести руку на мышь, открыть меню, найти взглядом нужное подменю, навести на него курсор, щелкнуть, найти нужный пункт, навести на него курсор, щелкнуть. У меня на это уйдет в около четырех секунд.
              Вы медленно работаете мышкой. При средней скорости 100 действий в минуту (наведение плюс нажатие) — это от силы пара секунд. Тем более что у меня часто используемые программы сразу в панели меню, а то и на панели задач. Меню открывается горячей клавишой. В итоге это делается вообще меньше чем за секунду.
              • 0
                Если сработало автодополнение, то команда существует — запустится что-то другое.

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

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

                Я сейчас не рассматриваю часто запускаемую программу — её лучше вообще на хоткей повесить.
                • 0
                  О том и речь, что вы выдернули какой-то отдельный придуманный случай и делаете общие выводы. При том что ещё плохо владеете мышкой.
                  • 0
                    Мне надоело с вами спорить. Почитайте Джефа Раскина, чтоли. Он хорошо обосновывает, почему командный режим, хоть он и сложнее в освоении, гораздо быстрее, чем использование мыши. В общем все сводится к тому, что при увеличении количества элементов интерфейса повышается вложенность и уменьшаются размеры, что довольно неблагоприятно влияет на скорость работы с помощью мыши. Хоткеи и хорошо продуманный командный интерфейс решают эту проблему благодаря тому, что человеку не нужно искать глазами курсор, двигать мышь и зачастую делать несколько лишних действий ради одной кнопки, любые действия в командном интерфейсе доступны здесь и сразу.
                    • 0
                      Это лишь вопрос организации интерфейса и умения работать с мышкой. Если исследования делались на основе старых шариковых мышек, то современные оптические дают большую точность управления. Да и экраны стали больше, можно разместить больше элементов управления. См. ленточный интерфейс. Исследования имеют тенденцию устаревать.

                      К тому же вы сравниваете умелого владельца клавиатуры и консоли с неумелым пользователем мыши на неудачном интерфейсе.
                      • 0
                        Не только мышки изменились, клавиатуры тоже меняются, но дело не в этом. Там чисто теоретические изыскания, все оценки проводятся на модели, и если вы уменьшите в этой модели константы, связанные с мышью, вы не измените выводов, ибо пять нажатий клавиш все равно получатся быстрее, чем десяток движений мышкой от того, что все элементы не уместились на экране (Я мог бы вставить сюда картинку Apple App | Google App | our company app, но не буду искать). Суть в том, что большинство программ имеют такое количество различных элементов интерфейса, что их просто невозможно уместить на экране все и сразу.
                        • 0
                          Не пойму о чем вы спорите. Вы забываете такое обстоятельство как время обучения. Если мы будем сравнивать людей умеющих пользоваться программой то скорость работы в командной строке может быть выше (хотя лично в моем случае, она обычно ниже).
                          А если мы возьмём человека не работавшего с данной программой или тем паче с подобными программами, то командная строка проиграет, ибо до получения результата нужно будет ещё маны покурить (а мы помним как пользователи читать любят).
                          Так что спор бессмысленный без этого аспекта.
                        • 0
                          …ибо пять нажатий клавиш все равно получатся быстрее, чем десяток движений мышкой от того, что все элементы не уместились на экране…
                          А с чего вы взяли, что узнать какие пять клавиш жать быстрее чем найти нужный пункт на экране мышкой? Вы ударяетесь в крайность, беря случай редкоиспользуемой команды, но это, скорее всего, значит некритичность скорости исполнения, и наверняка неизвестность этих клавиш. А значит, поиск нужных клавиш займёт куда большее время.
                          • 0
                            Я не ударяюсь в крайность. По закону подлости, обычно, нужно именно то, что разработчики засунули подальше. Это случается потому, что во время проектирования интерфейса нереально продумать абсолютно все кейсы использования программы, особенно если это какой-либо «универсальный» продукт. В сложном интерфейсе тоже без поллитры не разберешься и зачастую время обучения получается сопоставимым. У командных интерфейсов проблемой, скорее, является не обучение, а порог вхождения, который довольно высок.
                            • 0
                              Обычно требуется вам не значит обычно требуется всем. Надо брать репрезентативную выборку, а вы делаете выводы явно не на ней.
                              • 0
                                А сделайте мне репрезентативную выборку, чем пользуются люди в WYSIWYG редакторах, стилями или непосредственным форматированием текста и скажите, при выборе вы будете полагаться на эту выборку или на здравый смысл? Во втором случае вас ждет разочарование, ибо редактирование стилей обычно убирают куда подальше.

                                Я не говорю о всех, я говорю о людях, которые знают, чего хотят.
                                • 0
                                  Microsoft уже сделали, когда создавали ленточный интерфейс. Прочитайте про его создание. Задача в том и была, что при большом количестве пунктов обычные меню и тулбары неэффективны.
    • 0
      Чем навигационные хоткеи хуже командной строки? Если у каждого элемента видимого интерфейса будет свой хоткей, то любая навигация по меню правратится во всего лишь нажатие нескольких подряд сочетаний клавиш — не длиннее текстовой команды.
  • 0
    Ровно на эту тему есть прекрасные книги, их автор — Влад Головач. Это и «Искусство мыть слона», и «Проектирование пользовательских интерфейсов»; прочитавший их ответил бы на большую часть вопросов (я затруднился только с Mac vs PC, потому что никогда не пользовался первым)
    • 0
      А как же «The Human Interface» Джефа Раскина? Это же по сути библия построения интерфейсов.
  • +1
    Из вопроса № 5:
    Apple обзавелась копирайтом и патентом на такую строку меню.

    Canonical ещё не засужена?
    • +1
      Тссссс!

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