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

Ответ 1

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

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

различные методы отбора:

• выпадающий список - очевидно для отдельных выборок.
• открыть список multi select - например: многострочное текстовое поле, которое показывает 10 или 20 строк и имеет полосу прокрутки
• выпадающий список, в котором вы выбираете, затем нажмите и добавьте ссылку или кнопку, чтобы добавить несколько вариантов
• перемещение списка - там, где у вас есть два открытых списка, со всеми вариантами, доступными в левом списке, вы выбираете несколько, а затем нажмите кнопку, чтобы переместить выделение в нужный список.
• Флажки - полезно только для нескольких вариантов множественных возможностей выбора.
• Список элементов, каждый с кнопкой "добавить" рядом с ними - подходит для коротких списков

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

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

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

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

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

Ответ 3

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

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

Ответ 4

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

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

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

Ответ 5

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

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

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

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

Ответ 6

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

Ответ 7

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

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

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