Comments 67
извиняюсь за отклонение от темы, но вот это вообще повсеместно актуально:
ведь куда не пойди, везде почти и в бумажных и в электронных формах нам отводят строку в пол-листа А4 под дату, но зато приходится писать адрес или отчество (или еще что-то длинное) почти на полях ;)
Ширина поля должна соответствовать объему вводимого текста
ведь куда не пойди, везде почти и в бумажных и в электронных формах нам отводят строку в пол-листа А4 под дату, но зато приходится писать адрес или отчество (или еще что-то длинное) почти на полях ;)
> В. В. Головач. «Дизайн пользовательского интерфейса»
Наличие первым в списке литературы творения отечественной версии якоба нильсена = не самая лучшая рекомендация.
и… пора бы уже выдумать новые правила. подобных вышеприведенным и без того понаписано немало.
Наличие первым в списке литературы творения отечественной версии якоба нильсена = не самая лучшая рекомендация.
и… пора бы уже выдумать новые правила. подобных вышеприведенным и без того понаписано немало.
вы предлагаете заодно выдумать новые глаза, пальцы и… и вообще новых пользователей?!
лучшего нет способа позлить всякую кармадрочерскую шушару, чем написать какую-нибудь херню в адрес якоба нильсена, головача, артемия лебедева или билла гейтса. вон сколько слюней у народа потекло :)
Microsoft видимо решила выдумать свои правила дизайна и сделала топорные прямоугольники (хабы) в своей мобильной версии. А теперь они такой же дизайн решили внедрить в windows 8. А еще в этих хабах используются обычные цвета типа green, red, а не какие-то их оттенки с более приятным контрастом.
Такое ощущение, что дизайном занимался школьник создавший свой первый html.
Но народ схавал. Им дали «нате» и они кушают. И наверняка мой коммент заминусуют. И яростно начнут доказывать, что эти прямоугольники — душа дизайна.
Такое ощущение, что дизайном занимался школьник создавший свой первый html.
Но народ схавал. Им дали «нате» и они кушают. И наверняка мой коммент заминусуют. И яростно начнут доказывать, что эти прямоугольники — душа дизайна.
Если элемент меню вызывает диалоговое окно, то к названию необходимо приписать троеточие "...".
Вы забыли: Когда в меню есть подменю, надо справа от лэйбла меню рисовать стрелочку.
Так же можно использовать какой-либо звук (например, в пасьянсах при раздаче слышен шелест карт)
А в банк-клиенте онлайн должен быть слышен шелест денег.
Как по мне, особенно важно не переделывать по-своему те элементы интерфейса, к которым пользователь привык пользуясь другими программами или операционкой. Например, очень раздражает, когда в том месте, где обычно находится кнопка «Отмена», кто-то лепит кнопку «Справка». Особенно если она таких же размеров, а рядом все так же находится кнопка «Ок».
Точно так же пользователям не нравится, когда не находит ожидаемых элементов интерфейса (во всех прогах есть, а тут — нет). Например, тот же Ctrl+S или там контекстное меню.
Точно так же пользователям не нравится, когда не находит ожидаемых элементов интерфейса (во всех прогах есть, а тут — нет). Например, тот же Ctrl+S или там контекстное меню.
Натыкался как-то в Microsoft HIG на забавные рассуждения о кнопке «ОК». В частности, очень не рекомендуется в окошках с сообщениями об ошибке помещать кнопку «OK», так как «Error is definitely not OK» :)
Признаться, не читал рассуждений на эту тему. Думаю «Ок» в данном случае можно читать как «принял к сведению». Если же рассуждать, что ошибка — это совсем не «ок», тогда давайте писать «черт» (или какое-нибудь подобное выражение). Это будет полностью соответствовать ситуации, к тому же выглядит забавно :) Можно еще писать «забить» — тоже в тему будет, к тому же это глагол в инфинитиве — все в соответствии с требованиями :)
А если серьёзно, то мне интересно, что же предлагают умные люди писать вместо «ок» и «отмена».
А если серьёзно, то мне интересно, что же предлагают умные люди писать вместо «ок» и «отмена».
Мне это напомнило пользовательский интерфейс какого-то распространённого платёжного терминала (новоплат, вроде бы). Там при выборе, нужно ли печатать чек, «да» отмечено красным цветом и находится слева, а «нет», соответственно, — зелёным и справа. К тому времени, как сообразишь, что к чему, остаёшься без чека, проклиная проектировщиков их интерфейса и желая им ампутации передних конечностей. Но на самом деле, я вижу в таком расположении злой умысел: и бумага с чернилами экономятся, и с претензиями реже к ним приходят — нет чека, нет и претензий.
>> И, главное, не надо бояться копировать успешные и эффективные решения чужих интерфейсов!
Главное до суда не докопироваться :)
Главное до суда не докопироваться :)
Автор, а вас не смущает присутствие вертикального скроллбара на картинке в разделе «Списки»?
Есть немного) Дойдут руки, заменю картинку. Хотя… Если подумать, вертикальный скроллбар — он как идентификатор, что это список. Но тоже сомнительна польза.
Кстати, не раз замечал такую штуку: после того, как в списке количество элементов превышало количество, возможное для отображения, появлялся вертикальный скроллбар и откусывал немного текста. Поэтому, помимо всего прочего, вылезал еще и горизонтальный скроллбар. И если не отображать вертикальный скроллбар заранее, то хотя бы стоит побеспокоиться о свободном месте для его появления.
Не понимаю смысл таких статей. Давно есть документы вроде Microsoft UX Guidlines, где все четко по полочкам разложено.
А почему вы уверены, что подход майкрософта к рисованию UI самый правильный?
IMHO, пора уже комитету ISO взяться за стандартизацию UI, взяв лучшие практики.
Вряд ли из этого что-то хорошее получится. Чересчур специфичная область.
Ну, это лишнее. Не забывайте, что многие интерфейсные приемы патентуются, следовательно, стандарт не будет содержать конкретики и в итоге получится просто вода.
Лучше бы крупные разработчики софта более активно работали на тем, чтобы их сообщество разработчиков совершенствовалось в этой области. Это принесло бы больше пользы.
Лучше бы крупные разработчики софта более активно работали на тем, чтобы их сообщество разработчиков совершенствовалось в этой области. Это принесло бы больше пользы.
Мне, кстати, когда пришлось нарисовать интерфейс юзера (довольно примитивный), найти неудобные, странные или двусмысленные для будущего пользователя места помог учебник по тестированию, в котором немало места было отведено под важность удобства междумордия.
Ширина поля должна соответствовать объему вводимого текста.
Вообщем-то не всегда это возможно, например если пользователь должен задать в настройках путь к некоторому файлу, то делать ширину поля равной максимальной длине путя в системе будет маразмом. Впрочем в этом случае пользователь редко его вбивает ручками
Кроме того, даже если максимальная длина текста — 10 символов, не получится сделать ширину поля равной 10 символам, так как символы имеют переменную ширину. Сравните:
шшшшшшшшшш
,,,,,,,,,,
шшшшшшшшшш
,,,,,,,,,,
Кстати, для таких полей я бы отображал только букву диска, начальную и конечную папки, а также имя файла. Все остальное — под многоточие. Это гораздо лучше, чем то, что есть сейчас. Откусывание начала или конца пути несет меньше полезной информации.
«закон Фиттса — чем больше кнопка, тем легче в нее попасть курсором»
Да уж, звучит как прям ещё один закон мироздания.Фиттс на равне Ньютоном и Ейнштейном.
Да уж, звучит как прям ещё один закон мироздания.Фиттс на равне Ньютоном и Ейнштейном.
Вообще если говорить о проектах, в которых задействовано более двух-трёх программистов, так или иначе «влияющих» на интерфейс, то вполне имеет смысл разработать некий документ, описывающий общий стиль и поведение интерфейса. Для затравки вполне можно воспользоваться гайдлайнами Микософта и Эппла, которые есть в открытом доступе, и выработать на основе их некий свой стиль. С одной стороны, не нужно переусердствовать — этот стиль не должен очень уж сильно выбиваться из общей концепции операционной системы, но, с другой стороны, должен быть вполне узнаваем и в чём-то уникален именно для Ваших продуктов. Также этот документ также сильно упрощает работу вновь прибывающих программистов. У меня есть такой документ (который, к сожалению, не имею права выложить в открытый доступ), так вот в нём более двухсот страниц с описаниями контролов, их взаимного расположения, поведения, и т. д. В любом случае имееет смысл полистать вот эти доки — там есть полезные советы:
Windows User Experience Interaction Guidelines (UX Guide)
Guidelines for Creating Mac OS X Apps
Java Look and Feel Design Guidelines
Windows User Experience Interaction Guidelines (UX Guide)
Guidelines for Creating Mac OS X Apps
Java Look and Feel Design Guidelines
Худшим вариантом является использование строки статуса в качестве подсказок при наведении на тот или иной элемент окна.
Не соглашусь. В GIMP очень удобно в строке статуса подсказки по модификаторам инструментов сделаны.
Слово комильфо это по-французски «comme il faut», что переводится как «как надо» или «как следует», и заголовок вашей статьи лишён смысла.
Решили вставить какое-то заимствованное словечко — так хоть потрудитесь узнать что оно обозначает.
Решили вставить какое-то заимствованное словечко — так хоть потрудитесь узнать что оно обозначает.
Как и в случае с чекбоксами и радиокнопками, списки ни в коем случае не должны инициировать какое-либо действие
Ну это смотря где и как. В мак ос например не так.
Ну и вообще:
Выбрал страну — логично подгрузить ее города.
Нажал на чекбокс — стали доступны дополнительные опции.
Вобщем «ни в коем случае», как-то слишком категорично.
Да и пункт «Высота списка не должна превышать 7-8 строк. Такое количество элементов легче запоминается.» тоже весьма спорный. Зачем пользователю запоминать список?
Это лишь рекомендация. Не закон :) Законов в интерфейсе нет и не будет, всегда найдутся спорные ситуации. Все дело в том, что хуже не будет, если этим рекомендациям следовать. Хотя, опять же повторюсь, на все бывает исключение.
Опять же, если в списке 10 элементов, лучше отобразить все 10 и убрать прокрутку, чем сделать 8 с прокруткой. Особенно раздражает, если часто приходится выбирать 10-й.
Кстати, для малых список, IMHO, было бы правильным прикидывать в динамике: если 1-3 элемента вызывают появление прокрутки, то увеличим размер списка на эти 1-3 элемента, а если больше — может, лучше даже уменьшить на 1-2 элемента, чтобы прокрутка выглядела обоснованнее. Для пользователя будет комфортнее (хотя видимое число элементов меньше — парадокс!)
Детальное руководство по дизайну пользовательского интерфейса Apple подходит не только для Маков, содержит массу примеров, размеры в пикселях и кнопок, и промежутков между ними, и расстояний от кнопок до границ окна, и все все все. Припадите к первоисточнику developer.apple.com/library/mac/#documentation/UserExperience/Conceptual/AppleHIGuidelines/Intro/Intro.html
«Для пользователя конечным продуктом является не программа, а интерфейс» —не совсем так. Для пользователя конечным продуктом явлется функционал приложения. Если функционал нужен и заменит программу нечем, то неудобный интерфейс будут с руганью, но терпеть. Если функционал неинтересен, то только особо уникальным и прикольным интерфейсм будут пользоваться для удовольствия, а по прямому назначению программу использовать не станут и скоро забудут.
«Для пользователя конечным продуктом явлется функционал приложения.» — не совсем так.
Человеку приложение требуется для достижения каких-то целей. И тут уже играет роль совокупность интерфейса и функционала. Все-таки работает он с интерфейсам, но для достижения своей цели использует функции приложения. И если есть баланс и человека он устраивает — все шоколадно, человек работает, цели достигаются. Если есть перекос, можно либо терпеть в отсутствие альтернативы, либо использовать другой продукт.
Человеку приложение требуется для достижения каких-то целей. И тут уже играет роль совокупность интерфейса и функционала. Все-таки работает он с интерфейсам, но для достижения своей цели использует функции приложения. И если есть баланс и человека он устраивает — все шоколадно, человек работает, цели достигаются. Если есть перекос, можно либо терпеть в отсутствие альтернативы, либо использовать другой продукт.
Уж не обессудьте, похоже на конспект гидлайнов.
Еще про кнопки в упор не согласен: большие кнопки в упор друг к другу лучше, чем более мелкие, но с промежутками.
Еще про кнопки в упор не согласен: большие кнопки в упор друг к другу лучше, чем более мелкие, но с промежутками.
Кнопки без промежутка неудобны, если нажать на одну из их требуется быстро, реагируя на какое-то событие. Когда кнопки «склеены» друг с другом на позиционирование тратится больше времени
Почему это тратится больше времени? Пруф, метрика, что-нибудь кроме наития имеется? Закон Фиттса никто не отменял, а то что мелкая кнопка якобы глазами находится быстрее (или вызывает более точное попадание), чем большая это еще доказать надо. А это, я уверен, недоказуемо.
Я не говорю о склейке мелких кнопок, я говорю о замене пробельного пространства меж кнопками на пространство самих кнопок. Промахнувшись — с вероятностью попадешь в нужную кнопку, а не в пустоту. Если-же ошибся, то вероятность ошибиться и с пробелами та-же.
Я не говорю о склейке мелких кнопок, я говорю о замене пробельного пространства меж кнопками на пространство самих кнопок. Промахнувшись — с вероятностью попадешь в нужную кнопку, а не в пустоту. Если-же ошибся, то вероятность ошибиться и с пробелами та-же.
Имеется определенный объем наблюдений.
Закон Фиттса никто не отменял. И именно из него (или его следствий, как уж правильно сказать) логично получается, что быстро выбрать из двух объектов нужный проще, если объекты разнесены в пространстве. Не придется тратить время на поиск границы между ними с тем, чтобы случайно не ошибиться.
Закон Фиттса никто не отменял. И именно из него (или его следствий, как уж правильно сказать) логично получается, что быстро выбрать из двух объектов нужный проще, если объекты разнесены в пространстве. Не придется тратить время на поиск границы между ними с тем, чтобы случайно не ошибиться.
Дело-то все в том, что объекты разнесены в пространстве и когда они склеены друг с другом, причем ровно на те же промежутки.
Вы говорите о позиционировании курсора — то есть о восприятии разнесенных кнопок как более удаленных (хотя это не так) и соответственно о более точном позиционировании. Мы как-бы лучше целимся, якобы.
Так вот, во-первых и те и те удалены одинаково, так что Фиттс применим только по размеру. А во-вторых если сравнить позиционирование мелких и крупных кнопок, но в одинаковом пространственном ритме, то это утверждение не доказано. Я считаю, что крупные кнопки позиционируются не хуже мелких, только вместо процента пустых попаданий имеется процент попаданий по кнопке, что соответственно экономит время и нервы кликающего.
Вы говорите о позиционировании курсора — то есть о восприятии разнесенных кнопок как более удаленных (хотя это не так) и соответственно о более точном позиционировании. Мы как-бы лучше целимся, якобы.
Так вот, во-первых и те и те удалены одинаково, так что Фиттс применим только по размеру. А во-вторых если сравнить позиционирование мелких и крупных кнопок, но в одинаковом пространственном ритме, то это утверждение не доказано. Я считаю, что крупные кнопки позиционируются не хуже мелких, только вместо процента пустых попаданий имеется процент попаданий по кнопке, что соответственно экономит время и нервы кликающего.
Стотыщпятьсот уже подобных статей… А заменяет их все чтение книг Раскина, Купера и гайдлайнов, на которые постоянно ссылаются в комментариях.
Почти ничего на сказано про цвета. А зря.
Стоило бы упомянуть про вредность как слишком пестрых, так и тупо черно-белых интерфейсов.
Очень правильно сказано про привычность — с привычным интерфейсом нормально нужно внедрять даже сложные в пользовании (в силу сложности задач) продукты.
В целом — полезная, но нуждающаяся в дополнениях статья.
Стоило бы упомянуть про вредность как слишком пестрых, так и тупо черно-белых интерфейсов.
Очень правильно сказано про привычность — с привычным интерфейсом нормально нужно внедрять даже сложные в пользовании (в силу сложности задач) продукты.
В целом — полезная, но нуждающаяся в дополнениях статья.
Sign up to leave a comment.
Комильфо интерфейса пользователя