Проектирование взаимодействия с пользователями. Виды ошибок. Игнорирование пользователя - Ю‑эксперт
  • +7 (495) 055-13-58
    (9:00-20:00)
  • Бесплатная консультация

Проектирование взаимодействия с пользователями. Виды ошибок. Игнорирование пользователя

Как могут выглядеть варианты этой ошибки:

  • Курсор не следует за движениями пользователя и скачет или продолжает движение после остановки мыши
  • Кнопки показывают нажатие с задержкой или вообще не показывают его
  • Меню, скроллбары, ползунки отстают от действий пользователя, разрушая взаимосвязь движение-отображение
  • Операции перемещения и изменения размера не согласуются с движениями пользователя и не показывают обратную связь
  • Программа не показывает, что она занята, она просто игнорирует пользователя
  • Программа время от времени недоступна, когда она совершает какие-то внутренние действия
  • Во время продолжительных операций не отображается индикатор процесса исполнения
  • Во время продолжительных операций нет возможности их отмены
  • Программа не использует время простоя (idle time) и, когда пользователь отдаёт заранее предсказуемую команду, она тратит много времени, чтобы её исполнить
  • Программа не показывает когда она зависает, и не сообщает что случилось

Отзывчивые программы сразу показывают реакцию на нажатие клавиш, кнопок и перемещения курсора и предсказывают время выполнения операции. Такие программы дают возможность заниматься другими делами во время выполнения длительной операции, обрабатывают очередь запросов разумно, поэтому совершают внутренние операции и задачи низкого приоритета в фоне. А главное – они предвидят запросы пользователя!

Проектируйте отзывчивые программы!

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

Задержки реакции могут быть разной продолжительности, программа не должна исполнять всё немедленно. Программа не должна выполнять операции в том порядке, в котором их запросил пользователь и буквально понимать и исполнять его команды.

Пользователи не роботы, нужно учитывать человеческие возможности и ограничения.

Даже если программа не может немедленно обработать запрос пользователя, она должна показать что приняла его.

Рисунок 1

Показывайте индикаторы занятости, если действие программы занимает несколько секунд.

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

Рисунок 2

Эффективные индикаторы исполнения длительных операций акцентируют внимание на том, сколько работы осталось. Например, не “3 файла скопировано”, а “Осталось 4 файла”.

Они показывают общий прогресс, а не прогресс текущего шага. Не “До завершения текущей операции осталось 5 сек”, а “До завершения осталось 35 сек”.

Показывают прогресс с 1%, а не c 0%, так как пользователи беспокоятся, если индикатор стоит на 0% более 1-2 секунд – они думают что операция не началась.

Эффективные индикаторы показывают прогресс на 100% не более 1-2 секунд.
Если индикатор зависает на 100% более 1-2 секунд, пользователи думают что операция зависла.

Прогресс должен показываться плавно, без прыжков и использовать человеческие величины: не “Осталось 27 сек”, а “Осталось менее 1 минуты”.

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

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

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

Рисунок 3

Чтобы сделать своевременный отклик программы:

  • Показывайте сразу (0,1 сек), что вы приняли запрос пользователя.
  • 0,1 – 1 сек на отображение индикатора занятости
  • > 1 сек на отображение индикатора выполнения длительной операции
  • Показывайте вначале самую главную информацию
  • Показывайте приблизительный (первый) результат для того, чтобы пользователь мог уточнить свои действия

Взаимодействие с пользователем не всегда должно быть синхронным

Переносите выполнение не критичных по времени задач в фоновый режим. Пока ресурсы компьютера не заняты, выполняйте задачи для анализа и просчёта вероятных запросов пользователя. Эти задачи нужно выполнять в самом низком приоритете.

Например, так работает функция текстового поиска. Пока вы просматриваете текущее вхождение найденного слова, функция поиска ищет остальные вхождения.А пока вы просматриваете текущую страницу сложного документа, программа подготавливает отображение следующей страницы.

Работайте на будущее в свободное время, предугадывайте запросы пользователя!

Обрабатывайте очередь запросов для изменения порядка и приоритетов задач.

Для перехода по ссылке не нужно ждать загрузки всей страницы. Перед исполнением задачи из очереди запросов проверьте действительно ли её ещё нужно исполнять. Если нет – пропустите её.

Игнорируйте задачи, выполнение которых уже не имеет смысла

Например, выполнение очереди запросов на перемещение курсора или мыши – это ненужная задача, так как перемещение курсора должно выполняться в режиме реального времени.

Если вы нажмёте шесть раз стрелку вверх при перемещении по тексту и потом быстро нажмёте три раза стрелку вниз, то очевидно, что не нужно отрабатывать лишние три раза вверх.

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

Изменяйте стратегию поведения программы в режиме реального времени, в зависимости от ситуации

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

Проверяйте длину очереди запросов и если она сильно возрастает и вы не успеваете вовремя, уменьшайте качество или количество результатов.

Лучше грубый результат сейчас, чем супер-хороший потом

Например, при большой загрузке процессора, можно отрисовывать более грубые модели объектов в режиме реального времени, а потом досчитывать результат.

Этот подход можно ещё назвать так – “Сделайте черновой вариант быстро и дорабатывайте его, пока не вышло время”.

При прокрутке содержимого окна, скроллбар может запросить окно, сколько времени потребуется для отображения содержимого. И если это
> 0.1 сек, то продолжить скроллирование до конца перемещения курсора, а потом перерисовать содержимое.

Просчитывайте сколько операция займёт времени и решайте КАК вы будете её исполнять

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

Необходимо, чтобы:

  • программа знала свои временные ограничения
  • программа знала свои требования по качеству результатов
  • функции должны предоставлять приблизительное время своего исполнения и уровень качества результата. В идеале они должны предоставлять набор вариантов различного уровня качества и времени для их исполнения.
  • существовал протокол для поиска наиболее качественного результата за имеющееся время

Просчитывайте, сколько операция займёт времени, и решайте исполнять ли её вообще

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

Больше свежих новостей в нашем Telegram-канале. Подписывайтесь!



Запросите





Нажимая на кнопку, вы даёте своё согласие на обработку персональных данных. Политика обработки персональных данных

Свяжитесь с нами