Всем привет!
Только что столкнулся с ситуацией, которая заставила задуматься.
Хотелось бы знать мнение более просвещенной общественности.
Извините, что получилось длинно, но без конкретики никак...
Конкретно мой случай такой.
Есть список платежных поручений и список реестров для зачисления денег на счета банковских платежных карт клиентов.
Пользователь в программе (мышкой) устанавливает связь между платежным(-и) поручением(-ями) и соответствующим(-и) ему реестром(-ами).
В программе в диалоге, где производится привязка, сначала идет выбор из списка платежного поручения, подлежащего связыванию, а затем из списка реестров выбирается реестр.
При этом на список реестров налагается фильтр: отображаются только те реестры, которые могут быть привязаны к выбранному платежному поручению. Есть правила (требования бизнес-логики):
одно платежное поручение и один реестр могут содержать сумму зачисления либо только на счета клиентов-резидентов, либо только на счета клиентов-нерезидентов. Т.е. суммы для "резов" и "нерезов" смешивать нельзя.
с платежным поручением на "реза" можно связать только реестр на "реза"
с платежным поручением на "нереза" можно связать только реестр на "нереза" Проблема возникла такая:
Пришло платежное поручение на "реза", а реестр к нему на "нереза" (ошибка плательщика).
Производить такое зачисление нельзя.
После выбора пользователем платежного поручения реестр, который вроде бы надо (но нельзя) подвязать из списка пропал (был отсеян фильтром).
У пользователя возник законный вопрос: "Что за безобразие?! Почему вдруг программа глюкнула???"
А теперь более общая формулировка проблемы:
По требованиям предметной области, при определенных обстоятельствах, пользователю нельзя позволить выполнить некоторое действие.
Проверка выполнения/нарушения этих требований не требует много времени и ресурсов. Вопрос:
Как (с точки зрения организации UI) лучше реализовать это самое "непозволение", чтобы не ставить в тупик пользователя:
организовать GUI так, чтобы пользователь в принципе не мог выполнить действие, если требования нарушены. Например, не добавлять в список выбора элементы, недопустимые в данных обстоятельствах, или для кнопки сделать Visible=false или Enabled=false;
позволить пользователю попытаться сделать то, чего делать нельзя (выбрать недопустимый элемент списка или нажать на кнопку), а затем выдать сообщение ошибке, в котором объяснить почему так делать нельзя;
какой-то другой вариант... (какой?)
Недостаток первого варианта: пользователь будет считать, что программа глючит, пока я не объясню ему причину, по которой в списке отсутствует нужный ему элемент, а кнопка не нажимается (т.е. будет нужна консультация специалиста).
Недостаток второго варианта: пользователи нередко не воспринимают работу с программой как диалог человека с ПО, поэтому впадают в панику от любого окошечка с текстом.
Красота — наивысшая степень целесообразности. (c) И. Ефремов