Все равно придется ждать?

О вреде немодальноно отображения хода процесса

В руководстве Microsoft по разработке пользовательских интерфейсов предлагается такой критерий для применения немодального отображения хода процесса:

If users can do something productive while the operation is in progress, provide modeless feedback.

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

Рекомендация кажется осмысленной, однако то, что получается на практике далеко не всегда удачно, и тому есть некоторые причины.

Начну с пары примеров. Первый пример — самый распространенный: загрузка операционной системы. Windows старается показать рабочий стол как можно раньше, чтобы казалось, что загрузка идет быстрее. На практике же не смотря на то, что после появления рабочего стола можно сразу куда-то нажимать, некоторые программы еще продолжают загружаться и система «тормозит». Более того, если нетерпеливо кликнуть и запустить что-нибудь до того, как программы из автозагрузки закончат шуршать винчестером, суммарное время ожидания только учвеличится. Поэтому ускорение загрузки на самом деле в некоторой степени мнимое.

Второй пример — окно проводника в Vista, которое что-то делает после открывания. Казалось бы, по файлам можно щелкать пока готовятся эскизы. На самом деле нет: во время хода этого процесса порядок файлов иногда меняется. Бывает, файлы упрыгивают из-под мышки.


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

Раздражение

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

Реальная производительность

Мой скромный опыт разработки ПО говорит о том, что у некоторых длительных операций, в процессе которых что-то динамически меняется на экране, на перерисовку экрана может уходить довольно значительная доля времени. Нужно контролировать время на перерисовку. Иногда оказывается, что убрав мнимую интерактивность появления/обновления элементов на экране по одному можно весьма существенно уменьшить итоговое время загрузки. Однако в действительности все немного не так, как на самом деле. Оценка времени «торможения» программы делается людьми без секундомера, и потому более длительный «интерактивный» процесс может казаться более быстрым, чем более короткий процесс без такой анимации.

Поэтому при реализации всяческих динамически обновляемых в процессе чего-то штук, рекомендую реализовать два варианта и сравнить. Возможно, отключение перерисовки элементов «по одному» существенно снизит суммарное время работы, и можно будет ограничиться, к примеру, «бесконечно идущей» (indeterminate) полосой хода процесса.

Electriq Saturday 26 March 2011 at 11:27 am | | Russian | Four comments