Комментарии 31
Поэтому да, пользователь скорее обратит внимание на плохой дизайн, чем не хороший)
— «санитарные фичи» — не сделать их нельзя, т.к. пользователь будет воспринимать их отсутствие как существенный недостаток, а если сделать то пользователь вообще никак их не заметит);
— «линейные фичи» — что-то сделали чего нет у конкурента — в результате плюс немного лояльности к вам;
— «нелинейные фичи» — если их нет, то пользователем всё-равно, никто про них не знает, норма находится на одном уровне. Как только эта фича появляется — уровень нормы и требований резко возрастает, пользователя накрывает кратковременное счастье.
Что касается изингов, где-то слышал что для анимации НЕ геометрических метрик (цвета, теней, прозрачности, блюра и т.д.) лучше использовать только linear без всяких кривых Безье. Так лучше для производительности. Хотя, лучше наверное, такие свойства вообще не анимировать)
>>Если пути движущихся объектов пересекаются друг с другом, они не могут проходить друг через друга.
Это далеко не факт. Уточнение в следующем пункте — что объект должен подняться, а не пройти под другими, уже лучше, но сам пункт о не пересечении, как бы сомнителен и может, наоборот, оказаться менее удачным решением.
В статье собраны основные принципы и рекомендации по работе с анимацией, но конечно же это не догмат и все можно оспорить. Но мне как человеку который связан напрямую с данной тематикой статья очень помогла разобраться с основами и понять многие моменты.
Спасибо вам за комментарий.
А особенно, из анимации на самом примере в статье: сам хаотичный поиск пути объектами и движение их по свободным полям, может вызвать когнитивный диссонанс у пользователя, а не быстрая смена всех элементов, хоть они и пересеклись бы (ну желательно чтобы главный элемент проехал НАД всеми остальными, но все остальные — абсолютно без разницы, как там смещались бы, относительно друг-друга).
Любая анимация короче 100 мс мгновенна и не будет распознаваться вообще.
Ох, если бы. Удобно, конечно, ссылаться на статью 1993 года, которая ссылается на исследование 1968 года, но даже там написано "instantaneously". Распознаваться такая анимация будет большинством людей, но не будет напрягать. А вот выше этого — "user does lose the feeling of operating directly on the data". И это на самом деле так (во всяком случае для меня) — взаимодействие разбивается на миллион этапов "сконцентрировался", "потерял концентрацию". Пару раз в секунду. Если приложение постоянно развлекает меня анимациями по 200 мс, ничего сложного в нем сделать невозможно.
Спасибо всем тем, кто делает короткие анимации и большое спасибо, кто разрешает их отключать.
Да, конечно. Есть такой арт-директор Олег Чулаков, очень грамотно в своё время выступил на эту тему, попробуйте поискать по названию, не помню точно, но звучит примерно так: "для чего нужна анимация в интерфейсах и как она помогает пользователю", выступал давно, но по сути рассказывал принципы, которые актуальны и по сей день. И помимо этого есть достаточно много информации по данному вопросу, я наверное соберу статью попробую охватить этот вопрос, спасибо что затронули эту тему.
Хорошо что есть «element hiding helper»
Хотите быть актуальным на гребне волны: Делайте раньше других.
По статье: создается впечатление что сделать анимации в приложении правильно (в соответствии с гайдлайнами) — практически так же сложно и затратно как сделать остальное приложение.
Если вы точно знаете, что нажали именно на пункт меню, то окей. Но примерно половина пользователей, нажимая куда-то и видя совершенно новый экран, теряются, не понимая, куда они попали. Дальше они нажимают "назад" (на всякий случай), а потом снова на пункт меню. Чтобы убедиться, что всё в порядке.
Почти мгновенная анимация разворачивания (на пределе восприятия — примерно 50-75 мсек) никак не помешает, но исключительно эту неловкость.
Проблема в том, что в той же веб-разработкой все более менее сложные анимации все ещё тяжело реализовать. Нужно постоянно навешивать коллбеки и следить за тем, чтобы элемент все ещё был видимым, и его родитель тоже (display: block), и если меняется стейт родителя, то нужно обязательно оповещать детей, что что-то изменилось. В целом все это решаемые задачи, но как правило любые такие анимации при правильной реализации — это 20% бюджета на фронтенд. На чистой just анимации реализовать это все проще, на css — боль и слезы, использование Web Animations API во многом решает проблемы и с контролем, и с плавностью, но пока чистая поддержка браузерами не позволяет использовать этот подход.
Полное руководство по правильному использованию анимации в UX