Об удобном софте для сложных предметных областей.

[metaclass]

Каждый раз, когда я читаю justy_tylor или когда меня очередной раз посещает навязчивая идея сделать генерацию UI из моделей (как у меня генерируется все остальное), я вспоминаю вот эту картинку http://ips.intermech.ru/images/s1_big.png или интерфейс 3D Max или CadSoft Eagle.

Я до сих пор не могу для себя решить - адский пиздец сложности UI профессионального софта - это объективное следствие сложности предметки или же все-таки, как всегда в этом нашем IT - случайная сложность, потому что делают "как привыкли", "чтобы пользователи пользовались привычными метафорами" и "у нас эргономикой занимаются программисты".

У меня софт обычно простой. Потому что предметка вся это "ввести первичные данные, получить данные с 100500 приборов и желязяк и показать по ним отчеты", ресурсы ограничены, UI делать некому, соответственно все по максимуму сводится к обобщенным CRUD-оперденям. А бэк-енды, базы данных и бизнес-логика, когда она не особо связана с UI - для меня это отдых. Потому как в большинстве случаев укладывается в функциональщину и SQL.

Comments

[justy-tylor.livejournal.com]

"Переведено профессиональными художниками, озвучено профессиональными программистами". Есть разные плохие подходы для многоинформации. Вывести кучу окон и кнопок (демонстрация богатства среды), которые отжирают когнитивные ресурсы. Или как в MS Office - богатство среды давно продемонстрировано, поэтому марсианская логика часть информации прячет под шторки, но ненужное торчит, а нужное почему-то каждый раз оказывается скрытым, ибо "миллионы леммингов не могут ошибаться". Здесь такой момент, что "нужное далеко" и "ненужное маячит" одинаково губительны для интерфейса, но статистически общее среднее оказывается неудобным всем разумным людям.

Единственный гуманный подход - сбалансировать подачу информации (как дерево, с учётом веса/полезности сущностей) под выбранную типовую деятельность пользователя, с возможностью ребалансировки пользователем же под нетиповые действия. Нужное - близко. Редко нужное - дальше. Нужное только приходящему автоматизатору - во встроенной консоли. Продвинутый пользователь с нетиповой деятельностью определяет свои меню и шорткаты или просит приходящего автоматизатора.

Наивная генерация UI из моделей будет заведомо несбалансирована, а вот если в модель аннотации под UI вставить, то получится полноценный logical UI, и результат превысит по качеству любые дельфиформочки.

[metaclass.livejournal.com]

Я про аннотации и стили думал - т.е. из модели генерим что-нибудь обобщенно-универсальное, сопоставляясь со своими искаженными представлениями о том, что важно видеть, а потом подгоняем под юзеров стилями-настройками и прочим таким.

[justy-tylor.livejournal.com]

Стили задаются платформенными (или самописными) гайдлайнами, где однозначно указывается "10 условных пикселей между чекбоксами и никак иначе". На аннотации модели остаётся в основном выбор отображения индивидуальных свойств, разбиение на вертикальные и горизонтальные под- (подпод-) группы или перенос в отдельные экраны.

[gineer.livejournal.com]

так может говорить только тот, кто с (условными) CSSами не ебался

[justy-tylor.livejournal.com]

CSS это заплатка из visual в visual, со всеми прилагающимися граблями. А в треде обсуждается генерация из logical в visual, что работает совершенно иначе.

[gineer.livejournal.com]

" Бендер- Технику этого дела знаете? Воробьянинов- Нет,но его нужно выкрасть!" (С)

[gineer.livejournal.com]

но почему-то... еще никто не сделал его так, чтобы не вылезало два вида граблей:
одно -- неконсистентность, когда неожидано наталкиваешся на такой момент, что нужно "поправить всего чуть-чуть на пару пикселей" а система уже его не понимает и приходится танцевать танцы с бубном
второе -- прогтечка абстракций, когда мэнагэер и дизайнёр придумывает что-то такое, для чего оно не приспособлено (например разметка статическая, а он хочет сделать её динамической), и опять программисту танцы с бубном