В теме 48 ответов, и 12 участников, последнее обновление сделано пользователем 
Герман Шестеров 12 г назад.
-
Сообщения
-
Век живи. век учись … В первый раз слышу, что "эргономика" — это наука о труде! Не поверил, зашел в Вики и убедился, что действительно такое определение имеет место. Однако, заметьте, что "Более широкое определение эргономики, принятое в 2010 году Международной Ассоциацией Эргономики (IEA), звучит так: «Научная дисциплина, изучающая взаимодействие человека и других элементов системы, а также сфера деятельности по применению теории, принципов, данных и методов этой науки для обеспечения благополучия человека и оптимизации общей производительности системы». Если еще под "производительностью системы" подразумевать эффективность не только производственных (рабочих) систем, но и вообще систем взаимодействия "Человек — Продукт созидательной деятельности человека" (Бог их знает, что они там подразумевают), то определение станет неотличимым от того смысла, в котором оно использовалось несколько десятков лет назад, в мою бытность студентом и позже. Я думаю такое понимание эргономики, которое было официально принято Ассоциацией Эргономики только в 2010 году возникло не одномоментно, но давным давно существовало и под давлением этого факта Ассоциация его в конце-концов приняла.
эргономика — это все-таки (с самого высокого уровня абстракции) [i][b]наука [/b][/i]о труде, а юзабилити — [i][b]свойство [/b][/i]системы
В том то и дело, что словом "эргономика" в мою бытность архитектором, обозначалась как дисциплина, так и свойство продукта/изделия/товара/искусственной среды. "У этого продукта классная эргономика", — это было совершенно правомочное высказывание. Не знаю как сейчас, но что-то мне подсказывает, что точно так же. Но раз Вики!!! … то спорить тут не о чем, ваше видение вопроса (хотя мое мне больше нравится), по крайней мере имеет право на существование.
Все что Вы сказали по поводу "Насчет святости пользователей", полностью одобряю, оно ничуть не противоречит моим взглядам, тем более, что Вы ни одного моего конкретного утверждения не отвергаете. Но интересен для меня был именно акцент на том, что не стоит его (пользователя) переоценивать (равно как и недооценивать, о чем я, каюсь, кажись не упомянул), потому что о последнем говорят часто и часто пользуются этим как козырным тузом, где надо и не надо, а о первом политкорректно умолчивают … У нас разная сфера деятельности: у Вас веб, а у меня деловые приложения, и для меня та сторона, которую затронул я, более болезненна (просто очень!). А среди читателей ведь есть и те и другие.
И где ж еще поплакаться бедному сироте-аналитику? …Действительно, век живи, век учись
Для меня "У этого продукта классная эргономика" звучит так же диковато, как, например, "у этого продукта классная эстетика".У нас разная сфера деятельности: у Вас веб, а у меня деловые приложения, и для меня та сторона, которую затронул я, более болезненна (просто очень!). А среди читателей ведь есть и те и другие.
Зря Вы так категорично. Как раз большая часть моих проектов связана с деловыми приложениями, в том числе — и для десктопа. Конечно, есть свои нюансы, но в целом — многие вещи актуальны и для веба, и для мобильных систем, и даже для аппаратного обеспечения. Связано это, в первую очередь, с человеческой психологией и физиологией: копни поглубже в любое юзабилити — все рекомендации базируются в конечном итоге на них.
Не могу не встрять (:
Хоть не со всеми высказываниями Михая я согласен, но вот что касается эргономичности или эргономики как свойства, тут могу сказать, что действительно в таком виде данное слово использовалось и продолжает использоваться. Примеры: эргономичный стул, эргономичная подставка, эргономика рабочего места, да и ноутбуки и телевизоры любят сопровождать словами "хорошая эргономика".Приветствую бойцов аналитического фронта! В прошлой статье я начала рассматривать макеты интерфейсов пользовательского интерфейса (они же mockups, wireframes, мокапы, вайеры) и дала несколько практических советов по их созданию. Сегодня я расскажу о том, как можно проводить оценку созданных творений, не будучи при этом гуру юзабилити или мастером по Photoshop’у.
Читать дальшеВсем привет!Как и обещала, сегодня мы продолжим разговор об оценке графического интерфейса, но на этот раз займемся информационной архитектурой.
Еще раз хочу подчеркнуть: то, что предыдущая статья посвящена визуальному дизайну, а эта – информационной архитектуре, ни в коем случае не означает, что в таком порядке нужно оценивать интерфейс. Как правило, на практике все эти проверки нельзя явно отделить друг от друга, но для начала, чтобы упростить понимание, мы разберемся по отдельности с каждым компонентом.
Читать далее.Приветствую всех, кто дотерпел до 5 части моей писанины, а также всех новобранцев, присоединившихся только сейчас. Сегодня мы прикоснемся к самому «вкусному»: взаимодействию человек – система. Так как речь здесь пойдет о динамической составляющей, оценивать ее на статических макетах затруднительно (хотя нет ничего невозможного, разумеется). Поэтому сегодня мы будем больше говорить о динамических прототипах и реальных системах. Эту статью я решила сделать вводной в тему проектирования взаимодействия. Практические советы будут в следующей части, а пока мы поразмышляем над тем, каким бывает поведение программ с человеческой точки зрения и что с этим делать.
Читать далееСпасибо за статью.Хотел бы также отметить по поводу "п.5) Программа не дает пользователю шанса отменить свои действия.", что сообщения с подтверждением бесполезны на физиологическом уровне поведения человека, т.к. нажатие на "Ок" входит в привычку, и в данном случае, согласие с подтверждением является бессознательным поведением.
Кстати, чем больше действий в программе выполняются на бессознательном уровне, тем лучше, т.к. проще и быстрее работать с ней (подробнее о сознательном и бессознательном можно почитать у Дж.Раскина "Интерфейс").
Tilya, спасибо за интересую мысль!Задумалась. Действительно, когда действия выполняются "на автопилоте" и не приходится лишний раз грузить сознание, это плюс. Если рассмотреть 2 варианта обработки таких ситуаций (с подтверждением и без), вот что у меня получается:
С подтверждением:
- Пользователь нажимает на "удалить все безвозвратно навсегда"
- Система показывает сообщение "Вы уверены, что хотите удалить все безвозвратно навсегда? В случае, если вы нажмете "Да" бла бла бла на несколько строк"
- Пользователь жмет Enter на автомате
- Пользователь видит, что все удалено безвозвратно, поток прерван, пользователь в ярости (в печали)Без подтверждения:
- Пользователь нажимает на "удалить все безвозвратно навсегда"
- Система молча удаляет все безвозвратно навсегда, но оставляет заметную кнопку/ссылку "Восстановить все"
- Пользователь говорит "Омг, что ж я наделал" и жмет "Восстановить все".
- Система восстанавливает все удаленные объекты, пользователь продолжает дальше делать то, что он делал.Что скажете?
ну и я вставлю свои 5 копеек : )
гугл — не та компания, на которую стоит ориентироваться в вопросах удобства использования в большинстве случаев (хотя в последнее время они активно работают в этом направлении).
Но по данному конкретному вопросу их подход мне нравится -удаление писем в gmail: без подтверждения, однако появляется сообщение вверху страницы с двумя опциями "подробнее" — на случай, если я не знаю, что сотворила : ) и "отменить" — на случай, если я передумала).
Мне не докучают не нужными модальными окнами и я ни разу не удалила ничего нужного.Без подтверждения, но с отменой, более правильно, а как уже реализовать, это другой вопрос
Вы об этом же и написали в своей статье, я просто хотел объяснить почему подтверждения не работают
Tilya, спасибо за интересую мысль!
Задумалась. Действительно, когда действия выполняются "на автопилоте" и не приходится лишний раз грузить сознание, это плюс. Если рассмотреть 2 варианта обработки таких ситуаций (с подтверждением и без), вот что у меня получается:
[b]С подтверждением:[/b]
- Пользователь нажимает на "удалить все безвозвратно навсегда"
- Система показывает сообщение "Вы уверены, что хотите удалить все безвозвратно навсегда? В случае, если вы нажмете "Да" бла бла бла на несколько строк"
- Пользователь жмет Enter на автомате
- Пользователь видит, что все удалено безвозвратно, поток прерван, пользователь в ярости (в печали)…
Что скажете?А если подтверждение вешается не на Enter, а наоборот? Например, при отмене инсталляции на автопилот вешается Cancel, а для подтверждения нужно кликнуть на другую кнопку.
Если подтверждение вешается не на "обычную" кнопку, то у автопилота происходит разрыв шаблона. "Почему ничего не происходит???!!!"Если подтверждение вешается не на "обычную" кнопку, то у автопилота происходит разрыв шаблона. "Почему ничего не происходит???!!!"
Разрыв шаблона. Именно так.
Enter может вообще не работать, но пользователь привыкнет кликать мышью Ок, это будет чуть муторно, но все равно войдет в привычку, просто может чуть позжеНе в порядке возражения ко всему сказанному в статье, но только по поводу первого пункта, как одного из непременных признаков "свинского" поведения программы:
1) Программа ведет себя так, будто это она главная. Ваш пользователь может быть кем угодно: профессором, балериной или полным идиотом. Но в любом случае главным должен быть он.
Дело в том, что это не всегда верно. Всегда ли программа — всего лишь вспомогательный инструмент? Одно дело, когда целью программного продукта (его владельцев) является извлечение максимального количества траффика (неважно какого качества, хотя бы и "чистого" белого шума) и только, и совсем другое, когда программа выступает в качестве канвы, обеспечивающей исполнение регламента, предопределенного сценария типизированной деятельности пользователя, в том числе, и с целью ограждения бизнеса от проявлений идиотизма. Корректно ли называть регламенты и должностные обязанности "вспомогательным инструментом" должностного лица? Я не предлагаю использовать девайс для раздачи оплеух и подзатыльников, но лишь предлагаю изъять из глобального определения дружественности ПО, пункт о лояльности к идиотизму (балерины — ладно, пусть остаются, я с ними еще не сталкивался). Дело в том, что прямые проблемы при проектировании ПО, связанные с этим штампом, отнюдь не редкость. Очень часто настаивая на реализации какого-нибудь сценария, основанием для которого является "мы всегда так делали, мы так привыкли и нас это устраивает", который явно нарушает логическую целостность бизнеса, представитель заказчика (обычно это будущий пользователь — начальник или зам.нач. какой-нибудь внутренней службы) в качестве последнего убийственного аргумента прибегает именно к ссылке на критерии дружественности ПО (capsLock от Enter только-только научился различать, а это уже знает!:(((…). В результате это чревато реализацией криво формализованных процессов (идиотизм ить надо как-то обрабатывать), что в свою очередь вызывает переусложнение (да еще какое!) и нестабильность систем … Да и всегда ли плохо, если так произойдет, что система поможет сравнительно гуманно избавиться от идиота?
Вы должны авторизироваться для ответа в этой теме.
