Здравствуйте, yukosoft, Вы писали:

Y>Специально для форума написал большую зелёную надпись — а можно было и бегущих красных муравьёв.
Image: core15.jpg
Вы не понимаете, о чём я пишу, увы.
Чисто для контекста: первую такую систему авто-генерации гуя по БД лично я написал в 1991 году на Clipper. И с тех пор наблюдаю возрождение этой идеи с завидной регулярностью.
То есть дело не в том, что я не понимаю, как это работает — я этот этап уже прошёл.

Y>кто-то писал: "Вместо популярного лет 10 уже паттерна query language, который бы позволял просто искать в стиле "статус:закрыт И период текущий месяц)" мы имеем сочетание комбобоксов и свободнотекстового поля ввода"
Y>Есть и такой конструктор запросов:
Y>Image: core12.jpg
Вы неверно понимаете мои аргументы. Дело не в конструкторе или деструкторе запросов. Речь о сценарии работы. Давайте рассмотрим подробнее паттерн, о котором я говорю.
Когда я ищу письмо в аутлуке, я могу написать просто

brent

Это мне найдёт все письма, где брент — отправитель, или получатель, или упомянут в тексте.
Если писем слишком много, я могу уточнить запрос вот так:

from:brent

Мне не надо возить мышкой, чтобы строить предикат типа "Атрибут: скролл-скролл-скролл-скролл... Имя Отправителя. Операция: клик-клик... равно содержит. b-r-e-n-t". Я просто пишу текст.
Я могу уточнить поиск, написав (опять в тексте! Безо всяких кликов, драг-н-дропов и прицеливаний в выпадающие окошки)

from:brent AND sent:August 2019

При этом, естественно, работает автодополнение.
Что это мне даёт? Всю мощь работы с текстом: то есть я могу редактировать запрос при помощи copy-paste. Автодополнение помнит мои запросы, поэтому если я часто ищу закрытые заказы, то достаточно набрать "ст", чтобы поиск предложил мне дополнить его до "статус:закрыт". И все остальные варианты запроса, вроде "статус:закрыт И закрыт>неделя назад", "статус:закрыт И закрыт:сегодня" тоже показаны прямо тут, достаточно пару раз нажать "вниз" и enter.

В чём преимущество? В пологой кривой обучения: вначале работы всё, что я умею — вводить буковки в поле ввода. Когда я осваиваю "конструктор фильтров", построенный в виде тех самых кнопочек/дропдаунов, то он строит именно текст — и если сначала я выбирал фильтр "закрытые за неделю" через меню, то через пару дней я уже запоминаю, как это пишется. Система подстраивается под меня, и в итоге я получаю доступ к фильтрам, актуальным именно для меня, буквально за пару кликов. Независимо от количества условий. Очень легко делать функции типа "сохранить как именованный фильтр", как это сделано в той же Jira.

Y>Конструктор умеет отображать данные в двух представлениях: табличное и карточное. Данные ищутся в табличной части а работа с данными может быть и в таблице и в карточке. Так вот конструктор как раз позволяет по требованию заказчика оперативно поменять представление.

Y>и вот как выполнено требование заказчика. В конструкторе снято 3 галки и затем перемещением мыши таблицы разложены так как укажет заказчик интерфейса. Возможно скорость и не важна но это заняло около 2 минут.
Y>Image: core14.jpg
Ок. А стало ли лучше? Во-первых, всё ещё кто-то должен сесть, и "заказать интерфейс". То есть проделать всю ту работу по проработке сценариев, про которую я говорил.
Во-вторых, потом надо ещё и выразить эти сценарии в терминах блоков конструктора. Вот вы за две минуты "решили" задачу "показать одновременно платежи, работы, и материалы".
Начнём с платежей. Они по-прежнему свалены в таблицу. Занято дочерта места (~7 строк) под бессмысленные заголовки, скроллбары и кнопки навигации. Это примерно как использовать рамный джип для того, чтобы тарелку с завтраком везти от кухни до дивана. В реальном UI достаточно одной строки: "Оплата: 100% (18 сентября: 2000р нал через кассу)". Если платежей несколько, то строка выглядит так: "Оплата: 100% (18 сентября: 1500р VISA, 500р нал через кассу)".
Если оплата неполная, то выглядит так: "Оплата: 25% (18 сентября: 500р нал через кассу) [+])
Таким образом, мы экономим место для действительно важных вещей на экране. Почитайте классиков — Нильсена, Тафти. У вас весь экран загажен chrome и non-data ink.

Далее — работы и материалы. В UI никак не видна связь между работами и материалами, что провоцирует на ошибки — например, есть работа по замене клавиатуры, а самой клавиатуры в заказе нет.
Неверно выполнена декомпозиция задачи. Очевидно, вместо "работ" и "материалов" должны быть "операции", которые, в свою очередь, требуют "работ" и "материалов". Попытка выразить эту идею при помощи конструктора эту идею попросту убьёт, т.к. у нас будет уже три уровня иерархии таблиц master-detail.
Очевидный способ решения — это список операций в не-табличном виде:

- замена аккумулятора: 500 р (работа: 500р, аккумулятор: 0р [+])
— замена экрана: 1100р (работа: 500р, матрица экрана: 600р [+])
[+]
Итого Работы: 1000р [Сделать скидку]
Итого Материалы: 600р

Выравнивание и прочие детали требуют проработки. Дизайн каждой строки требует проработки всех вариантов — один элемент, два элемента, много элментов; элементы с общими данными (например, из названий материалов при выводе автоматически убрано название модели, т.к. оно совпадает с названием модели в заголовке; при редактировании подробностей выводится полное название, цены выбираются из списка реально имеющихся на складе комплектующих).

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

Y>Конструкторы идеальны для решения прикладных задач и когда есть необходимость постоянной доработки или переработки интерфейса.
Скорее наоборот: использование конструкторов гарантирует необходимость постоянной доработки или переработки интерфейса.
Y>То что этот и похожие конструкторы "говно" — даже не поддаётся сомнению — это так! Только ручное создание и изменение форм и тысячи строк кода позволяют нам всем намазывать масло на хлеб.
Конструкторы, на самом деле, хорошая и правильная идея. Проблема — в их ориентации на структуру данных, а не на пользовательские задачи. При этом выбор выразительных средств крайне ограничен: для списков у нас есть только "грид", а он хорошо работает для очень специфических данных.

Кроме того, основная критика всё же не в адрес конструкторов, а в адрес авто-генераторов.
Конструктор подразумевает хоть какое-то участие человека, который может попытаться применить здравый смысл и дополнительные знания — например о том, что в типичном заказе 200 строк "деталей" и только 1 платёж, а не наоборот.

Автогенератор ничего этого не знает, он видит список с кардинальностью 0..∞, и хреначит его в таблицу. Он видит набор из 30 свойств у объекта, и хреначит их всех в колонки. У него нет данных о том, какие свойства являются важными, а какие — нет; какие используются редко, а какие — часто. В итоге получаем разрежённые гриды, которые одновременно показывают слишком много всего и слишком мало всего.
Прикладной программист начинает приносить структуру в жертву богу конструктора. Например, он интуитивно понимает, что колонки "Фамилия, Имя, Отчество" — это какой-то треш, подавляет их вывод в генератор атрибутами, и придумывает вычисляемое свойство ФИО, которое клеит всё вместе, борется с лишними пробелами при отсутствующем отчестве, и изобретает специальный контрол, который используется для ввода такого "композитного" свойства.

Всё это время стоило бы потратить на дополнительные исследования реальной задачи — как раз чтобы знать, что встречается часто, а что — редко. Less is more — идеальный UX должен как показывать как можно меньше мусора, и задавать как можно меньше вопросов.