Здравствуйте, MadHuman, Вы писали:
MH>Да, всё так. Но это работа не программиста, а аналитика, проектировщика интерфейсов. Уже после всей этой работы разработчик и получает ТЗ в виде конкретного экрана/формы и его дело его реализовать.
MH>Дело же не в той конкретной форме. Мысль Shmj о том, что интерфейсы (которые предположим что уже обдуманы аналитиком и проектировщиком интерфейсов) проще и быстрее конфигурировать чем программировать ручками.
MH>Более того во многих случаях, когда платформа позволяет, аналитики в состоянии вносить изменения в интерфейсы, не привлекая программистов.
Ну, вообще-то исходная мысль Shmj была ровно о том, что интерфейс должен возникать сам из описания структуры данных, безо всяких там аналитиков.
Если же мы отказываемся от этой мысли, то у нас остаётся что? Собственно, реализация интерфейса. Он строится из каких-то кусочков, кирпичиков.
Кирпичики укладываются в формы, свёрстанные определённым образом.
Где лежит граница между программированием и конфигурированием? Вон, ещё в Delphi можно было быстро накидать контролов на форму, понастраивать свойства, привязать их друг к другу и получить работающее приложение, не написав ни строчки кода.

1. Внесение изменений "на лету". То есть при визуальном программировании в той же Delphi или Visual Studio мы всё же должны выполнить компиляцию и деплоймент, чтобы изменения увидел клиент. "Конфигуратор" потенциально даёт возможность править формы без перезапуска приложения.
На практике, для веб приложений деплоймент не сложнее кнопки Save. В том смысле, что у всех 10000 клиентов новая версия появляется одновременно, без даунтаймов и беготни с дискеткой по машинам.
Зато принуждение хранить дизайн в исходниках позволяет, как я уже говорил, пользоваться контролем версий. Если правка формы сломала приложение, то версионированные исходники позволят нам оперативно вернуть всё назад. Конфигурация, сохраняемая "в базу" таких плюшек не даёт — придётся весь тулчейн изобретать заново.

2. Состав кирпичиков. Аналитик с опытом работы неизбежно привыкает мыслить в рамках конструктора. Хорошие решения ему уже даже в голову не приходят; он сразу мыслит "вот тут будет грид, тут табы, тут тулбар". Даже если ему приходит в голову хорошая мысль, то он отбрасывает её как заведомо трудную в реализации. Типа "ну, грид с деревом и тулбаром я и сам накидаю; а за интерактивной картинкой придётся идти к разработчикам и дизайнерам, это минимум месяц ждать. Ну его".
В принципе, это можно было бы решить при помощи более могучего набора кирпичей. То, что мы видим сейчас в гуй-конструкторах — то же, что в 1994 году. Чуть другие формы кнопок, а так всё то же самое. Гриды, табы, тулбары, деревья. Дропдаун, спиннер, календарь. TreeGrid как венец сложности контрола; динамический докинг как венец кастомизации гуя пользователем. Полный тупик, уныние, казарма.

Единственная система с мало-мальски другой парадигмой форм ввода, которую я видел за последние 20 лет, была Lotus Notes. Увы, канула в небытие, раздавлена мейнстримом. Там, похоже, в какой-то момент ушёл последний человек, который понимал в usability, а наследники быстро развалили все достижения, став на несколько лет завсегдатаями WTF сайтов.

Фокус разработки usable софта переместился сначала в веб, потом в мобилки. На десктопе мы безнадёжно застряли в девяностых. Впрочем, веб — немногим лучше. Сайтов, которые было бы реально удобно использовать — единицы. Более-менее приемлемо работают только топовые мобильные приложения. И то — в каждом найдётся, за что поругать.