Serzh KZПо поводу всякого рода художества форм, я как раз таки пытаюсь более универсальные формы разработать так, что бы было проще обучать пользователей а значит дешевле процесс внедрения.
Универсальность форм - палка о двух концах. Универсальную форму, наверное, проще реализовать программисту. А у пользователя не один универсальный бизнес-процесс, а много разных и конкретных. Ему под каждый бизнес-кейс хотелось бы форму, которая делает именно этот бизнес-кейс максимально прозрачным и эргономичным.
Связаный с этим соображением минус универсальных форм - при расширении функционала, добавлении фичей они сильно разрастаются, чтобы редко требуемая фича все равно тем или иным способом была на экране, в то время как в большинстве случаев она будет болтаться мертвым грузом.
Так что построить эргномоичный интерфейс, найти тончайший баланс между универсальностью и конкретностью непросто.

Serzh KZДобавлю, что я не ставлю задачу рисовать специфичные формы гриды и т.д.
Я пытаюсь получить скорость:
1) Скорость при вводе данных(табличные представления для исходных наборов,импорт(ручной,автоматический),система понятных ошибок, отсрочка исправления ошибок)
2) Скорость при полученние данных(фильтрация,группировка,статистика,куб)
3) Скорость построения сценария формирования данных в реляционную базу(путем конфигурирования)
4) Скорость работы реляционной базы(алгоритмы автоматической перестройки и создания индексов, создание промежуточных таблиц)
5) Скорость работы клиента(создание или испльзование готовых фреймворков пока второе предпочтительней)
6) Скорость администрирования объектов(роли позволяющие управлять любыми элементам ПО)
Не согласен. Скорость ради скорости - мы инженеры формулы один ?
1. Некоторые перечисленные в данном пункте фичи с скорости не имеют отношения. Вводить данные в табличном виде, когда а-ля эксель можно копировать куски ячеек с места на место это удобно. Система понятных ошибок, отсрочка исполнения - это не скорость. Про ошибки и дырки в данных важно то, что на этапе ввода на определенном рабочем месте действительно может быть известна не вся информация, но не дать бизнесу ввести данные по выгодной сделке, упускать продажу нельзя. Надо чтобы система позволяля фронту вводить неполностью консистентные данные, но потом должны быть механизмы периодической или по запросу верификации данных, так, чтобы все выявленные дырки и несоответствия предоставлялись для дальнейшей обработки. В моей системе это была "система проверочных отчетов", которая с соблюдением определенной дисциплины, графика, тыкала мордой ответсвенных за то пользователей в найденные косяки.
3. Отконфигурировав что-то бежать как на пожаре смымла нету. Процедура конфигурирования не настолько частая, сопровождается дополнительными действиями (согласованиями, тестированием, и т.п.), поэтому давить педаль газа в пол нет необходимости.
4. Тоже разовые/нечастые процедуры, проводящиеся в процессе разработки нового функционала а не при постоянной эксплуатации системы.
5. На хорошо устроенных фреймворках скорость работы клиента определяется мощностью и сложностью серверных данных.
6. Тоже здесь важнее не скрость а удобство, администрирование - разовая, периодическая работа а не постоянная. Администрировать уже отстоявшуюся систему практически не требуется.

В общем как анекдоте про матерого быка и молодого бычка. Надо медленно спуститься с горки... Поспешай не торопясь.