Ну так я ж жто и описал. У вас размещение по центру но не с прижимом к нижней части зкрана, а чуть дальше. В верхней полусфере идет барабан выбора группы. Свайп вниз - возврат назад. Думаю 180 градусов нижней полусыеры будет достаточно для возврата Можно даже сократить верхнюю полусферу до 150 градусов. Гоавное не текущие 90, мало. Размер сот как раз оптимален под палец, не надо их уменьшать или изменять расстояния между ними, будет хуже, на мой взгляд.
Если выводить полукруг на 180 градусов (а больше не надо), то поместится 4, ну может 5 иконок на барабане. Этого достаточно для ориентира по соседним позициям, при этом нет большой области для прокрутки. Трёх позиций в углу мне лично маловато, 5 гораздо лучше. Опять же это может быть настраиваемым функционалом: количество иконок, градус вывода барабана.
P.S. не используйте нейронки для ответов, выглядит как чистой воды неуважение к собеседнику, мы все таки общаемся с людьми со всеми их недостатками, а не с нейронками идеализированными. Спасибо
Для навигации мышью кстати за прокрутку колеса будет отвечать колесо мыши, ЛКМ для перехода на выбранное меню, а ПКМ или ЛКМ на сектор возврата - для возврата. Для навигации типа джойстик 4-позиционный или клавиатура еще проще - вверх - переход к выделенному пункту. Вниз - возврат обратно. Лево-право - смещение позиции колеса в нужную сторону. По сути будет навигация как в квестах старых.
Второй вариант концепции гораздо понятнее, чем первые версии. Но меня не покидает вопрос - а почему блин все жмется в левый нижний угол? Почему не в правый? Или по центру?
Радиальное перемещение связанных групп и по сути прокрутка - в целом это удобно. Но если этих групп не будет очень много, иначе придется делать кучу вложений, а это периодически раздражает когда надо быстро перейти в нужный раздел.
Возьмем для примера телеграм (скам не хочу). Что у нас есть? Есть группы. В группах есть чаты. Некоторые чаты могут быть закрепленными. Внутри чатов могут быть темы. Внутри уже сами сообщения. Сейчас навигация от общего списка к нужному сообщению достигается от 2 до 5 переходов. Если удастся сократить хотя бы на один переход - уже хорошо.
И да, концепция отлично работает для плавающих кнопок для тех же списков, вместо всплывающего меню.
ИМХО, я бы разместил меню по центру, переход назад через свайп внизу / вверх, в зависимости от ориентации полукруга прокрутки. Целый круг тоже можно, но должен быть небольшой сектор, за которую круг с неограниченным количеством элементов должен прятаться, заодно он будет определять свайп для возврата назад по дереву навигации.
Решение хорошее, опробовал сегодня и на яблоке, и на андроиде. Везде свои плюсы и минусы, но думаю они решаемые. Вот чего, конечно, не хватает - это федерации. Развернуть локальный сервер нынче имеет смысл, который сложно переоценить, но без возможности общения с другими островами - он по факту бесполезен. Потому что изолированный корп.чат можно сделать сейчас на каком угодно открытом \ коммерческом решении, но почти никто не предлагает федерацию, кроме пожалуй Matrix / Element.
Да есть оплата. Сам сидел продолжительное время. Здесь скорее речь о том, что провайдер, принимающий оплату из РФ, для Европы как красная тряпка для быка. А если это оплата через зарубежные способы, то вроде норм.
Судя по моим изысканиям в последние пару дней, щас впринципе арендовать vds в Европе с оплатой в рублях нереально. Скорее всего по причинам указанным в статье.
Ну если в расширении творить дичь и не обкладывать это тестами / документацией и вообще херню творить, то конечно оно дороже выходит.
Мы по своему опыту сокращаем издержки обновления с вынесением доработок через расширения примерно в 3 раза, за счет использования программных изменений форм, гита, diffmerge для быстрого изменения захваченных модулей и сравнения с изменениями в типовых.
Для себя вывели несколько приложений в веб на 1С:Элемент: платежи, внутренний учет задач, корпоративный портал, несколько доп.сервисов для обмена данными. По сути получилась аналогичная схема как у вас, только бекенд и фронт у нас идет в виде единого приложения, которое пишется теми же 1С-никами, которые дорабатывают и учетные системы на платформе. Особенно круто это работает на мобилках, так как сейчас это основной вид интерфейса для руководства. Обмен по HTTP, который делается в самом веб-приложении, то есть учетные системы так и остаются за NATом в защите. В последнее время экспериментирую с переходом на реалтайм обмен через 1С:Шину (брокера сообщений по сути), у которого есть нормальная поддержка что в платформе, что в Элементе.
А за in-frame режим отдельное спасибо. Долгое время пытался понять как 1С в своем решении Бизкуб засунули отображение приложения на 1С внутри приложения на 1С:Элемент, теперь понял.
Вы сейчас по сути описали работу технологии 1С:Элемент, который по факту - веб-приложение на реакте с java-бекендом, при этом все реализовано в привычной для 1С-ника парадигме проектирования с множеством синтаксического сахара, компонентности, переиспользуемость и всего того, чего так не хватает в самой платформе. Да, и интерфейс там даже чуть приятнее чем в 8.5 (речь про типовой формат), но при этом никто не запрещает сделать сколь угодно сложный и красивый интерфейс. Мы вот у себя такого рода вещи делаем на Элементе как раз, с обменом по REST \ кролику с основной учетной системой 1С. Причем никаких веб-разработчиков, все силами 1С-ников.
1С:Касса. Там еще есть 1С:РМК, но это больше именно как чистый фронт, который должен подключаться к какой-либо бек системе: Кассе, Торговле, Бухгалтерии, УНФ и т.д. Детали на официальном сайте 1С можно посмотреть.
В библиотеке стандартных подсистем есть же механизм обновления конфигурации через интернет. Вот ее можно использовать для облачного обновления и установки, только не с серверов 1С (хотя можно и их), а со своего. С расширениями еще проще, они сами себя в целом умеют обновлять, по аналогии с самообновлением конфигурации. Вот и пожалуйста, централизованное распространение единой версии ПО. А данные через опять же БСП-шный механизм EnterpriseData по HTTP (точнее SOAP). Все уже придумано за нас, это надо только организовать и настроить.
Тем более что у 1С есть полноценное оффлайн приложение, которое обменивается только итоговыми данными по ценам, выручке, номенклатуре и прочая. Там даже чеки не передаются, ибо незачем, отчет о розничных продажах закрывает потребность. Но если очень надо - можно и их.
Просто мало кто действительно хочет в ритейле заниматься поддержкой всех 50 баз отдельно, каждая свою, вот и придумывают то риб, то облачное размещение. Сам сопровождаю одну такую розничную сеть, которая наотрез отказалась от использования оффлайн приложения на точках по вышеозначенным причинам + еще нескольким внутренним.
Специально для разработчиков, которые не любят устоявшуюся парадигму языка 1С, и был выпущен язык 1С:Элемент, который java-подобный (потому что бекенд на java сделан и синтаксис явно взят оттуда) веб ориентированный (потому что транслируется в react js) язык с поддержкой части возможностей ООП (наследования нет, но есть интерфейсы), синтаксическим сахаром а-ля свежие версии java / python и множеством внутренних улучшений. Насчет подключаемых модулей на java - пока ждем, но запрос к разработчикам фреймворка есть. И да, эффект получается такой же как при появлении 8.0 в бытность 7.7 как основной платформы и технологии.
В 8.3 вырвиглазный желтушный цвет. В 8.5 ранних сборках очень криво отрисовывался интерфейс, сильно перегруженный. В свежих 8.5 уже выглядит намного лучше, но опять же - жесткие рамки интерфейса и возможностей. В Элементе за счет переиспользуемости компонент и большого набора базовых элементов можно собрать какие угодно доп компоненты, которые отсутствуют в стандартной поставке. А если и их не хватает - что ж, HTML + CSS никто не отменял.
Не стоит. Я разрабатываю на 1С чуть больше 10 лет, стремясь использовать в своих проектах самые современные фишки и интерфейсы 1С. И писать решение с нуля - это самое худшее решение. Писать решение на базе стандартных библиотек 1С - лучше, но тоже так себе.
И полтора года пишу на Элементе, где нет вообще ничего кроме двух демок, документации и комьюнити. Там можно развиваться сколько угодно, и этот язык и Фреймворк я считаю более перспективным, нежели современную платформу 1С. В основном из-за малого легаси кода и библиотечного подхода к разработке, что кратно сокращает процесс разработки новых решений. Жаль только пока комьюнити небольшое, библиотек готовых мало (7 от 1С, с десяток от опенсорс сообщества)
Говорят, если начинаешь писать конфигурацию с нуля, с правильной архитектурой, с бизнес логикой продуманной, с адекватными и удобными интерфейсами, то Фреймворк 1С раскрывается с совершенно другой стороны... Пока не взвоешь от реального количества кода, который надо придумать и реализовать.
Ну так я ж жто и описал. У вас размещение по центру но не с прижимом к нижней части зкрана, а чуть дальше. В верхней полусфере идет барабан выбора группы. Свайп вниз - возврат назад. Думаю 180 градусов нижней полусыеры будет достаточно для возврата Можно даже сократить верхнюю полусферу до 150 градусов. Гоавное не текущие 90, мало. Размер сот как раз оптимален под палец, не надо их уменьшать или изменять расстояния между ними, будет хуже, на мой взгляд.
Если выводить полукруг на 180 градусов (а больше не надо), то поместится 4, ну может 5 иконок на барабане. Этого достаточно для ориентира по соседним позициям, при этом нет большой области для прокрутки. Трёх позиций в углу мне лично маловато, 5 гораздо лучше. Опять же это может быть настраиваемым функционалом: количество иконок, градус вывода барабана.
P.S. не используйте нейронки для ответов, выглядит как чистой воды неуважение к собеседнику, мы все таки общаемся с людьми со всеми их недостатками, а не с нейронками идеализированными. Спасибо
Для навигации мышью кстати за прокрутку колеса будет отвечать колесо мыши, ЛКМ для перехода на выбранное меню, а ПКМ или ЛКМ на сектор возврата - для возврата. Для навигации типа джойстик 4-позиционный или клавиатура еще проще - вверх - переход к выделенному пункту. Вниз - возврат обратно. Лево-право - смещение позиции колеса в нужную сторону. По сути будет навигация как в квестах старых.
Второй вариант концепции гораздо понятнее, чем первые версии. Но меня не покидает вопрос - а почему блин все жмется в левый нижний угол? Почему не в правый? Или по центру?
Радиальное перемещение связанных групп и по сути прокрутка - в целом это удобно. Но если этих групп не будет очень много, иначе придется делать кучу вложений, а это периодически раздражает когда надо быстро перейти в нужный раздел.
Возьмем для примера телеграм (скам не хочу). Что у нас есть? Есть группы. В группах есть чаты. Некоторые чаты могут быть закрепленными. Внутри чатов могут быть темы. Внутри уже сами сообщения. Сейчас навигация от общего списка к нужному сообщению достигается от 2 до 5 переходов. Если удастся сократить хотя бы на один переход - уже хорошо.
И да, концепция отлично работает для плавающих кнопок для тех же списков, вместо всплывающего меню.
ИМХО, я бы разместил меню по центру, переход назад через свайп внизу / вверх, в зависимости от ориентации полукруга прокрутки. Целый круг тоже можно, но должен быть небольшой сектор, за которую круг с неограниченным количеством элементов должен прятаться, заодно он будет определять свайп для возврата назад по дереву навигации.
Решение хорошее, опробовал сегодня и на яблоке, и на андроиде. Везде свои плюсы и минусы, но думаю они решаемые. Вот чего, конечно, не хватает - это федерации. Развернуть локальный сервер нынче имеет смысл, который сложно переоценить, но без возможности общения с другими островами - он по факту бесполезен. Потому что изолированный корп.чат можно сделать сейчас на каком угодно открытом \ коммерческом решении, но почти никто не предлагает федерацию, кроме пожалуй Matrix / Element.
Адептус-меканикус: Начало
Да есть оплата. Сам сидел продолжительное время. Здесь скорее речь о том, что провайдер, принимающий оплату из РФ, для Европы как красная тряпка для быка. А если это оплата через зарубежные способы, то вроде норм.
Судя по моим изысканиям в последние пару дней, щас впринципе арендовать vds в Европе с оплатой в рублях нереально. Скорее всего по причинам указанным в статье.
Казахстан и Беларусь доступны, пока...
Москва. Билайн проводной. Сервисы московские открывается, из СПб - нет. Внешний канал работает.
На мобильной сети того же Билайна все работает без проблем и трех букв.
Ну если в расширении творить дичь и не обкладывать это тестами / документацией и вообще херню творить, то конечно оно дороже выходит.
Мы по своему опыту сокращаем издержки обновления с вынесением доработок через расширения примерно в 3 раза, за счет использования программных изменений форм, гита, diffmerge для быстрого изменения захваченных модулей и сравнения с изменениями в типовых.
Для себя вывели несколько приложений в веб на 1С:Элемент: платежи, внутренний учет задач, корпоративный портал, несколько доп.сервисов для обмена данными. По сути получилась аналогичная схема как у вас, только бекенд и фронт у нас идет в виде единого приложения, которое пишется теми же 1С-никами, которые дорабатывают и учетные системы на платформе. Особенно круто это работает на мобилках, так как сейчас это основной вид интерфейса для руководства. Обмен по HTTP, который делается в самом веб-приложении, то есть учетные системы так и остаются за NATом в защите. В последнее время экспериментирую с переходом на реалтайм обмен через 1С:Шину (брокера сообщений по сути), у которого есть нормальная поддержка что в платформе, что в Элементе.
А за in-frame режим отдельное спасибо. Долгое время пытался понять как 1С в своем решении Бизкуб засунули отображение приложения на 1С внутри приложения на 1С:Элемент, теперь понял.
Вы сейчас по сути описали работу технологии 1С:Элемент, который по факту - веб-приложение на реакте с java-бекендом, при этом все реализовано в привычной для 1С-ника парадигме проектирования с множеством синтаксического сахара, компонентности, переиспользуемость и всего того, чего так не хватает в самой платформе. Да, и интерфейс там даже чуть приятнее чем в 8.5 (речь про типовой формат), но при этом никто не запрещает сделать сколь угодно сложный и красивый интерфейс.
Мы вот у себя такого рода вещи делаем на Элементе как раз, с обменом по REST \ кролику с основной учетной системой 1С. Причем никаких веб-разработчиков, все силами 1С-ников.
1С:Касса. Там еще есть 1С:РМК, но это больше именно как чистый фронт, который должен подключаться к какой-либо бек системе: Кассе, Торговле, Бухгалтерии, УНФ и т.д. Детали на официальном сайте 1С можно посмотреть.
В библиотеке стандартных подсистем есть же механизм обновления конфигурации через интернет. Вот ее можно использовать для облачного обновления и установки, только не с серверов 1С (хотя можно и их), а со своего. С расширениями еще проще, они сами себя в целом умеют обновлять, по аналогии с самообновлением конфигурации. Вот и пожалуйста, централизованное распространение единой версии ПО. А данные через опять же БСП-шный механизм EnterpriseData по HTTP (точнее SOAP). Все уже придумано за нас, это надо только организовать и настроить.
РИБ в целом зло, которое нужно убить.
Тем более что у 1С есть полноценное оффлайн приложение, которое обменивается только итоговыми данными по ценам, выручке, номенклатуре и прочая. Там даже чеки не передаются, ибо незачем, отчет о розничных продажах закрывает потребность. Но если очень надо - можно и их.
Просто мало кто действительно хочет в ритейле заниматься поддержкой всех 50 баз отдельно, каждая свою, вот и придумывают то риб, то облачное размещение. Сам сопровождаю одну такую розничную сеть, которая наотрез отказалась от использования оффлайн приложения на точках по вышеозначенным причинам + еще нескольким внутренним.
Специально для разработчиков, которые не любят устоявшуюся парадигму языка 1С, и был выпущен язык 1С:Элемент, который java-подобный (потому что бекенд на java сделан и синтаксис явно взят оттуда) веб ориентированный (потому что транслируется в react js) язык с поддержкой части возможностей ООП (наследования нет, но есть интерфейсы), синтаксическим сахаром а-ля свежие версии java / python и множеством внутренних улучшений. Насчет подключаемых модулей на java - пока ждем, но запрос к разработчикам фреймворка есть. И да, эффект получается такой же как при появлении 8.0 в бытность 7.7 как основной платформы и технологии.
В 8.3 вырвиглазный желтушный цвет. В 8.5 ранних сборках очень криво отрисовывался интерфейс, сильно перегруженный. В свежих 8.5 уже выглядит намного лучше, но опять же - жесткие рамки интерфейса и возможностей. В Элементе за счет переиспользуемости компонент и большого набора базовых элементов можно собрать какие угодно доп компоненты, которые отсутствуют в стандартной поставке. А если и их не хватает - что ж, HTML + CSS никто не отменял.
Не стоит. Я разрабатываю на 1С чуть больше 10 лет, стремясь использовать в своих проектах самые современные фишки и интерфейсы 1С. И писать решение с нуля - это самое худшее решение. Писать решение на базе стандартных библиотек 1С - лучше, но тоже так себе.
И полтора года пишу на Элементе, где нет вообще ничего кроме двух демок, документации и комьюнити. Там можно развиваться сколько угодно, и этот язык и Фреймворк я считаю более перспективным, нежели современную платформу 1С. В основном из-за малого легаси кода и библиотечного подхода к разработке, что кратно сокращает процесс разработки новых решений. Жаль только пока комьюнити небольшое, библиотек готовых мало (7 от 1С, с десяток от опенсорс сообщества)
Говорят, если начинаешь писать конфигурацию с нуля, с правильной архитектурой, с бизнес логикой продуманной, с адекватными и удобными интерфейсами, то Фреймворк 1С раскрывается с совершенно другой стороны... Пока не взвоешь от реального количества кода, который надо придумать и реализовать.
Итог - заработать в найме именно на дизайне миллион - нереально. Потому что когда ты руководишь - ты не занимаешься дизайном