Там есть эффект примагничивания, возможно на видео это выглядит странно, но прототип сделан не для просмотра, а для использования. В любом случае этот концепт не для всех. Анна Де Армас не всем нравится, что уж говорить про какие-то там концепты:) жаль, что моё видео вас огорчило
В такой концепции кнопку “назад” некуда вставить, либо она будет прерывать соты, что тоже странно… Кстати, по-моему я не упоминал, что в настройках приложения можно включить опцию гироскопа, тогда наклоном аппарата с регулируемой силой вращается “барабан” это забавно и удобно (опять же по моему мнению). 3 мало… Мне даже такого не приходило в голову… Возможно стоит поиграть с размером сот или плотностью их распределения чтобы больше разместь, стоит попробовать, спасибо за мнение! P.S. - Про ИИ понял) я впервые тут, если честно и не совсем понимал как тут всё устроено, раз все за живое непосредственное общение то я только за:) хотя красиво оформленный текст мне тоже нравится)
Про гибридный подход… Блин, возможно конечно, но хотелось чего-то простого, элементарного по сути. Повторюсь, это лишь концепт) мне показался удобным и это не значит, что так будет для всех, поэтому и прошу вашего мнения. И да, спасибо за идеи, хотя, если честно не совсем понял про перетекающие списки
Про иконки согласен на 1000%. Я даже пробовал делать разные уровни или разделы по цветами, но что иконки, что цвета превращают всё в аляпистую мусорку. Я пришёл к заключению, что лучший вариант это прозрачные узлы на любых промежуточных уровнях, но выбранная иконка на заключительном узле, плюсь можно поиграть с прозрачностью. Так же неплохо смотрится если имитировать мутное стекло, под которым изображение. Про порядок и навигацию не понимаю опасений если честно, но возможно это мои проблемы/особенности… Повторюсь, я очень много времени тестировал этот подход и мне он кажется до ужаса удобным простым и запоминающимся. Я намеренно создавал длинные “корни” и не испытывал неудобств при скольжении по ним. “Но если пункты добавляются пользователем, то это дерево быстро становится неуправляемым.” - а вот тут полностью не согласен. В том то и дело, что пользователь сам добавляет узлы и выстраивает пути. Пути выстраивается логикой пользователя, когда ты сам создаешь путь типа общение-работа-проект#42-Василий, или общение-семья-родня-дальние-Дядя Петя, либо общение-семья-мама, то по моему мнению тут полная управляемость и понимание, при чем собственное логическое понимание своих же ветвей, которые ты сам построил своей логикой. Не совсем понимаю как тут можно заблудиться. Возможно я не правильно понял вашу мысль. А вы пробовали это сделать в приложении?
Много чего есть, но мне интересно искать новые решения и подходы. Я делюсь и спрашиваю вашего мнения. Не думаю, что если что-то уже есть, то не может быть более удобного решения
А вы попробовали и вам показалось неудобным? Или посмотрели видео и вам померещился студень? Не скажу, что я предлагаю, скорее делюсь своей идеей, которая мне показалась интересной.
Вы правда думаете ИИ так может ответить?) Вы знакомы с ним поверхностно. ИИ делает красивые markdown, и добавляет чуть структуру в мои слова. мне нравится это визуально, если тут это не принято, могу не пользоваться
Согласен, «раздувание» приложений часто вредит юзабилити. Но мой концепт — это не попытка продать саму идею супераппа как бизнес-модели.
Реальность такова, что любой действительно ёмкий сервис (будь то банк, госуслуги или даже сложный мессенджер) со временем неизбежно превращается в когнитивный хаос из бесконечных списков, меню и вкладок. Мой вопрос в другом: если мы всё равно обречены иметь дело с многофункциональными системами, готовы ли мы сменить привычное «кладбище иконок» на что-то более живое и рефлекторное?
Это видео — лишь попытка проверить фрактальный движок на «максимальных оборотах», чтобы увидеть, насколько эффективно соты справляются с по-настоящему глубокой структурой данных.
Спасибо за развернутый комментарий и конкретные предложения по эргономике! Постараюсь ответить на все ваши тезисы:
1. Про расположение (Лево / Право / Центр) Вы абсолютно правы относительно кастомизации. В финальной версии выбор угла (левый нижний для правшей или правый для левшей, ) — это обязательная настройка. Сейчас выбрано левое положение как базовое для прототипа.
Почему не центр? Текущее угловое расположение — результат множества тестов.
Логика «барабана»: Центральное радиальное меню заставило бы нас вращать всю окружность (или большую её часть), что неудобно на вытянутых экранах смартфонов. Сейчас мы видим только 1/3 окружности. Это позволяет реализовать бесконечную прокрутку, не превращая интерфейс в громоздкое «колесо обозрения». Соты как бы «выплывают» из-за границы экрана и уходят обратно.
Наполнение уровней: Если поместить меню в центр, то для старта прокрутки необходимо будет создать сразу много элементов (штук 6), иначе круг будет выглядеть пустым. По моей задумке, не стоит делать большое количество сот на одном уровне — проще и быстрее «нырнуть» глубже, чем бесконечно крутить барабан. Поэтому соты добавляются по одной по мере необходимости.
Мертвая зона: Кнопка «назад» сейчас находится в идеальной позиции под большим пальцем, что исключает случайные нажатия при навигации, но позволяет мгновенно выйти на уровень выше.
2. Про количество переходов и когнитивную нагрузку На видео навигация может казаться медленной, потому что я стараюсь показать её плавно. На практике, когда вы используете приложение 5-й или 10-й раз, включается рефлекторная навигация.
В Telegram или любом списке вам нужно на каждом этапе прочитать строку, чтобы «прицелиться» и нажать. Это когнитивная нагрузка.
В ОРДО вы не читаете. Вы помните вектор. Спуститься на 4-5 уровней вглубь — это серия из 5-6 мгновенных микродвижений, которые делаются буквально «вслепую». Это происходит быстрее, чем скролл длинного списка и поиск нужного чата глазами.
3. Про универсальность (мышь, джойстики, клавиатура) Вы верно подметили универсальность логики. Хотя я проектировал интерфейс строго как Touch-first, математическая модель фрактальных сот действительно легко адаптируется под любой ввод:
Мышь: Колесо идеально заменяет инерционный скролл барабана, а ПКМ можно закрепить за сектором возврата.
Джойстик: Ваше сравнение со «старыми квестами» очень точно передает дух проекта. Движение Вверх — вход, Вниз — назад, Право/Лево — вращение барабана. Если интерфейс так легко ложится на 4-позиционный джойстик, значит, в его основе лежит крепкая логика, которая не рассыпается при смене устройства.
Концепция с «сектором», за который прячется круг, интересная — я думал о чем-то подобном для режима планшетов, но для узких экранов смартфонов текущая «угловая дуга» пока кажется самым компактным решением. Спасибо за идеи!
Интересное предложение, но буду честен, сейчас у меня недостаточно времени даже для своего проекта, так что данный момент не готов отвлекаться. Но в перспективе можно конечно)
Спасибо за такой глубокие и интересные вопросы! Вы абсолютно правы: ОРДО, а по-русски ПОРЯДОК — это в первую очередь рабочий концепт, манифест альтернативного взгляда на интерфейсы и приватность, и мне очень ценно обсудить его ограничения.
Постараюсь ответить на ваши тезисы, объединив техническую часть и философию проекта.
Про навигацию, мышечную память и «анти-поиск» (Тезисы 1 и 2)
Идея навигации в ОРДО построена на двух принципах: она должна быть очевидной, а спустя короткое время — становиться буквально рефлекторной (на уровне мышечной памяти). Рефлекторный свайп: Например, чтобы спуститься на 5-й уровень глубины фрактала, пользователю нужно сделать всего 6 коротких свайпов пальцем в угле не более 90 градусов. Пальцы сами запоминают этот «рисунок» движения. Маячки вместо слепого блуждания: Навигация не будет слепой. Логика «маячков» реализуется через пульсацию «хлебных крошек». Если глубоко в ветви дерева есть непрочитанный чат или входящий пинг, то все родительские узлы по пути к этой ветви будут мягко пульсировать. Пользователь видит этот светящийся след и точно знает, куда ведет дорожка.
Отсутствие строки поиска — это фича, а не баг:) Я намеренно не планировал делать строку поиска, так как она идет вразрез с философией приложения. ПОРЯДОК создавался как место общения «для своих», для тех, с кем действительно есть о чем поговорить. Это пространство не для сиюминутных диалогов в стиле «открыл / закрыл / ответил раз в 10 минут». Существуют прекрасные и привычные нам всем мессенджеры, где можно быстро скинуть список покупок или узнать дежурное «как дела». ПОРЯДОК — это другая история, это пространство для глубоких, осознанных диалогов, которые имеют смысл, так это было задумано изначально.
Про адаптивное перестроение дерева (Тезис 3)
Идея автоматического смещения ячеек на основе их «веса» (частоты общения) заманчива, но она полностью разрушает пространственную память. Если соты будут постоянно менять свои места на основе алгоритмов, рефлекторная навигация станет невозможной. Это как если бы в вашей квартире дверь в кухню постоянно менялась местами с дверью в спальню просто потому, что сегодня вы чаще ходили в спальню. Статичность сетки позволяет выработать автоматический жест. Перестроение сетки должно быть исключительно ручным, под личным контролем пользователя.
Главная фича: Бесшовный суверенный мультисервер
Эта история началась, когда пошла вся эта возня с блокировками, цензурой, замедлениями и навязыванием конкретных платформ для общения. Мне захотелось создать систему, в которой люди смогут общаться при любом раскладе. В ПОРЯДКЕ любой пользователь может поднять свой собственный сервер Go Relay и пригласить туда друзей. При этом в одном приложении у вас на экране могут одновременно находиться соты-чаты, физически расположенные на десятке разных серверов (включая ваш личный). Но самое главное — при переходе между диалогами, завязанными на разные серверы, вы как пользователь этого даже не замечаете. Приложение бесшовно переподключает сокеты под капотом, сохраняя единую картину вашего персонального пространства. Эта механика уже на финишной прямой.
Требования к экрану и кнопочные устройства (Тезис 4)
Да, этот концепт изначально проектировался исключительно под современные смартфоны с сенсорными экранами. Пытаться адаптировать гексагональную сотовую навигацию под кнопочные телефоны (типа KaiOS) или джойстики — нерационально. Для кнопочных и несенсорных устройств классический текстовый список или CLI-интерфейс (командная строка) всегда были и будут на порядок эффективнее и экономичнее. ПОРЯДОК — это Touch-First концепт.
Работа WebSocket в условиях плохой связи (Тезис 5)
Это самый сложный вопрос для любого TCP-подключения в условиях застройки, хендоверов и потерь пакетов. Как это компенсируется сейчас: 1. Пакеты пингов и сообщений у нас весят всего по несколько байт (сырой зашифрованный массив). 2. На клиенте реализован быстрый цикл переподключения, а на сервере — временный почтовый ящик в оперативной памяти (pingMailbox). Если связь пропала во время перехода между вышками, сервер сохраняет пинг у себя (до 24 часов). Как только клиент восстанавливает WebSocket-сессию, он мгновенно забирает пропущенные пинги. Вектор развития: Использовать TCP на плохой связи — компромисс. В идеале транспортный уровень нужно переводить на QUIC / UDP (по аналогии с HTTP/3), чтобы избежать блокировок очереди при потере отдельных пакетов и сделать соединение устойчивым при частых сменах IP.
Работа поверх альтернативных сетей связи (Тезис 6)
Сейчас приложение жестко привязано к IP-сетям (интернет / LAN). Однако, благодаря тому, что все данные шифруются сквозным шифрованием (E2EE) на устройствах и превращаются в сырой массив байт, теоретически нет никаких препятствий для передачи этих пакетов через альтернативные виды связи (например, через радиомодемы LoRa, сеть Meshtastic или любительские радиостанции). Как только я опубликую открытый код Go-сервера, сообщество сможет написать транспортные адаптеры для пересылки байтовых пакетов ПОРЯДКА вообще без использования традиционного интернета.
Там есть эффект примагничивания, возможно на видео это выглядит странно, но прототип сделан не для просмотра, а для использования. В любом случае этот концепт не для всех. Анна Де Армас не всем нравится, что уж говорить про какие-то там концепты:) жаль, что моё видео вас огорчило
В такой концепции кнопку “назад” некуда вставить, либо она будет прерывать соты, что тоже странно… Кстати, по-моему я не упоминал, что в настройках приложения можно включить опцию гироскопа, тогда наклоном аппарата с регулируемой силой вращается “барабан” это забавно и удобно (опять же по моему мнению). 3 мало… Мне даже такого не приходило в голову… Возможно стоит поиграть с размером сот или плотностью их распределения чтобы больше разместь, стоит попробовать, спасибо за мнение! P.S. - Про ИИ понял) я впервые тут, если честно и не совсем понимал как тут всё устроено, раз все за живое непосредственное общение то я только за:) хотя красиво оформленный текст мне тоже нравится)
Про гибридный подход… Блин, возможно конечно, но хотелось чего-то простого, элементарного по сути. Повторюсь, это лишь концепт) мне показался удобным и это не значит, что так будет для всех, поэтому и прошу вашего мнения. И да, спасибо за идеи, хотя, если честно не совсем понял про перетекающие списки
Про иконки согласен на 1000%. Я даже пробовал делать разные уровни или разделы по цветами, но что иконки, что цвета превращают всё в аляпистую мусорку. Я пришёл к заключению, что лучший вариант это прозрачные узлы на любых промежуточных уровнях, но выбранная иконка на заключительном узле, плюсь можно поиграть с прозрачностью. Так же неплохо смотрится если имитировать мутное стекло, под которым изображение. Про порядок и навигацию не понимаю опасений если честно, но возможно это мои проблемы/особенности… Повторюсь, я очень много времени тестировал этот подход и мне он кажется до ужаса удобным простым и запоминающимся. Я намеренно создавал длинные “корни” и не испытывал неудобств при скольжении по ним. “Но если пункты добавляются пользователем, то это дерево быстро становится неуправляемым.” - а вот тут полностью не согласен. В том то и дело, что пользователь сам добавляет узлы и выстраивает пути. Пути выстраивается логикой пользователя, когда ты сам создаешь путь типа общение-работа-проект#42-Василий, или общение-семья-родня-дальние-Дядя Петя, либо общение-семья-мама, то по моему мнению тут полная управляемость и понимание, при чем собственное логическое понимание своих же ветвей, которые ты сам построил своей логикой. Не совсем понимаю как тут можно заблудиться. Возможно я не правильно понял вашу мысль. А вы пробовали это сделать в приложении?
Много чего есть, но мне интересно искать новые решения и подходы. Я делюсь и спрашиваю вашего мнения. Не думаю, что если что-то уже есть, то не может быть более удобного решения
Вы не в ту сторону ушли. Речь была про прокрутку “барабана” в моей концепции. При чем тут дата рождения?
А вы попробовали и вам показалось неудобным? Или посмотрели видео и вам померещился студень? Не скажу, что я предлагаю, скорее делюсь своей идеей, которая мне показалась интересной.
Не успел с этим наиграться, а всем уже надоело) Учту
Вы правда думаете ИИ так может ответить?) Вы знакомы с ним поверхностно. ИИ делает красивые markdown, и добавляет чуть структуру в мои слова. мне нравится это визуально, если тут это не принято, могу не пользоваться
Спасибо за развернутый комментарий и конкретные предложения по эргономике! Постараюсь ответить на все ваши тезисы:
1. Про расположение (Лево / Право / Центр) Вы абсолютно правы относительно кастомизации. В финальной версии выбор угла (левый нижний для правшей или правый для левшей, ) — это обязательная настройка. Сейчас выбрано левое положение как базовое для прототипа.
Почему не центр? Текущее угловое расположение — результат множества тестов.
Логика «барабана»: Центральное радиальное меню заставило бы нас вращать всю окружность (или большую её часть), что неудобно на вытянутых экранах смартфонов. Сейчас мы видим только 1/3 окружности. Это позволяет реализовать бесконечную прокрутку, не превращая интерфейс в громоздкое «колесо обозрения». Соты как бы «выплывают» из-за границы экрана и уходят обратно.
Наполнение уровней: Если поместить меню в центр, то для старта прокрутки необходимо будет создать сразу много элементов (штук 6), иначе круг будет выглядеть пустым. По моей задумке, не стоит делать большое количество сот на одном уровне — проще и быстрее «нырнуть» глубже, чем бесконечно крутить барабан. Поэтому соты добавляются по одной по мере необходимости.
Мертвая зона: Кнопка «назад» сейчас находится в идеальной позиции под большим пальцем, что исключает случайные нажатия при навигации, но позволяет мгновенно выйти на уровень выше.
2. Про количество переходов и когнитивную нагрузку На видео навигация может казаться медленной, потому что я стараюсь показать её плавно. На практике, когда вы используете приложение 5-й или 10-й раз, включается рефлекторная навигация.
В Telegram или любом списке вам нужно на каждом этапе прочитать строку, чтобы «прицелиться» и нажать. Это когнитивная нагрузка.
В ОРДО вы не читаете. Вы помните вектор. Спуститься на 4-5 уровней вглубь — это серия из 5-6 мгновенных микродвижений, которые делаются буквально «вслепую». Это происходит быстрее, чем скролл длинного списка и поиск нужного чата глазами.
3. Про универсальность (мышь, джойстики, клавиатура) Вы верно подметили универсальность логики. Хотя я проектировал интерфейс строго как Touch-first, математическая модель фрактальных сот действительно легко адаптируется под любой ввод:
Мышь: Колесо идеально заменяет инерционный скролл барабана, а ПКМ можно закрепить за сектором возврата.
Джойстик: Ваше сравнение со «старыми квестами» очень точно передает дух проекта. Движение Вверх — вход, Вниз — назад, Право/Лево — вращение барабана. Если интерфейс так легко ложится на 4-позиционный джойстик, значит, в его основе лежит крепкая логика, которая не рассыпается при смене устройства.
Концепция с «сектором», за который прячется круг, интересная — я думал о чем-то подобном для режима планшетов, но для узких экранов смартфонов текущая «угловая дуга» пока кажется самым компактным решением. Спасибо за идеи!
Привет!
Интересное предложение, но буду честен, сейчас у меня недостаточно времени даже для своего проекта, так что данный момент не готов отвлекаться. Но в перспективе можно конечно)
Спасибо за такой глубокие и интересные вопросы! Вы абсолютно правы: ОРДО, а по-русски ПОРЯДОК — это в первую очередь рабочий концепт, манифест альтернативного взгляда на интерфейсы и приватность, и мне очень ценно обсудить его ограничения.
Постараюсь ответить на ваши тезисы, объединив техническую часть и философию проекта.
Про навигацию, мышечную память и «анти-поиск» (Тезисы 1 и 2)
Идея навигации в ОРДО построена на двух принципах: она должна быть очевидной, а спустя короткое время — становиться буквально рефлекторной (на уровне мышечной памяти). Рефлекторный свайп: Например, чтобы спуститься на 5-й уровень глубины фрактала, пользователю нужно сделать всего 6 коротких свайпов пальцем в угле не более 90 градусов. Пальцы сами запоминают этот «рисунок» движения. Маячки вместо слепого блуждания: Навигация не будет слепой. Логика «маячков» реализуется через пульсацию «хлебных крошек». Если глубоко в ветви дерева есть непрочитанный чат или входящий пинг, то все родительские узлы по пути к этой ветви будут мягко пульсировать. Пользователь видит этот светящийся след и точно знает, куда ведет дорожка.
Отсутствие строки поиска — это фича, а не баг:) Я намеренно не планировал делать строку поиска, так как она идет вразрез с философией приложения. ПОРЯДОК создавался как место общения «для своих», для тех, с кем действительно есть о чем поговорить. Это пространство не для сиюминутных диалогов в стиле «открыл / закрыл / ответил раз в 10 минут». Существуют прекрасные и привычные нам всем мессенджеры, где можно быстро скинуть список покупок или узнать дежурное «как дела». ПОРЯДОК — это другая история, это пространство для глубоких, осознанных диалогов, которые имеют смысл, так это было задумано изначально.
Про адаптивное перестроение дерева (Тезис 3)
Идея автоматического смещения ячеек на основе их «веса» (частоты общения) заманчива, но она полностью разрушает пространственную память. Если соты будут постоянно менять свои места на основе алгоритмов, рефлекторная навигация станет невозможной. Это как если бы в вашей квартире дверь в кухню постоянно менялась местами с дверью в спальню просто потому, что сегодня вы чаще ходили в спальню. Статичность сетки позволяет выработать автоматический жест. Перестроение сетки должно быть исключительно ручным, под личным контролем пользователя.
Главная фича: Бесшовный суверенный мультисервер
Эта история началась, когда пошла вся эта возня с блокировками, цензурой, замедлениями и навязыванием конкретных платформ для общения. Мне захотелось создать систему, в которой люди смогут общаться при любом раскладе. В ПОРЯДКЕ любой пользователь может поднять свой собственный сервер Go Relay и пригласить туда друзей. При этом в одном приложении у вас на экране могут одновременно находиться соты-чаты, физически расположенные на десятке разных серверов (включая ваш личный). Но самое главное — при переходе между диалогами, завязанными на разные серверы, вы как пользователь этого даже не замечаете. Приложение бесшовно переподключает сокеты под капотом, сохраняя единую картину вашего персонального пространства. Эта механика уже на финишной прямой.
Требования к экрану и кнопочные устройства (Тезис 4)
Да, этот концепт изначально проектировался исключительно под современные смартфоны с сенсорными экранами. Пытаться адаптировать гексагональную сотовую навигацию под кнопочные телефоны (типа KaiOS) или джойстики — нерационально. Для кнопочных и несенсорных устройств классический текстовый список или CLI-интерфейс (командная строка) всегда были и будут на порядок эффективнее и экономичнее. ПОРЯДОК — это Touch-First концепт.
Работа WebSocket в условиях плохой связи (Тезис 5)
Это самый сложный вопрос для любого TCP-подключения в условиях застройки, хендоверов и потерь пакетов. Как это компенсируется сейчас: 1. Пакеты пингов и сообщений у нас весят всего по несколько байт (сырой зашифрованный массив). 2. На клиенте реализован быстрый цикл переподключения, а на сервере — временный почтовый ящик в оперативной памяти (
pingMailbox). Если связь пропала во время перехода между вышками, сервер сохраняет пинг у себя (до 24 часов). Как только клиент восстанавливает WebSocket-сессию, он мгновенно забирает пропущенные пинги. Вектор развития: Использовать TCP на плохой связи — компромисс. В идеале транспортный уровень нужно переводить на QUIC / UDP (по аналогии с HTTP/3), чтобы избежать блокировок очереди при потере отдельных пакетов и сделать соединение устойчивым при частых сменах IP.Работа поверх альтернативных сетей связи (Тезис 6)
Сейчас приложение жестко привязано к IP-сетям (интернет / LAN). Однако, благодаря тому, что все данные шифруются сквозным шифрованием (E2EE) на устройствах и превращаются в сырой массив байт, теоретически нет никаких препятствий для передачи этих пакетов через альтернативные виды связи (например, через радиомодемы LoRa, сеть Meshtastic или любительские радиостанции). Как только я опубликую открытый код Go-сервера, сообщество сможет написать транспортные адаптеры для пересылки байтовых пакетов ПОРЯДКА вообще без использования традиционного интернета.