Комильфо интерфейса пользователя

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

Кто ответит за дизайн?



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

Рекомендации по оформлению


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

Кнопки


Кнопки бывают нескольких видов:
  • кнопки прямого действия (командные кнопки), запускают какое-то действие;
  • кнопки доступа к меню, название говорит само за себя;
  • чекбоксы и радиокнопки, позволяют пользователю делать выбор из множества вариантов.
Другие возможные нестандартые решения так или иначе можно отнести к одному из этих трех основных видов кнопок (к примеру, umbrUI — CSS3 range slider, checkbox + radio button — нестандартная реализация стандартных кнопок). Кстати говоря, ссылка — тоже командная кнопка, но ссылки в интерфейсе программ используются гораздо реже, поэтому о них речи не будет.
Из неформального определения командной кнопки следует, что лишь по нажатию оной может быть иницировано действие, и ни в коем случае не понажатию чекбоксов или радиокнопок.

Размер:
  • На размер кнопки распространяется закон Фиттса — чем больше кнопка, тем легче в нее попасть курсором. Из этого следует, что кнопки надо делать большими. Однако это не всегда правильно, в некоторых случаях оправдано использование маленьких кнопок.
  • Помимо этого, размеры нескольких кнопок, расположенных в одном окне, должны быть равными или хотя бы пропорциональными.
Положение:
  • Нежелательно размещать кнопки впритык, лучше оставлять между ними пустой промежуток, потому как одно дело, когда пользователь промахивается мимо кнопки, и совсем другое — если, промахнувшись, он еще и ошибочно нажимает на другую кнопку.
  • Совершенно неприемлемо удалять из видимости те кнопки, на которые нажать нельзя, взамен этого их необходимо делать неактивными, иначе пользователь будет теряться («клянусь, эта кнопка только что была здесь!»).
  • В группе не должно быть менее двух радиокнопок (это очевидно, однако, бывают случаи...). Помимо этого, как минимум одна радиокнопка должна быть отмечена по умолчанию, об этом частенько забывают.
  • Желателен вертикальный порядок чекбоксов и радиокнопок, приемлемо и расположение в две-три колонки, но никак не в разноброс. Пользователь должен сразу видеть, какие кнопки к какой группе относятся.
Текст:
  • Надпись на кнопке по возможности должна быть в виде глагола в форме инфинитива (Прийти, Увидеть, Нажать) и как можно более точно отражать суть.
  • Более внимательно нужно отнестись к использованию к кнопки «ОК» и по возможности заменять «ОК» на соответствующий глагол. Об этом читаем тут: Почему кнопка «ОК» теперь считается дурным тоном в дизайне.
  • Желательно совсем отказаться от использования кнопки «Применить», особенно в наборе OK-Применить-Отмена. Такое сочетание кнопок порождает некоторые неопределенности у пользователя, не будем обсуждать какие.
  • На кнопке доступа к меню должна быть какая-нибудь индикация о том, что она именно отображает меню (самый лучший вариант — стрелочка вниз/вбок).
  • Подписи к кнопкам не должны содержать отрицание во избежание возможных заблуждений пользователя.
  • Пользователь скажет вам отдельное спасибо, если подписи к чекбоксам и радиокнопкам так же будут реагировать на нажатие.
Списки
  • Как и в случае с чекбоксами и радиокнопками, списки ни в коем случае не должны инициировать какое-либо действие, чем обычно грешат сайты с выбором города, языка и прочего, которые тут же перекидывают на другую страницу.
  • Если в списке одиночного выбора присутствует «пустой» элемент, то это не должна быть пустая строка, следует применять мета-элемент «ничего».
  • В списке множественного выбора желательно присутствие мета-элемента «все значения».
  • По возможности элементы списка должны быть каким-либо образом отсортированы, если не по типу, то хотя бы по алфавиту.
Размер:
  • Ширина списка должна быть достаточна как минимум для того, чтобы пользователь мог различить его элементы.
  • Высота списка не должна превышать 7-8 строк. Такое количество элементов легче запоминается.
Поля ввода


Размер:
  • Ширина поля должна соответствовать объему вводимого текста.
  • Так же ширина поля не должна быть больше максимальной длины строки. Если пользователь ввел в поле максимальное количество символов, и наблюдает пустое пространство, то он может подумать, что где-то ошибся, не надо вводить пользователя в заблуждение.
Текст:

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

Меню

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

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

Группировка:
  • Всегда группируйте элементы меню, не стоит бояться чрезмерного использования разделителей. Вы только поможете пользователю быстрее ориентироваться в вашем меню.
  • Группировать элементы следует максимально логично, причем исходя из логики пользователя, а не программиста.
  • Взаимоисключающие элементы желательно помещать в отдельный уровень иерархии.
Контекстное меню:
  • Контекстное меню не должно быть единственным способом вызова функций.
  • Меню желательно делать не особо длинным, 7-8 элементов.
  • В контекстном меню особенно важен порядок — первыми должны быть более релевантные элементы.
Прочее
  • Горизонтальные полосы прокрутки — это очень плохо. Пользователь их не любит.
  • В строке заголовка окна первым должно идти имя документа, а лишь затем — приложения. Ярким примером служит Microsoft Word 2003: «Microsoft Word — Document1.doc», и при большом количестве открытых окон в панели задач не будут различимы наименования документов.
  • Строку статуса необходимо использовать либо как индикатор состояния системы, либо как панель инструментов для опытных пользователей. Худшим вариантом является использование строки статуса в качестве подсказок при наведении на тот или иной элемент окна.
  • Панель инструментов нежелательно делать единственным способом вызова функций.
Отклик системы:
  • Если системой совершается длительная операция, курсор необходимо сменить на «курсор с часиками». В любом случае, пользователя необходимо уведомить, что система что-то делает, а не простаивает.
  • При более длительных операциях следует отвлечь внимание пользователя. К примеру, полосой прогресса, удивительно, но она ускоряет время. Так же можно использовать какой-либо звук (например, в пасьянсах при раздаче слышен шелест карт).
  • Когда система завершила длительную операцию, об этом нужно уведомить пользователя, например «пропищать».
И, главное, не надо бояться копировать успешные и эффективные решения чужих интерфейсов! Интуитивный интерфейс — это знакомый интерфейс. Единообразие приложений очень важно. Если пользователь, к примеру, привык сохранять документ на сочетание Ctrl+S, то не надо в своем приложении учить его новым сочетаниям клавиш.

Использованная литература


В. В. Головач. «Дизайн пользовательского интерфейса».
Джеф Раскин. «Интерфейс: новые направления в проектировании компьютерных систем».
Дженифер Тидвелл. «Разработка пользовательских интерфейсов».
Рекомендации Алана Купера и Стива Круга.
Поделиться публикацией

Похожие публикации

Комментарии 67

    +18
    извиняюсь за отклонение от темы, но вот это вообще повсеместно актуально:
    Ширина поля должна соответствовать объему вводимого текста

    ведь куда не пойди, везде почти и в бумажных и в электронных формах нам отводят строку в пол-листа А4 под дату, но зато приходится писать адрес или отчество (или еще что-то длинное) почти на полях ;)
      +1
      Да, для документов я бы вообще требовал автора заполнить созданный им шаблон реальными значениями без вылезания за форму :-)
        +1
        А так же заставить вывести этот документ на печать с заполненными полями и без искажений структуры :)
      –6
      > В. В. Головач. «Дизайн пользовательского интерфейса»
      Наличие первым в списке литературы творения отечественной версии якоба нильсена = не самая лучшая рекомендация.
      и… пора бы уже выдумать новые правила. подобных вышеприведенным и без того понаписано немало.
        +4
        вы предлагаете заодно выдумать новые глаза, пальцы и… и вообще новых пользователей?!
          0
          лучшего нет способа позлить всякую кармадрочерскую шушару, чем написать какую-нибудь херню в адрес якоба нильсена, головача, артемия лебедева или билла гейтса. вон сколько слюней у народа потекло :)
            +3
            Microsoft видимо решила выдумать свои правила дизайна и сделала топорные прямоугольники (хабы) в своей мобильной версии. А теперь они такой же дизайн решили внедрить в windows 8. А еще в этих хабах используются обычные цвета типа green, red, а не какие-то их оттенки с более приятным контрастом.
            Такое ощущение, что дизайном занимался школьник создавший свой первый html.
            Но народ схавал. Им дали «нате» и они кушают. И наверняка мой коммент заминусуют. И яростно начнут доказывать, что эти прямоугольники — душа дизайна.
              0
              А люди из Microsoft, выпустив первые прототипы, сидят сейчас за мониторами и читают такие вот мнения и еще баг-репорты коллекционируют. И решают, что перекрасить, что иначе расположить, что убрать, а что добавить :)
                0
                Нормальный рабочий процесс, так многие умные люди поступают :)
            +1
            Если элемент меню вызывает диалоговое окно, то к названию необходимо приписать троеточие "...".


            Вы забыли: Когда в меню есть подменю, надо справа от лэйбла меню рисовать стрелочку.
              +1
              В стандартных контролах эта стрелочка уже присутствует.
              +13
              Так же можно использовать какой-либо звук (например, в пасьянсах при раздаче слышен шелест карт)

              А в банк-клиенте онлайн должен быть слышен шелест денег.
                +5
                не-не-не. Надо разделять события. Поступление на расчетный счет должно сопровождаться звуком сыплющихся монет, а платежка — звуком сливного бачка.
                +4
                Как по мне, особенно важно не переделывать по-своему те элементы интерфейса, к которым пользователь привык пользуясь другими программами или операционкой. Например, очень раздражает, когда в том месте, где обычно находится кнопка «Отмена», кто-то лепит кнопку «Справка». Особенно если она таких же размеров, а рядом все так же находится кнопка «Ок».
                Точно так же пользователям не нравится, когда не находит ожидаемых элементов интерфейса (во всех прогах есть, а тут — нет). Например, тот же Ctrl+S или там контекстное меню.
                  +2
                  Натыкался как-то в Microsoft HIG на забавные рассуждения о кнопке «ОК». В частности, очень не рекомендуется в окошках с сообщениями об ошибке помещать кнопку «OK», так как «Error is definitely not OK» :)
                    0
                    Признаться, не читал рассуждений на эту тему. Думаю «Ок» в данном случае можно читать как «принял к сведению». Если же рассуждать, что ошибка — это совсем не «ок», тогда давайте писать «черт» (или какое-нибудь подобное выражение). Это будет полностью соответствовать ситуации, к тому же выглядит забавно :) Можно еще писать «забить» — тоже в тему будет, к тому же это глагол в инфинитиве — все в соответствии с требованиями :)

                    А если серьёзно, то мне интересно, что же предлагают умные люди писать вместо «ок» и «отмена».
                      +4
                      Вместо «ОК» в ошибках писать «Понять и простить»
                        +2
                        Все просто — Use «Close» instead
                          0
                          Во многих случаях лучше бы иметь кнопку Undo…
                            0
                            Вместо OK или Close в контексте сообщения об ошибке.
                      +3
                      Мне это напомнило пользовательский интерфейс какого-то распространённого платёжного терминала (новоплат, вроде бы). Там при выборе, нужно ли печатать чек, «да» отмечено красным цветом и находится слева, а «нет», соответственно, — зелёным и справа. К тому времени, как сообразишь, что к чему, остаёшься без чека, проклиная проектировщиков их интерфейса и желая им ампутации передних конечностей. Но на самом деле, я вижу в таком расположении злой умысел: и бумага с чернилами экономятся, и с претензиями реже к ним приходят — нет чека, нет и претензий.
                      0
                      >> И, главное, не надо бояться копировать успешные и эффективные решения чужих интерфейсов!
                      Главное до суда не докопироваться :)
                        0
                        Остается надеяться на разумность :)
                          0
                          Да, вот одни тут докопировались недавно :)
                          0
                          Автор, а вас не смущает присутствие вертикального скроллбара на картинке в разделе «Списки»?
                            0
                            Есть немного) Дойдут руки, заменю картинку. Хотя… Если подумать, вертикальный скроллбар — он как идентификатор, что это список. Но тоже сомнительна польза.
                              0
                              Кстати, не раз замечал такую штуку: после того, как в списке количество элементов превышало количество, возможное для отображения, появлялся вертикальный скроллбар и откусывал немного текста. Поэтому, помимо всего прочего, вылезал еще и горизонтальный скроллбар. И если не отображать вертикальный скроллбар заранее, то хотя бы стоит побеспокоиться о свободном месте для его появления.
                            –1
                            Не понимаю смысл таких статей. Давно есть документы вроде Microsoft UX Guidlines, где все четко по полочкам разложено.
                              +2
                              А почему вы уверены, что подход майкрософта к рисованию UI самый правильный?
                                0
                                IMHO, пора уже комитету ISO взяться за стандартизацию UI, взяв лучшие практики.
                                  0
                                  Вряд ли из этого что-то хорошее получится. Чересчур специфичная область.
                                    +1
                                    Ну, это лишнее. Не забывайте, что многие интерфейсные приемы патентуются, следовательно, стандарт не будет содержать конкретики и в итоге получится просто вода.
                                    Лучше бы крупные разработчики софта более активно работали на тем, чтобы их сообщество разработчиков совершенствовалось в этой области. Это принесло бы больше пользы.
                                      0
                                      Верно подметили. Разработчики должны тренироваться и набираться опыта. Потому что даже если у продукта есть аналоги, пользователь выберет именно тот, что приятней на глаз и на ощупь :)
                                  +2
                                  Мне, кстати, когда пришлось нарисовать интерфейс юзера (довольно примитивный), найти неудобные, странные или двусмысленные для будущего пользователя места помог учебник по тестированию, в котором немало места было отведено под важность удобства междумордия.
                                    0
                                    Названием книжки поделитесь, пожалуйста :)
                                      +2
                                      Да я думаю, практически любая подобная книга подойдет. В моем случае, это был «Канер, Фолк, Нгуен — Тестирование программного обеспечения»
                                    0
                                    Ширина поля должна соответствовать объему вводимого текста.

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

                                      шшшшшшшшшш
                                      ,,,,,,,,,,
                                        0
                                        Отдельная песня — системные настройки операционной системы. У меня плохое зрение, время от времени ставлю крупный размер шрифта. И начинает то тут, то там такая жесть вылазить, что без слез не взглянешь…
                                          0
                                          Для простых случаев — моноширинный шрифт в помощь.
                                          0
                                          Кстати, для таких полей я бы отображал только букву диска, начальную и конечную папки, а также имя файла. Все остальное — под многоточие. Это гораздо лучше, чем то, что есть сейчас. Откусывание начала или конца пути несет меньше полезной информации.
                                          –1
                                          «закон Фиттса — чем больше кнопка, тем легче в нее попасть курсором»

                                          Да уж, звучит как прям ещё один закон мироздания.Фиттс на равне Ньютоном и Ейнштейном.
                                            +2
                                            «Закон Фиттса (Fitt's Law)» — это устоявшийся термин. Кстати именно им объсняется тот факт, что кпопочка Start расположена в углу экрана :)
                                              0
                                              В углу? Может, по-умолчанию оно и так, но при расположении панели задач справа (очень удобно, когда привыкнешь) она уже не в углу. Со всеми вытекающими.
                                                0
                                                P.S. Поэтому кнопка «Пуск» на клавиатуре — очень большой плюс.
                                            +2
                                            Вообще если говорить о проектах, в которых задействовано более двух-трёх программистов, так или иначе «влияющих» на интерфейс, то вполне имеет смысл разработать некий документ, описывающий общий стиль и поведение интерфейса. Для затравки вполне можно воспользоваться гайдлайнами Микософта и Эппла, которые есть в открытом доступе, и выработать на основе их некий свой стиль. С одной стороны, не нужно переусердствовать — этот стиль не должен очень уж сильно выбиваться из общей концепции операционной системы, но, с другой стороны, должен быть вполне узнаваем и в чём-то уникален именно для Ваших продуктов. Также этот документ также сильно упрощает работу вновь прибывающих программистов. У меня есть такой документ (который, к сожалению, не имею права выложить в открытый доступ), так вот в нём более двухсот страниц с описаниями контролов, их взаимного расположения, поведения, и т. д. В любом случае имееет смысл полистать вот эти доки — там есть полезные советы:
                                            Windows User Experience Interaction Guidelines (UX Guide)
                                            Guidelines for Creating Mac OS X Apps
                                            Java Look and Feel Design Guidelines
                                              0
                                              Худшим вариантом является использование строки статуса в качестве подсказок при наведении на тот или иной элемент окна.

                                              Не соглашусь. В GIMP очень удобно в строке статуса подсказки по модификаторам инструментов сделаны.
                                                +1
                                                Рискую навлечь негодование, но, IMHO, подсказки лучше отображать в непосредственной близости от курсора, т.к. внимание именно на курсоре. А бегать глазами на подсказку и обратно — чисто физичестки утомительно.
                                                  0
                                                  В этом вся соль! Подсказки в строке состояния уменьшают концентрацию на объекте действия. Хотя, как видим, кому-то беготня глазами вполне по нраву :)
                                                +1
                                                Слово комильфо это по-французски «comme il faut», что переводится как «как надо» или «как следует», и заголовок вашей статьи лишён смысла.
                                                Решили вставить какое-то заимствованное словечко — так хоть потрудитесь узнать что оно обозначает.
                                                  +1
                                                  Как и в случае с чекбоксами и радиокнопками, списки ни в коем случае не должны инициировать какое-либо действие

                                                  Ну это смотря где и как. В мак ос например не так.

                                                  Ну и вообще:
                                                  Выбрал страну — логично подгрузить ее города.
                                                  Нажал на чекбокс — стали доступны дополнительные опции.
                                                  Вобщем «ни в коем случае», как-то слишком категорично.
                                                    0
                                                    Да и пункт «Высота списка не должна превышать 7-8 строк. Такое количество элементов легче запоминается.» тоже весьма спорный. Зачем пользователю запоминать список?
                                                      0
                                                      Это лишь рекомендация. Не закон :) Законов в интерфейсе нет и не будет, всегда найдутся спорные ситуации. Все дело в том, что хуже не будет, если этим рекомендациям следовать. Хотя, опять же повторюсь, на все бывает исключение.
                                                        0
                                                        Опять же, если в списке 10 элементов, лучше отобразить все 10 и убрать прокрутку, чем сделать 8 с прокруткой. Особенно раздражает, если часто приходится выбирать 10-й.
                                                          0
                                                          Кстати, для малых список, IMHO, было бы правильным прикидывать в динамике: если 1-3 элемента вызывают появление прокрутки, то увеличим размер списка на эти 1-3 элемента, а если больше — может, лучше даже уменьшить на 1-2 элемента, чтобы прокрутка выглядела обоснованнее. Для пользователя будет комфортнее (хотя видимое число элементов меньше — парадокс!)
                                                      0
                                                      Детальное руководство по дизайну пользовательского интерфейса Apple подходит не только для Маков, содержит массу примеров, размеры в пикселях и кнопок, и промежутков между ними, и расстояний от кнопок до границ окна, и все все все. Припадите к первоисточнику developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/Intro/Intro.html
                                                        +1
                                                        Я подниматель трупов, но наткнувшись не смог сдеражаться?
                                                        +1
                                                        «Для пользователя конечным продуктом является не программа, а интерфейс» —не совсем так. Для пользователя конечным продуктом явлется функционал приложения. Если функционал нужен и заменит программу нечем, то неудобный интерфейс будут с руганью, но терпеть. Если функционал неинтересен, то только особо уникальным и прикольным интерфейсм будут пользоваться для удовольствия, а по прямому назначению программу использовать не станут и скоро забудут.
                                                          0
                                                          «Для пользователя конечным продуктом явлется функционал приложения.» — не совсем так.
                                                          Человеку приложение требуется для достижения каких-то целей. И тут уже играет роль совокупность интерфейса и функционала. Все-таки работает он с интерфейсам, но для достижения своей цели использует функции приложения. И если есть баланс и человека он устраивает — все шоколадно, человек работает, цели достигаются. Если есть перекос, можно либо терпеть в отсутствие альтернативы, либо использовать другой продукт.
                                                          0
                                                          Уж не обессудьте, похоже на конспект гидлайнов.
                                                          Еще про кнопки в упор не согласен: большие кнопки в упор друг к другу лучше, чем более мелкие, но с промежутками.
                                                            0
                                                            Кнопки без промежутка неудобны, если нажать на одну из их требуется быстро, реагируя на какое-то событие. Когда кнопки «склеены» друг с другом на позиционирование тратится больше времени
                                                              0
                                                              Почему это тратится больше времени? Пруф, метрика, что-нибудь кроме наития имеется? Закон Фиттса никто не отменял, а то что мелкая кнопка якобы глазами находится быстрее (или вызывает более точное попадание), чем большая это еще доказать надо. А это, я уверен, недоказуемо.
                                                              Я не говорю о склейке мелких кнопок, я говорю о замене пробельного пространства меж кнопками на пространство самих кнопок. Промахнувшись — с вероятностью попадешь в нужную кнопку, а не в пустоту. Если-же ошибся, то вероятность ошибиться и с пробелами та-же.
                                                                0
                                                                Имеется определенный объем наблюдений.

                                                                Закон Фиттса никто не отменял. И именно из него (или его следствий, как уж правильно сказать) логично получается, что быстро выбрать из двух объектов нужный проще, если объекты разнесены в пространстве. Не придется тратить время на поиск границы между ними с тем, чтобы случайно не ошибиться.
                                                                  0
                                                                  Дело-то все в том, что объекты разнесены в пространстве и когда они склеены друг с другом, причем ровно на те же промежутки.
                                                                  Вы говорите о позиционировании курсора — то есть о восприятии разнесенных кнопок как более удаленных (хотя это не так) и соответственно о более точном позиционировании. Мы как-бы лучше целимся, якобы.
                                                                  Так вот, во-первых и те и те удалены одинаково, так что Фиттс применим только по размеру. А во-вторых если сравнить позиционирование мелких и крупных кнопок, но в одинаковом пространственном ритме, то это утверждение не доказано. Я считаю, что крупные кнопки позиционируются не хуже мелких, только вместо процента пустых попаданий имеется процент попаданий по кнопке, что соответственно экономит время и нервы кликающего.
                                                            0
                                                            Все правильно написано
                                                              0
                                                              Стотыщпятьсот уже подобных статей… А заменяет их все чтение книг Раскина, Купера и гайдлайнов, на которые постоянно ссылаются в комментариях.
                                                                +1
                                                                Почти ничего на сказано про цвета. А зря.
                                                                Стоило бы упомянуть про вредность как слишком пестрых, так и тупо черно-белых интерфейсов.
                                                                Очень правильно сказано про привычность — с привычным интерфейсом нормально нужно внедрять даже сложные в пользовании (в силу сложности задач) продукты.
                                                                В целом — полезная, но нуждающаяся в дополнениях статья.

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

                                                                Самое читаемое