Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Мобильная разработка доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 26
Второй вариант концепции гораздо понятнее, чем первые версии. Но меня не покидает вопрос - а почему блин все жмется в левый нижний угол? Почему не в правый? Или по центру?
Радиальное перемещение связанных групп и по сути прокрутка - в целом это удобно. Но если этих групп не будет очень много, иначе придется делать кучу вложений, а это периодически раздражает когда надо быстро перейти в нужный раздел.
Возьмем для примера телеграм (скам не хочу). Что у нас есть? Есть группы. В группах есть чаты. Некоторые чаты могут быть закрепленными. Внутри чатов могут быть темы. Внутри уже сами сообщения. Сейчас навигация от общего списка к нужному сообщению достигается от 2 до 5 переходов. Если удастся сократить хотя бы на один переход - уже хорошо.
И да, концепция отлично работает для плавающих кнопок для тех же списков, вместо всплывающего меню.
ИМХО, я бы разместил меню по центру, переход назад через свайп внизу / вверх, в зависимости от ориентации полукруга прокрутки. Целый круг тоже можно, но должен быть небольшой сектор, за которую круг с неограниченным количеством элементов должен прятаться, заодно он будет определять свайп для возврата назад по дереву навигации.
Для навигации мышью кстати за прокрутку колеса будет отвечать колесо мыши, ЛКМ для перехода на выбранное меню, а ПКМ или ЛКМ на сектор возврата - для возврата. Для навигации типа джойстик 4-позиционный или клавиатура еще проще - вверх - переход к выделенному пункту. Вниз - возврат обратно. Лево-право - смещение позиции колеса в нужную сторону. По сути будет навигация как в квестах старых.
Спасибо за развернутый комментарий и конкретные предложения по эргономике! Постараюсь ответить на все ваши тезисы:
1. Про расположение (Лево / Право / Центр) Вы абсолютно правы относительно кастомизации. В финальной версии выбор угла (левый нижний для правшей или правый для левшей, ) — это обязательная настройка. Сейчас выбрано левое положение как базовое для прототипа.
Почему не центр? Текущее угловое расположение — результат множества тестов.
Логика «барабана»: Центральное радиальное меню заставило бы нас вращать всю окружность (или большую её часть), что неудобно на вытянутых экранах смартфонов. Сейчас мы видим только 1/3 окружности. Это позволяет реализовать бесконечную прокрутку, не превращая интерфейс в громоздкое «колесо обозрения». Соты как бы «выплывают» из-за границы экрана и уходят обратно.
Наполнение уровней: Если поместить меню в центр, то для старта прокрутки необходимо будет создать сразу много элементов (штук 6), иначе круг будет выглядеть пустым. По моей задумке, не стоит делать большое количество сот на одном уровне — проще и быстрее «нырнуть» глубже, чем бесконечно крутить барабан. Поэтому соты добавляются по одной по мере необходимости.
Мертвая зона: Кнопка «назад» сейчас находится в идеальной позиции под большим пальцем, что исключает случайные нажатия при навигации, но позволяет мгновенно выйти на уровень выше.
2. Про количество переходов и когнитивную нагрузку На видео навигация может казаться медленной, потому что я стараюсь показать её плавно. На практике, когда вы используете приложение 5-й или 10-й раз, включается рефлекторная навигация.
В Telegram или любом списке вам нужно на каждом этапе прочитать строку, чтобы «прицелиться» и нажать. Это когнитивная нагрузка.
В ОРДО вы не читаете. Вы помните вектор. Спуститься на 4-5 уровней вглубь — это серия из 5-6 мгновенных микродвижений, которые делаются буквально «вслепую». Это происходит быстрее, чем скролл длинного списка и поиск нужного чата глазами.
3. Про универсальность (мышь, джойстики, клавиатура) Вы верно подметили универсальность логики. Хотя я проектировал интерфейс строго как Touch-first, математическая модель фрактальных сот действительно легко адаптируется под любой ввод:
Мышь: Колесо идеально заменяет инерционный скролл барабана, а ПКМ можно закрепить за сектором возврата.
Джойстик: Ваше сравнение со «старыми квестами» очень точно передает дух проекта. Движение Вверх — вход, Вниз — назад, Право/Лево — вращение барабана. Если интерфейс так легко ложится на 4-позиционный джойстик, значит, в его основе лежит крепкая логика, которая не рассыпается при смене устройства.
Концепция с «сектором», за который прячется круг, интересная — я думал о чем-то подобном для режима планшетов, но для узких экранов смартфонов текущая «угловая дуга» пока кажется самым компактным решением. Спасибо за идеи!
Люди честно делятся своим мнением, а вы им ИИ отвечаете.
Если выводить полукруг на 180 градусов (а больше не надо), то поместится 4, ну может 5 иконок на барабане. Этого достаточно для ориентира по соседним позициям, при этом нет большой области для прокрутки. Трёх позиций в углу мне лично маловато, 5 гораздо лучше. Опять же это может быть настраиваемым функционалом: количество иконок, градус вывода барабана.
P.S. не используйте нейронки для ответов, выглядит как чистой воды неуважение к собеседнику, мы все таки общаемся с людьми со всеми их недостатками, а не с нейронками идеализированными. Спасибо
В такой концепции кнопку “назад” некуда вставить, либо она будет прерывать соты, что тоже странно… Кстати, по-моему я не упоминал, что в настройках приложения можно включить опцию гироскопа, тогда наклоном аппарата с регулируемой силой вращается “барабан” это забавно и удобно (опять же по моему мнению). 3 мало… Мне даже такого не приходило в голову… Возможно стоит поиграть с размером сот или плотностью их распределения чтобы больше разместь, стоит попробовать, спасибо за мнение! P.S. - Про ИИ понял) я впервые тут, если честно и не совсем понимал как тут всё устроено, раз все за живое непосредственное общение то я только за:) хотя красиво оформленный текст мне тоже нравится)
Ну так я ж жто и описал. У вас размещение по центру но не с прижимом к нижней части зкрана, а чуть дальше. В верхней полусфере идет барабан выбора группы. Свайп вниз - возврат назад. Думаю 180 градусов нижней полусыеры будет достаточно для возврата Можно даже сократить верхнюю полусферу до 150 градусов. Гоавное не текущие 90, мало. Размер сот как раз оптимален под палец, не надо их уменьшать или изменять расстояния между ними, будет хуже, на мой взгляд.
Суперапп не нужен совсем.
Согласен, «раздувание» приложений часто вредит юзабилити. Но мой концепт — это не попытка продать саму идею супераппа как бизнес-модели.
Реальность такова, что любой действительно ёмкий сервис (будь то банк, госуслуги или даже сложный мессенджер) со временем неизбежно превращается в когнитивный хаос из бесконечных списков, меню и вкладок. Мой вопрос в другом: если мы всё равно обречены иметь дело с многофункциональными системами, готовы ли мы сменить привычное «кладбище иконок» на что-то более живое и рефлекторное?
Это видео — лишь попытка проверить фрактальный движок на «максимальных оборотах», чтобы увидеть, насколько эффективно соты справляются с по-настоящему глубокой структурой данных.
Реальность такова, что любой действительно ёмкий сервис (будь то банк, госуслуги или даже сложный мессенджер) со временем неизбежно превращается в когнитивный хаос из бесконечных списков, меню и вкладок.
Я понял так, что весь этот «когнитивный хаос» вы предлагаете свести к запоминанию «вектора микродвижений». Типа, «7 вверх, 3 вправо, еще 3 вверх»? И все это на подрагивающем, как студень, колесе?
А вы попробовали и вам показалось неудобным? Или посмотрели видео и вам померещился студень? Не скажу, что я предлагаю, скорее делюсь своей идеей, которая мне показалась интересной.
Желания попробовать не возникло, ограничился просмотром видео. Или на самом деле колесо не увеличивается в размере, а потом через долю секунды не возвращается к обычному размеру? Тогда может быть и погорячился насчет студня.
Просто надоели все эти «находки» нынешних «дизайнёров» от слова «комбайнёр». Листаешь страницу, а ее продолжение при проматывании то слева выезжает, то справа.
Мышь: Колесо идеально заменяет инерционный скролл барабана, а ПКМ можно закрепить за сектором возврата.
Какойтскролл барабана? Это когда Аппл вместо нормального поля ввода даты прикрутил барабан и теперь все имеют счастье крутить его до дога рождения? Минимум 18 делений а в среднем 40-50 при каждом использовании?
Вместо того чтобы ввести 4 цифры?
Вообще, такие радиальные меню уже давно отточили во всяких Maya и Blender. Как по мне там этим очень удобно пользоваться. И его даже не в отсутствии подписей (они там есть) — скорее дело в более равномерном ux и меньшей точности.
Увидеть эту идею на телефоне — это очень интересно. Но меня смущает несколько практических вопросов.
Для начала вопрос иконок. Подобрать хорошие иконки — это прям очень сложно. Почти никто с этим не справляется. Подписи нужны.
А второй вопрос: как подбирать категории. Если это статическая навигация — то может, конечно и ок. Но если пункты добавляются пользователем, то это дерево быстро становится неуправляемым. Тут либо делать какую-то хитрую автоматику (что сложно), либо заставлять пользователя заниматься организацией.
Например, если говорить об интерфейсе мессенджер, хочется иметь возможность не заниматься организацией своих контактов. А в таком случае, плоский список удобнее, т.к. в нём просто больше пунктов помещается.
Быть может имеет смысл какой-то гибридный подход, как в Maya сделать: основные, или часто используемые пункты в радиальном меню, а все остальные списком (сверху). Можно даже дальше пойти и синхронизировать скролл списка: чтобы при прокручивании радиального меню, пункты из него перетакали в список, а из списка в радиальное меню.
Про иконки согласен на 1000%. Я даже пробовал делать разные уровни или разделы по цветами, но что иконки, что цвета превращают всё в аляпистую мусорку. Я пришёл к заключению, что лучший вариант это прозрачные узлы на любых промежуточных уровнях, но выбранная иконка на заключительном узле, плюсь можно поиграть с прозрачностью. Так же неплохо смотрится если имитировать мутное стекло, под которым изображение. Про порядок и навигацию не понимаю опасений если честно, но возможно это мои проблемы/особенности… Повторюсь, я очень много времени тестировал этот подход и мне он кажется до ужаса удобным простым и запоминающимся. Я намеренно создавал длинные “корни” и не испытывал неудобств при скольжении по ним. “Но если пункты добавляются пользователем, то это дерево быстро становится неуправляемым.” - а вот тут полностью не согласен. В том то и дело, что пользователь сам добавляет узлы и выстраивает пути. Пути выстраивается логикой пользователя, когда ты сам создаешь путь типа общение-работа-проект#42-Василий, или общение-семья-родня-дальние-Дядя Петя, либо общение-семья-мама, то по моему мнению тут полная управляемость и понимание, при чем собственное логическое понимание своих же ветвей, которые ты сам построил своей логикой. Не совсем понимаю как тут можно заблудиться. Возможно я не правильно понял вашу мысль. А вы пробовали это сделать в приложении?
В том то и дело, что пользователь сам добавляет узлы и выстраивает пути
Пользователь может сам выстроить пути, или обязан? Я, как пользователь, не всегда хочу заниматься организацией. Я это знаю по опыту настройки папок и рабочего стола.
Ну, то есть, я готов настроить несколько наиболее важных мне пунктов. Но всё остальное — не то. На настройку уходит много времени и итераций. Особенно, когда регулярно добавляются новые позиции(контакты, приложения и прочее).
И уж тем более я не готов заниматься настройкой в процессе работы. Если мне написал человек, я хочу взять и ответить ему, а не сидеть и выбирать куда его распределить.
Про порядок и навигацию не понимаю опасений если честно, но возможно это мои проблемы/особенности
Я не знаю, о чём Вы. Процитируйте, пожалуйста, конкретный фрагмент моего (исходного) сообщения.
Я даже пробовал делать разные уровни или разделы по цветами, но что иконки, что цвета превращают всё в аляпистую мусорку.
Проблема не в дизайне, а скорее в том, что тяжело распознать, что значит иконка. Подписи в этом плане универсальнее.
P.S. на хабре есть блоки цитат, используйте их пожалуйста.
Про гибридный подход… Блин, возможно конечно, но хотелось чего-то простого, элементарного по сути. Повторюсь, это лишь концепт) мне показался удобным и это не значит, что так будет для всех, поэтому и прошу вашего мнения. И да, спасибо за идеи, хотя, если честно не совсем понял про перетекающие списки
Простое подходит для простых случаев. Если задача исходно сложная, её нельзя решить просто. Так называемая intrinsic complexity.
Про пересекающие списки. Как будет выглядеть Ваш барабан, если в нём будет 20-40-100 элементов? По идее, у него должен быть неполный круг, и где-то должны быть точка рождения и точка уничтожения иконок. То есть когда прокручивается барабан, крайняя иконка с одной стороны исчезает, а с другой стороны появляется новая, следующая иконка.
Точно такие же точки рождения и уничтожения находятся сверху и снизу линейного списка.
Предложение в том, чтобы объеденить одну из точек уничтожения барабана с точкой рождения списка. То есть, когда какая-то иконка пропадает с барабана при прокрутка, она тут же появляется сверху/снизу списка. Ну и они соответственно скролятся синхронно.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Интерфейсная биомимимикрия: может ли фрактальная навигация заменить «кладбище иконок» в SuperApp?