Проектирование системы автозаполнения для выбора экземпляра типа агрегата - PullRequest
0 голосов
/ 17 июля 2009

Агрегат типа T состоит из 4 строк: t = c1 c2 c3 c4

Каждый из c1 c2 c3 c4 может иметь ряд уникальных значений:

  • c1 может иметь ряд уникальных значений c1.1, c1.2, c1.3, ... c1.n, где 'n' может быть довольно высоким, около 30000.
  • c2 имеет гораздо меньше уникальных значений, не более 5, то есть n <5 </li>
  • Для c3 и c4 n непредсказуемо, но обычно 10

Существует несколько экземпляров типа T, около 200 000 - все они состоят из разных значений c1 c2 c3 c4.

    t1 = c1.1 c2.1 c3.1 c4.1
    t2 = c1.2 c2.1 c3.2 c4.2
    t3 = c1.3 c2.2 c3.2 c4.3
    ...
    tN = c1.n c2.n c3.n c4.n

Цель состоит в том, чтобы позволить пользователю выбрать один действительный экземпляр типа T. В настоящее время пользовательский интерфейс (C # Winforms .NET 2.0) показывает 4 выпадающих списка автозаполнения с уникальными значениями для c1 c2 c3 c4 в каждом. После выбора одного действительного экземпляра он подается на вход во внешнюю систему. Преимущество текущего пользовательского интерфейса состоит в том, что он был быстрым (учитывая, что это версия v1.0) и достаточно быстрым - стандартное выпадающее меню автозаполнения Winforms, похоже, не имеет проблемы с 30k уникальных элементов и Пользователь может быстро выбрать набор из четырех значений.

Проблема с этим заключается в том, что, хотя он позволяет пользователю быстро вводить то, что ему нужно, автозаполнение не помогает пользователям находить подходящие, не имея понятия, соответствует ли выбранная им комбинация значений существующей. , действительный объект. Для опытных пользователей это в основном не проблема; однако новые пользователи продолжают выбирать значения c1 c2 c3 c4, которые фактически не приводят к действительному экземпляру типа T.

Мой вопрос: есть ли какой-нибудь другой способ, которым я мог бы создать пользовательский интерфейс для ввода T, чтобы пользователи могли воспользоваться преимуществами автозаполнения (я действительно хочу избегать интерфейсов в стиле списка выбора, они намного медленнее для ввода данных) в то же время позволяя новым пользователям выбирать допустимые комбинации значений?

Хотя исходная реализация основана на .NET, я был бы рад услышать о решениях на любых других платформах. Мой вопрос действительно о разработке более эффективного пользовательского интерфейса, а не о конкретных платформах.

Отредактировано для уточнения: приветствуются алгоритмические (т.е. не-пользовательские) предложения.

Ответы [ 2 ]

1 голос
/ 17 июля 2009

Мой ответ не имеет прямого отношения к реализации графического интерфейса, но вы можете поместить все действительные комбинации t1-> tN в patricia trie и использовать его для построения автодополнения при вводе .

0 голосов
/ 17 июля 2009

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

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

Похоже, у вас есть алгоритм, который определяет, какие комбинации допустимы, вышеупомянутая возможность также будет возможна

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...