В прошлом посте https://habr.com/ru/articles/1045002/ я рассказывал про ORDO как про приватный мессенджер с нестандартной навигацией. Но сегодня я хочу отложить тему анонимности и поговорить о чем-то более глобальном — о том, как мы взаимодействуем с информацией в 2026 году.
У меня есть гипотеза, и я хочу проверить её вместе с вами.
Проблема: «Интерфейсная свалка»
Современные SuperApp (или любые ёмкие сервисы) превратились в бесконечные списки, меню и подменю. Нас окружает «кладбище иконок». Каждый раз, открывая такое приложение, мы вынуждены вчитываться в названия разделов. Мы тратим когнитивный ресурс на сканирование текста. Возможно я утрирую, но всё же...
В живой природе нет списков и таблиц. Информация там организована через узлы, ветви и связи. Это называется биомиметикой. (да, я снова об этом:)) Я задался вопросом: а что, если применить этот принцип к сложным системам? Так появилась «другая сторона» моего движка — универсальная оболочка для SuperApp.
Я подготовил короткое демо, где попытался упаковать в соты структуру Госуслуг, банковского сервиса и мессенджера одновременно.
Видео презентация концепта:
https://youtube.com/shorts/tT5JbExW3Gc
О чем это видео и почему мне кажется, что это путь?
Я выделил три момента, в которых вижу потенциал. Посмотрите и скажите: это правда удобно или у меня «авторские галлюцинации»?
1. Навигация на кончиках пальцев (Spatial Memory) В классическом меню мы ищем глазами. Здесь же работает пространственная память.
Первый уровень: базовые векторы (Общение, Госуслуги, Финансы, Город).
Второй уровень: детализация (в Госуслугах — Поликлиники, Документы; в Финансах — Карты, Счета). Все на расстоянии одного жеста. Вам не нужно искать раздел «Штрафы», палец сам помнит вектор движения (например, «вверх-вправо и еще раз вправо»). Мозг освобождается от задачи «чтения» и поиска.
2. Сота как живой контейнер В сотах сокрыта огромная гибкость. Сота — это не просто кнопка. В моем прототипе на Kotlin + Compose сота легко превращается в любой объект. Обратите внимание на момент в видео с водительским удостоверением: сота не просто ведет в раздел, она сама разворачивается в информационную карточку документа. Это и есть бесшовность.
3. Единая экосистема без швов Главная идея, которая меня драйвит: пользователь не должен замечать, что он переключается между разными сервисами. В этой оболочке общение с мамой, оплата налога и проверка расписания транспорта выглядят как перемещение по одному живому организму.
Техническая сторона вопроса
Весь этот «оркестр» управляется фрактальным движком. Использование Jetpack Compose позволяет делать такие переходы плавными и легкими для системы. Это доказывает, что концепция жизнеспособна не только на бумаге, но и в коде.
Вместо вывода — вопрос к сообществу
Я вижу в этом потенциал альтернативного лаунчера или даже новой философии оболочек для ОС, где всё «под рукой», а не «под списком».
Но я — создатель, и мой взгляд замылен. Мне правда интересно услышать ваше мнение:
Есть ли у такого «пространственного» подхода будущее в реальных массовых сервисах?
Готовы ли мы отказаться от привычных списков ради рефлекторной навигации?
Или это слишком радикально и «мозг» пользователя не захочет переучиваться?
Буду рад любым размышлениям и здоровому скепсису в комментариях!
⬢ GitHub проекта: github.com/YOURORDO/ORDO
Комментарии (25)
nbkgroup
11.06.2026 22:29Суперапп не нужен совсем.
Synthesis0100 Автор
11.06.2026 22:29Согласен, «раздувание» приложений часто вредит юзабилити. Но мой концепт — это не попытка продать саму идею супераппа как бизнес-модели.
Реальность такова, что любой действительно ёмкий сервис (будь то банк, госуслуги или даже сложный мессенджер) со временем неизбежно превращается в когнитивный хаос из бесконечных списков, меню и вкладок. Мой вопрос в другом: если мы всё равно обречены иметь дело с многофункциональными системами, готовы ли мы сменить привычное «кладбище иконок» на что-то более живое и рефлекторное?
Это видео — лишь попытка проверить фрактальный движок на «максимальных оборотах», чтобы увидеть, насколько эффективно соты справляются с по-настоящему глубокой структурой данных.
JuryPol
11.06.2026 22:29Реальность такова, что любой действительно ёмкий сервис (будь то банк, госуслуги или даже сложный мессенджер) со временем неизбежно превращается в когнитивный хаос из бесконечных списков, меню и вкладок.
Я понял так, что весь этот «когнитивный хаос» вы предлагаете свести к запоминанию «вектора микродвижений». Типа, «7 вверх, 3 вправо, еще 3 вверх»? И все это на подрагивающем, как студень, колесе?
Synthesis0100 Автор
11.06.2026 22:29А вы попробовали и вам показалось неудобным? Или посмотрели видео и вам померещился студень? Не скажу, что я предлагаю, скорее делюсь своей идеей, которая мне показалась интересной.
JuryPol
11.06.2026 22:29Желания попробовать не возникло, ограничился просмотром видео. Или на самом деле колесо не увеличивается в размере, а потом через долю секунды не возвращается к обычному размеру? Тогда может быть и погорячился насчет студня.
Просто надоели все эти «находки» нынешних «дизайнёров» от слова «комбайнёр». Листаешь страницу, а ее продолжение при проматывании то слева выезжает, то справа.
Synthesis0100 Автор
11.06.2026 22:29Там есть эффект примагничивания, возможно на видео это выглядит странно, но прототип сделан не для просмотра, а для использования. В любом случае этот концепт не для всех. Анна Де Армас не всем нравится, что уж говорить про какие-то там концепты:) жаль, что моё видео вас огорчило
lazarus_net
11.06.2026 22:29Мышь: Колесо идеально заменяет инерционный скролл барабана, а ПКМ можно закрепить за сектором возврата.
Какойтскролл барабана? Это когда Аппл вместо нормального поля ввода даты прикрутил барабан и теперь все имеют счастье крутить его до дога рождения? Минимум 18 делений а в среднем 40-50 при каждом использовании?
Вместо того чтобы ввести 4 цифры?
lazarus_net
11.06.2026 22:29Есть такая штука -поиск - начинаешь писать/ говорить тебе выдают список что подходит запоминать ничего не надо. - все просто и деревянно.
Synthesis0100 Автор
11.06.2026 22:29Много чего есть, но мне интересно искать новые решения и подходы. Я делюсь и спрашиваю вашего мнения. Не думаю, что если что-то уже есть, то не может быть более удобного решения
Synthesis0100 Автор
11.06.2026 22:29Вы не в ту сторону ушли. Речь была про прокрутку “барабана” в моей концепции. При чем тут дата рождения?
cpud47
11.06.2026 22:29Вообще, такие радиальные меню уже давно отточили во всяких Maya и Blender. Как по мне там этим очень удобно пользоваться. И его даже не в отсутствии подписей (они там есть) — скорее дело в более равномерном ux и меньшей точности.
Увидеть эту идею на телефоне — это очень интересно. Но меня смущает несколько практических вопросов.
Для начала вопрос иконок. Подобрать хорошие иконки — это прям очень сложно. Почти никто с этим не справляется. Подписи нужны.
А второй вопрос: как подбирать категории. Если это статическая навигация — то может, конечно и ок. Но если пункты добавляются пользователем, то это дерево быстро становится неуправляемым. Тут либо делать какую-то хитрую автоматику (что сложно), либо заставлять пользователя заниматься организацией.
Например, если говорить об интерфейсе мессенджер, хочется иметь возможность не заниматься организацией своих контактов. А в таком случае, плоский список удобнее, т.к. в нём просто больше пунктов помещается.
Быть может имеет смысл какой-то гибридный подход, как в Maya сделать: основные, или часто используемые пункты в радиальном меню, а все остальные списком (сверху). Можно даже дальше пойти и синхронизировать скролл списка: чтобы при прокручивании радиального меню, пункты из него перетакали в список, а из списка в радиальное меню.
Synthesis0100 Автор
11.06.2026 22:29Про иконки согласен на 1000%. Я даже пробовал делать разные уровни или разделы по цветами, но что иконки, что цвета превращают всё в аляпистую мусорку. Я пришёл к заключению, что лучший вариант это прозрачные узлы на любых промежуточных уровнях, но выбранная иконка на заключительном узле, плюсь можно поиграть с прозрачностью. Так же неплохо смотрится если имитировать мутное стекло, под которым изображение. Про порядок и навигацию не понимаю опасений если честно, но возможно это мои проблемы/особенности… Повторюсь, я очень много времени тестировал этот подход и мне он кажется до ужаса удобным простым и запоминающимся. Я намеренно создавал длинные “корни” и не испытывал неудобств при скольжении по ним. “Но если пункты добавляются пользователем, то это дерево быстро становится неуправляемым.” - а вот тут полностью не согласен. В том то и дело, что пользователь сам добавляет узлы и выстраивает пути. Пути выстраивается логикой пользователя, когда ты сам создаешь путь типа общение-работа-проект#42-Василий, или общение-семья-родня-дальние-Дядя Петя, либо общение-семья-мама, то по моему мнению тут полная управляемость и понимание, при чем собственное логическое понимание своих же ветвей, которые ты сам построил своей логикой. Не совсем понимаю как тут можно заблудиться. Возможно я не правильно понял вашу мысль. А вы пробовали это сделать в приложении?
cpud47
11.06.2026 22:29В том то и дело, что пользователь сам добавляет узлы и выстраивает пути
Пользователь может сам выстроить пути, или обязан? Я, как пользователь, не всегда хочу заниматься организацией. Я это знаю по опыту настройки папок и рабочего стола.
Ну, то есть, я готов настроить несколько наиболее важных мне пунктов. Но всё остальное — не то. На настройку уходит много времени и итераций. Особенно, когда регулярно добавляются новые позиции(контакты, приложения и прочее).
И уж тем более я не готов заниматься настройкой в процессе работы. Если мне написал человек, я хочу взять и ответить ему, а не сидеть и выбирать куда его распределить.
Про порядок и навигацию не понимаю опасений если честно, но возможно это мои проблемы/особенности
Я не знаю, о чём Вы. Процитируйте, пожалуйста, конкретный фрагмент моего (исходного) сообщения.
Я даже пробовал делать разные уровни или разделы по цветами, но что иконки, что цвета превращают всё в аляпистую мусорку.
Проблема не в дизайне, а скорее в том, что тяжело распознать, что значит иконка. Подписи в этом плане универсальнее.
P.S. на хабре есть блоки цитат, используйте их пожалуйста.
Synthesis0100 Автор
11.06.2026 22:29Про гибридный подход… Блин, возможно конечно, но хотелось чего-то простого, элементарного по сути. Повторюсь, это лишь концепт) мне показался удобным и это не значит, что так будет для всех, поэтому и прошу вашего мнения. И да, спасибо за идеи, хотя, если честно не совсем понял про перетекающие списки
cpud47
11.06.2026 22:29Простое подходит для простых случаев. Если задача исходно сложная, её нельзя решить просто. Так называемая intrinsic complexity.
Про пересекающие списки. Как будет выглядеть Ваш барабан, если в нём будет 20-40-100 элементов? По идее, у него должен быть неполный круг, и где-то должны быть точка рождения и точка уничтожения иконок. То есть когда прокручивается барабан, крайняя иконка с одной стороны исчезает, а с другой стороны появляется новая, следующая иконка.
Точно такие же точки рождения и уничтожения находятся сверху и снизу линейного списка.
Предложение в том, чтобы объеденить одну из точек уничтожения барабана с точкой рождения списка. То есть, когда какая-то иконка пропадает с барабана при прокрутка, она тут же появляется сверху/снизу списка. Ну и они соответственно скролятся синхронно.
Irit_LS
Второй вариант концепции гораздо понятнее, чем первые версии. Но меня не покидает вопрос - а почему блин все жмется в левый нижний угол? Почему не в правый? Или по центру?
Радиальное перемещение связанных групп и по сути прокрутка - в целом это удобно. Но если этих групп не будет очень много, иначе придется делать кучу вложений, а это периодически раздражает когда надо быстро перейти в нужный раздел.
Возьмем для примера телеграм (скам не хочу). Что у нас есть? Есть группы. В группах есть чаты. Некоторые чаты могут быть закрепленными. Внутри чатов могут быть темы. Внутри уже сами сообщения. Сейчас навигация от общего списка к нужному сообщению достигается от 2 до 5 переходов. Если удастся сократить хотя бы на один переход - уже хорошо.
И да, концепция отлично работает для плавающих кнопок для тех же списков, вместо всплывающего меню.
ИМХО, я бы разместил меню по центру, переход назад через свайп внизу / вверх, в зависимости от ориентации полукруга прокрутки. Целый круг тоже можно, но должен быть небольшой сектор, за которую круг с неограниченным количеством элементов должен прятаться, заодно он будет определять свайп для возврата назад по дереву навигации.
Irit_LS
Для навигации мышью кстати за прокрутку колеса будет отвечать колесо мыши, ЛКМ для перехода на выбранное меню, а ПКМ или ЛКМ на сектор возврата - для возврата. Для навигации типа джойстик 4-позиционный или клавиатура еще проще - вверх - переход к выделенному пункту. Вниз - возврат обратно. Лево-право - смещение позиции колеса в нужную сторону. По сути будет навигация как в квестах старых.
Synthesis0100 Автор
Спасибо за развернутый комментарий и конкретные предложения по эргономике! Постараюсь ответить на все ваши тезисы:
1. Про расположение (Лево / Право / Центр) Вы абсолютно правы относительно кастомизации. В финальной версии выбор угла (левый нижний для правшей или правый для левшей, ) — это обязательная настройка. Сейчас выбрано левое положение как базовое для прототипа.
Почему не центр? Текущее угловое расположение — результат множества тестов.
Логика «барабана»: Центральное радиальное меню заставило бы нас вращать всю окружность (или большую её часть), что неудобно на вытянутых экранах смартфонов. Сейчас мы видим только 1/3 окружности. Это позволяет реализовать бесконечную прокрутку, не превращая интерфейс в громоздкое «колесо обозрения». Соты как бы «выплывают» из-за границы экрана и уходят обратно.
Наполнение уровней: Если поместить меню в центр, то для старта прокрутки необходимо будет создать сразу много элементов (штук 6), иначе круг будет выглядеть пустым. По моей задумке, не стоит делать большое количество сот на одном уровне — проще и быстрее «нырнуть» глубже, чем бесконечно крутить барабан. Поэтому соты добавляются по одной по мере необходимости.
Мертвая зона: Кнопка «назад» сейчас находится в идеальной позиции под большим пальцем, что исключает случайные нажатия при навигации, но позволяет мгновенно выйти на уровень выше.
2. Про количество переходов и когнитивную нагрузку На видео навигация может казаться медленной, потому что я стараюсь показать её плавно. На практике, когда вы используете приложение 5-й или 10-й раз, включается рефлекторная навигация.
В Telegram или любом списке вам нужно на каждом этапе прочитать строку, чтобы «прицелиться» и нажать. Это когнитивная нагрузка.
В ОРДО вы не читаете. Вы помните вектор. Спуститься на 4-5 уровней вглубь — это серия из 5-6 мгновенных микродвижений, которые делаются буквально «вслепую». Это происходит быстрее, чем скролл длинного списка и поиск нужного чата глазами.
3. Про универсальность (мышь, джойстики, клавиатура) Вы верно подметили универсальность логики. Хотя я проектировал интерфейс строго как Touch-first, математическая модель фрактальных сот действительно легко адаптируется под любой ввод:
Мышь: Колесо идеально заменяет инерционный скролл барабана, а ПКМ можно закрепить за сектором возврата.
Джойстик: Ваше сравнение со «старыми квестами» очень точно передает дух проекта. Движение Вверх — вход, Вниз — назад, Право/Лево — вращение барабана. Если интерфейс так легко ложится на 4-позиционный джойстик, значит, в его основе лежит крепкая логика, которая не рассыпается при смене устройства.
Концепция с «сектором», за который прячется круг, интересная — я думал о чем-то подобном для режима планшетов, но для узких экранов смартфонов текущая «угловая дуга» пока кажется самым компактным решением. Спасибо за идеи!
trinxery
Люди честно делятся своим мнением, а вы им ИИ отвечаете.
Synthesis0100 Автор
Вы правда думаете ИИ так может ответить?) Вы знакомы с ним поверхностно. ИИ делает красивые markdown, и добавляет чуть структуру в мои слова. мне нравится это визуально, если тут это не принято, могу не пользоваться
cpud47
Последнее время, много где предпочитают хоть и не очень структурированный/понятный текст, но написанный вручную.
Synthesis0100 Автор
Не успел с этим наиграться, а всем уже надоело) Учту
Irit_LS
Если выводить полукруг на 180 градусов (а больше не надо), то поместится 4, ну может 5 иконок на барабане. Этого достаточно для ориентира по соседним позициям, при этом нет большой области для прокрутки. Трёх позиций в углу мне лично маловато, 5 гораздо лучше. Опять же это может быть настраиваемым функционалом: количество иконок, градус вывода барабана.
P.S. не используйте нейронки для ответов, выглядит как чистой воды неуважение к собеседнику, мы все таки общаемся с людьми со всеми их недостатками, а не с нейронками идеализированными. Спасибо
Synthesis0100 Автор
В такой концепции кнопку “назад” некуда вставить, либо она будет прерывать соты, что тоже странно… Кстати, по-моему я не упоминал, что в настройках приложения можно включить опцию гироскопа, тогда наклоном аппарата с регулируемой силой вращается “барабан” это забавно и удобно (опять же по моему мнению). 3 мало… Мне даже такого не приходило в голову… Возможно стоит поиграть с размером сот или плотностью их распределения чтобы больше разместь, стоит попробовать, спасибо за мнение! P.S. - Про ИИ понял) я впервые тут, если честно и не совсем понимал как тут всё устроено, раз все за живое непосредственное общение то я только за:) хотя красиво оформленный текст мне тоже нравится)
Irit_LS
Ну так я ж жто и описал. У вас размещение по центру но не с прижимом к нижней части зкрана, а чуть дальше. В верхней полусфере идет барабан выбора группы. Свайп вниз - возврат назад. Думаю 180 градусов нижней полусыеры будет достаточно для возврата Можно даже сократить верхнюю полусферу до 150 градусов. Гоавное не текущие 90, мало. Размер сот как раз оптимален под палец, не надо их уменьшать или изменять расстояния между ними, будет хуже, на мой взгляд.