Пользовательский интерфейс, позволяющий более 700 вариантов выбора

Question

В своем настольном приложении .NET я написал ( для внутреннего использования ), где мне нужно разрешить своим пользователям применять диагностику в плане участника.В настоящее время в системе насчитывается 700 единиц, и они продолжают расти.Мне нужно разрешить им добавлять несколько диапнозов одновременно.В настоящее время я разрешаю это через combo check list box.Это работает, но INSANELY неудобно как для меня, так и для пользователей.

Я ищу то, как я могу показать их пользователям.В идеале мне нужно было бы показать два критерия для каждого из них.Diagnosis Name и Diagnosis Code

Идеи?Как бы вы справились с этим?

Я использую .Net 3.5sp1 и SQL 2005 для бэкэнда.Мне все равно, если решение будет WPF или Winforms .

Answer 1

Я бы использовал 2 списка, 2 кнопки и текстовое поле.

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

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

Answer 2

Вы должны изменить свое мышление. Речь идет не о предоставлении им данных, а о регистрации намерений пользователей.

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

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

Как только вы узнаете, какую работу они выполняют и для чего они делают, я готов поспорить, что набор опций резко сократился.

Я связывал это дюжину раз, но этот подкаст, посвященный скотоводству с Грегом Янгом - это необходимость, которую должен слушать каждый разработчик.

Answer 3

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

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

Answer 4

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

Если у пользователей есть какая-то документация, с которой они вводят, и коды прямо там, разрешите им свободно входить в текстовое поле. Во время проверки текстового поля запросите таблицу допустимых кодов и получите код и описание для заполнения в таблице выше, если найдена только 1 запись. Если их больше 1, отобразите всплывающее окно с сеткой вариантов, соответствующих вашему запросу, и разрешите их выбирать из THAT. Любой такой выбранный будет добавлен к вашей основной сетке. Если НЕТ записей найдено, это может быть из-за type-o или кода, который просто не существует. Я бы тогда отбросил строку до тех пор, пока вы не запросите и не получите некоторый результат. Затем, как было сказано ранее, позвоните во вторичную форму, чтобы выбрать из доступных кодов диагностики. Пример: если Diag-код «12345» не может быть найден, ищите «1234», «123», «12», «1», пока что-то не вернется с результатом.

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

Answer 5

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

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

Другой вариант - создание рабочего процесса и переосмысление интерфейса. Я знаю, что вы упомянули, что они должны вводить их одновременно, но если есть возможность создать многостраничную запись (аналогично мастеру), это будет гораздо менее сложным. «Выберите параметры из категории 1 ...» на странице 1 ..., а затем - далее. Опять осторожно, чтобы ваши пользователи знали, где они находятся в сфере вашего приложения. Шаг 2 из 8.

Существует множество факторов, в том числе то, как часто используется приложение, какой уровень квалификации у ваших пользователей, что вы пытаетесь достичь в итоге?

НТН

Answer 6

Проблема в том, что просто нет такого громоздкого элемента управления с 700+ элементами в нем. Деревья, списки, комбинированные списки, списки данных ... все это (по разным причинам) боль, когда у вас столько предметов.

Я бы предложил предоставить либо А) некоторую категоризацию данных, чтобы ограничить выбор и иметь комбинированный список для переключения между этими категориями, либо Б) текстовую запись, которая имеет автозаполнение, чтобы уменьшить размер элементов, из которых выбирать.

Для B я бы использовал (довольно стандартный) режим просмотра двух списков, ввода текста и двухкнопочного режима. Подключите событие изменения текста, чтобы «отфильтровать» левый вид списка, используйте кнопку «Добавить», чтобы добавить выбранные строки в правый вид списка. Используйте кнопку «Удалить», чтобы вывести их из правого представления текста.

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

Я использую B) в нескольких продуктах, и это прекрасно работает.

Answer 7

Я бы реализовал что-то вроде:

Available              Assigned
+-----------------+    +-------------------+
|                 |    |                   |
|                 |    |                   |
|                 |    |                   |
|                 |    |                   |
|                 |    |                   |
|                 |    |                   |
|                 |    |                   |
+-----------------+    +-------------------+

Filter: -----------

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

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

Answer 8

Я думаю, что простое поле для ввода текста, с автозаполнением выпадающего списка. когда выбор сделан, добавьте еще одно поле на страницу для следующей записи.