Об’єктивне і суб’єктивне відчуття часу

Головна | Про нас | Зворотній зв'язок

Будь-яка людина хоче працювати швидко. Якщо роботу (або, розуміючи ширше, будь-яка дія) можна виконати швидко, у людини виникає приємне відчуття. Хитрість тут в тому, що суб'єктивне відчуття часу часто сильно відрізняється від об'єктивного, так що методи підвищення реальної швидкості роботи, описані на початку книги, допомагають аж ніяк не завжди.

Людське сприйняття часу влаштовано своєрідно. З одного боку, користувачі здатні виявити лише 8-відсоткова зміна тривалості в двох або четирехсекундном часу реакції системи. З іншого боку - не можуть точно визначити сумарну тривалість кількох послідовних дій. Більш того, сприймається тривалість дій безпосередньо залежить від рівня активності користувача, так що суб'єктивна тривалість послідовності дій завжди нижче такої ж за часом паузи. Це спостереження зовсім не результат напружених досліджень: всі знають, що при бездіяльності (нудьгу) час тече нестерпно повільно. Важливо розуміти, що дія може бути не обов'язково фізичним: лежачи на дивані і дивлячись фільм, тобто не здійснюючи майже ніяких фізичних дій, час можна витратити дуже швидко.

Таким чином, суб'єктивну швидкість роботи можна підвищити двома способами:

- Заповнення пауз між подіями. Є дані про те, що якщо в періоди очікування реакції системи користувачам показується індикатор ступеня виконання, суб'єктивна тривалість паузи істотно знижується. Судячи з усього, чим більше інформації пред'являється користувачам в паузах, тим менше суб'єктивне час. З іншого боку, ця інформація може викликати стрес у короткочасній пам'яті, так що користуватися цим методом треба обережно.

- Поділ великих дій користувачів на більш дрібні. При цьому кількість роботи збільшується, але зате суб'єктивна тривалість знижується. Поганий цей метод тим, що збільшує втому.

З іншого боку, підвищення об'єктивної швидкості роботи часто здатне підвищити і суб'єктивну швидкість. Інша розмова, що в кожному конкретному випадку це потрібно перевіряти секундоміром. У цій перевірці немає нічого складного: потрібно просто порівняти об'єктивну тривалість дії з його суб'єктивної тривалістю.

За лезу ножа. Немає нічого більш неприємного, ніж психологічна напруга, інакше кажучи - стрес. Оператор на атомній станції або пілот літака не просто спокійно сидять і натискають на кнопочки, але налягають на кнопочки, знаючи, що якщо вони натиснуть не на ту кнопочку, всім доведеться дуже і дуже туго. Більшість комп'ютерних програм і сайтів не вимагає від користувача такої міри психологічної напруги. Проте, їм є, куди рости.

Справа в тому, що майже весь час користувач може що-небудь зіпсувати і знає це. Він може відформатувати жорсткий диск, може стерти або зіпсувати потрібний файл. Не дивно, що користувач часто боїться. А якщо не боїться, то схильний недооцінювати свої можливості до руйнування, чому знижується пильність. Куди не кинь, усюди клин. Єдиним повноцінним рішенням є можливість скасування користувачем своїх попередніх дій, без обмеження кількості рівнів скасування і типу відміняються дій. Завдання це непросте, але зате результат вкрай важливий. Користувач, що знає, що він не може зробити помилку, відчуває радість і умиротворення. На жаль, створення таких систем, не будучи виключно важкою справою з точки зору технології (ми, як ніяк, живемо вже в двадцять першому столітті) вимагає зміни парадигми мислення програмістів, так очікувати швидкого настання ери загального щастя годі й говорити. Найчастіше більш реалістичним рішенням є давно вже існуюча практика ховати небезпечні для користувача місця інтерфейсу. Формально, це хороший і правильний спосіб. Проблема полягає в тому, що при цьому логічно ховати всі функції, які змінюють дані, наприклад банальна функція автоматичної заміни може миттєво знищити текст документа (досить масовості замінити одну букву на будь-яку іншу і забути скасувати цю дію).

Іншим фактором, що істотно впливає на суб'єктивне задоволення користувачів, є відчуття контролю над системою. Існує значна частина користувачів, для якої використання комп'ютера не є дією звичним. Для таких користувачів відчуття того, що вони не здатні контролювати роботу комп'ютера, є найсильнішим джерелом стресу. Для інших користувачів відсутність почуття контролю не приносить додаткового стресу, але все одно призводить до незадоволення.

Таким чином, користувачів потрібно всіляко забезпечувати відчуттям, що нічого не може статися, поки цього не захочеться самому користувачеві. Функції, що працюють в автоматичному режимі, але час від часу прокидаються і вимагають від користувачів реакції, викликають стрес. У будь-якому випадку, варто всіма силами вселяти користувачам думка, що тільки явно виражене дія приводить до дії системи (це, зокрема, головний аргумент проти ролловеров - користувач ще нічого не натиснув, а вже щось сталося).

Геть звідси, ідіот!

Жоден користувач не може довго і продуктивно працювати з системою, яка його засмучує і ображає. Проте, такі «скандальні» системи є нормою. Виною тому повідомлення про помилки. Зверніть увагу, що тут я пишу не про те, як запобігати помилкам користувача, але про те, чому повідомлення про помилки погані.

Справа в тому, що більшість повідомлень про помилки в дійсності не є власне повідомленнями про помилки. Насправді вони показують користувачеві, що система, якою він користується:

- недостатньо гнучка, щоб пристосуватися до його діям

- недостатньо розумна, щоб показати йому його можливі межі його дії

- самовпевнена і вважає, що користувач дурень, яким можна і потрібно зневажати.

Розберемо це докладніше.

Недостатня гнучкість. Багато програм щиро «впевнені», що користувач цар і бог, і коли виявляється, що користувач хоче неможливого (з їхньої точки зору), вони починають «відчувати» розчарування. Виявляють ж вони своє почуття діалогами про помилки.

Мал. 11. Ось що буває, якщо користувач спробує ввести значення, яке йому потрібно, але яке система не вміє обробляти. Тут можливо три альтернативних рішення. По-перше, при проектуванні системи можна ретельніше підходити до вибору її функціональності. По-друге, можна просто ігнорувати неправильність значення, округляючи його до найближчого можливого (індіціруя, можливо, самостійність дій системи одноразовим миготінням відповідного поляввода). По-третє, замість звичайного поля введення можна використовувати крутилку

Насправді безліч дій користувача спрямовані не на те, щоб зробити так, а не інакше, а на те, щоб зробити приблизно так, як хочеться. Користувачеві часто немає справи, можна домогтися точного результату чи ні. Показувати йому в таких випадках діалог про помилку нерозумно, оскільки користувачеві не потрібно нічого знати. Йому потрібен результат.

Небажання показати межі дії. У багатьох випадках користувач робить дії, які сприймаються програмою як неправильні, не тому, що він дурень, але тому, що система не показала йому кордонів можливого дії.

Всі такі повідомлення порочні, оскільки їх можна було б уникнути, просто блокувавши можливість здійснення некоректних дій або показавши користувачеві їх некоректність до вчинення дії.

Самовпевненість. Нормою також є випадки, коли система намагається виставити справу так, як ніби користувач ідіот, а система, навпаки, є втілення безпомилковості і правоти.

Мал. 13. Для кого невірне? І хто, власне, винен, система або користувач?

Насправді не користувач зроблений для системи, але система для користувача. Таким чином, будь-яким чином обмежувати користувача неправильно.

Користувачі ненавидять повідомлення про помилки

Підсумовуючи, можна сказати, що майже будь-яке повідомлення про помилку є ознака того, що система спроектована погано. Завжди можна зробити так, щоб показувати повідомлення було б не потрібно. Більш того. Будь-яке повідомлення про помилку говорить користувачеві, що він дурень. Саме тому користувачі не люблять повідомлення про помилки, а якщо говорити відвертіше, їх ненавидять.

Мал. 14. Саме так користувачі сприймають будь-які повідомлення про помилки.

Таким чином, майже всі повідомлення про помилки повинні бути видалені. Зрозуміло, мова йде не про те, щоб просто викинути шматки коду з програми, а про те, що системи спочатку треба проектувати так, щоб в них була відсутня необхідність в таких повідомленнях. Неможливо повноцінно працювати з системою, яка по кілька разів за день тебе лає.