Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 145
Ответ на дополнительный вопрос связан с праворукостью пользователя. Для правши порядок таков.
Б. Правый нижний угол.
У меня рука быстрее всего едет в правый верхний угол — отталкивается от тела как бы.
Б. Правый нижний угол.
У меня рука быстрее всего едет в правый верхний угол — отталкивается от тела как бы.
Скорее всего вы орудуете мышью всей рукой, а не пальцами покоящейся кисти.
Т.е. Вам легче подгибать пальцы чем выпрямлять? (Я согласен с arvitaly)
Как раз двигая пальцами для движения к нижнему краю приходится «подсовывать» мышь под ладонь. Неудобно!
Я тоже попадаю в левый верхний намного легче. Всё потому, что двигаю мышь пальцами, а уже потом кистью, если пальцев не хватило. Но хватка у меня, видимо, такая, что на выпрямление пальцев у меня буфер больше, чем на сгибание. Скажем так, где-то на 2\3 я уже их согнул и дистанции от центра экрана до угла при 1920 разрешении уже не хватает. Именно по этой причине мне, видимо, и удобно панель задач в Windows держать сверху.
PS: Причем из четырёх углов самый неудобный это нижний правый для меня.
PS: Причем из четырёх углов самый неудобный это нижний правый для меня.
может дело в разрешении монитора? мне на ноуте тоже проще в правый верхний перевести курсор, не двигая руку.
Мышцы-сгибатели всегда работают быстрее, чем мышцы-разгибатели, поэтому движение «к себе» быстрее, чем «от себя». Проверяется легко — коснитесь пальцем чего-нибудь горячего и посмотрите, в какую сторону Ваш организм постарается убрать руку. :-)
Может быть и быстрее… Но пример Вы привели не очень удачный :D Не долго бы выжил организм, который когда касается чего-то горячего еще сильнее в него упирается ;)))
Это классический пример из теории эргономики. А касаться чего-то горячего можно и на горизонтальной поверхности.
Ну и, если тянет на эксперименты, попробуйте коснуться чего-то горячего, ограничив движение руки «к себе». «Глупый» организм все равно дернется именно в эту сторону, увы.
Ну и, если тянет на эксперименты, попробуйте коснуться чего-то горячего, ограничив движение руки «к себе». «Глупый» организм все равно дернется именно в эту сторону, увы.
Это потому, что в дикой природе (миллионы лет назад, когда формировались все эти рефлексы) организмы будущих людей гораздо чаще попадали в ситуацию «пальцы коснулись чего-то горячего, достаточно отдёрнуть их», нежели в ситуацию «пальцы коснулись чего-то горячего, но ограничено движение руки "к себе"».
Бог с ней, с историей происхождения видов.
Глупо спорить с очевидным — движение мышкой к себе (т.е. курсор вниз) быстрее, чем обратное. Другое дело, что это совершенно не принципиально в плане компьютерной эргономики:
1. Движения мышкой — сознательные (т.е. решение принимает головной мозг, а не спинной).
2. Скорость сознательной реакции (порядка 0.2 секунды) чуть ли не на порядок медленнее, чем скорость мышечного движения.
Т.е., условно говоря, между 0.21с и 0.23с разница настолько ничтожная, что учитывать ее просто нет смысла.
Глупо спорить с очевидным — движение мышкой к себе (т.е. курсор вниз) быстрее, чем обратное. Другое дело, что это совершенно не принципиально в плане компьютерной эргономики:
1. Движения мышкой — сознательные (т.е. решение принимает головной мозг, а не спинной).
2. Скорость сознательной реакции (порядка 0.2 секунды) чуть ли не на порядок медленнее, чем скорость мышечного движения.
Т.е., условно говоря, между 0.21с и 0.23с разница настолько ничтожная, что учитывать ее просто нет смысла.
Глупо спорить с очевидным — движение мышкой к себе (т.е. курсор вниз) быстрее, чем обратное.
Глупо спорить с очевидным — когда мышку держишь пальцами и опираешься на стол подушечкой большого пальца (большой палец горизонтален), то движению мыши «на себя» сопротивляется и упомянутая подушечка («многомяс») и общая упругость ладони.
Из такого положения «выкинуть» мышку вправо-вверх намного легче, чем «воткнуть» глубже в ладонь.
У меня тоже так — более легкие углы правый верхний и левый нижний.
Потому как движение делаю только кистью и предплечьем (как бы круговое).
Для движения по диагонали левый верх — правый низ уже задействовано плечо, возможно отрывается локоть от стола и т.д.
Потому как движение делаю только кистью и предплечьем (как бы круговое).
Для движения по диагонали левый верх — правый низ уже задействовано плечо, возможно отрывается локоть от стола и т.д.
| Б. Правый нижний угол.
Правша. Самый не удобный для меня угол. Пользовался пальцами.
Просто на хватает запаса хода мышки, что бы туда долететь.
Правша. Самый не удобный для меня угол. Пользовался пальцами.
Просто на хватает запаса хода мышки, что бы туда долететь.
Поставил сейчас 600 dpi. Получилось всё почти наоборот:
Б) Левый нижний угол. Достаточно немного повернуть мышь по часовой стрелке.
В) Правый верхний угол. Мышь двигается туда двумя пальцами по достаточно ровной траектории.
Г) Правый нижний угол. Мышь также двигается двумя пальцами, но попадаю менее точно, то в правый край, то в нижний, то в дату.
Д) Левый верхний угол. Мышь тоже двигается двумя пальцами, но по сильно загнутой дуге, поэтому попадаю в левую стенку на большом расстоянии от верхнего края. Приходится либо двигать с усилием, либо докатывать.
Видимо сказывается то, что я использую Windows и часто открываю меню «Пуск», и проводник у меня самый левый на панели задач.
Вывод: меню надо делать справа, а кнопку «закрыть» — слева и желательно с отступом.
Б) Левый нижний угол. Достаточно немного повернуть мышь по часовой стрелке.
В) Правый верхний угол. Мышь двигается туда двумя пальцами по достаточно ровной траектории.
Г) Правый нижний угол. Мышь также двигается двумя пальцами, но попадаю менее точно, то в правый край, то в нижний, то в дату.
Д) Левый верхний угол. Мышь тоже двигается двумя пальцами, но по сильно загнутой дуге, поэтому попадаю в левую стенку на большом расстоянии от верхнего края. Приходится либо двигать с усилием, либо докатывать.
Видимо сказывается то, что я использую Windows и часто открываю меню «Пуск», и проводник у меня самый левый на панели задач.
Вывод: меню надо делать справа, а кнопку «закрыть» — слева и желательно с отступом.
Б) Левый нижний угол. Достаточно немного повернуть мышь по часовой стрелке.
Вы хотели сказать «против часовой»?
По часовой если, то будет правый угол.
У меня датчик чуть позади центра.
Против часовой — это если датчик впереди центра. На моей мыши можно и против часовой, но надо двигать дальше.
у меня вообще предплечье упирается в угол стола, поэтому мне удобнее брать мышку подушечками пальцев (1 палец упирается в левый борт, два в левый (мизинец и безымянный), указательный и срёдний уже над кнопками). Локоть т.о. находится уже ниже стола, а ладонь нависает над мышкой. Так что мышку я двигаю даже не рукой а пальцами, благодаря чему траектория скорее напоминает ломаную, а не дугу.
Левая сторона всегда предпочтительней, в право тяжелее. Затем идет верх, потом низ. В качестве доказательства могу привести мемуары военных летчиков, которые все как один, при необходимости разворота, заваливались на левое крыло. Ну и, в конце концов, читать мы привыкли с левого верхнего угла.
Надо будет на досуге написать программу, которая замеряет время перемещения мыши из центра экрана во все углы и усредняет статистику. Пока интуитивно кажется, что вы правы
Это вообще самый бредовый момент в статье. Мне, например, намного легче завести мышь в левый нижний угол. После него легче всего в верхний правый, так как для этих двух движений нужно всего лишь согнуть-разогнуть руку в локтевом суставе.
Зависит не только от хвата, но и от мышки. На большой высокой мыши, которая хорошо лежит в руке правый нижний угол самый неудобный, мышь в руку упирается; левый верхний самый простой — пальцами мышь выталкивается; остальные углы — примерно одинаково запястье повернуть. С маленькой нетбучной мышкой во все углы нормально.
Если кнопка «OK» из двух символов окажется маловата, добавьте пробелов в начале и в конце.
Размер кнопки, если она маленькая, нужно задать явно. Подбирать размер пробелами, наверно, не стоит.
Насчет функциональных клавиш на маке — немного не соглашусь: во-первых, в современных условиях они крайне редко используются, поэтому в них, вроде как, не нужно часто попадать. Нет необходимости нажимать на них вслепую, при печати десятипальцевым методом. Во-вторых, в них человек целится все-таки руками, а не мышкой, а это значительно проще. При этом они (в любом исполнении клавиатуры и при любой своей размерности) находятся на таком расстоянии, что попасть в них вслепую невозможно, поэтому человек посмотрит на клавиатуру, и попасть в клавишу не составит труда.
То есть, если принимать во внимание баланс между частотой возникновения необходимости нажатия данных клавиш и преимуществ от уменьшения этих клавиш, то решение, видимо, оправдано.
То есть, если принимать во внимание баланс между частотой возникновения необходимости нажатия данных клавиш и преимуществ от уменьшения этих клавиш, то решение, видимо, оправдано.
На момент написания оригинальной статьи они действительно были разделены на группы по 4 (сейчас — нет). Но, по-моему, с попаданием вслепую это никак не связано, т.к. тогда у человека должно быть три руки (над основной частью клавиатуры 12 функциональных клавиш). Скорее, разделение сделано, чтобы визуально было легче найти нужную группу, а уже потом лучше прицелиться в соответствующей группе.
Речь идет о маковской клавиатуре. assets.overclock.net.s3.amazonaws.com/6/65/65b6df06_vbattach175959.jpeg
А какие команды ос висят на этих клавишах? все что я знаю контекстны для приложения, и да иногда это Explorer или браузер.
Все что вы описали (кроме alt+f4, пожалуй) — контекст приложения. никто не мешает разработчику использовать эти клавиши по своему усмотрению, например дать пользователю все настроить. Visual Studio — отличный пример, когда на функциональные клавиши вынесены функции, и пользователь сам все может настроить
Когда я разрабатывал в 80-х алгоритм иерархических меню на Mac, я предложил буферную зону в форме сектора (<)
Только недавно читал статью на хабре о таком меню на Амазоне, и мне показалось это инновацией, а оно вон как получается…
Я тоже вспомнил об этой статье ( habrahabr.ru/post/171905/ ) когда проходил тест, так что и в голову не пришло назвать это «узким местом».
Да и вообще из текста непонятно, о каких меню идёт речь, например, в 5-м пункте я подумал о меню «Пуск» VS док и не мог понять, чем это он быстрее.
Да и вообще из текста непонятно, о каких меню идёт речь, например, в 5-м пункте я подумал о меню «Пуск» VS док и не мог понять, чем это он быстрее.
Прекрасная статья с точки зрения теории.
Однако на практике выясняется, что за один рабочий день человек совершает максимум пару десятков ошибок позиционирования курсора, что дает в самом плохом случае минуту непродуктивно потраченного времени. При этом на процессы ожидания (получение почты, компиляция программы, запуск приложения, выслушивание гудков в телефоне и т.д.) тратится на пару порядков больше.
Поэтому современная эргономика призвана в большей степени не уменьшать время попадания в цель, а снижать отрицательную эмоциональную нагрузку от ошибок. Самый простой пример: в случае запуска какого-либо длительного процесса лучше преднамеренно увеличить время, необходимое для старта (двойной щелчок вместо одинарного, запрос подтверждения), чем дать пользователю максимально быстро запустить долгий процесс ошибочно и материться после этого. :-)
Однако на практике выясняется, что за один рабочий день человек совершает максимум пару десятков ошибок позиционирования курсора, что дает в самом плохом случае минуту непродуктивно потраченного времени. При этом на процессы ожидания (получение почты, компиляция программы, запуск приложения, выслушивание гудков в телефоне и т.д.) тратится на пару порядков больше.
Поэтому современная эргономика призвана в большей степени не уменьшать время попадания в цель, а снижать отрицательную эмоциональную нагрузку от ошибок. Самый простой пример: в случае запуска какого-либо длительного процесса лучше преднамеренно увеличить время, необходимое для старта (двойной щелчок вместо одинарного, запрос подтверждения), чем дать пользователю максимально быстро запустить долгий процесс ошибочно и материться после этого. :-)
Вопрос 5. Объясните, почему меню Apple в пять раз быстрее, чем меню Microsoft.
Я, конечно, не модный дизайнер, но меня меню в стиле Apple (в Unity так) раздражает очень сильно. Это, по сути, единственная вещь в Unity, которая меня бесит. Я даже к идиотскому расположению кнопок, слева на заголовке, привык. Радует только то, что меню используется крайне редко.
А причина одна. Я вижу перед носом окно. И все, что относится к этому окну, я расчитываю найти на нем. И постоянно забываю, что модный дизайнер ухреначил меню на второй 25" монитор и меню находится почти в метре от окна (я сейчас утрирую, но все же...).
В 99 году, на одном 15" мониторе, когда приложение почти всегда было развернуто на весь экран, это, наверно, было хорошей идеей. Но не сейчас.
Имхо это косяк именно Unity. В родном OSX меню более продумано и удобно, Unity до этого еще работать и работать. И что ведь характерно, все никак не могу уловить, чего же конкретно не хватает)
> А причина одна. Я вижу перед носом окно. И все, что относится к этому окну, я расчитываю найти на нем. И постоянно забываю, что модный дизайнер ухреначил меню на второй 25" монитор и меню находится почти в метре от окна (я сейчас утрирую, но все же...).
Ну это все-таки виндовый стереотип к принадлежности меню окну. а про меню на втором экране — лично у меня тоже 2 монитора и Ubuntu и меню работает на том экране, на котором отображается само окно.
> А причина одна. Я вижу перед носом окно. И все, что относится к этому окну, я расчитываю найти на нем. И постоянно забываю, что модный дизайнер ухреначил меню на второй 25" монитор и меню находится почти в метре от окна (я сейчас утрирую, но все же...).
Ну это все-таки виндовый стереотип к принадлежности меню окну. а про меню на втором экране — лично у меня тоже 2 монитора и Ubuntu и меню работает на том экране, на котором отображается само окно.
«Ну это все-таки виндовый стереотип к принадлежности меню окну»
Я бы не сказал. Я уже 4 года винду вижу только на картинках и на тестовой виртуалке иногда.
«а про меню на втором экране...»
Ну я же написал, что утрирую немного, хорошо хоть до этого маразма не дошли :)
Но, тем не менее, если у вас 2.5к монитор и окошко размером 300*200 пикселей висит в правом нижнем углу экрана, искать меню в левом верхнем углу несколько нелогично, я считаю.
Ведь по обсуждаемому «закону»:
«Время, необходимое, чтобы достичь цели, зависит от расстояния до цели и её размера.»
Зачем же расстояние увеличивать?
Я бы не сказал. Я уже 4 года винду вижу только на картинках и на тестовой виртуалке иногда.
«а про меню на втором экране...»
Ну я же написал, что утрирую немного, хорошо хоть до этого маразма не дошли :)
Но, тем не менее, если у вас 2.5к монитор и окошко размером 300*200 пикселей висит в правом нижнем углу экрана, искать меню в левом верхнем углу несколько нелогично, я считаю.
Ведь по обсуждаемому «закону»:
«Время, необходимое, чтобы достичь цели, зависит от расстояния до цели и её размера.»
Зачем же расстояние увеличивать?
> В родном OSX меню более продумано и удобно
Наверное OSX вы не пользовались, потому как там меню только одно и на одном мониторе. И выше описанная проблема очень сильно достает
Наверное OSX вы не пользовались, потому как там меню только одно и на одном мониторе. И выше описанная проблема очень сильно достает
Неправда ваша, пользовался в свое время, работал на Mac Pro со снежным барсом на борту. Может, характер работы был такой (аудио-постпродакшн), или (что более правдоподобно) софт был грамотно написан, но неудобств замечено не было. Да, и работать приходилось аж с 3 мониторами. Тут скорее всего дело в другом — в софте были грамотные хоткеи, и 70% работы выполнялось ими.
А меня сильно раздражает близость расположения меню и кнопки закрытия. Ну это ж кашмар какой то.
За такое дизайнерм нужно руки отрывать.
За такое дизайнерм нужно руки отрывать.
За такое дизайнеров нужно отрывать с руками
Это вы так толсто троллите или серьёзно не понимаете проблемы случайно закрыть браузер после набора статьи на тысячу-другую символов, потянувшись зайти в меню, но промахнувшись?
На полном серьезе: во-первых, благодаря тому, что мышка упирается в верхний край экрана, в меню попасть очень просто, а в кнопку закрытия окна — тяжело, т.к. она относительно маленькая. А во-вторых, я стараюсь не писать больших текстов в браузере, для этого есть текстовые редакторы с массой полезных функций для работы с текстом, одна из которых — возможность сохранить. А кроме того, мне не очень понравился тон комментария: дизайнерам, которые создали интерфейс макоси с массой очень удобных и красивых решений, оказывается, нужно оторвать руки. Почему? — потому что кому-то не понравилось, где сделаны кнопки работы с окнами.
За хорошее — награждать, за плохое — руки отрывать. Одно другому не мешает =) Тем более, что вы не знаете, одни и те же это были дизайнеры или нет.
Ну, и, опять же, логического обоснования переноса кнопки «закрыть» влево я так до сих пор и не видел. Понимаю ещё перенести остальные кнопки управления окном вдаль от [ X ], чтобы не путались, но уж положение кнопки в дальнем от всех остальных (кнопок и меню) углу, правом, на мой взгляд, самое логичное.
Ну, и, опять же, логического обоснования переноса кнопки «закрыть» влево я так до сих пор и не видел. Понимаю ещё перенести остальные кнопки управления окном вдаль от [ X ], чтобы не путались, но уж положение кнопки в дальнем от всех остальных (кнопок и меню) углу, правом, на мой взгляд, самое логичное.
Кстати да, бесит адски. НО! Никто не мешает переконфигачить это основное меню вправо. Или вниз. Другое дело, что в любом случае оно будет мешать тонюсенькому скроллу справа в окне. В общем нет совершенства
Я куда больше хочу оторвать руки тем «гениям», чьими стараниями команды «закрыть таб» и «закрыть приложение» оказались на соседних клавишах (Cmd+W и Cmd+Q).
«Принадлежность к окну» — вопрос по большей части привычки. А вот ситуация в Юнити, когда открыто два окна, и чтобы имея активным первое ткнуть в главное меню второго, надо сначала на него явно переключиться, ткнув в него (середина экрана), а потом уже по меню (край экрана) — очень неудобна. Еще хуже, если два монитора, и окна открыты на полный экран — тогда не переключившись даже заголовка окна и кнопок «свернуть/максимизировать/закрыть» не видно.
Прочитав 5-й вопрос, я подумал ровно то же. Бесит это меню на отлете при работе на двух и более мониторах. Очень неудобно.
По статье видно, что ей 14 лет. Сейчас некоторые пункты критически устарели из-за развития технологий, некоторые с головой выдают эппловского интерфейсщика, и, скажем так, немного спорны.
слишком категорично :) человек за 14 лет не сильно изменился, а правила просты как дверь, не вижу причин, почему они не работают сегодня
Как по мне, большие мониторы и высокое разрешение как раз усложняют процесс попадания по нужным кнопкам, цели становятся меньше, а расстояния больше. Вот и появились лазерные мыши, а рибон, как раз, попытка разместить часто используемые функции как можно ближе. Вообщем, я пока что не вижу противоречий, эргономика работала задолго до появления экранных интерфейсов ;)
Тач-интерфейсы, кстати, тоже подчиняются этим правилам
Тач-интерфейсы, кстати, тоже подчиняются этим правилам
И ещё интересный момент, мне кажется, что современные смартфоны с очень большим экраном немного теряют в удобстве, тк очень сложно с ними работать одной рукой. И да, именно по этой причине tab bar в iOS удобнее аналогичного контрола в Android, только потому, что он находится внизу экрана :)
Что ж вы остановились на Windows 7? Тогда уж продолжайте до Windows 8 с одним-двумя окнами метро-приложения на 24" FullHD и контекстными меню внизу экрана. В этих условиях статья уже не выглядит устаревшей.
Согласен, сильно чувствуется привязка для работы мышью.
большинство ответов будет другими если Вы будет управлять не мышью а рукой/пальцем/телом.
большинство ответов будет другими если Вы будет управлять не мышью а рукой/пальцем/телом.
капитан-очевидность с вами не согласен :) палец/рука/тело менее точны, чем движения мышью. в конце концов, многолетнее использование мышки хорошо развивает мелкую моторику. например, после 8ми лет работы с графическими редакторами, я могу идеально точно выделить любую область с точностью до пикселя. а тач интерфейсы менее требовательны к точности попадания, что полностью соотвествует закону Фиттса :)
Но Тоньяццини и есть эппловский интерфейсщик.
Спасибо за перевод. Не посоветуете ли что-нибудь подобное по touch-интерфейсам?
Просто поймите смысл закона Фиттса, и никакой тест на пригодность вашего UI не будет нужен :)
Закон Фиттса, думаю, не формулировался с оглядкой на современные мобильные интерфейсы, поэтому определенно должны быть какие-то отличия/особенности.
Так как знал закон Фиттса, то в целом ответил на тест неплохо. Хотя открыл для себя несколько полезных идей, например, про буферную зону не догадывался (хотя интуитивно, наверное, понимал).
Скрывающееся меню пуск на порядок удобнее обычного, так как не занимает драгоценное место на экране.
О да, холиварщики подтянулись. Между прочим из-за неудобства постоянно отображаемого меню, Apple даже вынуждены были придумать специальный полноэкранный режим. Так как эта гадость, называемая доком, занимает кучу места на экране, при этом практически никогда не нужна. Все переключения происходят без его использования.
Док можно сделать автоскрывающимся. Кстати, работает лучше, чем в «Виндоуз», т.к. в винде время от времени перестает автоматически отображаться при переводе мышки в нижнюю часть экрана. Помогает вин-кей.
В Мак-Оси невозможно скрыть панель с меню (сверху) без полноэкранного режима. А вообще, в полноэкранке есть еще несколько плюшек помимо отсутствия панели с меню.
В Мак-Оси невозможно скрыть панель с меню (сверху) без полноэкранного режима. А вообще, в полноэкранке есть еще несколько плюшек помимо отсутствия панели с меню.
На самом деле, на мой взгляд панель в windows убога настолько, что лучше бы её вовсе не было. Начиная с XP она начала жиреть за счет экрана, а механизм отображения скрытой панели действительно обычно срабатывает тогда, когда это не нужно и не работает нормально тогда, когда ты этого хочешь. У всевозможных дока в OSX и слизанных с неё присутствует та же проблема (при том, что сам по себе элемент не сильно нужный).
В моем понимании идеальная панель — тонкая и все свободное место на ней занимают кнопки окон (не маленькие кнопки, как на доке, а реально прямоугольники занимающие всё место), кнопка для вызова меню на панели не нужна вовсе, это действие гораздо лучше смотрится в контекстом меню, пусть даже оно и никак не относится к текущему контексту.
В моем понимании идеальная панель — тонкая и все свободное место на ней занимают кнопки окон (не маленькие кнопки, как на доке, а реально прямоугольники занимающие всё место), кнопка для вызова меню на панели не нужна вовсе, это действие гораздо лучше смотрится в контекстом меню, пусть даже оно и никак не относится к текущему контексту.
Такк вот кто виноват в рождении ублюWindows 8
Собственно конкретно по статье, основная идея которой это закон Фикса:
«Время, необходимое, чтобы достичь цели, зависит от расстояния до цели и её размера.»
Из этой фразы не понятно самое важное — как время зависит от расстояния и размера цели. Например, для меня, человека слабо связанного с интерфейсами, не очевидно, что чем больше цель — тем больше время (из статьи).
«Время, необходимое, чтобы достичь цели, зависит от расстояния до цели и её размера.»
Из этой фразы не понятно самое важное — как время зависит от расстояния и размера цели. Например, для меня, человека слабо связанного с интерфейсами, не очевидно, что чем больше цель — тем больше время (из статьи).
Вот здесь есть интерактивная демонстрация закона Фиттса: fww.few.vu.nl/hci/interactive/fitts/
Не стоит гадать, когда можно немного погуглить :)
Оригинал вот тут — raskin-interface.narod.ru/interface/chapter4.htm#s4.1, листаем до 4.4.1.
Закон Фитса позволяет определить количественно тот факт, что чем дальше находится объект от текущей позиции курсора или чем меньше размеры этого объекта, тем больше времени потребуется пользователю для перемещения к нему курсора.
В одномерном случае, при котором размер объекта вдоль линии перемещения курсора обозначается как S, а дистанция от начальной позиции курсора до объекта — как D, закон Фитса формулируется следующим образом:
Время (мс) = a + b \log_2(D/S+1)
Константы a и b устанавливаются опытным путем по параметрам производительности человека.
Оригинал вот тут — raskin-interface.narod.ru/interface/chapter4.htm#s4.1, листаем до 4.4.1.
1. Спасибо всем откликнувшимся к моему комментарию, но я собственно о том, что не плохо бы в самой статье кратко объяснить этот момент.
2. Извиняюсь за «Фикса», поздно заметил, редактировать уже не могу.
2. Извиняюсь за «Фикса», поздно заметил, редактировать уже не могу.
Наоборот. Там должна быть обратная пропорциональность.
Надо было этой статьей потыкать в нос разработчикам интерфейса Metro для ПК!
А что не так с метро на ПК? Большие плитки, в них легко попасть как пальцем, так и мышкой. Не понял сути притензии
В том то и дело что они черезчур большие! И страшноватые!
И что? По статье выйдет разве что «слишком удобно».
Ну в статье говорится об объективности оценки интерфейса а не о субъективном его восприятии пользователем, конечно некоторые влюбились в плиточки и не запускают по пять программ в полноэкранном режиме одновременно и не перемещаются между ними щелкая мышкой. Таким образом я боюсь как бы от многозадачности в будущих версиях этой ОС не отказались (
Когда-то делали одну софтину для телевизионной аппаратной, так с удивлением оказалось, что людям там было полностью наплевать на её интерфейс. Они мне объяснили, что по ходу эфира ни у кого не будет времени рассматривать иконки и пытаться тыкать их мышкой, какие бы понятные и большие они не были, в каком бы месте экрана не находились. Попросили вынести 2 десятка основных функций на хоткеи, причём (внимание!) таким образом, чтобы их было можно нажимать не глядя на клавиатуру человеку, не владеющему слепым набором (человек — спец в телевидении, а не машинистка, смотрит по ходу дела на картинку с камер, а не на клавиатуру).
В итоге основные фичи были повешены на кнопки Esc, F1, F4/F5, F8/F9, F12, угловые CTRL, тильду (~), бекспейс, пробел, стрелки. Эти кнопки можно нажать вслепую, просто потому что рука «чувствует» их, даже если вы не владеете «слепым» набором. Получилось, по отзывам, очень удобно.
В итоге основные фичи были повешены на кнопки Esc, F1, F4/F5, F8/F9, F12, угловые CTRL, тильду (~), бекспейс, пробел, стрелки. Эти кнопки можно нажать вслепую, просто потому что рука «чувствует» их, даже если вы не владеете «слепым» набором. Получилось, по отзывам, очень удобно.
Кнопки Esc, F1 и т.д. — это тоже интерфейс :)
Минусующим. Будете спорить с определением интерфейса?
Вы бы мысль развили, тогда бы стало понятно, спорить с Вами или нет.
Upd: кажись дошло со второй попытки. Вы имеет в виду, что «наплевать на интерфейс» — не совсем верно, потому что кнопки на клавиатуре — тоже «интерфейс». Да, может быть не совсем верно сказано. Я имел в виду графический интерфейс программы, т.е. то, что нарисовано в окне.
Upd: кажись дошло со второй попытки. Вы имеет в виду, что «наплевать на интерфейс» — не совсем верно, потому что кнопки на клавиатуре — тоже «интерфейс». Да, может быть не совсем верно сказано. Я имел в виду графический интерфейс программы, т.е. то, что нарисовано в окне.
В Visual Studio 2010 всё ещё есть один пиксель в полноэкранном режиме между меню и краем экрана, та же проблема в опере, фейспалм
Какая проблема в Опере в полноэкранном режиме?..
Там нет ПАНЕЛИ вкладок. Вкладки всё так же переключаются через ПКМ+скролл и Ctrl+Tab.
Собственно, в Опере интерфейс заточен как раз на то, чтобы практически все действия можно было сделать вообще не перетаскивая мышь ни на какую фиксированную позицию — через жесты и модификаторы. Все панельки и кнопочки можно рассматривать как легаси «Для тех, кто не хочет переучиваться» + как визуальные индикаторы.
Собственно, в Опере интерфейс заточен как раз на то, чтобы практически все действия можно было сделать вообще не перетаскивая мышь ни на какую фиксированную позицию — через жесты и модификаторы. Все панельки и кнопочки можно рассматривать как легаси «Для тех, кто не хочет переучиваться» + как визуальные индикаторы.
Вы Оперу ни с чем не путаете? Нет там никакого «они ужасно моргают и надо искать нужную — это долго.»
Картинка: habrastorage.org/storage2/ab0/29b/587/ab029b587acbbfec831dbf00087f7f6c.png
Картинка: habrastorage.org/storage2/ab0/29b/587/ab029b587acbbfec831dbf00087f7f6c.png
в опере в обычном режиме
>> Время, необходимое, чтобы достичь цели, зависит от расстояния до цели и её размера.
Вопрос 3 наглядно демонстрирует, почему это неверно (или как минимум неполное утверждение). В первую очередь время зависит от расположения цели, а потом уже все остальное. В угловой пиксель я попаду быстрее всего с любого расстояния.
Вопрос 3 наглядно демонстрирует, почему это неверно (или как минимум неполное утверждение). В первую очередь время зависит от расположения цели, а потом уже все остальное. В угловой пиксель я попаду быстрее всего с любого расстояния.
Просто там размер равен бесконечность. Так что все верно
Здесь дело не в размере цели, а в том, что я могу использовать другие элементы (границы экрана к примеру), чтобы быстрее достичь ее. Возьмите, скажем, кнопку в углу, но с отступом в 100 px от границ. Бесконечный размер ей сложно приписать :) но в нее я попаду все равно быстрее, чем в ту же кнопку посередине экрана, так как просто загоню курсор в угол и немного потяну его обратно.
> Вопрос 6. Укажите узкое место в многоуровневых меню. Как его можно обойти?
Ответ в статье неправильный. Самый простой способ обойти узкое место — выбросить мышку и сделать меню командной строкой.
Тогда и остальные вопросы теряют смысл, кстати. Идеальное решение.
Ответ в статье неправильный. Самый простой способ обойти узкое место — выбросить мышку и сделать меню командной строкой.
Тогда и остальные вопросы теряют смысл, кстати. Идеальное решение.
Не соглашусь. Хорошая командная строка имеет не плохое автодополнение. Поэтому набрать что-нибудь вроде ink<tab> проще, чем найти мышкой меню, в нем Graphics а в нем уже Inkscape.
Вот только для того, чтобы начать набирать в командной строке надо перенести руку с мыши на клавиатуру. Скорость же набора одной рукой довольно низка.
Знаете, все с точностью наоборот — чтобы начать что-то делать мышью надо перенести на неё руку с клавиатуры. Это кстати одна из причин, по которой я полностью отказался от мыши в пользу тачпада — руки тянуть не надо, только пальцы, а с трекпоинтом вообще сказка, очень жалею, что сейчас на моей клавиатуре его нет.
А зачем проверять правильность автодополнения? Сработает — прога запустится, не сработает — не велика проблема.
С мышкой идет последовательность: Перенести руку на мышь, открыть меню, найти взглядом нужное подменю, навести на него курсор, щелкнуть, найти нужный пункт, навести на него курсор, щелкнуть. У меня на это уйдет в около четырех секунд.
С командной строкой Вы даже не задумаетесь об этом: хотите запустить inkscape? Вы начинаете вводить первые буквы, жмете таб и энтер, вы можете даже не глядеть, ни на клавиатуру, ни на экран. Достоинства слепого ввода в том, что не думаешь о том, как ввести то или иное слово, ты его просто вводишь. Я это делаю за полторы секунды.
На самом деле, это дело привычки, пока не попробуешь работать с хорошей консолью (и пока не узнаешь мелкие фишки, которые не всегда очевидны, но которыми начинаешь пользоваться на уровне рефлексов), этого не поймешь.
С мышкой идет последовательность: Перенести руку на мышь, открыть меню, найти взглядом нужное подменю, навести на него курсор, щелкнуть, найти нужный пункт, навести на него курсор, щелкнуть. У меня на это уйдет в около четырех секунд.
С командной строкой Вы даже не задумаетесь об этом: хотите запустить inkscape? Вы начинаете вводить первые буквы, жмете таб и энтер, вы можете даже не глядеть, ни на клавиатуру, ни на экран. Достоинства слепого ввода в том, что не думаешь о том, как ввести то или иное слово, ты его просто вводишь. Я это делаю за полторы секунды.
На самом деле, это дело привычки, пока не попробуешь работать с хорошей консолью (и пока не узнаешь мелкие фишки, которые не всегда очевидны, но которыми начинаешь пользоваться на уровне рефлексов), этого не поймешь.
Если сработало автодополнение, то команда существует — запустится что-то другое.
Это бред, чему же еще запускаться, если команда с именем программы, которую вы хотите запустить существует?
(учтите, хороший автокомплит не подставит что-либо, когда есть несколько разных вариантов, а выведет список этих вариантов и будет ждать следующего символа).
100 действий в минуту? Вы сильно загнули, я такие частые щелчки слышу только когда сосед в доту играет, осознанные действия с такой скоростью не происходят.
Я сейчас не рассматриваю часто запускаемую программу — её лучше вообще на хоткей повесить.
Мне надоело с вами спорить. Почитайте Джефа Раскина, чтоли. Он хорошо обосновывает, почему командный режим, хоть он и сложнее в освоении, гораздо быстрее, чем использование мыши. В общем все сводится к тому, что при увеличении количества элементов интерфейса повышается вложенность и уменьшаются размеры, что довольно неблагоприятно влияет на скорость работы с помощью мыши. Хоткеи и хорошо продуманный командный интерфейс решают эту проблему благодаря тому, что человеку не нужно искать глазами курсор, двигать мышь и зачастую делать несколько лишних действий ради одной кнопки, любые действия в командном интерфейсе доступны здесь и сразу.
Не только мышки изменились, клавиатуры тоже меняются, но дело не в этом. Там чисто теоретические изыскания, все оценки проводятся на модели, и если вы уменьшите в этой модели константы, связанные с мышью, вы не измените выводов, ибо пять нажатий клавиш все равно получатся быстрее, чем десяток движений мышкой от того, что все элементы не уместились на экране (Я мог бы вставить сюда картинку Apple App | Google App | our company app, но не буду искать). Суть в том, что большинство программ имеют такое количество различных элементов интерфейса, что их просто невозможно уместить на экране все и сразу.
Не пойму о чем вы спорите. Вы забываете такое обстоятельство как время обучения. Если мы будем сравнивать людей умеющих пользоваться программой то скорость работы в командной строке может быть выше (хотя лично в моем случае, она обычно ниже).
А если мы возьмём человека не работавшего с данной программой или тем паче с подобными программами, то командная строка проиграет, ибо до получения результата нужно будет ещё маны покурить (а мы помним как пользователи читать любят).
Так что спор бессмысленный без этого аспекта.
А если мы возьмём человека не работавшего с данной программой или тем паче с подобными программами, то командная строка проиграет, ибо до получения результата нужно будет ещё маны покурить (а мы помним как пользователи читать любят).
Так что спор бессмысленный без этого аспекта.
Я не ударяюсь в крайность. По закону подлости, обычно, нужно именно то, что разработчики засунули подальше. Это случается потому, что во время проектирования интерфейса нереально продумать абсолютно все кейсы использования программы, особенно если это какой-либо «универсальный» продукт. В сложном интерфейсе тоже без поллитры не разберешься и зачастую время обучения получается сопоставимым. У командных интерфейсов проблемой, скорее, является не обучение, а порог вхождения, который довольно высок.
А сделайте мне репрезентативную выборку, чем пользуются люди в WYSIWYG редакторах, стилями или непосредственным форматированием текста и скажите, при выборе вы будете полагаться на эту выборку или на здравый смысл? Во втором случае вас ждет разочарование, ибо редактирование стилей обычно убирают куда подальше.
Я не говорю о всех, я говорю о людях, которые знают, чего хотят.
Я не говорю о всех, я говорю о людях, которые знают, чего хотят.
Чем навигационные хоткеи хуже командной строки? Если у каждого элемента видимого интерфейса будет свой хоткей, то любая навигация по меню правратится во всего лишь нажатие нескольких подряд сочетаний клавиш — не длиннее текстовой команды.
Ровно на эту тему есть прекрасные книги, их автор — Влад Головач. Это и «Искусство мыть слона», и «Проектирование пользовательских интерфейсов»; прочитавший их ответил бы на большую часть вопросов (я затруднился только с Mac vs PC, потому что никогда не пользовался первым)
Из вопроса № 5:
Canonical ещё не засужена?
Apple обзавелась копирайтом и патентом на такую строку меню.
Canonical ещё не засужена?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Тест на фиттспригодность