В теме 16 ответов, и 6 участников, последнее обновление сделано пользователем 
Kremien 13 г, 2 мес. назад.
-
Сообщения
-
А также аналитик и user experience, эргономика, проектирование пользовательских интерфейсов и все, что с этим связано. Полезная литература, ссылки, обмен опытом и прочее.Отличный пример Experience map, созданный для описания того, как геймеры собирают информацию об играх, делятся ей и принимают решение о покупке. На мой взгляд, создание такого рода Experience map — отличный способ понять конечных пользователей.Всем привет!
Как отображать кнопку, недоступню для объекта на текущий момент? Наверняка, решение здесь зависит от определённых факторов. Так вот эти факторы и соответстующие им решения я бы и хотела с вами обсудить.
Решения:
1 — "дизаблить" кнопку и в тултипе объяснять причину её недоступности
2 — не отображать её
3 — отображать и после "клика", объяснять пользователю причину её недоступности
4 — ещё?Факторы:
1 — причина недоступности (класс объекта, состояние объекта, связи объекта)
2 — конечно же пользователи
, а точнее их средний опыт(система может быть ориентирована как на новичка, так и на бывалого, которого решение №3 может раздражать)
3 — ещё ?Очень хочется узнать ваше мнение.
Спасибо!Здравствуйте, Елена!Наверное, нет идеального подхода, который работал бы для такой задачи во всех случаях. Для меня ключевым фактором является контекст. Если действие, которое вызывается кнопкой, является закономерным и логичным этапом в выполнении пользовательской задачи (например, отправка формы после ее редактирования), есть смысл кнопку не прятать, но сделать недоступной (решение 1). Тогда она будет служить еще и подсказкой следующего шага, который может выполнить пользователь.
Можно, конечно, использовать и решение 3 (кнопка кликабельная, но после клика отображается сообщение о недоступности действия и ее причине), но я такой подход не очень люблю, т.к. на практике он приводит к ошибочным действиям. Пользователи имеют свойство кликать все, что кликается, при этом не обращая внимания на сообщения. Так что если кнопка сразу выглядит как неактивная, скорее сработает рефлекс "ага, я что-то сделал не так, что бы это могло быть?".
Если кнопка предоставляет какие-то дополнительные опции, которые имеют смысл только при специфических условиях (например, если пользователь на форме выбрал параметр, для которого требуется ввод дополнительных данных во всплывающем окне), я за то, чтобы не отображать кнопку до наступления соответствующего контекста, когда она понадобится, дабы не вносить визуального шума.Это общий подход, а так конечно нужно рассматривать факторы, которые вы упомянули, особенно состояние и связи объекта. Бывают случаи, когда логика проста и прозрачна (например, кнопка недоступна, т.к. объект не был выделен). А бывает, что для доступности кнопки нужно совершить 5 действий, включая ритуальный танец с бубном: тогда нужно продумывать, как подсказать пользователю об этих действиях.
Здравствуйте, Елена,
я бы предложил описать "жизненный цикл" кнопки, т.е. последовательность ее возможных состояний, а уж для каждого состояния определить ее визуальную форму
1. Кнопка не может быть нажата (например, нет контента) — кнопка недоступна (или не видна)
2. Кнопка может быть нажата, но действие не будет выполнено (например, не все поля формы заполнены правильно) — кнопка имеет нейтральный вид (например, Ок). После нажатия кнопки можно дать подсказку, что именно нужно сделать.
3. Кнопка может быть нажата и все будет ок — кнопка выделена (например, Ок)
4. Кнопка должна быть нажата — ЖМИ!Belle Morte спасибо за развёрнутый ответ, я с ним полностью согласна, поэтому вопросов нет
AndrewK, интересный подход
! Однако, я бы всё-таки выделила три состояния кнопки в зависимости от доступности действия:1 — не может быть выполнено (мой вопрос касался именно этого состояния);
2 — может быть выполнено;
3 — предпочтительно для выполнения.Отдельное спасибо за совет по выделению состояния №3!
Всем привет!Как связаны межу собой Usability и User Experience? Может ли система иметь Good User Experience и Bad Usability? Bad User Experience и Good Usability? В разных источниках эта связь трактуется по разному.
Помогите разобраться, пожалуйста
Всем привет!
Как связаны межу собой Usability и User Experience? Может ли система иметь Good User Experience и Bad Usability? Bad User Experience и Good Usability? В разных источниках эта связь трактуется по разному.
Помогите разобраться, пожалуйста
Юзабилити — это свойство (или характеристика.. я всегда путаю эти понятия) системы. User Experience — это НЕ свойство системы, это некая сумма ощущений человека, которые возникают у человека при взаимодействии с системой. Поэтому система НЕ может иметь Good/Bad/… User Experience, но она может оставлять / создавать некоторые ощущения, т.е. создавать после использования себя любимой какой-то User Experience.
Поэтому, имхо, корректней было бы задать такой вопрос: может ли система с хорошим показателем юзабилити оставлять после себя плохой "опыт использования"? А может ли система с плохими показателями юзабилити оставлять после себя хороший "опыт использования"?Добрый вечер, Елена!С радостью помогу ;)
User Experience — это характеристика, описывающая всю совокупность переживаний, которые испытывает пользователь при взаимодействии с системой. Притом взаимодействие здесь понимается максимально широко: это и непосредственное использование системы, и общение со службой поддержки, обсуждение с другими пользователями, воспоминания об аналогичной системе и т.д. и т.п. Примером могут служить, пожалуй, Mac-и и iPhone/iPad-ы: это уже не просто компьютер, телефон и т.п. Это символ принадлежности к определенной группе, в некотором роде — статусное понятие.
Что касается соотношения понятий Usability и UX: мне в этом плане очень нравится предложенная Питером Морвиллем схема:
honeycombbig.jpg
На ней видно, что юзабилити — это часть UX, притом далеко не единственная.
В качестве примера: как пример хорошего юзабилити и плохого UX любят приводить сайт Якоба Нильсена: http://www.useit.com/. Да, он суперпростой, и его считают удобным. Но… он ведь такой отстойный, не правда ли? )
Что касается обратного примера… сходу не могу придумать, но чисто гипотетически: представьте, что вы купили новый телефон. Он вам нравится и вполне подходит, удобнее и юзабильнее некуда. Но тут начинают твориться странные вещи: вы присматриваетесь с своим друзьям/знакомым, которые говорят: "Фу, какое барахло, вот iPhoneWP7 вещь, а это — прошлый век". Вы сталкиваетесь с неисправностью, идете в сервисный центр, а вам там устраивают скандал и говорят, что ничего чинить не будут и "сам дурак". Потом отправляетесь в Интернет, читаете отзывы, и узнаете, что это не единичный случай, а такое у этой компании сплошь и рядом. И тут ваш тот самый Experience уходит окончательно в минуса. Может быть телефон был не так уж и плох. Но купите ли вы второй такой же? И станете ли связываться с этой фирмой?Ася, я че то запутался… Ты привела оба примера на хорошую юзабельность и плохой UX. А вот наоборот? Красиво, в теории полезно, зачетная техподдержка, а юзать неудобно и тяжело?Ася, я че то запутался… Ты привела оба примера на хорошую юзабельность и плохой UX. А вот наоборот? Красиво, в теории полезно, зачетная техподдержка, а юзать неудобно и тяжело?
Я бы предложил такой вариант.. Телефоны с плохой эргономикой, но, которые, например, отлично звонят, держат батарею, не разлетаются в щепки при падении, не ломаются сами по себе и которые стоят не очень дорого. Т.е. как бы опыт использования у тебя, вроде, как и неплохой, но могло бы быть и лучше (юзабилити увеличить). Пойдет вариантик?
Мой вариантик:
Есть, допустим, суперпопулярный модный телефон, который для всех ну просто "must have". Покупаете его, вам все завидуют, а потом замечаете, что телефон-то красивый и модный, но из-за сенсорного экрана вы постоянно при разговоре ухом нажимаете не те кнопки. Да и смс-ку на ощупь в кармане не наберешь…
Эх, кажется вас немного не туда занесло. Юзабилити — это не просто свойство системы, а свойство системы относительно определенного пользователя.Пример системы с плохим юзабилити, но возможно хорошим User Experience — головоломка-пазл.
Эх, кажется вас немного не туда занесло. Юзабилити — это не просто свойство системы, а свойство системы относительно определенного пользователя.
Тогда уже и относительно определенного контекста использования. Можно глянуть мою статью, где я приводила понятие юзабилити, там я как раз писала о том, что понятие это имеет смысл только в отношении определенного пользователя и контекста.
Насчет примера с головоломкой не соглашусь. В чем цель головоломок? В конечном итоге — найти разгадку и почувствовать, какой ты молодец. Можно ли добиться цели при помощи конкретной головоломки (эффективность)? Насколько сложно добиться цели именно этим способом (продуктивность)? Приятен ли сам процесс ее разрешения (удовлетворенность)? Если ответы — "да", "умеренно сложно, но в этом и фича", "да", то юзабилити головоломки высокое.
Ответ "нет" может быть в случае, если в самой головоломке присутствует, например, производственный брак и ее собрать нормальным способом нельзя. Или материал неприятный на ощупь, оставляет занозы и т.п.У меня родился ещё один вопрос по юзабилити
Можете ли вы привести пример чек-листа стандартов, который вы использовали при проектировании интерфейса, чтобы сделать его унифицированным?
Например:
-Называть кнопки удаления delete, а НЕ remove
-Все слова в названиях форм писать с большой буквы
-Обязательно запрашивать подтверждение при удалении
и т.д.
Вы должны авторизироваться для ответа в этой теме.
