Comments 49
Спасибо за перевод, а можете объяснить как с ним связан скриншот контакт листа?
Он демонстрирует одну из основных проблем современных интерфейсов, когда берут старый интерфейс, добавляют пустого места побольше и запихивают в экран поменьше.
Конкретно интерфейсу этого окошка ещё повезло: в нём не было ничего, что можно было бы из него выдрать и новом варианте запрятать так, что сходу хрен найдёшь.
Поле поиска теперь хрен найдешь, без границ и одного цвета с нижней плашкой поди еще пойми, где оно.
И отсутствие границ в табличных данных — это тоже повсеместный современный идиотизм. Ладно еще, здесь узенькая колонка, но даже это создает неудобства, а когда большие таблицы?
И отсутствие границ в табличных данных — это тоже повсеместный современный идиотизм. Ладно еще, здесь узенькая колонка, но даже это создает неудобства, а когда большие таблицы?
это из книги Refactoring UI — refactoringui.com
Картинка в начале статьи притянула тем что я с ней не согласен. Слева (под красным крестиком) выглядит лучше, удобнее чем справа.
Сама статья какая-то нудная и я её не осилил. И так и не понял связана ли она как-то с картинкой или нет.
Сама статья какая-то нудная и я её не осилил. И так и не понял связана ли она как-то с картинкой или нет.
UFO just landed and posted this here
Правая картинка с зелёной галочкой «лучше» тем, что соответствует базовым рекомендациям типографики и дизайна в web-е:
- если есть что убрать — убирай (чем меньше визуального шума — тем легче/быстрее воспринимать информацию)
- вместо границ/бордеров предпочтение лучше отдавать отступам («правило внутреннего и внешнего»)
- наглядная гифка, которая частично раскрывает суть вопроса
hsto.org/getpro/habr/comment_images/a12/ee4/81d/a12ee481df93e55ef57a90c8533d6868.gif - также кнопки действия более явно с помощью плашки отделены в футере от основного контента списка
если есть что убрать — убирайКто решает какой элемент лишний? Почему лишним элементом оказывается постоянно очень полезная для меня окантовка-граница элемента? Чем лучше видишь боковым зрением элемент, тем быстрее попадёшь в него мышкой. Логично?
вместо границ/бордеров предпочтение лучше отдавать отступамВот об этом я и писал выше. Почему??? Кто придумал это правило, и почему его надо применять везде? А критически поразмыслить не судьба?
наглядная гифка, которая частично раскрывает суть вопросаЯ не считаю, что всё из этой гифки применимо везде. Думать надо всегда.
также кнопки действия более явно с помощью плашки отделены в футере от основного контента спискаА вот это хорошо.
Чем лучше видишь боковым зрением элемент, тем быстрее попадёшь в него мышкой. Логично?
Не логично. Если только вы не покажите, как вы попадаете мышкой в цель, которая находится в области бокового зрения.
Вот об этом я и писал выше. Почему??? Кто придумал это правило, и почему его надо применять везде? А критически поразмыслить не судьба?
Как уже написали выше: потому что отступы создают меньше шума. Именно поэтому правило так и звучит: «предпочтение лучше отдавать». И это не значит, что везде нужно использовать отступы, а не бордеры. Это значит, что как раз нужно использовать критическое мышление. Для которого хорошо бы сначала изучить матчасть.
Если только вы не покажите, как вы попадаете мышкой в цель, которая находится в области бокового зрения.Сделайте или представьте, что у вас панель задач скрывается. Насколько быстро вы будете переключать на ней окна по сравнению с нескрывающейся панелью? Если она статическая, то вы заранее видите примерно где расположен нужный элемент и начинаете вести курсор в ту сторону, а потом постепенно рулите к нему. А если панели нет, то вы ведёте примерно к центру панели (или в нужную половину экрана), ждёте появления панели и ведёте к нужному элементу.
В данном случае происходит примерно то же самое, только менее выражено. И элемент, обрамлённый рамкой, лучше заметен.
потому что отступы создают меньше шумаА вот это как-то доказано? Вон, например, в Материал Дизайне (мало с какой частью я там согласен, конечно) вместо разделения отступами придумали карточки. А это визуальный шум по вашему, ибо рамки :) Вот справа на этой странице, в блоке «Что обсуждают» можно было сделать красивые карточки вместо цельного блока с разделителями. Это было бы плохо по-вашему?
Для которого хорошо бы сначала изучить матчасть.Проблема в том, что эта матчасть вся очень противоречивая.
Конечно, элемент, который обрамлён рамкой, лучше заметен. В этом и проблема. Если всё обвести рамками, всё начнёт кричать. Под «шумом» подразумевается то, что каждый элемент (в том числе и пустоту) мозгу необходимо прочитать и обработать. Но пустоты считываются легче. Всё это особенно критично, когда мы учимся работать с интерфейсом. Конечно, потом мозг привыкает и быстрее отбрасывает мусор. Но вероятность совершить ошибку всё равно выше, потому что мусор продолжает создавать лишнюю нагрузку.
То что в Материале есть карточки, не значит, что их нужно использовать везде.
Не думаю, что матчасть противоречивая. Скорее её мало кто знает. Я программист, немного интересующийся дизайном. И даже при этом вижу грубые ошибки повсюду. То что дизайнеры убирая рамки и увеличивая отступы, например, забывают о контрасте и правиле внутреннего и внешнего, не значит, что рамки нужно пихать везде. Приёмов ещё много.
Особенно достало читать в комментах выпады в сторону анимации. Если вас анимация бесит, это значит, что анимация хреновая, а не то что она не нужна. И тоже самое с другими современными тенденциями в дизайне. Не тенденции плохие, а дизайнеры (или программисты), которые не понимают их сути. Достаточно посмотреть на тот же Материал и на CSS-фреймворки, его реализующие.
То что в Материале есть карточки, не значит, что их нужно использовать везде.
Не думаю, что матчасть противоречивая. Скорее её мало кто знает. Я программист, немного интересующийся дизайном. И даже при этом вижу грубые ошибки повсюду. То что дизайнеры убирая рамки и увеличивая отступы, например, забывают о контрасте и правиле внутреннего и внешнего, не значит, что рамки нужно пихать везде. Приёмов ещё много.
Особенно достало читать в комментах выпады в сторону анимации. Если вас анимация бесит, это значит, что анимация хреновая, а не то что она не нужна. И тоже самое с другими современными тенденциями в дизайне. Не тенденции плохие, а дизайнеры (или программисты), которые не понимают их сути. Достаточно посмотреть на тот же Материал и на CSS-фреймворки, его реализующие.
Плюсануть не могу, к сожалению. А то бы плюсанул.
На все твои «почему?» я отвечу очень просто: потому что есть придуманные кем-то, основанные на хрен знает чём некие «правила», которым многие люди начинают (не думая) следовать и получаем то, что получаем. Те самые блёклые, практически однотипные для разных сайтов дизайны. Где, плюс ко всему, не всегда можно быстро разбраться, где что находится.
На все твои «почему?» я отвечу очень просто: потому что есть придуманные кем-то, основанные на хрен знает чём некие «правила», которым многие люди начинают (не думая) следовать и получаем то, что получаем. Те самые блёклые, практически однотипные для разных сайтов дизайны. Где, плюс ко всему, не всегда можно быстро разбраться, где что находится.
вместо границ/бордеров предпочтение лучше отдавать отступам («правило внутреннего и внешнего»)
Для контента, с которым не нужно интерактивно взаимодействовать, оно так и есть. Но закон Фиттса говорит в пользу границ.
Как связаны Фиттс и границы? Чтобы увеличить область нажатия, границы не нужны.
Зато границы помогают не потерять строку, если вдруг между левым и правым столбцом оказалось много пустого места, например, из-за нескольких коротких имён и фамилий подряд.
Именно нужны, иначе её бесполезно увеличивать. Закон Фиттса работает ведь на человеке, а не на программе. Если человек не видит размеры области нажатия из‐за отсутствия границ, то он склонен считать областью саму надпись и будет целиться именно в неё.
На практике это будет не так. Кто-то будет в обоих случаях целится в надпись, а кто-то — в область вокруг. Здесь личный опыт сработает сильнее всяких рамок. Если хотите, чтобы 100% пользователей поняли, что вся область кликабельна, сделайте каждый пункт меню в виде большой нестилизованной <button>. И радуйтесь, что вы решили эту задачу, убив всё остальное.
Человек не думает ни о каких областях нажатия. Он кликнет так, чтобы ему было понятно, чего он хочет. А когда из-за плохого дизайна машина его не поймёт, он переучиться кликать на саму надпись, а не на область. И бордеры не исправят это. Только cursor: pointer и время, проведённое с нормальным интерфейсом.
Если человек не видит размеры области нажатия из‐за отсутствия границ, то он склонен считать областью саму надпись и будет целиться именно в неё.
Человек не думает ни о каких областях нажатия. Он кликнет так, чтобы ему было понятно, чего он хочет. А когда из-за плохого дизайна машина его не поймёт, он переучиться кликать на саму надпись, а не на область. И бордеры не исправят это. Только cursor: pointer и время, проведённое с нормальным интерфейсом.
Статья скорее для тех, кто рулит, а не гребёт. Правильные вопросы задаёт.
>Слева (под красным крестиком) выглядит лучше, удобнее чем справа.
Аналогично. Дизайнеры,… дь.
Аналогично. Дизайнеры,… дь.
Увидел КДПВ, не согласился, подгорел, статью ниосилил, комменатрий написал
Ничего, вроде, не забыл?
Ничего, вроде, не забыл?
Ошибка на обеих картинках в том, что сортировка по фамилии, а выравнено по имени, поэтому взгляд бегает зигзагом при прокрутке и попытке что‐то найти.
Я тоже считаю, что левый вариант правильнее, и могу аргументировать: намного удобнее заранее (не при наведении курсора, например) видеть границы элемента чтобы кликнуть/тапнуть правильно.
Кроме того, есть какая-то статистика по количеству пенсионеров/плоховидящих/инвалидов, которым нужно делать элементы шире? Я, почему-то, уверен, что людей, способных тапнуть по правильному элементу на первом скриншоте больше, чем тех, кто промахнётся. И тогда элементов на экране будет больше, что правильно. А если уже очень в жопе свербит, то делайте 2 варианта интерфейса — нормальный и широкий (но не как некоторые делают — широчайший и «компактный»).
Кроме того, есть какая-то статистика по количеству пенсионеров/плоховидящих/инвалидов, которым нужно делать элементы шире? Я, почему-то, уверен, что людей, способных тапнуть по правильному элементу на первом скриншоте больше, чем тех, кто промахнётся. И тогда элементов на экране будет больше, что правильно. А если уже очень в жопе свербит, то делайте 2 варианта интерфейса — нормальный и широкий (но не как некоторые делают — широчайший и «компактный»).
Лично для меня правый вариант визуально приятнее:
- Нет отвлекающих бесполезных линий (разделители имен) — кликать я в любом случае буду по имени, а не по области. Если в левый список добавить 20 имен — зарябит в глазах
- "Поочередная" цветовая гамма разделяет принципиальные элементы формы (белый фон заголовка, серый фон строки поиска, белый список контактов, серый фон кнопок управления)
- "Объемная тень" вокруг формы (не знаю как этот эфект называется). Визуально смотрится хорошо, правда не уверен как это будет работать поверх других элементов страницы (хотя если это список не поверх страницы, тогда ок)
кликать я в любом случае буду по имени, а не по областиВот об этой проблеме я и писал. Вам требуется намного более точно поднести курсор, а с границами (видимыми всегда) можно намного быстрее и точнее целиться.
Если в левый список добавить 20 имен — зарябит в глазахНо малое количество строк заставит вас (больше) скроллить и тратить больше времени на простую задачу. Каждый наскок скролла заставляет ваш мозг перенастроить глаза и перепарсить список.
Вот об этой проблеме я и писал. Вам требуется намного более точно поднести курсор, а с границами (видимыми всегда) можно намного быстрее и точнее целиться.
Я не вижу разницы в наведении курсора на имя с рамкой или без. Я в любом случае навожусь на текст. А по пустой области я кликать никогда не буду — мой опыт говорит мне о том, что слишком часто разработчики не думали о такой возможности и клик по области не работал
Могу только добавить мои первые реакции на каждый из список: Когда я вижу левый список моей инстинктивной реакцией является разглядывать его (фокус на всех этих черточках). Когда я вижу правый список я начинаю читать имена
Если точнее, то с гланицами можно быстрее и менее точно целиться.
Есть такой очень маленький момент с этим «тапать». Я вот всегда делал элементы без границ максимально большими, чтобы не надо было целится «ровно в яблочко текст». Без бордеров потому что обычно нав не нуждается в бордерах, ибо (!) не должен привлекать лишнее внимание — все и так знают где он находится и что там примерно стоит ожидать.
Это мой способ, а вот у компании Яндекс почему-то очень разный подход к этому. Например, на Я.Музыке кнопки во всю высоту блока навигации, а вот на Я.Переводчике они играют роль табов и резко по размерам становятся равны обычным кнопкам. Из чего есть вот такое личное наблюдение: на музыке я могу спокойно тыкать пальцем в знакомую область и не материться, что промахнулся. В переводчике же я должен чётко попадать по слову, потому как совершенно не понятно, где же там заканчивается эта магическая кнопка-вкладка.
Это мой способ, а вот у компании Яндекс почему-то очень разный подход к этому. Например, на Я.Музыке кнопки во всю высоту блока навигации, а вот на Я.Переводчике они играют роль табов и резко по размерам становятся равны обычным кнопкам. Из чего есть вот такое личное наблюдение: на музыке я могу спокойно тыкать пальцем в знакомую область и не материться, что промахнулся. В переводчике же я должен чётко попадать по слову, потому как совершенно не понятно, где же там заканчивается эта магическая кнопка-вкладка.
В двух словах он описывает проблемы сложныех интерфейсов и сетует, что нет простых способов их разрешить.
Ну ок.
Поведение кнопки «Назад», время отклика и навигация (все в вебе, понятное дело) это проблемы созданные этими самыми инженерами, которые сейчас сокрушаются о том, что интерфейсы стали не торт.
Ну ок.
Поведение кнопки «Назад», время отклика и навигация (все в вебе, понятное дело) это проблемы созданные этими самыми инженерами, которые сейчас сокрушаются о том, что интерфейсы стали не торт.
UFO just landed and posted this here
Возможно я неправильно выразился: в платформе проблем нет. Есть проблемы с инженерами, которые ее неправильно используют и удивляются тому, что у них трудности.
UFO just landed and posted this here
Мне сложно ответить на что-то чего я не утверждал.
Веб можно использовать для построения сложных интерактивных интерфейсов, но не нужно придумывать революционные решения типа бесконечной прокрутки и изменения поведения кнопок, чтобы потом с ними мужественно бороться, а нужно изначально строить интерфейсы которые используют имеющийся функционал.
Веб можно использовать для построения сложных интерактивных интерфейсов, но не нужно придумывать революционные решения типа бесконечной прокрутки и изменения поведения кнопок, чтобы потом с ними мужественно бороться, а нужно изначально строить интерфейсы которые используют имеющийся функционал.
All this issues are solved, except Priority yet.
Я видел пару ваших демок. Таблица, у которой прыгают границы столбцов во время прокрутки — это точно не вписывается в принципы хорошего дизайна.
- При чём тут дизайн?
- Колонка фиксированной ширины будет либо тратить пространство впустую, когда в видимой области нет больших данных, либо обрезать эти данные. Тоже не идеальные варианты.
- Ширины колонок не сложно зафиксировать.
- Ну и дайте ссылку на принципы хорошего дизайна что ли. А то я тут парюсь, из 3 зол выбираю. Есть же, наверно, идеальное решение.
1. UX затрагивается в статье во многих местах. Конкретно эта проблема, на мой взгляд, описывается в пункте Navigation:
… и прыгать.
2. Пусть так. Но прыгать в интерфейсе ничего не должно. Тогда изменение ширины нужно анимировать. Но мне кажется, что в большинстве случаев фиксированная ширина сработает лучше.
3. Я, кстати, не уверен. Меняя DOM при скроле вы решили одну проблему, создав другую.
4. Очень много вопросов хорошо разобраны в советах Бюро: bureau.ru/bb/soviet. Не какие-то догмы, а аргументированные разборы задач.
Я ненавижу Реакт не меньше вашего. И как раз хотел написать комментарий, что Дэн отбросил сообщество в создании качественного UX назад. Если добавление самой микроскопической функции требует изменение нескольких слоёв, разбросанных по нескольким файлам — на хороший UX внимания уже не остаётся. Если базовые задачи раздроблены на десятки плохо связанных библиотек — на хороший UX внимания уже не остаётся.
Вы как всегда пытаетесь сделать вид, что у $mol всё хорошо из коробки. Но вот вам камень в оба огорода: что в документации Redux, что в демках $mol не сохраняется положение скролла при движении по истории (History Back). Наши инструменты должны сами решать такие проблемы по умолчанию, без прикладывания усилий.
Мы ожидаем, что интерфейс будет «стабильным» при взаимодействии с ним. Элементы не должны внезапно исчезать
… и прыгать.
2. Пусть так. Но прыгать в интерфейсе ничего не должно. Тогда изменение ширины нужно анимировать. Но мне кажется, что в большинстве случаев фиксированная ширина сработает лучше.
3. Я, кстати, не уверен. Меняя DOM при скроле вы решили одну проблему, создав другую.
4. Очень много вопросов хорошо разобраны в советах Бюро: bureau.ru/bb/soviet. Не какие-то догмы, а аргументированные разборы задач.
Я ненавижу Реакт не меньше вашего. И как раз хотел написать комментарий, что Дэн отбросил сообщество в создании качественного UX назад. Если добавление самой микроскопической функции требует изменение нескольких слоёв, разбросанных по нескольким файлам — на хороший UX внимания уже не остаётся. Если базовые задачи раздроблены на десятки плохо связанных библиотек — на хороший UX внимания уже не остаётся.
Вы как всегда пытаетесь сделать вид, что у $mol всё хорошо из коробки. Но вот вам камень в оба огорода: что в документации Redux, что в демках $mol не сохраняется положение скролла при движении по истории (History Back). Наши инструменты должны сами решать такие проблемы по умолчанию, без прикладывания усилий.
А можете развернуть мысль: за что вы ненавидите Реакт?
И что вы имеете в виду: что Дэн в посте неправильно описал актуальные проблемы, или что он своим вкладом в Реакт нанес вред сообществу?
Я имел ввиду, что нас отбросили назад Реакт и Редакс.
Реакт слишком низкоуровневый. Отказ от двустороннего датабиндинга — ошибка. Это не решение проблемы, а бегство. Аналогично можно отказываться от высокоуровневых ЯП и писать всё на Ассемблере, чтобы делать всё явно. На простых задачах десятки строк Реакта и Редакса — просто двусторонний датабиндинг написанный явным образом. На сложных — все эти ограничения по потокам данных никак не помогают. С двусторонним датабиндингом легко запутаться. А в решении проблем, которые созданы ограничениями Редакса, невозможно не запутаться.
Реакт слишком низкоуровневый. Отказ от двустороннего датабиндинга — ошибка. Это не решение проблемы, а бегство. Аналогично можно отказываться от высокоуровневых ЯП и писать всё на Ассемблере, чтобы делать всё явно. На простых задачах десятки строк Реакта и Редакса — просто двусторонний датабиндинг написанный явным образом. На сложных — все эти ограничения по потокам данных никак не помогают. С двусторонним датабиндингом легко запутаться. А в решении проблем, которые созданы ограничениями Редакса, невозможно не запутаться.
что в документации Redux, что в демках $mol не сохраняется положение скролла при движении по истории (History Back). Наши инструменты должны сами решать такие проблемы по умолчанию, без прикладывания усилий.
Ради интереса — а можете привести пример готовой либы, которая автоматически без конфигурирования разруливает все подобные вещи? (и наверное состояние всех input,select,*, textSelection, что там ещё бывает).
На всякий случай сразу уточню — у любого domBlock-а может быть скролл, получается нужно отслеживать всё dom-поддрево на предмет его наличия, пытаться его сопоставить при прыжках по истории и восстанавливать. Но всё решаемо, конечно.
Не думаю, что кто-то заморачивался над скроллами каждого блока на странице. Опять же, мы просто не подошли к этой проблеме. Куча более банальных вещей требуют нашего внимания.
Что касается инпутов и прочего, я решал так: делал в глобальном стейте ветки, синхронизированными с History state и c URL query. Дальше остаётся только поместить нужные данные внутрь этих веток и их состояние будет сохраняться при переходах по истории или даже при перезагрузке страницы. Всё ещё нужно задуматься, какие данные где хранить, но дальше дополнительных действий не требуется.
Что касается инпутов и прочего, я решал так: делал в глобальном стейте ветки, синхронизированными с History state и c URL query. Дальше остаётся только поместить нужные данные внутрь этих веток и их состояние будет сохраняться при переходах по истории или даже при перезагрузке страницы. Всё ещё нужно задуматься, какие данные где хранить, но дальше дополнительных действий не требуется.
Элементы не должны внезапно исчезать и прыгать.
Так они не внезапно, а в ответ на действие пользователя. Я согласен, что анимированное изменение ширины колонок было бы вообще классно. Но даже скачок — лучше, чем вот это с предложением двигать вручную колонки туда-сюда:
Именно для работы лучше, а не для "подёргать за скроллбар".
в демках $mol не сохраняется положение скролла при движении по истории (History Back).
Оно было изначально везде, но потом я это выпилил, оставив лишь там, где это действительно нужно. Например, тут: http://mol.js.org/app/habhub/
Дело в том, что не всякий раз скроллинг должен восстанавливаться. Там много нюансов специфичных для конкретных мест использования. Например, в HabHub позиция скроллинга запоминается отдельно для каждой статьи, что позволяет продолжить чтение с того места, на котором остановились ранее, даже если вернулись не "назад", а "вперёд", кликнув по ссылке на предыдущую статью. И делается это тремя строчками кода.
[deleted]
Озвучивание проблем — это хорошо. Но еще бы хотелось посмотреть и предлагаемые варианты их решения :) Без них статья получается какая-то незавершенная, что ли. И лучше бы разные варианты решений, с плюсами и минусами каждого из них. Тогда было бы что обсуждать.
Sign up to leave a comment.
Основные проблемы разработки современных интерфейсов