Кейс-малютка по проектированию интерфейсов

[vadimk91]

Я конечно мимокрокодил, но вместе с вариантами "работает с", "работает без" я бы добавил третий "неизвестно" или "нет данных", а не "выберите". Это как приказ что-то выбрать другое, imho

[RieSet]

Я конечно не знаю ЦА, задачи и контекста, но это сложно назвать интерфейсом

Прототип - да, наверно

Если детальнее, то интерфейс неразрывно связан с ЦА для которой делается и задачами перед интерфейсом. Это какой-то очень грубый подход к интерфейсам

Теперь пользователь может осознанно не заполнять этот параметр (например, если не знает, работает или нет контрагент с НДС) и так же осознанно выбрать из предложенных вариантов.

Это предположение может исходить только при знании ЦА и задач интерфейса. Иногда, при знании особенностей реализации БД в системе и требований к полноте данных сохраняемых в системе

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

[Ivnika]

Что мешает на итоговой форме выводить просто фразу "Работает с НДС" и наоборот? Зачем прямо обязательно наименование поля?

[MrShnaider]

Этот пример подтверждает мою теорию о моделях в интерфейсах. Я пытался понять, какой минимальный набор моделей (элементов) достаточен, чтобы создать интерфейс любой сложности. И пришёл к выводу, что чек-бокс как модель не является необходимой.

Если мы даём пользователю сделать выбор, то его можно отобразить как select "1-из-многих" или "много-из-многих". Как следствие в коде и БД вместо Boolean будет Enum. Так мы не только сокращаем количество моделей (уйдут чекбоксы, радио-кнопки, переключатели), но и позволим себе расширять список вариантов, когда это потребуется