предположим, что пишется 1000 параметров(что слегка дохрена), каждое значение пускай будет 100 байт каждый(что тоже перебор). по правилам параметры пишутся 8 раз в секунду ( были дебаты насчет поднять до 16, но все производители мягко послали регулятора в лес )
получим 8Мб/с или порядка 70Гб, за сутки полета.
пусть дополнительно пишутся все переговоры с землей и внутри ( если маразм мне не изменяет то там 9 каналов) пусть они пишут это на 320кб/c, пусть тоже сутки это даст нам еще порядка 35 Гб.
итого где то 100 Гб за сутки.
Но насколько я помню, там не все данные пишутся 8 раз в секунду, Разброс от 8 раз в секунду до 1 раза за 16 секунд, данные укладываются в так называемые FDAU и в среднем поток получается около мегабита в секунду ( без учета, голоса)
так что цифра в 500Гб за полет, как то сомнительна.
вот в это и противоречие. если у вас ( при декларируемом вами подходе — показываем только нужное) в диалоге выбора товаров присутствуют контролы (как вы пишете редко используемые) с полной инфой по товару и они явно делают сам диалог сильно тяжелее для восприятия.
тоесть вы рекомендуете некий принцип, а сами ему не следуете, потому, что не позволяет решить несколько бизнес задач на одном экране, я правильно понимаю?
С ссылками беда. книги могу рекомендовать следующие:
Рассказы конструктора
Ракеты и люди
Воспоминания главного конструктора танков
Записки конструктора-оружейника
Оружие победы
Путь в ракетной технике
Кузницы грома
Цель жизни
Как я стал инженером
Война и мы.
в 7.7 и 8.0 форма платежки одна на все случае. если мы говорим о системе из коробки.
Что изменится в подходе от количества человек? Ну будет интерфейс для специалистов, интерфейс для мастеров и интерфейс для начальников цехов (и еще десяток разных).
термин ескд говорит о чем нибудь? число участников обычно выливается в число ролей и сложность процессов. роли и процессы выливаются в сложный гуй. упрощать этот гуй без детального знания процессов заказчика и наличия ванги для определения как они (процессы) изменятся в будущем — достаточно бессмысленный и дорогостоящий процесс.
Возьмите дизайн гайды сапа или сейлфорса — там не самый глупые люди работают, очень интересно про дизайн гуев пишут.
Предположил, что ваша область описана на странице вашего продукта.
Почему я должен возражать против вашего подхода? я лишь говорю что в многих случаях он не работает.
то есть если изложить краткую версию дискуссии:
Вы: для решения проблемы со сложным гуем в ерп давайте показывать только те данные, которые нужны сейчас пользователю. в итоге интерфейс станет проще поскольку на нем будет меньше контролов.
Я: не вопрос, вот форма в ней почти 70 полей ( я про декларацию) их все надо показывать, поскольку только в сумме они определяют следующее действие пользователя. ваш подход не сработает. как быть дальше?
на основании опыта предположу что таких ситуаций сильно больше 50%. таким образом предполагаю, что с помощью вашего подхода проблему в целом не решить.
+ скриншоты вашей системы подтверждают ( особенно если предположить, что на них показаны только нужные данные) — интерфейс не получается простым.
50 бухгалтеров это конечно очень много, но это просто иллюстрация из понятной вам предметной области.
гораздо интереснее когда десятки начальников цехов, пара сотен мастеров, пара тысяч специалистов, сотни поставщиков, десятки тысяч единиц номенклатуры и стандартизованные формы ескд. ( средней руки заводик в общем).
в общем в области ерп за пределами розничной торговли вам будет ждать масса открытий.
Директор и бухгалтер конечно имеют разные и не пересекающиеся функции. а что делать если у вас в бухгалтерии 50 человек и все они колотят платежки по своим участкам. форму плтежки тоже раной показывать? там ведь в зависимости от назначения платежа разные поля заполняются
например чтобы в случае отсутствия пети, вася влился в работу быстрее. тоесть передача знаний петей будет примерно такой. вот на том экране у тебя «рассерятся» поля А, Б, В и в них вводишь то-то и все. В вашем случае петя сначала должен будет посмотеть — а каким в итоге будет гуй у васи. что ему покажут, а что нет.
но в целом шире: экраны в ерп делаются не просто так, чтобы показать данные. экран описывает стадии какогото процесса и если ты участник процесса, то тебе очень часто полезно видеть все данные. даже если ты в итоге вводишь в одно поле 5 циферок и нажимаешь «ок».
Возможно в вашей системе и приходится давать доступ от другого пользователя, а в обычных ерп, просто прав добавляют ( или ролей).
Васе вчера они были не нужны, но вот с сегодняшнего дня петя в отпуске, начальник подписал приказ о том что вася петю замещает, админ зашел в консольку и добавли васе прав. вася логинится и… «але админ, а че у меня тут картинка другая?».
у вас в компании часто водителей грузовиков в пилоты берут работать? клиенты не жалуются?:)
Еще раз: ваш подход применим в ограниченном количестве случаев. Если вы будете смешивать разные подходы к проектированию гуя в одном приложении, то, вероятнее всего, у вас быстро начнется каша.
Любой экран управления как правило имеет несколько групп пользователей, которые смотрят все данные, но выполняют ( каждая группа) свои операции.
Афоризмы это отличная штука, правда на любой из них всегда можно найти такой же яркий, но с противоположным смыслом, например:
для любой проблемы существует красивое, элегантрое, простое и неверное решение
тут еще есть момент того, что ролю людей в больших компаниях часто изменяются. вчера кладовщик вася работал себе, а сегодня он замещает кладовщика петю, который имел право чтото отпускать и рррраззз — вася видит совсем другие экраны. васе страшно, да.
Забавно что вы судите о чем-то, не имея представления о предметной области. в результате все выдвинутые вам предположения не верны.
декларация это несколько объемных документов с кучей полей. всем участникам процесса нужно видеть все эти поля, даже при том, что редактировать они могут только некоторые. поэтому ваш подход показа пользователям разных экранов с «их» полями — не вариант.
новых типов деклараций не существует и новых экранов не надо. Повторюсь, вы «совершенно не видите» неприменимость вашего подхода, потому что не знаете предметной области. На мой взгляд это опрометчиво.
В рамках одной небольшой компании это вполне может работать. когда появится много магазинов, разные страны, разные комплаенсы, и много еще чего — вот тогда врядли.
почемуто многие воспринимают ерп — как бухгалтерия + склад. а это дай бог чтобы 10%.
получим 8Мб/с или порядка 70Гб, за сутки полета.
пусть дополнительно пишутся все переговоры с землей и внутри ( если маразм мне не изменяет то там 9 каналов) пусть они пишут это на 320кб/c, пусть тоже сутки это даст нам еще порядка 35 Гб.
итого где то 100 Гб за сутки.
Но насколько я помню, там не все данные пишутся 8 раз в секунду, Разброс от 8 раз в секунду до 1 раза за 16 секунд, данные укладываются в так называемые FDAU и в среднем поток получается около мегабита в секунду ( без учета, голоса)
так что цифра в 500Гб за полет, как то сомнительна.
но думаю мы уже начинаем ходить по кругу.
Рассказы конструктора
Ракеты и люди
Воспоминания главного конструктора танков
Записки конструктора-оружейника
Оружие победы
Путь в ракетной технике
Кузницы грома
Цель жизни
Как я стал инженером
Война и мы.
термин ескд говорит о чем нибудь? число участников обычно выливается в число ролей и сложность процессов. роли и процессы выливаются в сложный гуй. упрощать этот гуй без детального знания процессов заказчика и наличия ванги для определения как они (процессы) изменятся в будущем — достаточно бессмысленный и дорогостоящий процесс.
Возьмите дизайн гайды сапа или сейлфорса — там не самый глупые люди работают, очень интересно про дизайн гуев пишут.
Почему я должен возражать против вашего подхода? я лишь говорю что в многих случаях он не работает.
то есть если изложить краткую версию дискуссии:
Вы: для решения проблемы со сложным гуем в ерп давайте показывать только те данные, которые нужны сейчас пользователю. в итоге интерфейс станет проще поскольку на нем будет меньше контролов.
Я: не вопрос, вот форма в ней почти 70 полей ( я про декларацию) их все надо показывать, поскольку только в сумме они определяют следующее действие пользователя. ваш подход не сработает. как быть дальше?
на основании опыта предположу что таких ситуаций сильно больше 50%. таким образом предполагаю, что с помощью вашего подхода проблему в целом не решить.
+ скриншоты вашей системы подтверждают ( особенно если предположить, что на них показаны только нужные данные) — интерфейс не получается простым.
гораздо интереснее когда десятки начальников цехов, пара сотен мастеров, пара тысяч специалистов, сотни поставщиков, десятки тысяч единиц номенклатуры и стандартизованные формы ескд. ( средней руки заводик в общем).
в общем в области ерп за пределами розничной торговли вам будет ждать масса открытий.
если кассиру добавили прав на операцию возврата, то почему он не может сделать возврат?
тем более я не понял — где я это предлагаю?
но в целом шире: экраны в ерп делаются не просто так, чтобы показать данные. экран описывает стадии какогото процесса и если ты участник процесса, то тебе очень часто полезно видеть все данные. даже если ты в итоге вводишь в одно поле 5 циферок и нажимаешь «ок».
Васе вчера они были не нужны, но вот с сегодняшнего дня петя в отпуске, начальник подписал приказ о том что вася петю замещает, админ зашел в консольку и добавли васе прав. вася логинится и… «але админ, а че у меня тут картинка другая?».
у вас в компании часто водителей грузовиков в пилоты берут работать? клиенты не жалуются?:)
Любой экран управления как правило имеет несколько групп пользователей, которые смотрят все данные, но выполняют ( каждая группа) свои операции.
Афоризмы это отличная штука, правда на любой из них всегда можно найти такой же яркий, но с противоположным смыслом, например:
для любой проблемы существует красивое, элегантрое, простое и неверное решение
декларация это несколько объемных документов с кучей полей. всем участникам процесса нужно видеть все эти поля, даже при том, что редактировать они могут только некоторые. поэтому ваш подход показа пользователям разных экранов с «их» полями — не вариант.
новых типов деклараций не существует и новых экранов не надо. Повторюсь, вы «совершенно не видите» неприменимость вашего подхода, потому что не знаете предметной области. На мой взгляд это опрометчиво.
почемуто многие воспринимают ерп — как бухгалтерия + склад. а это дай бог чтобы 10%.