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

Question

В настоящее время я пересматриваю область моего программного обеспечения для Windows и смотрю на изменение отношения с 1-> M на M-> M. В результате мне нужно настроить пользовательский интерфейс, чтобы приспособить выбор нескольких связанных записей.

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

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

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

Изображения или ссылки на них приветствуются!

Редактировать: вот пример того, что я рассматриваю:

Answer 1

Мне нравится, как StackOverflow связывает множество тегов со многими вопросами:

_{Элементы отображаются в виде пользовательских типов}

1. Вы, очевидно, начинаете с записи, с которой хотите связать несколько элементов.

2. По мере ввода поиска отображаются совпадения(не нужно нажимать на «Поиск»)

3. Пользователь выбирает нужную запись (Сортировка была бы хороша. SO использует «релевантность тега». Например, ввод «a» приводит к тому, что Java довольночем asp, потому что в Java больше вопросов, чем в asp, в вашем случае релевантность может быть именем пользователя)

4. Система создает связь (в памяти)

5. Если несколько полей (5+) заполняют поле ввода, они перемещаются в полурегиблированную область (не проблема SO, потому что в ней только 5 тегов с одним вопросом, но в вашем случае что-то вродепонадобится функция "интересные теги")

_{Связанные элементы перемещаются в «жесткую» область}

Конечно, вупорядоченным образом (с использованием таблицы)

• Наконец, когда пользователь завершает ассоциацию, он нажимает кнопки SAVE или CANCEL.

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

Кроме того, если вы заставляете пользователя щелкать мышью по чему-то, когда он печатает, пользовательский интерфейс менее эффективен (я думаю, что есть что-то под названием закон Хика об этом, но довольночестно говоря, я могу ошибаться)

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

Answer 2

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

Существуют различные методы выбора. ,С точки зрения удобства использования было бы предпочтительнее использовать ОДИН метод для каждого сценария. Затем, когда пользователь увидит это, он будет знать, что делать.

различные техники выбора:

1. раскрывающийся список - очевиден для одиночного выбора.
2. открытый список мультивыберите - например: многострочное текстовое поле, которое показывает 10 или 20 строк и имеет полосу прокрутки
3. , где вы выбираете, затем нажимаете и «добавляете» ссылку или кнопку, чтобы добавить несколько элементов выбора
4. перемещение списка- если у вас есть два открытых списка, со всеми вариантами, доступными в левом списке, вы выбираете несколько, а затем нажимаете кнопку, чтобы переместить ваш выбор в правильный список.
5. Флажки - подходит только для нескольких вариантовиз нескольких вариантов выбора.
6. Список элементов, каждый с кнопкой «рядом» рядом с ними - хорошо для коротких списков

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

Если вы можете рассчитывать наПользователь может фильтровать список, как в вашем примере, тогда 6 может подойти. Если вы думаете о том, как работает тегирование изображений в Facebook, я думаю, что оно довольно эффективно для длинных списков: background: тегирование изображений в Facebook - это механизм, который позволяет назначать одному или нескольким людям отдельные части изображения, т. Е. Маркировать их.

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

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

Вот изображение приложения тегов Facebook: http://screencast.com/t/9MPlpJQJzBQ

Answer 3

понятный графический интерфейс http://img25.imageshack.us/img25/8568/28666917.png

ссылка на исходное изображение

Другое дело, что, на мой взгляд, ваша проблема не в выборе нескольких записей,но фильтруя эти десятки тысяч записей. Ассоциация M-> M может быть реализована различными способами, но сложная часть заключается в предоставлении удобного и логичного способа просмотра / поиска огромного количества данных.

Answer 4

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

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

Answer 5

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

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

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

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

Answer 6

Существует ряд важных вопросов, которые следует рассмотреть - сколько записей обычно будет использоваться (в отличие от доступных для ассоциации)? Будет ли большое количество записей на одной стороне ассоциации (учитывая переход от 1-> M, это кажется вероятным)?

Если одна из количеств записей обычно очень мала (<10,Я бы сказал), назовите это LHS (потому что это обычно так), тогда лучшим способом связывания может быть разрешение поиска элементов LHS и RHS, а затем перетаскивание их в список - элементы LHS в списоксобственно;Элементы RHS в существующие элементы LHS. Таким образом, интуитивно понятно определить отношение к элементам. Вы также можете добавить другие параметры, такие как «связать со всеми» или групповое перо, чтобы можно было назначить несколько записей нескольким другим записям - нет ничего утомительного, как выполнение 15 перетаскиваний одной и той же записи. </p>

На самом деле, я думаю, что это самая важная часть любого дизайна интерфейса M-> M - минимизировать повторение. Проделать то же самое для сотен записей (помните, что если "никто никогда не ...", они будут), это несоблюдение правил, особенно если это сложно. Я знаю, что это, кажется, противоречит моему предыдущему совету, но я не думаю, что это так - разрабатывайте для типичного варианта использования, но убедитесь, что нетипичные не делают программу непригодной для использования.

Answer 7

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