Скільки часу може зайнятися поява екрана, перш ніж це буде розглянуто як ефективність?

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

Невже я перенапружений? Яка прийнятна кількість часу для очікування появи екрана?

Це старе дослідження, але 10 секунд - це погано:

http://www.useit.com/papers/responsetime.html

зі сторінки:

Основна порада щодо часу реагування була приблизно однаковою протягом тридцяти років [Miller 1968; Карт та ін. 1991]:

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

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

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

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

Що думають призначені користувачі цього додатка? Якщо з ними все гаразд, тоді не хвилюйся. Деякі програми, які мають обробляти велику кількість даних, добре, щоб команда, відкрита вікном, мала затримку перед відкриттям.

Якщо можливо додати екран заставки або панель прогресу або щось, щоб вказати користувачеві, що він працює, було б добре. Я, як правило, намагаюся додати якийсь показник прогресу, якщо моє тестування показує, що вікно, як правило, займає більше 2-4 секунд.

Ми дотримуємось правила про те, що користувачеві БУДЬ будь-який зворотній зв'язок повинен тривати більше 2 секунд

Я сказав будь-який зворотній зв'язок, оскільки бувають випадки, коли неможливо завантажити всю сторінку протягом 2 секунд. Ви повинні повідомити користувачам, що очікувати через перші 2 секунди.

Хоча DKnight цитує в своїй відповіді гарне дослідження , ще одне, що слід врахувати, - це вимоги до продуктивності системи. Користувачі виконують якусь роботу, залежну від часу, або чомусь потрібні швидкі вимоги? Якщо ви можете якось запитати користувачів, який час відгуку вони хотіли б бачити, особливо з точки зору мінімально прийнятного часу, це було б найкраще. Проведення тестування на юзабіліті за допомогою спостереження також було б корисним для загальної юзабіліті, і якщо ви побачите, що користувач розчарується в очікуванні після виконання певної дії, то ви знаєте переглянути результати роботи цієї частини системи.

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

Я згоден, що 10 секунд, безумовно, занадто багато. Я працював над інтранетними програмами в «Програмному домі» (використовувався лише внутрішніми працівниками) і максимальна затримка під час завантаження сторінки становила 5 секунд. Це була для мене межа.

Однак я бачив інше внутрішнє застосування, дійсно дуже складне, але там, де час завантаження був чимось драматичним. У найгіршій ситуації через тисячі записів / запитів це зайняло близько 2 хвилин! Але це, звичайно, занадто далеко від загального контексту.

Тому я б сказав, що 3 або 4 секунди - це межа для надання хорошої послуги з реагування.

Це не проблема ефективності як такої, а проблема GUI. Користувачеві слід сказати, що робить програма, і якщо це займе більше 1-2 секунд, слід відобразити панель прогресу.

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

Типовою проблемою таких програм є втрата фізичної пам'яті, тому дисковий введення / вивід стає вузьким місцем для завантаження та заміни. Також може бути просто набір даних настільки великий, що алгоритм O (N ^ 3) тепер просвічується.