Есть ли статьи (стандарты разработки) по тому как делать интерфейс для мобильного приложения 1C.

Приложение простое
Выводиться план производства
рабочий аказ, который делает
Сканирует номенклатуру, которую выпускает
Сканирует материалы, который использовал и указывает кол-во

Думаю как сделать интрефейс, что взять за объект творческого подражания ?

Так ты сделай и посмотри как выглядит, попробуй сам попользоваться быстро и будет понятно как не надо
А как надо читай и смотри у раруса в видео

(1) хочу взять за основу интерфйс сбербанка, но даже не знаю можно ли делать горизонтальное прокручивание кнопок в 1C (выбор производственного станка)

(2) можно сделать любой практически интерфейс
через ПолеHTML

(3) Все говорят что можно, но никто не рассказывает как)

(3) html относится к 1С почти также как js, flutter или kotlin. Тогда почему бы не выбрать сразу один из перечисленных языков?

(3) ну а смысл в этом? Проще тогда на свое мобильное приложение ваять, а не костыльно, через webkit реализовывать на 1с.

(6) я еще могу понять, когда это занимает 10% от общей работы мобильного приложения

(4) https://cloud.mail.ru/public/mp3B%2FVwwoC2WX5

(6) (7) У меня нечто вроде библиотеки/фреймворка наваяно, чтобы удобно кодом на 1С ифейс ваять для webkit
Но html/css желательно знать да, чтобы кастомизировать легко

(5) можно работу разделить
фронт пишет спец по html/css/js а бэк и весь обмен с сервером берет на себя 1Сник
на 1С в МП очень удобно с данными работать

(10) Ты прям ломатель шаблонов.

(11) ну на 1С очень легко МП наваять (сложности в реальности оставляем за кадром типа сборки под ios и прочее)
вот произвольный интерфейс без извратов с ПолеHTML никак
спеца по 1С пока найти проще и дешевле чем по тому же kotlin, как и веберов
т.е. дорогой спец во android/java/kotlin/flutter заменяется парой относительно недорогих по html/css/js и 1С

Есть такая наука - UX/UI

(12) А можно попросить пару скриншотов с такого интерфейса? Чтобы понимать ради чего война? Если это возможно, конечно. Если нет - то хотя бы на словах, какие проблемы на практике это позволило решить.

(14) картинки - логотипы разного размера как кликабельные пальцем пункты меню, на произвольном фоне

(13) наука то есть, специалистов ее знающих и умеющих применять на практике нет

(15) Не, для такого добра отдельного программиста нам не надобно :)

(17) В 1С сделать не получится без html/css/js

делай каждое поле сканирования - отдельная форма.
так в акселоте например сделано

(12) а разве фронтеры дешевле чем андроидщики?

(20) хорошие фронтеры умеющие в современные фреймворки дороже
но тут они не нужны особо ибо фреймворком выступает 1С и нужны по сути верстальщики грамотные

(19) вот пример
https://i.imgur.com/HPJNBJS.png

(22) Вот сейчас Злоп придет, *опу надерет. И поделом

(23) За что?

(18) Дык и не надо слава богу.

(18) зачем скрещивать 1С и html/css/js
если можно клиента на html/css/js и через fetch обмениваться с 1С ?

(26) так можно и от 1С отказаться, вопрос что быстрей в написании и удобней при доработках/обновлениях
ТС спросил про интерфейс для МП, ответил что можно какой угодно почти
для учетного приложения мало смысла заморачиваться если стандартными элементами на формах можно
но если надо показать карту или еще что, например сделать какой то хитрый то вот вам ПолеHTML и вперед

(23) в 7-ке уже html можно ?

(24) за такое "междумордие"...
ну вот скажи честно - ты понимаешь что делается при этом экране, что требуется от пользователя? Если сейчас  требуется сканирование - то почему надпись об этом где-то ближе к концу экрана?

(28) емнип, делали. Ну по крайней мере, я смогу. Только зачем?

(30) спросил потому как в (23) ты вызывал специалиста по 7-ке

(31) скорее как спеца по мелким UI для ТСД

(32)+ хотя конечно его опыт со времен экранчиков 200x320 слегка уже устарел
сча есть ТСД с большими сенсорными экранами и часто без аппаратных кнопок, где его огромный опыт уже не катит
там надо место под палец и другие принципы UI уже, ну там свайпы и т.д.

(29) ето да

(29) логика этого интерфейса такая:
Форма все время одинаковая, только по очереди меняется поле ввода сверху вниз
Подсказка под полем ввода.

Ps идея не моя, а акселотовская

(35) да я примерно понял - именно потому, что я видел акселот. (сразу вспоминается анекдот, "чем отличаются большевики от коммунистов")
но согласись, это далеко не самый лучший UI.
(33) опыт - он не в "разрешении экрана", а в понимании "как надо работать".

(28) глянул, попалось https://infostart.ru/public/57767/

Побуду адвокатом дьявола.
Некрасивые и неинтуитивные интерфейсы - не такая уж и большая беда для "рабочих" продуктов. Функциональность важнее.
Хреновый UI уже будет не важен через неделю использования, а UX отлично ляжет на страшненький инженерный дизайн.
Я конечно за все хорошее против всего плохого и чувство прекрасного мне тоже не чуждо. Но при этом отдаю отчет что хороший UI в разы важнее для попсовых продуктов.

(38) Нормально сделанный UI позволяет новому сотруднику взять тот же терминал и в течение получаса работать так же, как обычный кладовщик. Чем меньше нужно думать пользователю при работе с интерфейсом, тем быстрее он адаптируется к работе и меньше накосячит.

(8) Выглядит круто, как так сделать?

(40) очень просто, поле html документа на всю форму. При открытии передаешь в него сверстанный html документ. Мутишь нужные js скрипты на различные события и вуаля

(41) Мутишь нужные js скрипты на различные события - вот здесь как раз хотелось бы поподробнее... Ибо с элементарной кнопкой надо сделать что-то на кнопку совсем непохожее...

(42) А зачем?

(42) Да пожалуйста, можете тут почитать)
https://docplayer.ru/26167854-Html5-i-css3-veb-razrabotka-po-standartam-novogo-pokoleniya.html

(44) вот по js
https://www.chitai-gorod.ru/catalog/book/817663/

(39) С одной стороны - тру. С другой - я бы это не переоценивал. Особенно для функциональности, где хоть так хоть эдак будет простое сценарное обучение.

(46) нормальный интерфейс  уменьшает количество ошибок в разы.

(45) Прекрасные книги, но там ни слова про то, как выкручиваться в МП 1С

(48) а что не так с выкручиванием на 1с? 1с в этом случае как браузер работает, ей передали страничку, она с ней работает

(47) при интенсивной работе интерфейс не сильно важен - исполнители наизусть помнят последовательность действий и ориентируются на звуковые сообщения. в интерфейс упираются взглядом только в проблемных ситуациях и здесь эхолотовский подробный интерфейс https://imgur.com/HPJNBJS может оказаться весьма полезен

(49) при использовании поля html есть известные ограничения на события
а все остальное конечно просто )

(47) Популярное мнение. Но я с ним не согласен.
Если интерфейс средней говнистости, а чел работает по откатанному сценарию - ничего там не увеличивается.
При этом не надо забывать, что UI <> UX. Красивый и интуитивный UI с точки зрения UX может оказаться далеко не идеалом.

(50) все от специфики зависит. В одной конторе в огромном ангаре тысячи ячеек со шмотками, и нужно визуально видеть товар, который собираешься собрать и сканером уже подтвердить сборку. А Терминал нужен, чтобы построить маршрут и подсказать в какой ячейке какую вещь взять. В режиме "эхолота" тут не поработаешь(

(52) А если приходит новый сотрудник? Бывает такая текучка на складе, что каждые 3-4мес новый сотрудник приходит, за 20тыс работать. Образование у таких дай бог школа. Некоторые даже смартфонами толком не пользовались, с кнопочными телефонами ходят. У многих еще и со зрением беда. Без нормального интуитивно-понятного интерфейса будет жизнь-боль обучать таких сотрудников работать с терминалом.

(54) Это ты подставился :) По-моему личному опыту, "пользователям с улицы" интуитивно понятные интерфейсы как раз нихрена не интуитивны. Это они нам с тобой интуитивны. И всем тем, кто постоянно имеет дело с интерфейсами. А человек "от сохи" на любой интерфейс смотрит как на новые ворота и никакой выгоды по скорости обучения не имеет. Тем более, те кто с кнопочными телефонами ходит. Они в любом случае будут плясать от заученного сценария.

(55) но когда на экране 100500 кнопок в хаотическом порядке и чтобы сделать 1 действие нужно нажать 50 кнопок, то такие пользователи обычно завтра на работу уже не выходят. Либо когда, все строго, шаг влево шаг вправо интерфейс не дает, все удобно под руку.

(52) можно сделать супер UX, но с корявым интерфейсом фиг им воспользуешься, либо испортишь экран терминала. После 1-2лет работы стилусом по полосе прокрутки на терминале появляется чуть ли не канавка из зарапин и нажатия уже еле еле отрабатывают. Можно сделать мелкие кнопки рядом и при нажатии пальцем, юзвер будет промахиваться постоянно и путать. Либо сделать мелкий шрифт, и люди с плохим зрением вообще будут страдать.

(53) по аналогии с общепитом эхоловский интерфейс это Макдональдс, безопасный и универсальный на 4-

в ситуации ...в огромном ангаре тысячи ячеек со шмотками... ничего страшного нет - в одной ячейке должна лежать одна товарная позиция и после сканирования ячейки идет сканирование товара.
самый запущенный вариант когда на одной полке полочного стеллажа лежат шмотки с DataMatrix'ами на разных юрлиц, но даже в этом случае визуализация товара не нужна

(56) где ты видишь 100500 кнопок на https://imgur.com/HPJNBJS
ты щас споришь ради спора )

(57) Ты пишешь как раз про недостатки UX.
UX - насколько легко/трудно выполнить действие для достижения нужной цели
UI - интуитивность, читабельность, эстетика

(59) про 100500 кнопок я говорю в общем, а не по данному скрину. Имеется в виду нагруженный интерфейс хуже поддается обучению для новых сотрудников, надеюсь с этим никто спорить не будет?

(58) а теперь представь что это секондхенд и у тебя каждая шмотка это отдельный артикул и таких у тебя уже за 2ляма перевалило. Фабричной линейки и восполняемого товара нет. Так о какой "одной товарной позиции" для одной ячейки может быть речь?)

(49) как она работает? Она ничего не может. Речь про мобильное приложение, не про толстый/тонкий клиент. В мобильном приложении там оно не может вообще ничего. В этом и заключается выкручивание. Нарисуйте, пожалуйста, код кнопки чтобы МП его отработало.

(62) с секондхендом опыта не имею, но всегда полагал, что это как товарная позиция "Обноски", единица измерения - кг

(64) а если ты в розницу продаешь этот сек, тебе пришла 1 тонна мешков, а на выходе получил 200тыс позиции и рознично ими уже торгуешь.

(61) Не надо приводить антипаттерны для войны насмерть. Ты пойми. Я ЗА хороший UI/UX. Я лишь высказал одну простую мысль - не стоит проецировать неоспоримую важность UI в попсовых приложениях на приложения "рабочие". В первом случае баланс между UI/UX часто смещают в сторону первого по понятным причинам. Во втором случае UX важнее. Поэтому высказывать "фу" глядя на рабочий стол подходя с "попсовой линейкой" - торопиться не стоит. Зачастую это дает лучший UX, который в таких приложениях важнее.

(52) только фактам плевать, согласен ты, или не согласен.
"красота" - это не "верстка", не "выключки", "выравнивания"  и т.п. дизайнерские заморочки.
красота - это когда на экране достаточно данных, чтобы осознанно выполнить нужное действие (либо осознанно отказать), и не более того. Это такой размер экранных элементов, чтоб не нужно было напрягать зрение. Это такое выделение, чтоб было понятно, что и зачем сейчас делать.
(54) бывает, что и чаще. (лето, сады - и желающих работать уменьшается. похолодание, делать в садах нечего - и они волшебным образом возвращаются...)
(55) интерфейсы надо делать не "для программистов", а для пользователей. Ходить за ними, за спиной, и смотреть - что они делают, зачем...

(58) а эта "одна позиция" в курсе, чт оона там должна лежать одна? у вас "склад Тьюринга", бесконечный в обе стороны?

(68) у меня склада пока нет - присматриваюсь
на клиентских складах все позиции в курсе где они должны лежать и как

(69) значит, мало клиентских складов видели...
то, что позиции в курсе, где они должны лежать - совершенно не означает, что они там должны лежать в гордом одиночестве.

(63) с чего вы взяли что МП ничего не может? Только что на коленке добавил поле html документа и добавил туда картинку. https://disk.yandex.ru/i/nfpDBY0u0hjz2g

(71) по кнопке тоже проблем нет, добавляешь в боди тег с кнопкой и в js событие кнопки отрабатываешь. Картинки можно хранить в вебе, можно в самой базе в ДД.

(72) но по мне это все равно изврат. Если приложуха в продакшен на 1к+ пользователей, то лучше ее писать с нуля на более подходящих языках, а не изобретать велосипеды. А если для внутреннего пользования, то смысл в этих бантиках и красивых кнопках сомнительный.

(70) не передергивай - в контексте обсуждения речь шла о шмотках. одежду неправильно смешивать в одной ячейке полочного стеллажа, на вешалах могут смешиваться, а в ячейке нет.
другие мелочные товары - инженерная сантехника, канцелярщина, парфюм и т.п. вполне укладываются по несколько позиций в одной ячейке

(73) с другой стороны, внутреннее приложение на пару-тройку десятков юзверей...
ну и важно не столько "бантики и рюшечки", сколько "крупная понятная кнопка"

(74) чем принципиально одежда отличается?

(74) я вам привел пример, где не возможно не смешивать одежду в одной ячейке. Даже возьмем вешалку, у вас на вешалке может быть штук 50 различных шмоток. Если пользователь увидит картинку этой шмотки, то он быстрее найдет нужную, а не будет перебивать все подряд и проверять штрихкоды. А штихкоды на шмотках обычно спрятаны внутри и чтобы их просканировать, необходимо шмотку достать и вывернуть.

(75) "сколько "крупная понятная кнопка"" - а на уф в чем проблема сделать такую кнопку? Можно же шрифт увеличить и даже овальной ее сделать, размер кнопки можно отредактировать. https://disk.yandex.ru/i/on61rbQhkVoWIQ

(78) да ни в чем. Инструмента достаточно. правда, несколько неудобный (хотя, может быть, я этих кошек неправильно готовлю, не умею). Но инструмент всего лишь добавляет удобств (или неудобств).

(79) зато все сразу адаптивно из коробки, не то что на общих формах. Где все привязки вручную расставлялись, где постоянные ошибки при растягивании интерфейса и прочее...

(80) хез. привязки даже в клюшках работали лучше.

(81) я для терминала на рдп в свое время задолбался формы рисовать, чтобы они корректно под разные экраны терминалов растягивались.

(82) но там ты "рисуешь", и они "подчиняются". а тут они ведут себя порой слишком самостоятельно...

(83) а тут ты создаешь множество папочек и привязываешь элементы к ним, устанавливая нужные свойства для папок)

(84) к этому просто надо привыкнуть

(85) ну да. как, впрочем, и "к тому"