Форма ввода адреса

За победу в конкурсе на лучшую экранную форму ввода адреса в «СофТрасте» объявлена премия. Мне денег за это не нужно, но я и реализовывать её не буду, а просто расскажу о своём видении концепта. Мир может становиться лучше бесплатно. Тем более, некоторые аспекты реализации довольно сложны: подсветка в комбобоксах, например.

Кому-то моё изложение покажется резким. Но это не так. Я вас всех люблю :-)

Самая большая проблема программистских интерфейсов в том, что программист невольно копирует внутреннюю структуру программы или базы данных в структуру экранных форм. Это в корне не правильно. Пользователь в гробу видал паттерны программирования и базы данных. Ему надо, чтобы всё быстро работало.

Для пользователя, адрес — это одна строка, хоть убей. Надо стремиться к одной строке, хоть убей. Может одной и не получится, но к ней надо стремиться, хоть убей.

Начнём со структуры базы: у нас плохой КЛАДР, ребята. Не обижайтесь. Таблица «Дом» бесполезна, в ней слишком много полей, которые то используются, то нет. Улица, строение, корпус и дом — это такие же равноправные члены иерархии, как район и город, а не поля в одной таблице. Таблица кратких наименований — вообще непонятно зачем. Логично, что предложить пользователю нормальный ввод с такой структурой сложновато. Можно сколько угодно по этому поводу говорить и брызгать слюной (мол, пришёл тут зелёный и сопливый, учит делать базы), но суть дела от этого не изменится. Нормальный КЛАДР — это три-четыре таблицы максимум: объект, тип объекта, таблица иерархической связи между объектами, ещё какая-нибудь вспомогательная таблица. Такая структура позволит унифицировать и поиск объекта в базе, и различные преобразования адресов.

Если нужно прикрутить контроль корректности структуры — ещё одна таблица возможных связей между типами объектов, но это уже отдельная история.

Перейдём к самому интересному — форме ввода. Существующие формы ужасны, факт. Даже не буду перечислять всех их недостатков.

Игнорировать инкрементальный ввод (выпадающие подсказки при вводе), когда весь мир использует этот концепт вот уже несколько лет, — по меньшей мере, неприлично. Вводить в поле «Населённый пункт» можно и код населённого пункта, и его название. Любой ввод подфильтровывает населённые пункты по всем полям. Для примера покажу для введённого текста «310»:

Аналогично для строки адреса:

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

Кнопка «…» открывает расширенный редактор (гриду) адресов. Он, в принципе, аналогичен тому, который используется сейчас. Например, если дом на улице не найден, его надо добавить, о чём нужно сообщить пользователю. При этом неплохо «выделить» соответствующие элементы управления. Оператор введёт номер дома в строке, либо откроет расширенный редактор по кнопке «…».

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

В качестве приятного бонуса и вау-фактора, удобно сделать, чтобы при нажатии на клавиатуре клавиши «Ctrl» все объекты становились «ссылками», которые ведут в соответствующий раздел редактора с уже подфильтрованными данными:

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

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

Всем удачи в борьбе за премию.