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

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

Даже поиск файлов в винде глючит. Хочешь найти myfile.txt, набираешь в строке поиска file.txt, ничего нет. А почемууу???

Вот в мозгу так и откладывается.

Здравствуйте, ArtDenis, Вы писали:

AD>Давно заметил, что в обычных прикладных программах пользователи практически никогда не используют поиск, даже если он там есть почти в каждом окне. Вместо него пользователь использует более длинный путь чтобы добраться к данным, выполняя много кликов мышкой и пролистывая рады данных в поисках нужных. С чем это связано? Можно ли пользователя заставить использовать поиск? Зачастую (по моим представлениям), он обеспечивает уменьшение времени доступа пользователя к нужным данным на порядок.

1. Маршрут запомнить легче, чем точное название. Если в маршруте ошибёшься, то всё равно — какую-то часть ты уже прошёл, поплутаешь и найдёшь. Если же ошибёшься с точным названием, то считай, что ты даже с места не сдвинулся.
2. Когда у тебя на улице спрашивают как пройти куда-то, то ты описываешь маршрут по ключевым/заметным строениям, а не по названиям улиц и номерам домов.
3. Если маршрут известен/знакомый, то ты гарантированно получишь результат или отсутствие результата. Существующие поисковые системы не гарантируют, что ты получишь именно тот же результат, что получил бы пройдя маршрутом.

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

> Можно ли пользователя заставить использовать поиск?

Вон тут рядом обсуждают который год, в каких случаях лучше использовать умные советы.
http://www.rsdn.ru/forum/usability/4602077.1.aspx

Автор: Glenn
Дата: 03.02.12

Если пользователь долго тыкается в диалогах и списках, и давно не использовал поиск, и список больше 2 экранов, показать ему совет по поиску. Допустим, выбрал он "Калькулятор"

"Если набрать первые буквы "кал" в строке поиска, но найти "калькулятор" можно быстрее "

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

У специалистов по юзабилити есть условная классификация пользователей на три группы

1. Люди, которым для навигации комфортнее пользоваться поиском.
2. Люди, которым комфортнее "браузить" с помощью меню
3. Люди, которые пользуются и тем, и другим способом

Это особенности людей, с которыми ничего не поделаешь.

Но, можно проектировать систему так, чтобы подтолкнуть человека к тому или иному методу.
Например:
1. сделать поиск не сбоку-припеку, а в таком месте, в котором он будет замечен в тот момент, когда человеку нужно что-то найти.
2. сделать поиск удобным и видным, с заметной кнопкой, с подсказками, что именно можно ввести, как в market.yandex.ru
3. поэксперементировать с дизайном и попробовать "подглядеть" за тем, как пользователи работают с системой, позадавать вопросы по ходу эксперимента.

Вот еще попалась статья по теме, правда, только на английском: http://www.uie.com/articles/browse_vs_search/

Cheers!
Julia
www.profsoUX.ru

Здравствуйте, о_О, Вы писали:

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

Здравствуйте, Real 3L0, Вы писали:

R3>1. Маршрут запомнить легче, чем точное название

Я думаю дело не в маршруте, а в комфорте. Пользователю не комфортно отрывать руку от мышки (его это основное орудие труда) и переключаться на клавиатуру.

Здравствуйте, koekto5, Вы писали:

K>Я думаю, это связано с недоверием к функции поиска и к его глючности, с которой все сталкивались.
Все ли? Какой % пользователей использует поиск файла средствами ОС вместо ручного поиска по папкам?

K>Даже поиск файлов в винде глючит. Хочешь найти myfile.txt, набираешь в строке поиска file.txt, ничего нет. А почемууу???
Потому, что для продвинутых запросов предусмотрены продвинутые возможности, в частности, постановочные знаки типа * и ?

Здравствуйте, Моторокер, Вы писали:

М>"Если набрать первые буквы "кал" в строке поиска, но найти "калькулятор" можно быстрее "

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

Здравствуйте, julvk, Вы писали:

J>Это особенности людей, с которыми ничего не поделаешь.
может, это особенность поиска? система определяет мышление или мышление систему? вот я в силу определенных причин не использую IDE. а потому даю функциям короткие и четкие имена (т.е. длинные долго писать без автодополнения, а без навигации в непонятных именах неразберешься). а с такой привычкой польза от IDE неочевидна и мне оно не нужно.

что тут первично по вашему -- мышление или среда?


J>Но, можно проектировать систему так, чтобы подтолкнуть человека к тому или иному методу.
а надо? зачем навязывать свои привычки другим? ИМХО проектировать надо так, чтобы работать и так, и эдак. зачем мне вообще поиск? нет, я согласен, что в кривой системе постоянно приходится искать то одно, то другое. и поиск тут не поможет. вот в убунте новой. поставил ее и... ОХРЕНЕЛ!!!! куда дели командную строку?! осталась только строка поиска. минут пять всмоминал как там командная строка называется. вспомнил -- ТЕРМИНАЛ!!! почему-то в голове крутился шелл, консоль... кстати, какого хрена она не знает, что такое шелл? в никсах _всегда_ та штука, через которою с машиной сношались шеллом именовалась. а виндах, конечно, это "command prompt". одна и та же сущность, а называется по разному.

J>1. сделать поиск не сбоку-припеку, а в таком месте, в котором он будет замечен в тот момент, когда человеку нужно что-то найти.
J>2. сделать поиск удобным и видным, с заметной кнопкой, с подсказками, что именно можно ввести, как в market.yandex.ru
а если человек не пользуется поиском? его же эта заметная кнопка будет раздражать.

Здравствуйте, ArtDenis, Вы писали:

AD>Давно заметил, что в обычных прикладных программах пользователи практически никогда не используют поиск, даже если он там есть почти в каждом окне. Вместо него пользователь использует более длинный путь чтобы добраться к данным, выполняя много кликов мышкой и пролистывая рады данных в поисках нужных. С чем это связано? Можно ли пользователя заставить использовать поиск? Зачастую (по моим представлениям), он обеспечивает уменьшение времени доступа пользователя к нужным данным на порядок.

Ааааа!! Это ты дизайнил Vista, KDE4, GNOME3 и Unity?!! Не буду использовать поиск, не буду, не буду и вообще ушёл на Xfce!

Здравствуйте, Centaur, Вы писали:

C>Ааааа!! Это ты дизайнил Vista, KDE4, GNOME3 и Unity?!! Не буду использовать поиск, не буду, не буду и вообще ушёл на Xfce!

Ты, знал, ты знал!

Здравствуйте, ArtDenis, Вы писали:

AD>Приветствую.
AD>Давно заметил, что в обычных прикладных программах пользователи практически никогда не используют поиск, даже если он там есть почти в каждом окне. Вместо него пользователь использует более длинный путь чтобы добраться к данным, выполняя много кликов мышкой и пролистывая рады данных в поисках нужных. С чем это связано? Можно ли пользователя заставить использовать поиск? Зачастую (по моим представлениям), он обеспечивает уменьшение времени доступа пользователя к нужным данным на порядок.

Имхо, поиск это, как правило, точное соответствие искомому шаблону. В той или иной степени конечно точное соответствие. Но все таки соответствие. Пользователю приходится думать, что именно он хочет найти. А есть такая идиома UI "не заставляйте меня думать".

В противовес поиску есть механизм "фильтров", ну и или не знаю как точно это назвать. Когда область данных последовательно сужается по условиям пользователя. Вроде покажи все новые данные, все старые. Хороший пример ентова дела это Quick Search в Total Commander: набираем букафки, а Тотал в активной панели отображает файлы, только соответствующие этому критерию, а остальные временно прячет.

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

Когда-то в своей Aml Pages я ввел фильтры. Всё! Забыли все про поиск. Потому как стандартный поиск был более чем продвинутым вариантом, мог чего и где угодно найти с кучей параметров. Но он заставлял думать. И в результате пользователи вместо того, чтобы решать задачу, думали как использовать в конкретный раз инструмент для решения задачи поиска.

Как то так, имхо, конечно. В общем такие механизмы как "фильтры", Quick Search в тотале помогают пользователю нащупать нужный маршрут, алгоритм и делать это легко и просто. Полный, в нашем программерском понимании поиск это сложный и тонкий инструмент. Им сложно пользоваться регулярно, т.к. он своей сложностью отнимает кучу времени у пользователя: настроить, проверить, еще раз перенастроить. У пользователей задача не проверить мощности поиска, а максимально быстро найти им нужное. И главный тормоз тут не алгоритм, как правило, а пользователь — именно его действия составляют под 80 процентов от общего времени до достижения искомого результата. Вот поэтому и не любят пользователи тот самый, наш любимый, великий и могучий "поиск" с 15-тью настройками, регулярками, областями поиска и прочей дрянью. Т_я_ж_е_л_о эти пользоваться постоянно.

Здравствуйте, мыщъх, Вы писали:

М>а потому даю функциям короткие и четкие имена

а я иногда за весь день имя придумать не могу, а потому иногда плюю на это дело и складывают 3 — 5 слов, описывающих суть происходящего.

притом, чаще всего, в комментариях которые я пишу проясняется 2 вещи:
0) что этот метод делает
1) зачем (почему) он нужен

Здравствуйте, Философ, Вы писали:

Ф>Здравствуйте, мыщъх, Вы писали:

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

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

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

> а потому иногда плюю на это дело и складывают 3 — 5 слов, описывающих суть происходящего.
можно пример функции из пяти слов? просто интересно...

Ф>притом, чаще всего, в комментариях которые я пишу проясняется 2 вещи:
Ф>0) что этот метод делает
ох, как же ненавижу я такие комментарии (хотя ими тоже грешу). у меня последнее время в комментариях или фрагменты спецификаций, например:
// A zlib stream has the following structure:
// 0 1
// +---+---+ +=====================+---+---+---+---+
// |CMF|FLG| (more-->) |...compressed data...| ADLER32 |
// +---+---+ +=====================+---+---+---+---+

или же "руками не трогать, это не баг, это для совместимости со старой версией" или "парсим xml руками потому что эти кретины присылают нам файлы ни фига не по спецификации и библиотечные парсеры работают с вероятностью 50 на 50 в зависимости от того будут ли в xml недопустимые по спецификации символы". так что такой комментарий комментирует не код и даже не что этот код делает (и так понятно из назввания, что парсит xml), а _почему_ этот код здесь. согласитесь, что без подобного комментария вы запросто можете пожать плечами (какой студент это писал?) выкинуть пару сотен строк кода и заменить ее одним библиотечным вызовом. и программа будет работать. какое время... и если третья сторона успеет пофиксить баг в экпорте xml, то есть шансы, что все будет шоколадно, но... а если не успеет? вот тут и нужно оставить коммент на этот случай, что мы парсим xml руками, потому что обнаружили, что наши поставщики поставляют то, что сносит крышу библиотечным парсерам.




Ф>1) зачем (почему) он нужен

Здравствуйте, ArtDenis, Вы писали:

AD>С чем это связано?

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

2. Контекст. Если вы ищете поиском, вы теряете контекст предмета. Вы сразу фокусируетесь на предмете и не видите что за ним, что перед ним, что рядом.

AD>Можно ли пользователя заставить использовать поиск?

Можно, но не нужно. См. unity.

Здравствуйте, мыщъх, Вы писали:

>> а потому иногда плюю на это дело и складывают 3 — 5 слов, описывающих суть происходящего.
М>можно пример функции из пяти слов? просто интересно...

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

А во-вторых, 5 слов — это я, конечно загнул (не уверен, что 5 слов было).
---------------------------

Чаще всего трудности с именованием возникают вот для таких методов:

        public void Evolve()
        {
            CleanOldData();
            KillByAge();
            ProducePosterity();
            IncrementAge();
            CleanGenerations();
        }

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

Здравствуйте, мыщъх, Вы писали:

М>кстати, в результате такого стиля при копи-пасте (ну куда же без нее) не приходится переименовать переменные. типа из одной функции выдернули кусок кода и воткнули в другую. и она "подхватила" все переменные. автоматом.

тут самоконтроль нужен.
если у меня возникает желание целиком утянуть кусок кода, а особенно без изменений — самое время для создания нового метода.

Бывает, что один и тот же код копипастится 10 и боле раз, после чего в 10 местах слегка подправляется. Понятно, что надо рефакторить, однако вчера оно должно было работать, а голова уже гудит...
Вставляем
//TODO: remove this shit
и говнокодим дальше.

Здравствуйте, Философ, Вы писали:

Ф>Здравствуйте, мыщъх, Вы писали:

Ф>{
Ф>CleanOldData();
Ф>KillByAge();
Ф>ProducePosterity();
Ф>IncrementAge();
Ф>CleanGenerations();
Ф>}

Clean и Kill смущет. из названий непонятно делает ли Clean тоже, что и Kill или Clean это очистка без убиения. ну, например, есть массив данных. очистить -- перезаписать нулями (null или "" в зависимости от...), а убить это сделаеть ему Free.

CleanOldData -- что такое Old? где в документации найти определение old? и где найти как оно конфигурируется? если конфигурируется вообще?

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

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

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

пикантность в наименовании флагов. блин, на хрена я дал имя флагу auto? вы догадываетесь, что оно означает? нет? и правильно. потому что я дэбил и у меня оно означает брать время из тестовой базы. девы, ес-но, поняли это не так. они поняли, что auto это брать текущее время автоматом. потому как еще есть флаги now и local. какой же я все-таки дэбил. никто так и не понял как их комбинировать... хотя мне казалось логично. если время не указано, а стоит now -- брать серверное время. если now | local -- клиентское. просто local будет поправка к явно заданному времени. auto -- время из базы. now | auto -- поправка на локальное время определяется самой функций при работе в нормальном режиме и берется из конфига при работе в тестовом.

короче, убил три дня пока объяснял как пользоваться этими флагами ;-( а все потому что выбрал неудачные названия. я их понимал по своему, а девы их понимали по своему. кстати, от auto ожидали того, что делает now, т.е. автоподстановки текущей даты с сервера. и вызывали функу auto | local. ну вы догадываетесь к чему приводила такая комбинация... самое интересное, что программа работала правильно. и тесты проходила, и в боевых условиях выдавала ожидаемый результат. вот только конфиги игнорировала, а потому когда вдруг возникла потребность смоделировать ситуацию на фейковой базе, то ни хрена оно не смоделировалось. программа упорно брала время из базы. а база фейковая (только что сгенерированная). и потому время в ней настоящее, а не то, какое мы указали в конфигах (типа это было триста лет тому назад). бааалин, программа игнорирует конфиг. где грабли?! а грабли в неправильном вызове функции, т.к. надо не auto | local, а now | local или просто auto.