Алан Купер. Об интерфейсе - супер книжка!!! Маст хэв!

Ну и у меня советов спрашивать

Во-первых, надо определиться с ИДЕОЛОГИЕЙ интерфейса. Иногда бывает нужно делать "жесткий арм" - шаг влево, шаг вправо - расстрел, прыжок на месте - попытка улететь. Для массовых рутинных отстоявшихся операций, малоквалифицированного персонала. Альтернативный вариант - интерфейс, поозволяющий легко скользить по данным, переходя от одной сущности к другой. Большее применение головного мозка для использования прогаммы, но возможно решать любые задачи. Я сторонник второго подхода.

Надо продумать архитектуру презентационного слоя системы, а это, неизбежно, тянет за собой общую архитектуру. Могу описать как эти слои работаю у меня.
Первый слой - таблицы базы данных. В этом слое решается вопрос логирования изменения и грубое, но абсолютно надежное разделенние прав доступа на уровне ядра БД.
Второй слой - таблицы, запросы, функции и процедуры базы данных как источники данных прикладных форм. Здесь же управляющие контроля, управляющие фильтрацями и сортировками при подгоне данных в прикладные формы.
Третий слой - сами прикладные формы.

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

Надо выбрать стиль интерфейса. Это может быть таббед стиль, как новый аксесах, более старомодный эмдиай, что-то еще. Я видел учетную финансовую систему, интерфейс которой был построен полностью на аутлайновых деревьях - было карасиво, и, наверняка логично с точки зрения программиста, но работать с ней было дико неудобно. Допустим, надо попрравить один и тот же атрибут в нескольких записях. В табличной форме это решается элесентарно - правим ячейку, переходим на следующую запись, правим ячейку (в том же столбце). В этой же системе надо было раскрыть дерево записи, добраться до нужного атрибута через несколько уровней узлов, потом раскрыть запись следующего объекта, сделать то же самое. При том что в деревьях вложенный куда-то внутрь атрибут фиг увидишь. Удобно, как зубная боль! Антипаттерн, адназначна!

Раз уж сказал про антипаттерны, продолжу растекаться мыслью по древу в этом же напраалении.

Продолжение следует

Ыщщо антипаттерны.

Столь часто задаваемые вопросы на этом форуме: Как мне в одной карточке сделать и редактирование записи и переход к нужной записи если я в каком-то поле введу какой-то код. Тоже ни хрена не удобно. Просмотр, поиск объектов через карточку, когда не видно их перечня - неприемлем. Удобный поиск в таблице и мгновенный, легкий переход на карточку найденной записи (в один клик) - то, что нужно. Казалось бы в новых аксесах разделенная форма то, что нужно, ан нет. Я с этим не согласен. Карточка должна показывать больше более подробные данные, нежели таблица. Подписи полей должны быть достаточно длинные, исчерпывающе описыющие поля. Визуальное расположение и группировка полей по смыслу должна присутствовать. Группы полей могут иметь общий для всех заголовок, подпись. Все это в табличной форме в принципе не реализуемо.

Еще один часто реализуемый антипаттерн на многих учетных системах - особенно тяжелых. Это скажи что тебе недо ? А что у вас есть ? и так долго. Имеется в виду, что для того чтобы не загружать бд тяжелыми запросами на таблицах с многомиллионными записями разработчик принял самое лнгкое и удобное для себя решение: при открытии табличная форма открыватеся пустая и пользователь должен сначала указать некие условия отбора, только после этого ему дозволяется получить данные. В чем состоит проблема - только в том, что пользлватель должен абсолютно четко представлять что где и как в этой таблице хранится. Ошибешься в задании фильтров - бац! результат - пустой. Многие опции фильтрации часто содержат пниятые в этой системе кодировки, ключевые слова и т.п. Часто без подписей, объяснений. Приходится тратить много времени, пока не нащупаешь комбинацию, которая дает непустую выборку чтобы посмотреть, что хоть эти данные из себя представляют! Табличные формы обязательно должны открываться с какими-то наиболее типовыми наборами, всеми способами помогать пользователю перейти к тому, набру, который ему нужен.

Продолжение следует.

Теперь кратко опишу концепцию интерфейса своих разработок.

Все прикладные формы пользователей относятся к одному из трех типов - Форма-карточка, Форма-таблица, Форма-струкрура, Вложенный грид. Помимо них вспомогательный формы: Модальные диалоги, Многоходовые визарды, Системные окна вывода сообщений и информирования о ходе выполнения процессов. Вот из этих кирпичиков построены все мои системы учтетно-финансового толка.

Все прикладные формы настраиваются в конфигураторе, т.е. кодить, чтобы форма задышала не нужно.

Форма карточка. Имеет источник данных. Имеет область заголовка, область главных данных, область набора вкладок. Может содержать любое количество Вложенных гридов (как правило, на вкладках). Вложенные гриды могут быть связаны с источником Формы-карточки или друг с другом какпарент-чаилд. Форма-карточка может использоваться как правая панель Формы-структуры, раскрывая данные текущего узла.

Продолжение следует

Форма-таблица.

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

Форма-структура.

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

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

Взаимодействие форм.

Ка было видно на картинках, формы имеют кнопки Открыть... Показать... Этими кнопками выполняется открытие новых форм и переход между ними. Из Формы-таблицы (а точнее Вложенного-грида) обязательно должна быть команда перхода в Форму-карточку. Если во Вложенном гриде запись - какая-то сложная сущность, то для нее можно открыть несколько Форм-карточек. Например, грид Реестр договоров. Открывается Карточка договора. Еще удобно сразу окрыть Карточку Покупателя по договору и Карточку Продавца.

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

Из Формы-карточки можно перейти "наверх" - в формы, содержащие набор данных, текущая запись которого развернута в Форме-карточке - в Форму таблицу и Форму-структуры.
Находясь на вкладке Формы-карточки с Вложенным гридом можно переходить на другие формы, содержащие данные этого грида - Карточки, Таблицы, Структуры.

Приведу пример переходов для картотеки контаргентов. Имеется набор таблиц, в которых хранятся данные по Организациям-контрагентам, включая информацию об их подчинении парент-чаилд, Физлицах, Работа Физлиц в Организациях на разных Должностях.

Открываем структуру контрагентов (Холдинго - Огранизация - Филиалы...). Открываем Карточку организации. Из нее со вкладки Физлиц - Карточку физлица. Из нее со вкладки Работа в организациях - Карточку организации. Из нее - Таблицу организаций. И так далее. (Разумеется во всех переходах выполняется позиционирование новой формы на текущей записи).

Кофигурирование форм.

Все формы, их содержмиое, открытия новых форм, переходы по формам - все конфигурируется. Для своей работы форме кода не требуется. (Только для красивого ресайзинга). Еще забыл про антипаттерн - нерезиновые формы. Все формы обязаны быть резиновыми, причем алгоритм их отрисовки должен давать хорошие результаты безо всяких сплиттеров - на основании собственной смышленности. Я обычно задаю зоны форм в долях от общего размера с минимальным и максимальным порогом.

Источники данных форм тоже содержатся в общем перечне и тоже конфигурируются.

Для встраивания специфического прикладного кода (когда-то же таки программа должна что-то делать кроме как показывать, вводить и редактировать данные) использется подписка на события.

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

Визуализация процесса загрузки данных.

Во всех прикладных формах (особенно тяжелых) надо обязательно стараться открывать форму как можно скорее (паузы должны быть меньше одной секунды). Уже потом показывать текущий статус загрузки данных. Только так пользователь будет чувствовать себя комфортно - о нем не забыли, система работает и делает именно то, что он от нее запросил. Далее будет 3 картинки.

1. Так форма откывается сразу
2. Дерево загружено, идет загрузка текущего узла
3. Все полностью загружено

Rivkin DmitryДа, извиняюсь, оговорился. Рекорд-селектор, конечно. Если щелкнуть по нему и выделить, то запись можно удалять?
Да.

Я, напротив, стараюсь везде где это возможность сохранить полноценную функциональность редактирования во вложенных гридах. Записи можно выделить и удалить. Можно править данные в определенном столбце - копипастить сверху вниз. Можно скопировать запись и вставить ее как новую. Это удобно для пользователя. Ну, и как я написал - к гриду должна быть карточка, где все датали развернуты и видны одновременно.

От кнопок ОК Сохранить и прочее я решил отказаться. (заместо этого юзаю толбар, см. рис.) Они есть только на модальных окнах. При редактировании записи вовложенном гриде и форме-карточке краснеет заголовок и появляется карандашик в области селектора записи. Шифт-энтер, шелчок по селектору - появляется модальный диалог, требующий подтвердить сохранение/перезапись объекта. Так работает во всех формах, мне кажется это достаточно удобным.

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

Форма ввода нового кустомера в твоем примере - о ней говорить нельзя, ее пока нет. Есть какой-то очень слабый прототип. Дизайна пока тоже нет. Самое сложное - выработать какой-то свой дизайн, который потом НЕУКОСНИТЕЛЬНО соблюдать во всех формах.

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

Селектор в окне табличной формы убери.

Вот пример моих карточек физлица и карточки юрлица.

ИзерлонерПрограммист-ЛюбительСелектор в окне табличной формы убери.
*dont know* а что имеется ввиду под селектором?
Вертикальная полоска с треугольничком у текущей записи. Область выделения записи. Ширина 270 твипов.

ИзерлонерП–Л, а как Вы выводите окна загрузки? Что это такое вообще? Рисунок, рамка с надписью или ещё что, выводимые от одного события до другого?

У меня бледно-желтый цвет означает ожидание выполнения каких-либо процессов. Поэтому и окна сообщений о процессах тоже бледно-желтые. Например выгужатель в эксел. При экспорте в эксел открывается как обычная форма, выполняется код выгрузки. При переборе в цикле спецификаций экспорта и цикле по записям БД опрашивается не нажата ли кнопка Прекратить эспорт и, если нажата, экспорт прекращается.

В гифе мой бледно-желтый цвет совсем обесцвечивается.

Одна щирокая таблица. Я стараюсь не делать наследования на таблицах, держу более-менее однообразные данные в широких. Так проще (практичнее) но менее реляционно-правильно и архитектурно изыскано.

Лучше не ты, давно уже переписываемся через форум.