Comments 42
У вас отсутствует 6 пунт.
Еще одно правило, на этот раз про веб: если пользователь может захотеть узнать больше о какой-то части текста — эта часть текста должна быть ссылкой. На примере вашего поста:
1. «Мне нравится определение Джефа Раскина (дизайнера, работавшего в тч над легендарным Apple II и написавшего культовую среди дизайнеров книжку “Интерфейс”)» — нужна ссылка на книгу и ссылка на информацию об авторе. Также, опционально, на информацию об Apple II.
2. «Люк Вроблевски (Luc Wroblevski) написал об этом отдельную книгу.» — аналогично.
3. «Дизайнер Алан Купер, например, перечисляет 9 разных способов.» — кто такой, где перечисляет?
1. «Мне нравится определение Джефа Раскина (дизайнера, работавшего в тч над легендарным Apple II и написавшего культовую среди дизайнеров книжку “Интерфейс”)» — нужна ссылка на книгу и ссылка на информацию об авторе. Также, опционально, на информацию об Apple II.
2. «Люк Вроблевски (Luc Wroblevski) написал об этом отдельную книгу.» — аналогично.
3. «Дизайнер Алан Купер, например, перечисляет 9 разных способов.» — кто такой, где перечисляет?
Как раз интересовала данная тема. Спасибо за список книг! :)
Клавиатуру к интерфейсу приложения нынче не подключают уже?
Согласен, обожаю хотекеи.
Мышку и пальцы тоже тогда уж
Я специально говорю больше про общий подход, чем про частности. Потому что хороший интерфейс можно создать и без кучи специальных дизайнерских знаний (сейчас меня коллеги закидают), а просто на основании здравого смысла и хорошего понимания кейсов
Я специально говорю больше про общий подход, чем про частности. Потому что хороший интерфейс можно создать и без кучи специальных дизайнерских знаний (сейчас меня коллеги закидают), а просто на основании здравого смысла и хорошего понимания кейсов
Спасибо за ссылки на книги.
Спасибо за хорошую статью и ссылки на книги.
UFO just landed and posted this here
Запнулся на пункте с примером Google Docs. Я могу ошибаться, но такое ощущение, что с GD люди разбираются быстрее потому, что имеют опыт работы с MS Office, т.к. интерфейс довольно схож с точки зрения используемых операций. То есть, пример, на мой взгляд, не удачный.
p.s. Но спасибо за статью.
p.s. Но спасибо за статью.
Шаблоны проектирования для дизайнеров интерфейса :)
Убирайте лишние клики
как показывает практика, и многие исследования (например вот тут (http://sixrevisions.com/usabilityaccessibility/10-usability-tips-based-on-research-studies)
Не стоит гнаться за количеством кликов. Лучше обратить внимание на удобство пользования.
Лучше я сделаю 20 кликов, но буду понимать, что происходит, чем буду пытаться вникнуть в экран который «оптимизировали» под 3 клика.
Формы, ошибки, обратная связь
тот же упомянутый Люк Вроблевски настаивает на том, что ошибку лучше предотвратить, чем переполнять приложение алертами об ошибках.
И сравнение Google Docs и MS Office, на мой взгляд неверное. В блокноте windows еще проще разобраться =)) но у всех этих приложений разное предназначение.
Например, сделайте список из радиобаттонов вместо комбобокса (если позволяет место), это сократит один клик.
Это может быть вредный совет. Бездумно гоняясь за минимизацией кликов можно сделать еще более неудобный интерфейс. Например, если поля ввода чередуются с селектами, то заполнять форму можно только с клавиатуры. Современные браузеры позволяют автоматически выбирать опции просто набирая их с клавиатуры. Заменив такой селект на радиобатоны мы вынуждаем человека пользоваться клавиатурой и мышей одновременно. А это потеря драгоценных секунд на фокусировку внимания и рекогносцировку рук. Tab нажимать гораздо быстрее и эргономичнее. Все, почему-то, в упор забывают про tabindex'ы. Это мощный инструмент, и вы должны следить за тем, чтобы при переходах между полями вам под руки не попадались ссылки каких-нибудь хэлперов.
Убирайте лишние клики
Реализация этой задачи приведит к желанию показывать как можно больше управляющих элементов на интерфейсе. А это перегиб в другую сторону. Кликов может быть много, пользователя это не сильно заботит, но все клики должны быть осмысленными и содержать как можно меньше ошибок. Именно на минимизацию ошибок пользователя нужно направлять свою энергию UX-дизайнера
Держите важную информацию на виду
Это сомнительного качества совет. Опять же, что есть важная информация? Важная для кого? Какой ее минимальный объем должен быть? С точки зрения пользователя очень сильно много информации может быть для него важной. Иногда объем информации такой, что «важная информация» будет отнимать полезное рабочее место.
радиобатоны тоже можно заполнять с клавиатуры
про таб-индексы хороший совет
>> ногда объем информации такой, что «важная информация» будет отнимать полезное рабочее место.
не будет
не бывает много информации — бывает плохой интерфейс
мне например, очень нравится, как эту проблему решили в MAC OS
про таб-индексы хороший совет
>> ногда объем информации такой, что «важная информация» будет отнимать полезное рабочее место.
не будет
не бывает много информации — бывает плохой интерфейс
мне например, очень нравится, как эту проблему решили в MAC OS
Да, радиобатоны тоже можно заполнять с клавиатуры, но лучше это делать мышей. Тупо быстрее. Особенно, когда вам надо выбрать последний элемент из списка.
Но, селект не подходит в тех случаях, когда нужна наглядность выбора, т.е. все пункты селекта должны всегда быть перед глазами. Тут только радиобатоны или их заменители.
Скорее всего вы не работали над системами для служб безопасности банков (десятки страниц информации могут быть), интерфейсами для аналитических инструментов (километровые таблички), для систем мониторинга (куча показателей). Если вы его сделаете с «воздухом», с большими и красивыми шрифтами, с тщательно разбитыми на закладки блоками информации, вас пользователи не то чтобы проклянут, лучи их ненависти будут до вас долетать с любой точки планеты.
Есть задачи уместить как можно больше на одном экране. И это не дебильное требование, а вынужденная мера.
Но, селект не подходит в тех случаях, когда нужна наглядность выбора, т.е. все пункты селекта должны всегда быть перед глазами. Тут только радиобатоны или их заменители.
не бывает много информации — бывает плохой интерфейс
Скорее всего вы не работали над системами для служб безопасности банков (десятки страниц информации могут быть), интерфейсами для аналитических инструментов (километровые таблички), для систем мониторинга (куча показателей). Если вы его сделаете с «воздухом», с большими и красивыми шрифтами, с тщательно разбитыми на закладки блоками информации, вас пользователи не то чтобы проклянут, лучи их ненависти будут до вас долетать с любой точки планеты.
Есть задачи уместить как можно больше на одном экране. И это не дебильное требование, а вынужденная мера.
я работала над системой для автоматизации телекомов
жуткое количество информации, функций, балковых операций и т.д.
и все равно придерживаюсь точки зрения, что не бывает много информации, а бывает плохой интерфейс
те, кто говорит, что плохой интерфейс — это вынужденная мера, видимо, просто не думали над более изящным решением
другое дело, что иногда это и не нужно — когда заказчика устраивает плохой интерфейс
жуткое количество информации, функций, балковых операций и т.д.
и все равно придерживаюсь точки зрения, что не бывает много информации, а бывает плохой интерфейс
те, кто говорит, что плохой интерфейс — это вынужденная мера, видимо, просто не думали над более изящным решением
другое дело, что иногда это и не нужно — когда заказчика устраивает плохой интерфейс
Что-то я перестал улавливать смысл фразы «не бывает много информации, а бывает плохой интерфейс»…
«Плохой интерфейс» может быть ничем иным, как субъективным мнением дизайнера, который не до конца понял задачу, которую этот самый интерфейс решал.
Могу привести еще пример. Кнопка удаления может специально и намеренно находиться в выпадающем списке, даже если ею довольно часто пользуются, потому что нельзя допускать «случайных» срабатываний или действий, которые были доведены до автоматизма или мышечной памяти пользователя. Костыль в данном случае — намеренное и осознанное решение, а не проявление неосознанных флуктуаций мозга дизайнера.
«Плохой интерфейс» может быть ничем иным, как субъективным мнением дизайнера, который не до конца понял задачу, которую этот самый интерфейс решал.
Могу привести еще пример. Кнопка удаления может специально и намеренно находиться в выпадающем списке, даже если ею довольно часто пользуются, потому что нельзя допускать «случайных» срабатываний или действий, которые были доведены до автоматизма или мышечной памяти пользователя. Костыль в данном случае — намеренное и осознанное решение, а не проявление неосознанных флуктуаций мозга дизайнера.
«Плохой интерфейс» может быть ничем иным, как субъективным мнением дизайнера, который не до конца понял задачу, которую этот самый интерфейс решал.
Нет, не может. Субъективное мнение дизайнера — это субъективное мнение дизайнера, «плохой/хороший» интерфейс — это, во-первых, мнение пользователей, а во-вторых, вполне себе объективная характеристика, которую можно даже померить, введя определенные метрики. Но дизайнер может и сам быть плохим.
Могу привести еще пример. Кнопка удаления может специально и намеренно находиться в выпадающем списке, даже если ею довольно часто пользуются, потому что нельзя допускать «случайных» срабатываний или действий, которые были доведены до автоматизма или мышечной памяти пользователя. Костыль в данном случае — намеренное и осознанное решение, а не проявление неосознанных флуктуаций мозга дизайнера.
А вот это никуда не годится. Сходу могу предложить 2 элементарных решения проблемы: а) Подтверждение удаления; б) «Восстановление» случайно удаленных данных.
Нет, не может. Субъективное мнение дизайнера — это субъективное мнение дизайнера, «плохой/хороший» интерфейс — это, во-первых, мнение пользователей, а во-вторых, вполне себе объективная характеристика, которую можно даже померить, введя определенные метрики. Но дизайнер может и сам быть плохим.
Мнение пользователей разнятся как песок на пляже. Потому что пользователь имеет собственные привычки и стереотипы. И оценка будет скорее «совпало или не совпало со стереотипами», чем объективной.
Хотелось бы мне услышать хоть одну метрику, по которой можно понять качество дизайна… Без шуток, мне реально интересно пообщаться на это тему.
А вот это никуда не годится. Сходу могу предложить 2 элементарных решения проблемы: а) Подтверждение удаления; б) «Восстановление» случайно удаленных данных.
Подтверждение удаления делается на мышечной памяти, через время пользователь перестает вообще реагировать на попапы. Особенности мозга, он не хочет каждый раз читать написанное, в итоге ставится тупой блок на элементы аналогичного поведения, и потом реация на любой попап будет одинаковой- быстрее нажать «Ок». Лично в моей практике было много раз, когда пользователи что-то делали, а потом думали, что же произошло.
Восстановление не всегда возможно. Удалите по сети файлы с чужой «шары».
Так что ваши варианты могут служить дополнением к моему изначальному варианту, но не заменой. Т.е. я готов еще больше костылей вставлять, только бы действия не были необдуманными или случайными. Намеренная деградация юзабилити — один из видов юзабилити :)
Видимо вы не доконца улавливаете разницу между «Дизайном» и «Дизайном интерфейса». «с «воздухом», с большими и красивыми шрифтами» — это не сюда, а вот «с тщательно разбитыми на закладки блоками информации», «уместить как можно больше на одном экране» (если это действительно требование) — над этим нужно поработать. Километровые таблички — это тоже интерфейс, они тоже могут быть «хорошими».
да не могут быть километровые таблички хорошими, потому что их никто смотреть не будет
вместо километровых табличек используйте поиск, сортировку, разбиение на вкладки или еще что-нибудь
если заказчика устраивают километровые таблички, значит его устраивает плохое решение
вместо километровых табличек используйте поиск, сортировку, разбиение на вкладки или еще что-нибудь
если заказчика устраивают километровые таблички, значит его устраивает плохое решение
Если всегда приходится заполнять все поля из этой колиметровой таблички, то переключение между табами — это лишние клики и возможность забыть какой-нибудь таб (проскочил, или переключился для заполнения како-то поля, а потом забыл обратно и т.п.). Где вводится много данных за раз — километровые таблички могут быть решением.
Но при этом есть и обратный к километровым табличкам подход, тоже весьма сомнительный с точки зрения дизайнеров интерфейса, но весьма эффективный с точки зрения пользователей — введение данных в одно поле. Сам видел в сбере вводят данные пользователя при заполнении специальной анкеты в одно поле (ФИО, номер паспорта, год рождения, номер карты и ещё какие-то там параметры). Даже мне это решение понравилось, потому что 1) все данные обязательны 2) все данные фиксированы (идут в одной последовательности и чётко разбиваются пробелами). Пользователю меньше кликов на переходы между полями и фокусировку внимания на другом поле, главное в правильном порядке ввести
Но при этом есть и обратный к километровым табличкам подход, тоже весьма сомнительный с точки зрения дизайнеров интерфейса, но весьма эффективный с точки зрения пользователей — введение данных в одно поле. Сам видел в сбере вводят данные пользователя при заполнении специальной анкеты в одно поле (ФИО, номер паспорта, год рождения, номер карты и ещё какие-то там параметры). Даже мне это решение понравилось, потому что 1) все данные обязательны 2) все данные фиксированы (идут в одной последовательности и чётко разбиваются пробелами). Пользователю меньше кликов на переходы между полями и фокусировку внимания на другом поле, главное в правильном порядке ввести
Но тут вылазит вторая проблема — валидация данных. Нужно иметь достаточное количество вспомогательных справочников, чтобы отделять наиболее страшные ошибки.
Например, адрес может записываться в весьма произвольной форме, и гарантировать правильность угадывания его составляющих можно только имея базу адресов.
Плюс проблема с подсветкой, что именно не понравилось в данных валидатору
Например, адрес может записываться в весьма произвольной форме, и гарантировать правильность угадывания его составляющих можно только имея базу адресов.
Плюс проблема с подсветкой, что именно не понравилось в данных валидатору
Там не надо адрес вводить, только «легки» данные. Хотя и с адресом тоже всё относительно просто — ответственность в таком случае перекладывается на оператора (если сложно сделать нормальную валидацию в программе), а оператор пусть сам решает каким интерфейсом пользоваться — быстрым под свою ответственность, или с несколькими полями, автодополнением и валидацией.
Видимо не улавливаю…
«Воздух» — это как раз дизайн чистейшей воды. Он позволяет делать акценты, сепарировать контент друг от друга, выполняет роль повышения удобства использования.
Большие шрифты — это опять таки дизайн, но уже контента. Акценты и удобство чтения информации — прямая задача дизайна, а тем более интерфейсов.
Большой объем данных при любом, даже самом крутом дизайне, понижает юзабилити. Если вы, как пользователь, не сможете переварить данные за короткий срок, то уже будет не важно, красивая была табличка или угребищная. Да, красивая дает бонусов, но это копейки, по сравнению с тем, что может дать замена таблички на что-то более читаемое.
«Воздух» — это как раз дизайн чистейшей воды. Он позволяет делать акценты, сепарировать контент друг от друга, выполняет роль повышения удобства использования.
Большие шрифты — это опять таки дизайн, но уже контента. Акценты и удобство чтения информации — прямая задача дизайна, а тем более интерфейсов.
Большой объем данных при любом, даже самом крутом дизайне, понижает юзабилити. Если вы, как пользователь, не сможете переварить данные за короткий срок, то уже будет не важно, красивая была табличка или угребищная. Да, красивая дает бонусов, но это копейки, по сравнению с тем, что может дать замена таблички на что-то более читаемое.
Поэтому выбросьте все, что можно, не заставляйте пользователя изучать лишнее.
Очень часто выбрасывают «ненужное» в настройках, думая что знают как мне удобно. И потом хрен что настроишь под себя «нестандартного». Нужно не выбрасывать, а скрывать скажем в «Дополнительно».
Не нужно ничего скрывать в «Дополнительно».
Вы же делаете приложение, удобное для пользователя и предназначенное для решения каких-то определенных задач, а не комбайн, который танцует и поет и картошку чистит и музыку пишет
Вы же делаете приложение, удобное для пользователя и предназначенное для решения каких-то определенных задач, а не комбайн, который танцует и поет и картошку чистит и музыку пишет
Зачастую видение способа решения этих задач у разработчика и пользователя сильно отличается. И то, что разработчик посчитал неважным чтобы настроить, бывает краеугольным камнем при принятии решения пользоваться программой или нет. И тогда другая программа, которая возможно выглядит как комбайн, но выполняет именно так, как мне нужно, выиграет.
Ваша статья ведь тоже своего рода интерфейс — интерфейс по Вашему взаимодействию с Хабром. Позволю себе оптимизировать его:
1. При создании интерфейса самое главное — думать. Важное дополнение — думать не только о себе.
2. Верное направление мысли помогут найти вот эти книги: (список)
3. Не следует слепо следовать всяким советам (даже если они из книг в пункте выше), ведь самое главное — думать.
P.S. И да — я с удовольствием поговорю на эту тему в комментариях.
1. При создании интерфейса самое главное — думать. Важное дополнение — думать не только о себе.
2. Верное направление мысли помогут найти вот эти книги: (список)
3. Не следует слепо следовать всяким советам (даже если они из книг в пункте выше), ведь самое главное — думать.
P.S. И да — я с удовольствием поговорю на эту тему в комментариях.
В конце каждой подобной статьи должна значиться ссылка-совет, с уточнением «где рейтинг > 100».
Список литературы в итоге формируется почти что идентичный.
Список литературы в итоге формируется почти что идентичный.
«Отличным примером здесь служит опять-таки сервис Google Drive. Мгновенное автосохранение документов позволяет вообще не думать о том, что данные надо сохранять.»
Мне как пользователю кривых рабочих proxy и очень нестабильного интернета от монополиста-провайдера этот совет режет ножом по живому. Это ужасная практика лишать пользователя контроля над сохранением! Из-за которой пользователь не в курсе сохранён документ или нет. Это очень мешает работе.
Мне как пользователю кривых рабочих proxy и очень нестабильного интернета от монополиста-провайдера этот совет режет ножом по живому. Это ужасная практика лишать пользователя контроля над сохранением! Из-за которой пользователь не в курсе сохранён документ или нет. Это очень мешает работе.
Sign up to leave a comment.
7 советов, как улучшить интерфейс вашего приложения