Comments 58
Слишком много общих формулировок, которые никак не помогут новичку и не дадут ничего состоявшемуся эксперту. На мой взгляд экспертность UX-дизайнера состоит в времени за которое в среднем могут пользователи получить доступ к самым важным или часто используемым функциям.
p.s Ненавижу когда достаточно простое мобильное приложение нельзя использовать одной рукой
p.s Ненавижу когда достаточно простое мобильное приложение нельзя использовать одной рукой
Более того, очень важно придерживаться поведенчиских моделей включая общие для определённых типов продуктов приёмы. Смысл в том, что дизайнеры обычно используют элементы, которые уже известны пользователям. Такой подход делает ориентирование в продукте более интуитивным и простым.
И здесь очень легко попасть в ловушку плохих привычных решений: использовать переключатели, модальные окна, вывод ошибок в окошке с единственной кнопкой ОК, диалоговые окна с вопросом о сохранении внесённых изменений и тому подобное — ведь всё это так хорошо известно пользователям.
В том то и состоит профессионализм. Чтобы знать, когда чекбоксы, а когда переключатели. Когда модалки, а когда можно обойтись и небольшой подписью рядом с инпутом.
Но новички это прочтут, а чем плохи режимы, переключатели и тому подобное они знать не будут, поскольку у них не окажется соответствующей теоретической базы, а статья эти вопросы никак не затрагивает. И модальные окна ведь так легко создавать — нужно лишь написать несколько строк кода. И программисты будут довольны. Так плохие интерфейсы и самовоспроизводятся постоянно.
Да, статья не даёт теории, она наоборот является перечислением того, чем отличаются хорошие дизайнеры от средних.
Но статья так же упоминает базовые принципы разработки интерфейса, которые помогают найти, что удобно, а что нет. Я имею в виду IA и тестирование на пользователях.
Ну и всё же о теории, это скорее не теория, а именно что опыт. Потому что эта «теория» меняется с каждым годом. А опыт и интегрированность в процесс, умение переступить через свои вкусы и «авторские решения» на благо целевой аудитории приложения — вот это и является профессиональными качествами.
Но статья так же упоминает базовые принципы разработки интерфейса, которые помогают найти, что удобно, а что нет. Я имею в виду IA и тестирование на пользователях.
Ну и всё же о теории, это скорее не теория, а именно что опыт. Потому что эта «теория» меняется с каждым годом. А опыт и интегрированность в процесс, умение переступить через свои вкусы и «авторские решения» на благо целевой аудитории приложения — вот это и является профессиональными качествами.
Нет, теория с каждым годом не меняется. О ней можно почитать в книге Джефа Раскина «Интерфейс. Новые направления в проектировании компьютерных систем». После можно перейти к книжке потолще: «Алан Купер об интерфейсе. Основы проектирования взаимодействия». И ещё Дональд Норман «Дизайн привычных вещей».
И вот с появившейся базой уже можно дальше самообразовываться, чтобы иметь возможность отличать хорошие советы от плохих и бесполезных.
И вот с появившейся базой уже можно дальше самообразовываться, чтобы иметь возможность отличать хорошие советы от плохих и бесполезных.
Вас наверное удивит, но модульные окна, с точки зрения кода, это одна из самых сложных задач в написании интерфейсов. Более сложнее только задачи с драгом ограниченным какими-либо правилами.
В iOS очень легко создаются. В Windows тоже не выглядит очень сложным. www.tutorialspoint.com/mfc/mfc_dialog_boxes.htm
Господа UX/UI-дизайнеры! Поалуйста прежде чем вставлять какуб либо «удобную» с вашего взгляда фичу в новый дизайн пожалуйста сделайте кнопку «вернуть как было».
Плохой UX/UI‐дизайнер именно так и сделает. А хороший сделает удобно без кавычек, а неудобное выкинет из интерфейса. Незачем оставлять неудобно, когда есть удобно. Незачем перекладывать проектное решение на плечи пользователя, ведь он не является UX/UI‐специалистом.
Но как сделать удобно без кавычек эта статья не рассказывает.
Но как сделать удобно без кавычек эта статья не рассказывает.
Одно замечание для UX/UI-дизайнеров которые пользуются статистическими данными метрик по использованию программного обеспечения. На основе этих метрик они делают некоторые выводы по улучшению логики воркфлоу процессов приложения.
Но есть один нюанс. Например если по статистике сказано, что 70% пользователей довольна, а 30% нет, то скорей всего UX/UI-дизайнер примет решение в пользу 70%. А это означает, что 30% будут недовольны.
С поколениями таких «улучшений» ситуация усугубляется.
Это очень не простой вопрос. Статистикой надо пользоваться аккуратно. И в этом случае я бы сказал даже вредно. Тут надо руковоствоваться именно своим опытом и чутьем. Иначе получится фейсбук с его «прекраснейшим» воркфлоу!
Но есть один нюанс. Например если по статистике сказано, что 70% пользователей довольна, а 30% нет, то скорей всего UX/UI-дизайнер примет решение в пользу 70%. А это означает, что 30% будут недовольны.
С поколениями таких «улучшений» ситуация усугубляется.
Это очень не простой вопрос. Статистикой надо пользоваться аккуратно. И в этом случае я бы сказал даже вредно. Тут надо руковоствоваться именно своим опытом и чутьем. Иначе получится фейсбук с его «прекраснейшим» воркфлоу!
К сожалению эта проблема встречается везде. Если 60% нравится кандидатура в президенты, то выбирается именно она, а остальные 40% остаются недовольны. Это называется демократия.
Проблемы появляются тогда, когда метрики собираются неправильно, когда исследуют не ту группу или не тот функционал. А полагаться на опыт — ну это давно уже пройденный этап. Ведь ситуация может быть другая, и опыт может быть не применим к данной ситуации.
Так что тут я бы всё же сделал акцент на том, что нужно уметь собирать правильные метрики.
Проблемы появляются тогда, когда метрики собираются неправильно, когда исследуют не ту группу или не тот функционал. А полагаться на опыт — ну это давно уже пройденный этап. Ведь ситуация может быть другая, и опыт может быть не применим к данной ситуации.
Так что тут я бы всё же сделал акцент на том, что нужно уметь собирать правильные метрики.
У такой демократии есть очевидные недостатки. В компьютерном мире такие недостатки могут быть исключены. Например выпуском открытого API. Вот это демократия. Тогда пользователи смогут юзать сервис так как им реально удобно. Как минимум у них будет такой шанс.
То, что вы хотите называется анархией) Но это мечта, о которой я тоже часто мечтаю. Тогда можно было бы сделать свои приложения с лучшим или тем же функционалом под себя. Так сказать полная кастомизация. Но к сожалению сейчас кастомизацией обладает только WEB, и в очень ограниченных рамках.
А вся история дизайна — это создание интерфейсов, которые были бы понятны максимальному количеству пользователей при минимальном количестве времени на обучение.
А вся история дизайна — это создание интерфейсов, которые были бы понятны максимальному количеству пользователей при минимальном количестве времени на обучение.
Тут лучше руководствоваться в первую очередь теорией, чтобы не наступать на грабли. И теоретическая база как раз поможет правильно интерпретировать результаты тестов, которые в этом случае окажутся полезными. Тогда и не получится так, как вы описали.
Как сделать удобно и без кавычек рассказывается в других статьях, на которые оригинал сам же и ссылается.
Незачем перекладывать проектное решение на плечи пользователя, ведь он не является UX/UI‐специалистом.Вот этот подход, в том числе у помянутого Раскина, я и ненавижу.
Парикмахеры
Похрен, что один пользователь работает больше мышкой, второй хоткеями, а третий вообще в консоли. Нафиг мышь, нафиг консоль, клавиатура вам тоже больше не нужна: смотрите, какая теперь у нас большая удобная кнопка прямо посреди сенсорного экрана!
— Что? Какие опции? Я их выкинул, я специалист, мне лучше знать.
Поубивал бы…
Форма головы как раз у всех одинакова, если не считать болезненные отклонения — с физиологией не поспоришь. Ваша интерпритация Раскина не верна — вы невнимательно его читали.
Форма головы как раз у всех одинаковаДолихо- и брахицефалы смотрят на вас с подозрением.
Для понимания: это была цитата из анекдота.
Приходит в комиссию по изобретениям изобретатель, и приносит автоматическую машинку для стрижки. Эдакая насадка на голову с вращающимися полукольцевыми лезвиями.И да, я достаточно внимательно читал Раскина. То, про что я говорю, он называет монотонностью.
Его спрашивают: у людей же форма головы чуть разная, ваша машинка насколько безопасна?
— Все с порядке, — отвечает изобретатель. — Разная, конечно, но только до первой стрижки.
Разработчики интерфейсов часто предлагают пользователям сразу несколько методов достижения того или иного результата. Например, одна и та же команда может выполняться как с помощью меню, так и с помощью сочетания клавиш.
…
Современные графические пользовательские интерфейсы, имеющие рабочий стол, являются сочетанием, по крайней мере, двух разных интерфейсов: с одной стороны, сравнительно видимой и быстроизучаемой системы на основе меню, а с другой – неполного собрания трудноизучаемых и труднозапоминаемых комбинаций клавиш. Сочетание двух ошибок не может дать правильного ответа.
…
На мой взгляд, интерфейс, который не имеет режимов и является – насколько это возможно – монотонным, был бы чрезвычайно удобным в использовании...
Долихо- и брахицефалы смотрят на вас с подозрением.
Я всё же имел в виду переносное значение, под которым подразумевал психофизиологию. Мне нужно было взять в кавычки, уточнить или вовсе сформулировать иначе.
То, про что я говорю, он [Раскин] называет монотонностью.
Да, это так. Но он не предлагает отказаться от управления клавиатурой или от управления мышью. Дальше по книге он даже приводит возможное направление решения этой проблемы. Но это больше про перспективные направления. А в текущих системах конкретно в этом вопросе, к сожалению, имеем то, что имеем. Но если в каком‐то кейсе есть возможность это исправить, то нужно исправлять. Но главное, не втаскивать подобные проблемы в те интерфейсные решения приложения, которые собственно разрабатываются, а не навязаны системой.
Поскольку я неявным образом именно что цитировал анекдот, то тут мы друг друга просто не поняли.
В остальном же…
В бытность мою инженером техподдержки небольшого провайдера, мне пришлось демонстрировать работоспособность свежеподключенного доступа в Сеть клиентам, въезжавшим в новый офис. Там еще не было даже мебели толком, на пять комнат два стола и три стула. И в качестве демонстрационного стенда (покажите нам на нашем оборудовании) — MacBook Pro.
Мой внутренний диалог состоял из исключительно нецензурных слов на протяжении примерно пяти минут. Потом я все же нашел, куда они запрятали консоль, и облегченно выдохнул.
И знаете? Я с ужасом думаю, что бы было, если бы известная своим вниманием к дизайну интерфейсов фирма Apple последовала бы совету Раскина и сделала бы этот интерфейс монотонным.
Наверное, я ретроград. Не делайте мне как лучше, оставьте как хорошо…
В остальном же…
В бытность мою инженером техподдержки небольшого провайдера, мне пришлось демонстрировать работоспособность свежеподключенного доступа в Сеть клиентам, въезжавшим в новый офис. Там еще не было даже мебели толком, на пять комнат два стола и три стула. И в качестве демонстрационного стенда (покажите нам на нашем оборудовании) — MacBook Pro.
Мой внутренний диалог состоял из исключительно нецензурных слов на протяжении примерно пяти минут. Потом я все же нашел, куда они запрятали консоль, и облегченно выдохнул.
И знаете? Я с ужасом думаю, что бы было, если бы известная своим вниманием к дизайну интерфейсов фирма Apple последовала бы совету Раскина и сделала бы этот интерфейс монотонным.
Наверное, я ретроград. Не делайте мне как лучше, оставьте как хорошо…
От возможности отдавать тектовые команды Раскин тоже не предлагает отказываться.
Значит, я действительно невнимательно читал.
Если интерфейс с единственным способом действий объявляется целью, но при этом мы не призываем отказываться от других способов действий… Всё, мой логический блок умер весь. Он и так-то был не выдающимся, мир его праху.
Если интерфейс с единственным способом действий объявляется целью, но при этом мы не призываем отказываться от других способов действий… Всё, мой логический блок умер весь. Он и так-то был не выдающимся, мир его праху.
Раскин говорит о том, что к монотонности нужно стремиться. Но немонотонный интерфейс приводит к значительно меньшим проблемам, чем режимы. Просто интерфейс будет сложнее изучать. И реализация будет сложнее.
А в разделе 5.2.2. «Команды» Раскин пишет о возможном направлении повышения монотонности в контексте графического интерфейса, хоткеев и коммандной строки. Описываемый подход в перспективе мог бы заменить текущую реализацию. Но именно в перспективе, поскольку такое не реализовать в рамках нынешней архитектуры операционных систем.
Но в рамках имеющихся возможностей и текущей целесообразности стремление к монотонности ведёт к упрощению как освоения интерфейса, так и его реализации, что тоже полезно. А Купер более подробно фокусируется на том, что и как можно делать в рамках существующих систем.
А в разделе 5.2.2. «Команды» Раскин пишет о возможном направлении повышения монотонности в контексте графического интерфейса, хоткеев и коммандной строки. Описываемый подход в перспективе мог бы заменить текущую реализацию. Но именно в перспективе, поскольку такое не реализовать в рамках нынешней архитектуры операционных систем.
Но в рамках имеющихся возможностей и текущей целесообразности стремление к монотонности ведёт к упрощению как освоения интерфейса, так и его реализации, что тоже полезно. А Купер более подробно фокусируется на том, что и как можно делать в рамках существующих систем.
немонотонный интерфейс приводит к значительно меньшим проблемам, чем режимы.Расскажите это пользователям vim.
Купера я тоже читал, спасибо. Понимаете, кроме вот всех этих рассуждений о монотонности интерфейса и легкости восприятия, которые вообще говоря нужны и важны, но все же: есть еще накопленный опыт пользователей.
Когда компания выкатывает очередной революционный интерфейс, накопленный опыт пользователей спускается в унитаз. Новичкам хорошо, им становится интуитивно понятнее. Опытным пользователям, которых почти всегда больше, чем новичков, приходится переучиваться заново.
Когда выпустили MS Office 2007 с интерфейсом Ribbon, из моих знакомых ему обрадовались человек пять. Ни один из этих пяти физически не мог набрать на клавиатуре хотя бы полстраницы: за отсутствием минимальных навыков печати это запросто могло занять половину рабочего дня. Вместо обмена двумя фразами в чате или электронного письма они предпочитали позвонить (трое до сих пор предпочитают, они так и не научились). Зато десяткам людей, имевших немалый накопленный опыт, и я в их числе, изменение интерфейса вовсе не пришлось по душе. Два года назад меня еще просили ставить офис 2003, последний с нормальным интерфейсом, даже имея лицензионный 2013-й. Лично я просто проголосовал ногами.
И да: чем сложнее задачи, которые вы выполняете, тем больше ваш накопленный опыт, и тем неочевиднее, неинтуитивнее, просто непонятнее будет интерфейс. Не существует возможности тонкой настройки Cisco NCS, написания драйвера, создания 3D-ролика методом Drag and Drop. Принципиально не существует.
Этому приходится учиться, учиться долго, накапливая тот самый опыт пользователей. И эта сущность, по моему скромному, на принятие решений об изменении интерфейса влиять тоже должна.
Привычные хоткеи нельзя выбрасывать из приложений для существующих систем, конечно же. Суть здесь в том, чтобы не плодить нарушение монотонности там, где это не нужно, где нет никакого пользовательского опыта.
В случае режимов опыт никак не помогает, поскольку привыкнуть к ним нельзя — модальные ошибки всё равно будут. От режимов нужно избавляться везде, где только можно. С модальными окнами аналогично.
А этот Риббон слепому десятипальцевому набору уж точно никак не мешает. Но у него проблема в том, что визуально искать в нём сложнее, чем в вертикальных списках меню. Ему бы мог помочь поиск подобный поиску по меню в macOS.
В 3D‐редакторах Drag and Drop очень широко используется.
В случае режимов опыт никак не помогает, поскольку привыкнуть к ним нельзя — модальные ошибки всё равно будут. От режимов нужно избавляться везде, где только можно. С модальными окнами аналогично.
А этот Риббон слепому десятипальцевому набору уж точно никак не мешает. Но у него проблема в том, что визуально искать в нём сложнее, чем в вертикальных списках меню. Ему бы мог помочь поиск подобный поиску по меню в macOS.
В 3D‐редакторах Drag and Drop очень широко используется.
Риббон слепому десятипальцевому набору уж точно никак не мешает.Не мешает.
Он сливает опыт пользования меню и иконками инструментов: то есть, как только от редактора требуется хоть что-то, кроме набора текста, так приплыли, учимся заново. Проблема тех пятерых в том, что они даже набор текста не осилили.
где нет никакого пользовательского опыта.Это может быть. Как только найдется область, в которой не будет переиспользования пользовательского опыта (каковую придумать мне не хватает фантазии, но почему нет).
В 3D‐редакторах Drag and Drop очень широко используетсяТак и в Visual Studio можно драгэнддропать кнопочки на формочку. А можно руками писать. Но вот если сделать ее интерфейс монотонным, исключив хоть тот способ, хоть этот…
От режимов нужно избавляться везде, где только можно.Давайте просто предположим, что можно это далеко не везде, в том числе с учетом накопленного опыта. Я со своим накопленным опытом десятипальцевого набора буду совершенно не рад обнаружить клавиатуру на 210 клавиш, где будут присутствовать одновременно кириллические и латинские клавиши. И отсутствие режимов ввода меня вовсе не утешит.
Фактически, режим — это способ уменьшить до приемлемого количество сущностей, которыми предполагается управлять одновременно. Как правило, это означает, что общее количество сущностей слишком велико для одновременного эффективного управления, что в свою очередь может означать сложность решаемых задач. Да, быстрый набор текста — это тоже довольно сложная задача, хотя и неплохо автоматизируемая привычкой.
Так и в Visual Studio можно драгэнддропать кнопочки на формочку. А можно руками писать. Но вот если сделать ее интерфейс монотонным, исключив хоть тот способ, хоть этот…
А исключать не надо. Нужен третий способ, который будет лучше этих двух вместе взятых. Тут есть где развернуться — тоже перспективное направление.
Я со своим накопленным опытом десятипальцевого набора буду совершенно не рад обнаружить клавиатуру на 210 клавиш, где будут присутствовать одновременно кириллические и латинские клавиши
Я не просто так добавил «где только можно». Ниже есть обсуждение, где на примере кейса предложенного Алхимиком я показал, как можно успешно избавляться от модальных окон.
А увеличение количества кнопок — это явно неправильный путь избавления от модальных раскладок, поскольку есть законы Фиттса и Хика. И количество пальцев на руках тоже ограничено. Кнопок на нынешней клавиатуре даже слишком много — можно было бы уменьшить.
Но способ всё‐таки есть даже в этом сложном и, казалось бы, неразрешимом случае.
Mozhno nabiratj tekst russkoj latinicej, a potom konvertirovatj yego v kirillicu. Takim sposobom mozhno poljzovatjsya xhotj desyatjyu pisjmennostyami, xhotj vsemi srazu. Yazyikovyixh kodov mnogo. ru
Tab↓↑
Можно набирать текст русской латиницей, а потом конвертировать его в кириллицу. Таким способом можно пользоваться хоть десятью письменностями, хоть всеми сразу. Языковых кодов много.
Может накатаете статейку про это, если разбираетесь. Чем, например, заменить модальное окно с вопросом о подтверждении удаления доменного объекта из таблицы? Особенно если это счет или договор на хорошую сумму — почему бы не переспросить этим окном пользователя дважды? А если юзер после внесенных изменеий в форму, тоже с хорошей цифрой в поле суммы, нажимает выход — не нужно ли у него модальным окном поинтересоваться — с сохранием выйти али без? Тут автосохранение не проходит, нужно явное подтверждение транзакции/изменений договора, а если дать молча выйти, не сохранив, то возможно юсер расчитывал на автосохранение, и тоже с финансовыми последствиями.
это я к коменту RomanKerinov, не к автору, с мобильного чуть промахнулся:)
Статейку пока вряд ли. Подтверждение всё равно не поможет, поскольку пользователь автоматически по привычке ошибочно нажмёт «Подтвердить», поскольку в условных 99% случаев всё в порядке и он нажимает именно эту кнопку. И при этом в 99% случаев окно с подтверждением будет только мешать и раздражать.
Лучше дать возможность отменить ошибочное действие. И всячески ненавязчиво помогать пользователям обнаружить ошибку теми или иными способами.
Если пользователь при выходе расчитывает на автосохранение, то чем должно помочь модальное окно с вопросом о сохранении изменений? Здесь поможет только реализация автосохранения.
Лучше дать возможность отменить ошибочное действие. И всячески ненавязчиво помогать пользователям обнаружить ошибку теми или иными способами.
Если пользователь при выходе расчитывает на автосохранение, то чем должно помочь модальное окно с вопросом о сохранении изменений? Здесь поможет только реализация автосохранения.
дать возможность отменить ошибочное действие
Не. Деньги списаны, получателю ушла смс-ка, день закрылся, отчеты в налоговой, поезд ушел.
Если пользователь при выходе расчитывает на автосохранение, то чем должно помочь модальное окно с вопросом о сохранении изменений? Здесь поможет только реализация автосохранения
Тоже не. Это порождает неоднозначность. Допустим есть новичек, который недавно устроился на работу, т.е. в основном по отношению к ПО интутит. Вот он заполнил форму договора, изменив сумму.
1) Вариант 1. А у нас сразу при вводе все автосохраняется. Сперва 1 000 000, а через 15 мин, когда по договору параллельно прошли денежные движения, оператор перепроверил ввод и сказал «ой я ошибся», там должно было быть 10 000. Не вариант.
2) Вариант 2. Автосохраняется не при вводе, а при выходе без окна подтверждения. Но потом обязательно окажется, что сохранять не нужно было. В ходе заполнения формы, чувак кому-то перезвонил, переуточнил данные и просто хотел выйти, ничего не сохраняя. Перебивать все поля формы обратно перед выходом — не серьезно. Делать кнопку — «вернуть все как было», которую можно забыть нажать перед выходом — тоже не вариант. Отдельная кнопка — «выйти без сохранения» — да, нафиг, если есть крестик в углу окна, кликнул и убежал. А последствия автосохранения, еще раз — мнгновенные и финансовые. Не лучше или просто переспросить — вам уйти с сохранением али без?
3) Вариант 3. При выходе автосохранения нет и предупреждений тоже, т.е. все теряется. Но пользователь молод и имеет такой экспириенс, что за него все должна делать программа, поэтому действительно предпочел нажать кнопку «выйти», вместо сперва «сохранить», а потом «выйти» в расчете, что и так сохранится. А деньги в итоге не провелись там где должны были, в нужный срок. Опять же — не спросить ли подтверждения сохранить или как?
Модальное окно работает, но для новичка — первый опыт. И в некоторых случаях оно кажется безальтернативным (это к предложению отказаться от них вообще). Но потом да, на него забивают так же, как некоторые электрики на резиновый коврик. Вот здесь уже тема для UX — может в окне подтверждения слово «деньги» делать зеленым, «будут» — желтым, а «списаны» — фиолетовым? :)
Не. Деньги списаны, получателю ушла смс-ка, день закрылся, отчеты в налоговой, поезд ушел.
Ну так и в случае с окном подтверждения будет то же самое, поскольку пользователь пропустит его на автомате. Загуглите сколько вопросов о том, как отменить ошибочную транзакцию. Оно не работает.
1) Вариант 1. А у нас сразу при вводе все автосохраняется. Сперва 1 000 000, а через 15 мин, когда по договору параллельно прошли денежные движения, оператор перепроверил ввод и сказал «ой я ошибся», там должно было быть 10 000. Не вариант.
Ну так и исправит, и новое значение заново автосохранится. Он же до отправки транзакции проверяет. В чём здесь проблема? Или я как‐то не так понял кейс?
2) Вариант 2. Автосохраняется не при вводе, а при выходе без окна подтверждения. Но потом обязательно окажется, что сохранять не нужно было. В ходе заполнения формы, чувак кому-то перезвонил, переуточнил данные и просто хотел выйти, ничего не сохраняя. Перебивать все поля формы обратно перед выходом — не серьезно. Делать кнопку — «вернуть все как было», которую можно забыть нажать перед выходом — тоже не вариант. Отдельная кнопка — «выйти без сохранения» — да, нафиг, если есть крестик в углу окна, кликнул и убежал. А последствия автосохранения, еще раз — мнгновенные и финансовые. Не лучше или просто переспросить — вам уйти с сохранением али без?
Автосохраняться должно при вводе. Должна быть возможность откатить изменения типа как в git (не с ручными коммитами, конечно) — именно для тех редких случаев, когда это понадобится. Но это не будет портить весь остальной основной опыт взаимодействия. Переспросить хуже, потому что окно будет на автомате проигнорировано, как в большинстве случаев — у людей вырабатываются привычки.
И почему мгновенные потери? Потери будут только после нажатия кнопки «Отправить тразакцию». Если кнопку нужно нажимать два или три раза, то это не решает проблему, а создаёт новую.
3) Вариант 3. При выходе автосохранения нет и предупреждений тоже, т.е. все теряется. Но пользователь молод и имеет такой экспириенс, что за него все должна делать программа, поэтому действительно предпочел нажать кнопку «выйти», вместо сперва «сохранить», а потом «выйти» в расчете, что и так сохранится. А деньги в итоге не провелись там где должны были, в нужный срок. Опять же — не спросить ли подтверждения сохранить или как?
Нет, лучше сделать автосохранение.
Модальное окно работает, но для новичка — первый опыт.
Да, именно в этом их проблема. Середняк его пропустит — их большинство. Опытный путём тренировок и серьёзных когнитивных усилий, возможно, не будет пропускать. Но это приведёт к снижению его работоспособности, а при этом опытным специалистам ещё и платить нужно больше. Хорошо ли это для бизнеса?
И в некоторых случаях оно кажется безальтернативным (это к предложению отказаться от них вообще).
Ну в случае форматирования накопителя, наверное, да. Но это системные фишки, а в прикладном софте модальное окно почти никогда не нужно.
Вот здесь уже тема для UX — может в окне подтверждения слово «деньги» делать зеленым, «будут» — желтым, а «списаны» — фиолетовым?
Не поможет. В книгах, которые я здесь упоминал, это всё разбирается.
Ну так и исправит, и новое значение заново автосохранится. Он же до отправки транзакции проверяет. В чём здесь проблема? Или я как‐то не так понял кейс?
Фининсовые последствия наступают с момента сохранения. Могут быть параллельные процессы, например, начисление процентов на сумму договора. Процент на 10 тыс. и на 1 млн. несколько отличается по ходу. Этот процесс может проигнорировать договора в режиме редактирования, чтоб вернуться к ним позже, а не брать в расчет то, что там чуваки недоввели или залипшую в сгущенке кнопку с нулем. Но в целом я вас понял.
Не поможет. В книгах, которые я здесь упоминал, это всё разбирается.А я думал, что есть какой-то приемчик, типа менять модальное окно каждый раз внешене, устраивая квест за кнопочкой Ок (сегодня кнопочка, завтра галочка), то это поможет. Не? Ну ладно :) Книжки гляну, спасибо.
Ну то есть должна быть кнопка, после которой наступают финансовые последствия, будь то «Отправить транзакцию» или что‐то ещё. А автосохранение должно сохранять в виде черновика. Чтобы предотвратить случайное нажатие, вместо кнопки можно повесить это действие на Drag and Drop, например. И случайного клика уже не будет, и модального окна со всеми его минусами тоже.
Количество внешних видов всё равно будет ограничено, поэтому не сработает. И даже если их будет очень много, то они все будут для пользователя на одно лицо, типа как реклама на сайтах, которая мозгом автоматически игнорируется.
А я думал, что есть какой-то приемчик, типа менять модальное окно каждый раз внешене
Количество внешних видов всё равно будет ограничено, поэтому не сработает. И даже если их будет очень много, то они все будут для пользователя на одно лицо, типа как реклама на сайтах, которая мозгом автоматически игнорируется.
Ну то есть должна быть кнопка, после которой наступают финансовые последствия, будь то «Отправить транзакцию» или что‐то ещё. А автосохранение должно сохранять в виде черновика. Чтобы предотвратить случайное нажатие, вместо кнопки можно повесить это действие на Drag and Drop, например. И случайного клика уже не будет, и модального окна со всеми его минусами тоже.
Теперь отпишусь, как суровый и бородатый программер. И по поводу этого
И модальные окна ведь так легко создавать — нужно лишь написать несколько строк кода. И программисты будут довольны. Так плохие интерфейсы и самовоспроизводятся постоянно.
Десктопное приложение. За столами сидят 3 менеджера. К одному пришел клиент и за 1 минуты до начисления процентов написал заяву\допку на изменениие суммы договора. Менеджер встал на табличку с договорами, выбрал запись и открыл форму одного из них, заблокировав доступ к нему для всех остальных процессов и сотрудников. Договор уже давно ушел из статуса «Черновик», ему лет 5, он в состоянии «Активен». В форме договора есть все — и кнопка выйти, и сохранить, и сохранить и выйти, выйти без изменений, подтвердить изменения и еще куча всего, что только можно придумать, и даже даже хер стеклянный туда дизайнер зачем-то вставил, но этот засранец (менеджер), после ввода суммы нажимает крестик в правом верхнем углу экрана. Выскакивает окно с надписью: Сумма договора была изменена на N 000 000 000 $ (крупным зеленым шрифтом), сохранить изменения (да\нет)? Первый менеджер скажет — о, точно, а сохранить-то я забыл. Второй — на подсознательном уровне скажет 'как же меня з… ли эти модалки, итак же понятно, что сохранить' и кликнет да, не глядя. Третий — на подсознательном уровне скажет 'как же меня з… ли эти модалки, итак же понятно, что не сохранять' и кликнет нет, не глядя. Так вот, пока первого менеджера не престрелят, а два других не начнут думать одинаково, модальное окно будет, извини. А если ко мне потом подойдут и скажут — наша «Клавдия Борисовна» все время ошибается с суммой договора. Тогда я скажу, там же есть окно подтверждения, их кто-то вообще читает? Тогда мне скажут — да, к вам вообще никаких претензий поэтому, но все-таки… Тогда я скажу, ладно, у нас UI\UX дизайнер — Роман, подойдите к нему, он-то уж что-нибудь придумает )))
Ну вот поэтому мы до сих пор и окружены плохими интерфейсами. Алан Купер «Психбольница в руках пациентов» — книга как раз об этом.
А крестик можно просто убрать и сделать две кнопки: «Отменить изменения» и «Обновить». И в результате модальные окна по‐прежнему не нужны.
А крестик можно просто убрать и сделать две кнопки: «Отменить изменения» и «Обновить». И в результате модальные окна по‐прежнему не нужны.
Так исторически сложилось (т.е. мега экспириенс), что возле крестика есть еще 2 кнопки — свернуть и развернуть, которые полезны при работе с окнами, а если при этом крестик станет неактивен или пропадет, то у здорового человека, действительно, может случиться когнитивный диссонанс. Это все равно что однажды зайти в лифт и не увидеть кнопку 3 на привычном месте, после 1 и 2. А тебе как раз надо на 3-й. Да, хорошо, что внизу еще есть запасная панель, но хотелось бы посмотреть в глаза тому, кто этот лифт так модно недавно проапгрейдил.
Это надуманные проблемы: и последняя, и предпоследняя. Не стоит делать из пользователя идиота — он знаком и с идиомой неактивной кнопки, и с идиомой закрытия окна. Закрытие окна никак не может и не должно приводить к отправке транзакции — это никак не связанные действия. Типичная ошибка программиста в UX дизайне состоит в том, что он рассматривает все возможные варианты, но не учитывает вероятность их наступления.
Если проблема забытых транзакций имеет место, то её нужно и решать, а не прикручивать костыли к кнопке закрытия окна, делая её мультифункциональной. Можно, к примеру, организовать наглядный стек подготовленных, но не отправленных транзакций. Возможно, можно ещё что‐то придумать — это уже нужно смотреть по ситуации.
Если проблема забытых транзакций имеет место, то её нужно и решать, а не прикручивать костыли к кнопке закрытия окна, делая её мультифункциональной. Можно, к примеру, организовать наглядный стек подготовленных, но не отправленных транзакций. Возможно, можно ещё что‐то придумать — это уже нужно смотреть по ситуации.
Не ну если это только раз в день кнопка нажимается, то все таки лучше переспросить хотя бы для того чтобы отсечь мисклик.
Ну или можно сделать как в farcry4-5 когда нажимаем кнопку появляется прогресс бар вокруг мышки, и чтобы клик реально произошёл нужно подержать в зажатом состоянии 1 секунду.
Если это какое‐то критически важное действие, то случайное нажатие лучше драг энд дропом отсечь, типа как разблокировка смартфона на драг энд дроп. Это будет эффективнее, чем переспрос или удержание. Переспрос может быть на автомате пропущен, а любые задержки в интерфейсе, тем более искуственно созданные — это плохо.
Вы задали очень интересный вопрос, на самом деле. Потому что такая ситуация показательна. И на неё может быть 2 ответа:
- Гугл уже убрал в своих интерфейсах модальные окна, взамен он показывает небольшое уведомление с кнопкой "отменить".
- В финансовых продуктах нет места UX, тут деньги крутятся и не надо никаких красивостей.
Оба ответа не являются правильными и надо смотреть конкретный случай. Если операция действительно никаким образом не может быть изменена, то модалка — хорошее решение. Если же операция производится пользователем на регулярной основе (создание или удаление чего-то или изменение чего-то), то скорее всего стоит всё же реализовать механизм с возможностью отмены или подтверждения другим человеком.
Так что именно в такой ситуации стоит проводить исследования и тестировать каждый подход, собирать статистику и либо решаться на что-то, либо не решаться.
И в ВК аналогично сделано.
И вот как раз в финансовых продуктах для UX особое место, так как ошибки могут стоить особенно дорого. Дело ведь не в красивостях, а в том, что модалка не предотвращает ошибки, а наоборот порождает.
И вот как раз в финансовых продуктах для UX особое место, так как ошибки могут стоить особенно дорого. Дело ведь не в красивостях, а в том, что модалка не предотвращает ошибки, а наоборот порождает.
модалка не предотвращает ошибки, а наоборот порождает.Это все равно, что обвинять светофор в порождении проезда на красный свет.
Порождает ошибку человек, у которого многократно повторенное действие дошло до автоматизма. Никаким UX вы это не исправите, разве что разозлите пользователя окончательно.
Нет, светофор — это хороший интерфейс: красный — стой, зелёный — едь. А модалка — это шлагбаум на нерегулируемом перекрёстке, который нужно вручную поднимать. Как думаете, такой вариант обрадует автомобилистов?
Смотрите: человеку для получения результата требуется выполнить ряд действий. Если эти действия выполняются достаточно регулярно, то они доходят до автоматизма. На этом месте, как я понимаю, мы с вами примерно согласны: на автомате можно пропустить ошибку, и это плохо.
Ошибка, как мы понимаем, возникает не на этапе вывода модального окна с подтверждением/отменой. Она возникает где-то раньше. В этой ситуации лишнее подтверждение — это лишний шанс прервать автоматические действия, остановиться и проверить все еще раз. Совсем от ошибки не спасет, но шанс несколько уменьшит.
Я еще раз отмечу, что разговор идет о финансовых транзакциях. То есть, после нажатия последнего подтверждения начинают действовать независящие от пользователя механизмы и деньги уходят. Дальше можно оспаривать перевод, судиться — но все это вне рамок нашего условного приложения. Это как выстрел: целиться можно долго, и возможно, предохранитель не лучшее решение с точки зрения интерфейса: но после нажатия на спусковой крючок пулю в ствол обратно уже не затолкаешь.
Какой бы вы предложили альтернативный вариант?
Ошибка, как мы понимаем, возникает не на этапе вывода модального окна с подтверждением/отменой. Она возникает где-то раньше. В этой ситуации лишнее подтверждение — это лишний шанс прервать автоматические действия, остановиться и проверить все еще раз. Совсем от ошибки не спасет, но шанс несколько уменьшит.
Я еще раз отмечу, что разговор идет о финансовых транзакциях. То есть, после нажатия последнего подтверждения начинают действовать независящие от пользователя механизмы и деньги уходят. Дальше можно оспаривать перевод, судиться — но все это вне рамок нашего условного приложения. Это как выстрел: целиться можно долго, и возможно, предохранитель не лучшее решение с точки зрения интерфейса: но после нажатия на спусковой крючок пулю в ствол обратно уже не затолкаешь.
Какой бы вы предложили альтернативный вариант?
Если человек принял решение отправлять, то он уже будет нажимать кнопки на автомате. Это как если сделать отправку по двойному или тройному клику на кнопку — толку не будет. Единственое, что может надёжно сделать модальное окно — это предотвратить отправку при случайном нажатии на кнопку. Но этого же можно добиться и без модального окна, если повесить отправку не на кнопку, а на Drag and Drop, например.
Вы считаете, что Drag&Drop пользователю как-то принципиально сложнее автоматизировать?
Нет, это защита от случайного нажатия на левую кнопку мыши, когда курсор случайно оказался над кнопкой. Это замена модального окна именно для этого случая. А от целеноправленного действия по отправке модальное окно всё равно не помогает. Тут уже вся надежда на внимательность пользователя, а внимельным быть проще, когда интерфейс не выносит мозг.
Да, ваше отписал варианты. Отмена может быть невозможной, а вводящий и подтверждающий — это может быть 1 лицо, т.к. конечная инстанция, или надо срочно. Но глаз от регулярной основы действий замыливается, поэтому, быть может, надо сделать прыгающие нули списываемой суммы в форме воздушных шариков в окне подтверждения?
На счет финансовых продуктов. Не то, что бы там прям нужны особые красивости, но юсер не должен его громко ненавидеть через 8 часов\неделю\год работы, сидя в очереди к окулисту или психиатору)). И вряд ли сейчас продашь что-то в стиле 95-х окошек, если продукт идет на внешний рынок. А вопрос борьбы с замыливанием глаза и пофигизмом к диалоговым окнам — это отдельная тема — вот эту штуку тоже бы как-то продумать и решать в режиме «здесь и сейчас».
На счет финансовых продуктов. Не то, что бы там прям нужны особые красивости, но юсер не должен его громко ненавидеть через 8 часов\неделю\год работы, сидя в очереди к окулисту или психиатору)). И вряд ли сейчас продашь что-то в стиле 95-х окошек, если продукт идет на внешний рынок. А вопрос борьбы с замыливанием глаза и пофигизмом к диалоговым окнам — это отдельная тема — вот эту штуку тоже бы как-то продумать и решать в режиме «здесь и сейчас».
Выше отписал ответ.
А вот именно к этому и приводят модальные окна. И это серьёзнее, чем красивый графический дизайн, хотя он тоже важен.
На счет финансовых продуктов. Не то, что бы там прям нужны особые красивости, но юсер не должен его громко ненавидеть через 8 часов\неделю\год работы, сидя в очереди к окулисту или психиатору)).
А вот именно к этому и приводят модальные окна. И это серьёзнее, чем красивый графический дизайн, хотя он тоже важен.
А вообще, хороший UI/UX — дизайнер с моей т. з. — это человек, который не только способен побороть избыточность, но и чувствует грань между минимализмом и убожеством. Тот, кто, напрмер, делал win10, в дизанейрских решениях ориентируясь на предшественника win 3.11, эту грань не прочуствовал. Ну и, пользуясь случаем, отдельное спасибо за лаконичный рибон-интерфейс.
Sign up to leave a comment.
Стань профессионалом. Полезные привычки UX-дизайнеров