Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 26
Отличная статья! При прочтении каждой статьи узнаю все новое и новое про дизайн пользовательских интерфейсов
Непонятно, почему кнопка поднимается при нажатии. Мы ведь нажимаем на нее — должна опускаться.
Это чисто догадка пальцем в небо, но когда тыкаешь в кнопку по увеличению тени можно понять, что приложение «зарегистрировало» нажатие. В обычном положении большие тени будут бросаться в глаза.
Подъем, или приближение, решает ряд нюансов. Элемент становится ближе к пользователю и пользователь интуитивно понимает, что он взаимодействует с этим элементом. Второй нюанс — в материальном дизайне элементы не могут проходить сквозь друг друга, поэтому двигаться ниже своей изначальной позиции элемент не может, так как может задеть другие элементы, которые находятся под ним.
Как вариант решения проблемы «поднятия» кнопки при нажатии:
- Делаем кнопку немного более приподнятой изначально
- Приподнимаем кнопку при наведении
- При нажатии делаем эффект волны и вдавливаем кнопку
Элемент приподнимается до нажатия, тем самым говорит о возможном взаимодействии с ним и как бы сам лезет под руку. А нажатие оформляется wave-эффектами.
Всё-таки классически «кнопки» мне ближе, чем материальный дизайн. Я до сих пор не могу понять, нажата кнопка или отжата, когда она приподнята. Т.е. само действие вижу, а вот какое было состояние и в какое перешло — не понимаю. Особенно, если всего одна кнопка была. Хуже только со свитчерами, в которых без подписи вообще разобраться невозможно. И не угодили же «галочки» дизайнерам… Но материальный дизайн гораздо симпатичнее плоского «метро» с любой точки зрения.
Почему поднятая кнопка темнее опущенной? Наоборот же надо: чем выше поднят элемент по оси Z, тем он светлее.
Интерфейс был бы намного более отзывчивый если б Андроид поддерживал hover жесты. Тогда понять нажимается ли элемент можно было бы просто приблизив палец.
А ведь Sony давно реализовала такой тач скрин (технология Floating Touch).
А ведь Sony давно реализовала такой тач скрин (технология Floating Touch).
Скриншот с окном «Run» не из Windows 95, а минимум из Windows 98. На нем видно главную фишку перехода на Windows 98 — градиентные заголовки окон :)
Для выделения активного элемента нужна явная область контакта прежде всего, а совсем не тень. Тень — для создания z-контекстов (панелей, уровней) и для обзначения плавающих элементов (типа MD-шной круглой кнопки). Тень — разрывает связь (контакт) с родительским элементом и элементами лежащими под, и именно для этих целей ее лучше использовать. Тени под всеми кнопками — создают визуальный шум, не более того.
Непонятно чем тень может отвлекать от функционала. Мне кажется иногда даже помогает подчеркнуть этот самый функционал. Дать понять пользователю нажимается та или иная штук или нет.
Сорри, не успел дописать:
Я не люблю отталкиваться от мысли что экран — это плоская вещь и значит, все остальное тоже должно быть. Для меня экран это скорее портал, в тот цифровой мир. Как бы это смешно не звучало, но мы тратим много времени проводя за компом, и уже погруженно находимся «в мониторе» а не перед ним. Когда мы смотрим кино, мы же видим содержание, а не саму плоскость экрана.
Столько возможностей изобразить всего разного, а исходят из идеи промышленного дизайна. Как монитор выглядит, из чего состоит. Внутренний мои может быть богаче и разнообразнее.
Просто сейчас такая мода, тогда никого перегруженность не смущала. Все радовались текстуркам и теням. Просто это надоело от перенасыщения и пришло время чего-то нового. И флат тоже надоест, будут «вау» от падающей тени ловить :-)
— Ещё приподнятые кнопки похожи по механизму на драг-н-дропные строчки, как в iOS. Тапнул, держишь — элемент оторвался от экрана, перетянул куда надо и отпустил — элемент упал вниз.
Я не люблю отталкиваться от мысли что экран — это плоская вещь и значит, все остальное тоже должно быть. Для меня экран это скорее портал, в тот цифровой мир. Как бы это смешно не звучало, но мы тратим много времени проводя за компом, и уже погруженно находимся «в мониторе» а не перед ним. Когда мы смотрим кино, мы же видим содержание, а не саму плоскость экрана.
Столько возможностей изобразить всего разного, а исходят из идеи промышленного дизайна. Как монитор выглядит, из чего состоит. Внутренний мои может быть богаче и разнообразнее.
Просто сейчас такая мода, тогда никого перегруженность не смущала. Все радовались текстуркам и теням. Просто это надоело от перенасыщения и пришло время чего-то нового. И флат тоже надоест, будут «вау» от падающей тени ловить :-)
— Ещё приподнятые кнопки похожи по механизму на драг-н-дропные строчки, как в iOS. Тапнул, держишь — элемент оторвался от экрана, перетянул куда надо и отпустил — элемент упал вниз.
Изображение в статье с Normal и Pressed Button некорректно — перепутаны состояния. Согласно концепции Material Design, правильно так:
Raised Button
Кто-нибудь встречал интерфейс исключительно жестовый, по движению прикоснувшихся пальцев, без визуальных элементов?
«Идеальный интерфейс — это тот, которого нет» — вот что интересует.
Или предложите приложение, к которому сложно не сделать визуальный интерфейс.
«Идеальный интерфейс — это тот, которого нет» — вот что интересует.
Или предложите приложение, к которому сложно не сделать визуальный интерфейс.
Подобные теории очень часто исходят из того, что «подобие реальному миру — это хорошо» — это аксиома, не требующая доказательства и вообще какого-либо рассмотрения. Но тут есть один момент: после первого короткого ознакомления и получения представления об интерфейсе, люди не рассматривают интерфейс ни в материальном мире, ни в цифровой форме. Они им просто пользуются. Конечно, преодоление барьера в начале пользования — важный момент, но не стоит ли именно так тогда эту задачу и рассматривать?
Простой пример: при использовании экранной клавиатуры, человек во-первых, загораживает все красоты анимации кнопок пальцем, а во-вторых, привыкнув к ней, он на нее вообще не смотрит, а смотрит только на появляющиеся на экране символы. Ровно также, как никто не смотрит на кнопки электронных часов, когда устанавливает на них время — смотрят на сам экран, как там цифры меняются.
Другой момент — обратная связь, реакция приложения. В подавляющем большинстве случаев, действие пользователя с каким-то элементом интерфейса должно приводить к изменению чего-либо. И только в случае, если приложение — кривое и тормозит, пользователь обращает внимание на реакцию самого элемента. «А нажалась ли эта кнопка? Почему ничего не происходит?» Так что реакция самого элемента (если он, конечно, не совмещен с тем, что, собственно, обязано менять состояние, как в случае переключателей) в таких случаях — не более чем костыль, призванный уменьшить фрустрацию пользователя от тормозящего приложения. Кнопка, которая демонстрирует, что ее нажали, как бы говорит: «Не волнуйтесь, ваше действие очень важно для нас, сейчас все линии заняты, когда кто-нибудь освободится, мы займемся вашей проблемой.» Это вроде как и нужно делать, но, опять же, стоит помнить о реальном смысле этого.
Конечно, есть и те люди, которые печатают одним пальцем и т.п., но тут уж решение за авторами — являются ли они их целевой аудиторией, или нет.
Лично меня раздражают неотключаемые (несмотря на то, что в Developer options телефона все анимации отключены) анимационные переходы — я знаю, что реакция приложения почти каждый раз откладывается до того, как отработает анимация перехода, воруя секунды моего времени. А реально нужны эти анимации в material design только тем, кто печатает одним пальцем и думает, что у компьютера есть собственная воля, либо тем, для кого дизайн — самоценен (и у кого дофига свободного времени, чтобы на него смотреть и мастурбировать по поводу того, как он продуман). Потому что тому, кто пользуется приложением, а не рассматривает его, важна реакция и простота доступа к необходимым функциям, а не чтобы его «не пугали внезапно сменяющиеся и возникающие ниоткуда элементы интерфейса».
Простой пример: при использовании экранной клавиатуры, человек во-первых, загораживает все красоты анимации кнопок пальцем, а во-вторых, привыкнув к ней, он на нее вообще не смотрит, а смотрит только на появляющиеся на экране символы. Ровно также, как никто не смотрит на кнопки электронных часов, когда устанавливает на них время — смотрят на сам экран, как там цифры меняются.
Другой момент — обратная связь, реакция приложения. В подавляющем большинстве случаев, действие пользователя с каким-то элементом интерфейса должно приводить к изменению чего-либо. И только в случае, если приложение — кривое и тормозит, пользователь обращает внимание на реакцию самого элемента. «А нажалась ли эта кнопка? Почему ничего не происходит?» Так что реакция самого элемента (если он, конечно, не совмещен с тем, что, собственно, обязано менять состояние, как в случае переключателей) в таких случаях — не более чем костыль, призванный уменьшить фрустрацию пользователя от тормозящего приложения. Кнопка, которая демонстрирует, что ее нажали, как бы говорит: «Не волнуйтесь, ваше действие очень важно для нас, сейчас все линии заняты, когда кто-нибудь освободится, мы займемся вашей проблемой.» Это вроде как и нужно делать, но, опять же, стоит помнить о реальном смысле этого.
Конечно, есть и те люди, которые печатают одним пальцем и т.п., но тут уж решение за авторами — являются ли они их целевой аудиторией, или нет.
Лично меня раздражают неотключаемые (несмотря на то, что в Developer options телефона все анимации отключены) анимационные переходы — я знаю, что реакция приложения почти каждый раз откладывается до того, как отработает анимация перехода, воруя секунды моего времени. А реально нужны эти анимации в material design только тем, кто печатает одним пальцем и думает, что у компьютера есть собственная воля, либо тем, для кого дизайн — самоценен (и у кого дофига свободного времени, чтобы на него смотреть и мастурбировать по поводу того, как он продуман). Потому что тому, кто пользуется приложением, а не рассматривает его, важна реакция и простота доступа к необходимым функциям, а не чтобы его «не пугали внезапно сменяющиеся и возникающие ниоткуда элементы интерфейса».
Не обязательно использовать рендеринг и всякие аэроэффекты, чтобы нарисовать тень — ее можно нарисовать заранее, еще в фотошопе и хранить две иконки — нажато, отжато, с практически нулевой нагрузкой.
А вот то, что плоский дизайн — хуже, чем любое выделение контрольных элементов — с этим я полностью согласен.
А вот то, что плоский дизайн — хуже, чем любое выделение контрольных элементов — с этим я полностью согласен.
Мое возмущение эффектами в данном случае касается как раз не того, что приложение «тормозит» из-за эффектов (то есть не важно, нарисованы ли они заранее или для них используются программные приемы), а того, что эти эффекты нельзя отключить, потому что разработчики считают их самоценными.
Если же приложение действительно тормозит само по себе, а эффекты позволяют ему «выиграть время», откладывая требуемую реакцию до момента, пока не отработают всякие анимации перехода — тоже ничего хорошего.
А про то, что хуже или лучше само по себе: плоский или объемный дизайн элементов, я просто вообще не писал ничего, это другой вопрос.
Если же приложение действительно тормозит само по себе, а эффекты позволяют ему «выиграть время», откладывая требуемую реакцию до момента, пока не отработают всякие анимации перехода — тоже ничего хорошего.
А про то, что хуже или лучше само по себе: плоский или объемный дизайн элементов, я просто вообще не писал ничего, это другой вопрос.
Это Apple виноват cо своей убогой iOS7+. интерфейс убили и иконки штатные. Остальные тупо начали копировать, потому что не принято думать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Графический интерфейс пользователя как отражение реального мира: тени и подъем элементов