Xpoint
   [напомнить пароль]

Комбобокс, да не комбобокс, на самом деле

Метки: [без меток]
2004-12-20 09:54:40 [обр] Андрей Новиков(8/1242)[досье]

Задача: дать человеку возможность привязать к объекту набор ключевых слов. Ключевых слов может быть много — десятки, а то и сотни. Человек может как придумать свои ключевые слова, так и выбрать уже существующие в системе (у других объектов).

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

Отсюда вытекает следующее решение: текстбокс + список. В списке имеем уже существующий набор, который мы можем покликать, в текстбокс дописываем те слова, которых нет в списке. Проблема — когда список содержит сотни записей, им очень неудобно оперировать — скролировать, выбирать нужную позицию и т.п — всё время случайно куда то "улетаешь", а потом мучительно долго ищешь место, на котором остановился.

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

спустя 42 минуты [обр] Кирилл [Kirk] Королев(0/673)[досье]
Вывалить скрытый див со словами-ссылками, имхо.
спустя 1 минуту [обр] Андрей Новиков(8/1242)[досье]

Тут пообщались с коллегой, возникла интересная модификация второго варианта — под текстбоксом располагаем div с overflow=scroll и пихаем в него ключевые слова, которые по onclick попадают в текстбокс.

Кирилл [Kirk] Королев[досье], синхронно пишем :) — это оно?

спустя 14 минут [обр] Евгений Петров(0/1055)[досье]
Может, сделать алфавитный переключатель?
По клику на букву показывается список из слов, начинающихся с нее.
Запоминать выделение слов (скорее всего это будет мультисписок). В дополнение можно формировать пользовательский список из выбранных слов (по клику на слове показывался бы список, в котором оно содержится). Его можно формировать и при выдаче страницы.
Можно реализовать ввод слов по одному в инпут с проверкой и передачей его в пользовательский список.
спустя 12 минут [обр] Андрей Новиков(8/1242)[досье]
Евгений Петров[досье], задача немного другая. Нет необходимости дать возможность ввести слово правильно с точки зрения написания или т.п. Есть задача дать возможность ввести слово правильно с точки зрения ассоциации. Ведь ассоциации меняются со временем, тем более они разные у разных людей. Поэтому человек должен видеть весь список, и разбиение по буквам ничего ему не даст — всё равно придется просмотреть все буквы, а это 60 лишних кликов.
спустя 44 минуты [обр] Кирилл [Kirk] Королев(0/673)[досье]
Андрей Новиков[досье] точно, оно =)
спустя 11 минут [обр] Давид Мзареулян(1/1003)[досье]
Почему бы не слямзить идею/технологию с Google Suggest?
спустя 2 минуты [обр] Давид Мзареулян(1/1003)[досье]
Это, конечно, не решит задачу ассоциаций… но, возможно, её и решать надо не на уровне интерфейса, а на уровне внутренней кластеризации ключевых слов? Я понимаю, что «категоризация ключевых слов неприемлема», но.
спустя 22 минуты [обр] Андрей Новиков(8/1242)[досье]
сообщение промодерировано

Давид Мзареулян[досье], это было первое, что мне предложили :). Но откуда системе знать, с чем у меня что ассоциируется? Задача этого интерфейса одна единственная — чтобы в разные года разные люди использовали для обозначения некоторого понятия одно и то-же ключевое слово. И тут база синонимов тоже не подойдет, потому что у людей могут быть абсолютно непредсказуемые ассоциации. Но люди при этом достаточно разумны, чтобы, когда они увидят чужую ассоциацию, догадаться, что для текущего случая надо использовать именно её.

Простейший (утрированный) пример — предположим, что интерфейсом пользуемся я и моя жена. Мне надо описать объект, ассоциирующийся с моей тещей. Я пишу в ключевом слове "теща". Жена потом описывает другой объект, который тоже ассоциируется с тещей, но её естественная реакция — написать "мама". Но увидев слово "теща", она конечно поймет, что использовать надо его. Это очень утрировано и притянуто за уши, но очень хорошо описывает то, чего я хочу добиться.

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

спустя 25 минут [обр] Давид Мзареулян(1/1003)[досье]

Пример всё-таки не совсем корректный. Для Вашей жены Ваша тёща — именно мама, и тут большой вопрос, кто из Вас имеет больше оснований на признание термина единственно верным.

ОК, наверное, понятно, что вываливать весь список слов по алфавиту — глупо. Откуда Ваша жена узнает, что искать нужный термин надо на букву «т», если терминов в списке — под тысячу? Пользователю проще будет вбить свой термин, чем искать в этой простыне чужой (в конце концов, ключевое слово — это способ быстрой классификации). Значит, система должна как-то подсовывать пользователю нужное слово. Откуда она узнает, что слово нужное? Она это может узнать только на основании предыдущего опыта. Мне кажется, думать надо в эту строну. Скажем, если записи может соответствовать несколько ключслов, то предлагать слова, которые встречались чаще всего вместе с вводимым словом (в Вашем примере система предложит, скажем «семья», «тёща», «ремонт»:)). Сама база записей в этом случае является семантической сетью для ключслов.

Ну, то есть, я бы думал примерно в эту сторону.

спустя 10 минут [обр] Алексей Волков, он же «Росомаха из Флориды»(17/468)[досье]

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

Обычно как раз люди идут от общего к частному, углубляясь в нужные дебри („семья > жена > тёща“), как это делается в таксономиях и классификаторах.

Если же тебе нужен плоский список, то термины в нём всё равно как-то должны быть организованы. Ты упоминаешь ситуацию „когда они увидят чужую ассоциацию“ — возможно, ты собираешься каждому пользователю позволять по-своему ассоциировать один и тот же объект? И показывать эти ассоциации в интерфейсе?

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

В дополнение к идее со списком — его лучше вешать сбоку, и делать по высоте на весь экран, по keypress пробовать проскроллить так, чтобы в центре всегда были слова, наиболее подходящие набранному в боксе. Но такой нестандартный интерфейс всё равно хорошо бы попробовать сначала, и потом уже решить, использовать его или нет.

спустя 33 минуты [обр] Андрей Новиков(8/1242)[досье]

Давид Мзареулян[досье], я же сказал, что он притянут за уши. Конечно есть проблема, какое клучевое слово правильнее, их замены, объединения и т.п. Но это все отдельные и на данном этапе не шибко важные задачи. Сейчас главное не называть одну сущность разными терминами.

Алексей Волков, он же «Росомаха из Флориды»[досье], подробнее: это будет не пользовательский сервис, а админский. Т.е. количество клиентов сильно ограничено. Пользователи будут только выбирать нужные слова из предложенного списка, конструируя таким образом выборку. Слов всё-таки будут не тысячи (с таким количеством это действительно бессмысленно), а не более сотни. Во, вспомнил еще один хороший пример - тэги в Гуглочте. Т.е. по сути это как раз то, чего я хочу, но по реализации мне их исполнение не очень нравится. Да и интерфейс у меня будет классическим вебовским - с формой и сабмитом.

спустя 6 часов [обр] Евгений Петров(0/1055)[досье]
Если я правильно понял, все равно задача сведется к статистике набора слов пользователями и постороению самонастраивающейся системы, учитывающей частоту совместного занесения слов.
То есть на первом этапе либо построить некое соответствие самому, либо вовсе его не строить.
В последующем корректировать коэффициенты соответствия в зависимости от выбора пользователей.
спустя 12 часов [обр] Андрей Новиков(8/1242)[досье]
Я не вижу, зачем нужно "учитывать частоту совместного занесения слов". Если я что-то описываю, как красивый и толстый, то это вовсе не значит, что что-то красивое может быть толстым, а что-то толстое красивым. В моем понимании ключевые слова ортогональны. Возможно я неправильно сделал, что изначально воспользовался в вебмастерской тусовке фразой "ключевое слово", которая сразу ассоциируется с веб-страницей, где, наоборот, должно быть как можно больше синонимов. Давайте сменим термин на "тэг" в его понимании Гуглочтой.
спустя 46 минут [обр] Евгений Петров(0/1055)[досье]
Дело не в том, как Вы его назовете... Будет оно называться "ключевое" или как-то по-другому...
Вопрос к Вам, Андрей. По какому принципу Вы собираетесь выдавать "подсказки" или формировать список "ассоциативных слов"?
На Google Suggest это просто соответствие начальных символов и ранжирование по частоте поисковых запросов. Вы же хотите именно ассоциативные наборы.
IMHO такие или другие "спец" наборы можно формировать на основе статистики. Поэтому я и предложил формировать ее на основе выбора пользователей. И если каждый второй будет вводить при выборе "контролер" слово "попрошайка", то оно и будет подсказываться при вводе следующим пользователем.
Можно по ходу менять набор слов или дополнять его теми словами, которые пользователь не выбирает, а вводит в текстовое поле.
спустя 36 минут [обр] Андрей Новиков(8/1242)[досье]
А кто здесь говорит о подсказках? Я упорно говорю, что ни тут не применимы, а мне все их советуют.
спустя 1 час 26 минут [обр] Юрий Щапов(3/114)[досье]
Андрей Новиков[досье]Быть может, Андрей, Вы нам конечную цель объясните?
спустя 32 минуты [обр] Андрей Новиков(8/1242)[досье]
Заменить древовидную структуру рубрикации на плоскую тэговую, которая мне кажется более удобной и перспективной. Я же в итоге сказал - прямо как в Гуглочте. (Кстати, прошу прощения, у них они метками, а не тегами называются)
спустя 1 час 50 минут [обр] Давид Мзареулян(1/1003)[досье]

Если речь идёт о метках, то во-первых, они совершенно не обязаны быть однословными. Не надо называть метку «тёща», надо назвать метку «мама жены Андрея Новикова»:). Тогда степень неоднозначности резко уменьшится. В идеале надо стараться называть метки так, чтобы у человека не возникало даже мысли назвать ту же группу по-другому.

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

Кстати, я немного игрался с такими вещами, и понял одну вещь. Плоская структура рубрик (с возможностью привязки документа к нескольким) действительно гораздо удобнее древовидной, но до определённого предела. Предел — где-то в районе 10-20 рубрик. В большем количестве ориентироваться трудно. Более того, начинают появляться рубрики типа (переводя на местный язык) «Языки программирования — PHP», «Языки программирования — Java» — т.е. эмулирующие дерево (в простейшем случае — эмулирующие фасеты). Потому что человеческий мозг — это инструмент для группировки и классификации, что бы там кто не говорил, и видя россыпь тегов, он не может не хотеть собрать их в кучки. Поэтому я бы посоветовал не выбрасывать дерево совсем, а таки предусмотреть его существование (в виде под-меток, под-тегов, под-рубрик — как угодно). При этом дерево образуют только метки, а документы, как и ранее, могут иметь несколько меток одновременно. Таким образом убивается достаточно много зайцев.

спустя 20 минут [обр] Андрей Новиков(8/1242)[досье]

Давид Мзареулян[досье], касательно первого я пока не готов возразить, т.к. кроме Гуглочты ничего пока подобного ручками не трогал (категории в КПК не в счет - слишком мелко). Да и в Гуглочте у меня тоже не шибко большая переписка, поэтому оценить не могу. Какой подход правильнее, будет видно из эксперимента.

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

Powered by POEM™ Engine Copyright © 2002-2005