Здравствуйте, Shmj, Вы писали:
S>Может и не велика, но когда форма вот такая:

S>Image: ServiceCenter_Main.jpg

S>т.е. когда есть 6 других таблиц, связанных с данной — то представьте сколько времени уйдет на создание такой формы. Нужен не только просмотр, но и добавление/редактирование данных. Вручную забембаешься поля вводить — даже если по 1 мин. на каждое — уже дня 2 уйдет.

S>Вот вы бы за сколько времени создали такую форму вручную? Притом что форма должна не просто быть, но еще и связана с данными — с 7 разными таблицами + еще словари (около 10). Путем конфигурации это делается максимум за час. Сколько у тебя уйдет на ручное написание?
Вот прямо спасибо за отличный пример.
Эта форма — тупик цивилизации. Программисту она может казаться даже красивой — полное доминирование математической модели над здравым смыслом. Нормальному человеку эта форма кажется ужасной.

Проектирование нормальных приложений идёт не от структуры данных, а от сценариев. Что люди делают с этой "формой"? Ищут заказы, создают новые заказы, изменяют существующие? Ответ "всё это, и ещё 12 действий из контекстного меню" не подходит — надо разобраться во всех из них. Классифицировать пользователей по ролям, для каждой роли знать относительные частоты всех сценариев.
Для каждого из сценариев прояснить основной успешный вариант и две-три самых популярных вариации — то есть прямо по шагам "смотрим на XXX, делаем YYY". Для каждого неуспешного сценария выяснить предлагаемые шаги по исправлению проблемы.
Внимательно изучить данные, которые нам нужно показать пользователю на каждом шаге каждого сценария, и данные, которые нужно у пользователя запросить.
Данные для показа приоритизировать. Запрашиваемые у пользователя данные нужно изучить под микроскопом на предмет того, как избежать их запроса вообще; если нельзя избежать — то минимизировать то, что спрашиваем; то, что осталось — валидируем мягким способом, расставляем хинты. Характерный пример — создаём новый заказ. А часто ли встречается такая ситуация, что клиент повторяет свой предыдущий заказ с небольшими вариациями — то есть можно его скопировать и дать подправить; ведь это быстрее, чем плодить новый? Часто ли встречается такая ситуация, что есть популярный набор работ для каждой модели телефона, и сразу после ввода букв "6s" можно угадать, что будут заказывать?

Даже не проделав всю эту титаническую работу, одного взгляда на форму достаточно, чтобы оценить её usability.
0. Поиск заказов сделан опытным мизантропом. Вместо популярного лет 10 уже паттерна query language, который бы позволял просто искать в стиле "статус:закрыт И периодтекущий месяц)" (а заодно ставить закладки или автоматически вычислять наиболее запрашиваемые фильтры) мы имеем сочетание комбобоксов и свободнотекстового поля ввода. 1990е.
1. Список заказов выведен в грид, который вдвое шире доступного места. Либо там справа — какая-то муть, которую вообще в списке заказов показывать не надо, либо пользователь вынужден постоянно скроллить влево-вправо.
2. Все связанные сущности выведены в виде гридов на взаимоисключающих табах. Нет возможности увидеть одновременно работы и материалы. WTF? Ведь очевидно, что для работы "замена экрана на S9" есть стандартный набор материалов, без которых она невыполнима. Нет, пусть пользователь потеет, ручками вбивает пары "работа-материал" в разные табы.
3. Всё, чего может быть больше одного, засовывается в грид, без малейшей попытки оценить распределение количества элементов. Например, у 99% заказов 0 или 1 платёж. Тем не менее, мы выделяем под них целый грид, а под него — отдельный таб. Теперь, чтобы посмотреть, оплачен ли заказ, надо кликать в него, а потом прыгать в таб. Десять баллов Слизерину.


В итоге вы за час делаете говно. Вот прямо берёте и увеличиваете объём страданий и ненависти в мире. Понятно, что можно сделать то же говно вручную, потратив неделю на раскладку гридов и кнопок по форме в том же виде.
Но речь не об этом, а о том, что можно было сделать UX примерно в 100 раз лучше безо всяких "гридов" и "табов", потратив чуть больше времени на анализ действий пользователей.
И вот такой, нормальный UX, вам не сделает никакой генератор. По крайней мере до тех пор, пока генератор собирается работать по модели данных.
Чтобы сделать хоть что-то приемлемое, генератор должен работать с моделью сценариев. Типа "пришёл клиент с новым заказом", "пришёл клиент забрать выполненный заказ", "позвонил клиент узнать статус заказа", "в процессе выполнения заказа возникли вопросы к клиенту, требующие согласования", "нужно оповестить клиента о готовности заказа". Вот с чем работает разработчик UI, и с чем должен работать генератор. А не со схемой типа "к заказу можно прицепить файлы, фотографии, платежи, работы и материалы". Да, можно. Ну и что?