Тривалість реакції системи

Часто користувачі надовго переривають свою роботу. Крім втрати фокусу уваги, про який уже сказано, це погано тим, що позбавлена ​​керівництва система починає простоювати. Зрозуміло, ми нічого не можемо зробити з цією ситуацією: дивно було б, якби, як тільки користувач відходив в туалет, система, скажімо, починала б форматувати жорсткий диск. Тим не менш, безсумнівно й інше: користувач нерідко відволікається не тому, що з'являються зовнішні подразники, а тому, що система не реагує на зовнішній подразник в особі користувача. Простіше кажучи, система робить що-небудь тривалий. Жоден ж людина при здоровому глузді не буде наполегливо дивитися в екран, знаючи, що система буде готова до прийому нових команд не раніше, ніж через п'ять хвилин. Відповідно, людина відволікається. Проілюструвати це дуже зручно на процесі друку. Друк документа в сто сторінок навіть на швидких принтерах займає істотне час, відповідно, більшість людей, відправивши такий документ до друку, починають ледарювати, оскільки, щоб почати таку дію їх трудовому процесі, їм потрібна роздруківка, якої ще немає. Проблема в тому, що відразу після того, як людина відволікається, системи найчастіше, у що б то не стало, починає турбуватися небудь від людини. Людина ж, упевнений в тому, що система працює, іде в іншу кімнату. Таким чином, людина і система байдикують. При цьому роздратування людини, який повернувся з обідньої перерви і замість роздрукованого документа знайшов діалогове вікно з питанням «Ви впевнені?», зазвичай виявляється безмірним. Це робить завжди вірним наступне правило: якщо процес приблизно буде тривалим, система повинна переконатися, що вона отримала всю інформацію від користувача до початку цього процесу. Є інше рішення цієї проблеми: система може вважати, що якщо користувач не відповів на запитання, скажімо, протягом п'яти хвилин, то його відповідь позитивна. Таким чином, той же самий сценарій вирішується по іншому: користувач відправляє документ на друк і йде, система запитує «Ви впевнені?» І чекає п'ять хвилин, після закінчення цього часу вона починає друк. Цей метод цілком працездатний, так що їм варто пользовать завжди, коли неможливий перший метод. Є й інша причина відволікання користувача. Користувач запускає небудь процес. Система показує йому індикатор ступеня виконання. Відсоток виконання за хвилину ледве доходить до чверті розміру індикатора. Користувач екстраполює ці дані і резонно вирішує, що у нього є три хвилини, щоб розім'ятися. Однак, як тільки він відходить від комп'ютера, відсоток виконання з нелюдською швидкістю починає рости і за секунду доходить до максимуму. Процес успішно закінчується, а пользовать ще три хвилини ледарює. І назад - індикатор показує, що процес виконується дуже швидко. Користувач розуміє, що у нього є всього хвилина і в поспіху втікає в іншу Конате. Повернувшись, він виявляє, що індикатор застряг на двадцяти відсотках і не проявляє тенденції знову швидко зростатиме. Відбуваються подібні випадки виключно тому, що індикатори ступеня виконання зазвичай розглядаються програмістами не як показники відсотка виконання завдання, але як індикатори того, що система взагалі працює. Для них це дуже зручно: оскільки єдиний з точки зору користувача процес часто складається з багатьох принципово різних системних процесів, що виконуються з різною швидкістю, можна не обтяжувати, намагаючись так збалансувати зростання індикатора, щоб він весь час відбувався з однаковою швидкістю. Іноді це «неутружденіе» приймає досить комічні форми, так, одного разу я бачив індикатор виконання, який спочатку ріс, потім став знижуватися, потім знову виріс. Проблема в тому, що користувачі розглядають такі індикатори саме як спосіб дізнатися, коли процес завершиться. Так що брехати користувачеві тут недобре.