Хабр Курсы для фронтендеров
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Фронтенд доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 32
Закреплённые комментарии
Вообще, тут не помешал бы ваш комментарий, @Boomburum.
Извините, но зачем делать настолько короткие статьи? И почему они проходят модераццию?
А почему они не должны проходить подерацию? И чем длинная статья лучше короткой?
Тут конкретный кейс, конкретное мнение. Идею передал читателю, можно сохранить в закладки что бы в нужный момент поделиться с коллегами готовой сформулированной мыслью, которая не займет 2 часа чтения.
Ну вообще понимаю вас. Я хотел пост оформить. Но так как в материале больше 1 изображения, Хабр отправил меня в формат статей.
PS
Что бы не было обмана ожиданий, Хабр специально добавили счетчик длительности чтения статьи в минутах, на preview-карточке. Тут кстати хороший пример UX решения :)
Извините, но зачем делать настолько короткие статьи?
Это куда лучше, чем водянистые - где смысла столько же, а текста в разы больше.
Нас дизайнер буквально говорил "в этом списке должно быть видно x элементов, остальное скроллится". А ты попробуй ещё объясни дизайнеру, что у него дизайн неправильный)
Если бы только это. Ещё и гигантские пустые поля, как минимум вдвое увеличивающие фактический размер элементов.
Для примера вклеил в картинку скрин выпадающего списка, взятого из программы, разработчики которой смутно догадываются, что моднявый смартфонный пальцетык на десктопе не очень применим.
Скрытый текст
Самый большой лол я видел в Яндекс.Маркете: там у них в фильтрах когда-то пустые боковые поля масштабировались пропорционально размеру окна, нормально отображаясь только на полноэкранном FullHD.
Да! Прям попали еще в одну болевую точку. В целом, даже на десктопе я не люблю слишком маленькие UI элементы в которые приходиться попиксильно целиться. Но и огромные UI элементы раздражают, когда они необосновано сжирают место.
Как-то раз на работе дизайнер рисовал что-то вроде Excel таблицы. В дизайне выглядело все безупречно, но когда это сверстали, огромные статисческие куски (header, footer) сжирали все место на экране, оставляя так же маленькую щель на строку таблицы (6-7 строк помещалось). Их вполне можно было уменьшить в несколько раз и сделать удобный для пользователя интерфейс.
Но это было в Альфабанке и согласовывать изменения инпутов UI-kit’а под конкретную задачу, потом идти с этим к руководителю UI/UX, а потом еще куда-то выше — дело крайне не благодарное. Мою идею завернули уже на уровне перепски в tg и в прод выкатили то, против чего я протестовал.
Современный UI явно свернул куда-то не туда. Я ведь еще помню, как панель управления Windows прекрасно умещалась на 14-дюймовом пузатом Синкмастере 3NE. А сейчас на 30-дюймовом мониторе ее приходится скроллить.
Вроде и правда фигня какая-то, но потом вспомнил что давно уже ничего не скролю, ибо нафига листать100500 элементов (особенно в мобильных девайсах типа потрать на установку будильника 2 часа), а пользуюсь текстовым поиском в интерфейсах. Проверил в интерфейсе создания поста - вроде работает...
Любой поиск по точному совпадению хорош там, где ты точно знаешь что искать. Поэтому я забросил пуск винды после хр, без иерархического, в котором видно весь путь, не могу там решительно ничего найти.
Про выпадающие списки - там соглашусь, если сразу понятно что вариантов много, то ищу и выбираю хоть что-то похожее на то, что нужно. Скорее всего там выбор будет не сильно важный, при таком количестве.
давно уже ничего не скролю ... а пользуюсь текстовым поиском в интерфейсах.
И все пользуются, потому что по-другому большинство пунктов найти либо сложно, либо вообще невозможно физически - путь к ним попросту отсутствует в иерархии меню. Чтобы в них попасть, нужно посветить лунным светом и сказать волшебное слово "меллон".
Да, есть поиск, и он помогает — можно не скроллить, а сразу напечатать. Но откуда мне знать, что именно печатать, если разработчики решили выдавать список из 100+ элементов порциями по 4 штуки?
Простите, ЧТО?) Речь же о настройках вашей публикации. Вы понятия не имеете, о чём пишете, и поэтому вам нужно увидеть весь список, прежде чем начать вписывать в поле поиска название подходящего хаба? И виноват в этом интерфейс хабра, всё так?
Если вести переписку с точки зрения эскалации конфликта — да, все так, черт возьми!
Но если адекватно — скорее всего мне просто не удалось донести проблематику и основную мысль, раз появился такой комментарий. Тезисно еще раз про суть проблемы:
Я написал статью, я знаю о чем она и на какую аудиторию. Но я понятия не имею как Хабр структурировал и класифицировал все эти IT-темы/базворды/направления IT/теги и т.д. Следовательно на этапе публикации стать у меня запрос на то, что бы увидеть всю структуру которая есть в виде списка. Но мне предлагают знакомиться с ней исключительно через поиск или пролистывание с 4 элементами на экране. Мне не удобно, я загнан в тупик. Вдруг я не знаю о каком-то термине который очень популярен и идеально подходит к моей статье. Я не храню в голове все Хабы, я хочу их видеть или просмотреть большим списком.
Именно поэтому в таком случае вы вписываете первые буквы, как вам кажется, подходящего хаба в поиск, и находите подходящий результат. Если хабов 100, и список пролистывается не с 4 элементами на экране, а с 20 - что-то принципиально изменится разве? Вам всё ещё придётся просмотреть все 100, с таким подходом, разве что проскроллить нужно будет кратно меньше. Зато тем, кто привык пользоваться поиском, придётся теперь смотреть на огроменный вываливающийся список.
А если 1000 будет, что тогда? Тоже будете говорить "хочу их видеть или просмотреть большим списком"? Поиск вашу проблему решил, названия хабов +- кореллируют с названиями, которые мы используем в реальной жизни, с возможными тематиками. Остальное уже ваши придирки/хотелки чисто под себя
Изменится количество лишних действий. Перемещение взгляда занимает меньше времени и требует меньшей точности моторики рук, чем прокрутка списка. Плюс при прокрутке еще нужно отслеживать "якорь", чтоб не прокрутить лишнего (это время и, опять-таки точность и лишние движения).
А если в списке прокрутки будет 1000 элементов - то это весомый аргумент уволить дизайнера UI. Потому что даже 100 элементов - это много для восприятия общем списком (но хотя бы меньше 150, которое психологами считается пределом).
Накидаю ещё вопросов вдогонку. Допустим у нас имеется выпадающий список на 20 элементов, вы победили. Как он должен вести себя, если сам элемент, открывающий выпадающий список, находится посередине страницы? Открыться в любую сторону с выносом элементов списка за пределы экрана? Открыться с обрезанием до границ экрана? Как такой список поведёт себя на экране в 15 дюймов с масштабированием в 50%? Если вы об этом не думали, предлагая свои хотелки, то вряд ли вы вообще фронтенд)
Короткий же выпадающий список исключает все эти проблемы, потому что ему так или иначе хватит места открыться в какую-либо сторону
Как он должен вести себя, если сам элемент, открывающий выпадающий список, находится посередине страницы? Открыться в любую сторону с выносом элементов списка за пределы экрана? Открыться с обрезанием до границ экрана? Как такой список поведёт себя на экране в 15 дюймов с масштабированием в 50%?
Открывается на столько, сколько есть места на экране.
Если select внизу экрана, а места нет, его можно открывать вверх, а не вниз.
Некоторые делают так: список открывается вниз и выпадает за видимые пределы области экрана (надо подскролить основную старицу вниз что бы увидеть весь список) — это дешевое решение, компромис между быстрой реализацией и удосбвтом пользователя.
Если вы об этом не думали, предлагая свои хотелки, то вряд ли вы вообще фронтенд)
10 лет опыта с FE, я какие только реализации не делал. Но тут не надо быть FE разработчиком, достаточно просто увидеть более user-friendly реализацию на любом другом сервисе.
PS
Но та реализация которая демонстрируется в статьей — самый халтурный способ из всех имеющихся
Есть такое понятие как когнитивная нагрузка, еще закон Миллера.
Может быть список сделан исходя из этих моментов, а не то как вы подумали.
Да! Нужен конкретный сценарий чтобы подтвердить смысл выпадающего списка с отображением максимально допустимого в экран ))) количества элементов
Автор, собственно, этот сценарий и приводит. Суть в том, насколько содержимое списка пользователю знакомо или интуитивно понятно.
Если список содержит предсказуемые сущности (например, список стран), а пользователь точно знает что ищет (свою страну) - естественно никто ничего скролить не будет, а сразу воспользуется поиском.
А в случае с хабами содержимое списка понятно лишь примерно, но что именно я там должен выбрать - так сходу непонятно. Нужно либо просматривать всё, либо мучать поиск догадками.
Тогда не представляю как должно быть "правильно" для этого элемента ввода, с точки зрения UI/UX, потому что растянуть список по высоте до размеров экрана это неполноценное решение, которое все равно заставит скроллить, а отображение огромного модального окна чтобы выбрать эти элементы тоже, на мой взгляд, странно
Ну и как подметили выше - отображение всего содержимого повышает когнитивную нагрузку, будет разбегаться глаза
Если нужно выбрать из десятков - сотен элементов, по возможности делаю окно с многоколоночным списком. если это уместно, то с разделением по категориям.
Вообще, тут не помешал бы ваш комментарий, @Boomburum.
А точно ли отображение фиксированного количества элементов в выпадающем списке (напр. 4.5) является антипаттерном?
В большинстве случаев не имеет ценности отображать выпадающий список высотой во весь экран, чтобы выбрать пару элементов, а в других случаях хватит поиска
Мне как пользователю все содержимое списка не известно, и я бы хотел хотя бы раз просмотреть его целиком, чтобы примерно запомнить, из чего он состоит.
Откуда мне узнать содержимое списка если мне дали только 4-5 элементов на выбор и поиск. Но в целом замечание верное, зависит от контекста. В данном контексте просмпотр списка нужен
Русский UX - суровой и беспощадный!
Вчера у одноклассника настраивал подключение системы умного отопления ZOND к котлу - вот там надо было или телепатом или близким другом дизайнера: непонятно ни как войти в режим изменений н как сохранить изменений.
Причём в бумажной документации тоже оь этом не говорилось.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
FE-разработчики, перестаньте буквально воспринимать дизайн