Реализация памяти в ваших приложениях

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

обретает новое качество. Традиционный подход с обязательной выда' чей диалоговых окон заменяется обдуманным процессом, в котором проектировщик задается более тонкими вопросами. Как много инфор' мации должно запоминать приложение? Что именно оно должна запо' минать? Должно ли оно помнить больше, чем просто последние на' стройки? Что понимать под изменением в поведении пользователя? Проектировщики рисуют в своем воображении различные ситуации, например: пользователь принимает один и тот же формат даты 50 раз подряд, а затем один раз вручную вводит дату в другом формате. Ка' кой формат программа должна использовать в следующий раз: тот, ко' торый использовался 50 раз, или самый последний? Сколько раз дол' жен быть указан формат, чтобы стать форматом по умолчанию? Про' грамма не должна спрашивать об этом у пользователя лишь потому, что здесь имеется неоднозначность. Она должна по своей инициативе принять разумное решение. Если оно окажется ошибочным, пользова' тель будет вправе отменить его.

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

Сокращение множества решений

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

Например, если вы вчера ходили за покупками в некоторый универ' сам, это еще не означает, что вы ходите только в него. Однако когда вам в следующий раз потребуются бакалейные товары, вы, вполне ве' роятно, пойдете туда же. Аналогично, даже если меню в вашем люби' мом китайском ресторанчике содержит 250 блюд, весьма вероятно, что вы выберете одно блюдо из пяти'шести любимых. Когда люди едут домой с работы, они выбирают один из немногих маршрутов, в зависи' мости от дорожной обстановки. Компьютеры, конечно, не переутомят' ся от того, что запомнят четыре или пять вариантов.

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

Сокращение множества решений наводит нас на мысль, что информа' ция о предпочтениях пользователя, которую должна запоминать про'

грамма, неким образом группируется. Не бывает какого'то одного пра' вильного варианта – они все правильные. Приложение должно нахо' дить более тонкие «зацепки», чтобы определить, какое решение из не' большого множества подходит в данном случае. Например, если вы применяете программу оформления чеков для оплаты своих счетов, приложение может быстро сообразить, что только два или три счета используются регулярно. Но как ей определить по чеку, к какому сче' ту он относится? Если программа запомнит, какие получатели и сум' мы соответствуют тому или иному счету, ей будет легко принимать ре' шение. Вы платите за квартиру каждый раз одну и ту же сумму! То же самое относится к выплате кредита за машину. Сумма, которую вы платите за электричество, может меняться, но она, вероятно, будет от' личаться от предыдущей не более чем на 10–20%. Эти сведения могут быть использованы программой, чтобы понять, что происходит, и по' мочь пользователю.

Пороги предпочтений

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

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

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

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