Что мне делать с раздутым окном выбора / выпадающим - PullRequest
0 голосов
/ 29 марта 2010

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

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

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

Теперь, в этой конкретной ситуации, имея иерархические данные и позволяя пользователям выполнять детализацию с использованием нескольких динамически сгенерированных выпадающих списков, вероятно, будет работать нормально. Однако каково лучшее решение, когда выбранные объекты / записи не имеют иерархической природы? В прошлом это делалось с помощью всплывающего окна с окном поиска и списком, но это кажется неуклюжим и устаревшим. В современном мире Web 2.0, как можно найти один объект среди множества форм?

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

Не стесняйтесь ссылаться на конкретные библиотеки с общими решениями этой проблемы или просто делиться тем, что вы сделали в своих проектах, в более общем виде

Ответы [ 3 ]

2 голосов
/ 29 марта 2010

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

Лично я предпочитаю это в любом случае, потому что я могу печатать быстрее, чем выделять что-то мышью, но это болезнь программиста, я думаю:)

0 голосов
/ 29 марта 2010

Различные методы организации больших объемов данных:

  • Иерархии
  • Пространственный (география / геометрия)
  • теги или грани

Различные методы поиска большие объемы данных:

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

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

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

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

Если бы я мог указать вам какой-нибудь список "лучших практик", я бы это сделал, но HID редко бывает таким четким. Используйте вышеупомянутые опции в качестве отправной точки и посмотрите, куда это вас приведет.

0 голосов
/ 29 марта 2010

Автозаполнение обычно является лучшим решением в моем опыте поиска, но только в том случае, когда пользователь может легко предоставить текстовые токены, как часть имени объекта или таксономии, которая содержит объект (например, категория продукта или почтовый индекс).

Однако это не всегда работает, особенно когда поведение «просмотра» было бы более подходящим - чтобы привести реальный пример, я однажды написал страницу для сайта сообщества, которая позволяла пользователю отправлять сообщения своим друзьям. Мы использовали автозаполнение там, позволяя несколько записей, разделенных запятыми.

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

(это было довольно давно - теперь все просто копируют Facebook ...)

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