Page 113 - 4695

проведений на пройдених екранах і, особливо реакція системи,
є досить значним.
Єдиним засобом підтримки контексту це є виведення пото-
чного стану даних в процесі виконання майстра. Як правило,
звичайний текстовий список із попередньо встановленими па-
раметрами працює погано (до того ж рідко вміщається в екран),
візуалізувати зміни важко, якщо взагалі можливо. Отже, краще
уникати довгих послідовностей (тим більше, що рівень мотива-
ції користувачів при збільшенні тривалості дії знижується).
Майстер чудово підходить до виведення довідкової інфор-
мації в самому інтерфейсі. Довідкову інформацію потрібно ви-
водити двох типів, а саме: короткий опис більш розгорнений
опис поточного кроку.
З розгорненим описом все просто. Будь-де внизу екрану
(щоб не збивати фокус уваги користувачів) виводиться один або
два абзаци, що надають стандартний набір інформації: що, на-
віщо і чому. З коротким описом складніше. На жаль, існуюче
представлення майстрів не має великого і помітного заголовка.
Наприклад, навіть такий прогресивний майстер, як використа-
ний в прикладі (рис. 7.9), не має явно помітного заголовку.
Шрифт дрібний, до того ж його розбірливість ослаблена фоном.
Закономірно, що біля кожного вікна послідовності має бути до-
бре видимий заголовок, який впадає у вічі. При цьому на від-
міну від звичайних заголовків вікна, він має бути написаний не
описово, а командно (зробіть те і те). Microsoft у деяких своїх
продуктах, що широко використовують майстра (називаючи це
спонукаючим призначеним для користувача інтерфейсом), вза-
галі рекомендує вважати заголовки за найважливіші елементи
майстрів. Особливо підкреслюється, що заголовки екранів по-
винні бути створені і сформульовані до початку проектування
екранів, при цьому вміст екранів не повинен виходити за рамки
сенсу заголовків.

112