2.2. Етапи проектування користувальницького інтерфейсу

Щопроводилися у свій час дослідження психологічних аспектів спілкування людини з комп'ютером показали, що варто всіляко прагнути до дегуманізації цього спілкування, тобто користувач не повинний сприймати комп'ютер як повноцінного співрозмовника. Проте обмін інформацією між користувачем і комп'ютером (точніше, його програмним забезпеченням) по усіх формальних ознаках відповідає поняттю "діалог" у загальноприйнятому змісті. Імовірно, читач навіть без допомоги Тлумачного словника зможе перелічити основні правила, що повинні дотримуватися, щоб діалог виявився конструктивним:

по-перше, учасники діалогу повинні розуміти мову один одного;

по-друге, вони не повинні говорити одночасно;

по-третє, чергове висловлення повинне враховувати як загальний контекст діалогу, так і останню інформацію, отриману від співрозмовника.

22

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

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

Тепер давайте згадаємо, чого не люблять наші співрозмовники.

Насамперед - зайвої фамільярності. Крім того, мало кому подобається, коли під час розмови його смикають за рукав, відкручують чи ґудзик використовують ще якісь оригінальні способи залучення уваги. Дуже короткі відповіді і занадто великі паузи можуть збити співрозмовника з користі, а зловживання спеціальними чи термінами жаргонізмами взагалі може привести до передчасного завершення бесіди.

Приведені вище міркування носять дуже загальний характер і застосовні практично до будь-якого діалогу, назависимо від того, у яких відносинах сосото-ят співрозмовники і з якою метою ведеться діалог. Однак ці фактори істотно впливають на структуру діалогу, тобто на форму спілкування. Наприклад, якщо зустрілися два приятелі, то діалог нагадує гру в теніс: ініціатива по черзі переходить від одного співрозмовника до іншого; якщо ви прийшли в ресторан, то ваше спілкування з офіціантом обмежується вибором блюд із запропонованого меню, а при оформленні закордонного паспорта чиновник запропонує заповнити одну-двох анкет, а потім перегляне їх, при необхідності уточнюючи ті чи інші моменти.

Таким чином, при проектуванні користувальницького інтерфейсу необхідно визначити:

o структуру діалогу;

o можливий сценарій розвитку діалогу;

o зміст керуючих повідомлень і даних, який можуть обмінювати

ся людина і додаток (семантику повідомлень);

o візуальні атрибути відображуваної інформації (синтаксис повідомлень).

2.2.1. ВИБІР СТРУКТУРИ ДІАЛОГУ

- Вибір структури діалогу - це перший з етапів, що повинний бути выпол-нен при розробці інтерфейсу.

Розглянуті нижче чотири варіанти структури діалогу є різновидами структури типу "питання - відповідь", проте кожна з них має свої особливості і найбільш зручна для визначеного класу задач.

23

ДІАЛОГ ТИПУ "ПИТАННЯ - ВІДПОВІДЬ"

Структура діалогу типу "питання-відповідь" (Q&A) заснована на аналогії зі звичайним інтерв'ю. Система бере на себе роль інтерв'юера й одержує інформацію від користувача у виді відповідей на питання. Це найбільш відома структура діалогу; усі діалоги, керовані комп'ютером, у тім чи іншому ступені складаються з питань, на які користувач відповідає. Однак у структурі Q& А цей процес виражений явно. У кожній крапці діалогу система виводить як підказку одне питання, на який користувач дає одну відповідь. У залежності від отриманої відповіді система може вирішити, який наступний питання задавати. Структура Q&A надає природний механізм уведення як керуючих повідомлень (команд), так і даних. Ніяких обмежень на чи діапазон тип вхідних даних, що можуть оброблятися, не накладається. Існують системи, відповіді в який даються природною мовою, але частіше використовуються пропозиції з одного слова з обмеженою граматикою.

Діалог у виді питань і відповідей у достатньому ступені забезпечує підтримку користувача, тому що навіть коротке навідне запитання при розумній побудові може бути що самопояснює. Структура Q&A не гарантує мінімального обсягу введення, оцінюваного по кількості натискань клавіш, однак при придатному підборі скорочень можна зменшити будь-яку надмірність. Разом з тим, струтура Q& А володіє одним істотним недоліком. Навіть якщо уведення відбувається досить швидко, для людини, що вже знає, які питання задає система і які відповіді потрібно на них давати, відповідати на всю серію питань вільно утомливо.

З появою графічного інтерфейсу структура Q& А трохи застаріла, проте в неї маються визначені достоїнства. Ця структура може задовольнити вимоги різних користувачів і типів даних. Зокрема , така структура особливо доречна при реалізації діалогу з безліччю "відгалужень", тобто в тих випадках, коли на кожне питання передбачається велике число відповідей, кожний з який впливає на те, який питання буде заданий наступним. З цієї причини структура Q&A часто використовується в експертних системах.

ДІАЛОГ НА ОСНОВІ МЕНЮ

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

Існує кілька основних форматів представлення меню на екрані: o список об'єктів, обираних прямою вказівкою, або вказівкою номера (чи мнемонічного коду);

24

o меню у виді блоку даних;

o меню у виді рядка даних;

o меню у виді піктограм.

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

Меню у виді піктограм являє собою безліч об'єктів вибору, раз-бросанных по всьому екрані; часто об'єкти вибору містять графічне представлення варіантів роботи.

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

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

Структура типу меню є найбільше природним механізмом для роботи з пристроями вказівки і вибору: меню являє собою зображення тих об'єктів, що вибираються користувачем. Якщо діалог складається винятково з меню, можна реалізувати послідовний інтерфейс, при якому користувач застосовує тільки пристрою для вказівки; однак така сталість рідка досяжне на практиці. Варто також помітити, що, хоча робота з цими пристроями не вимагає професійного володіння клавіатурою, для підготовленого користувача це не найшвидший спосіб вибору з меню. Замість указівки користувач може повідомити про свій вибір уведенням соответ-ствующего ідентифікатора.

Меню - це найбільш зручна структура діалогу для непідготовлених поль-зователей; тверда черговість відкриття й ієрархічна вкладеність меню мо-жет викликати роздратування професіонала, сповільнювати його роботу. Традиційна структура меню недостатньо гнучка і не повною мірою погодиться з методами адаптації діалогу, такими, наприклад, як випереджальне введення, за допомогою якого можна прискорити темп роботи підготовленого користувача. Більш докладно воп-росы організації і візуального представлення меню розглянуті в розділі "Про-ектирование елементів керування".

25

ДІАЛОГ НА ОСНОВІ ЕКРАННИХ ФОРМ

Як структура типу "питання - відповідь", так і структура типу меню припускають обробку на кожнім кроці діалогу єдиної відповіді. Діалог на основі екранних форм допускає обробку на одному кроці діалогу декількох відповідей. На практиці форми використовуються в основному там, де облік якої-небудь діяльності вимагає введення досить стандартного набору даних. Людина, що заповнює форму, може вибирати послідовність відповідей, тимчасово пропускати деяке питання, повертатися назад для корекції попереднього відповіді і навіть "порвати бланк" і почати заповнювати новий. Він працює з формою доти , поки не заповнить її цілком і не передасть системі. Програмна система може перевіряти кожну відповідь безпосередньо після чи уведення виждати і вивести список помилок тільки після заповнення форми цілком. У деяких системах інформація, що вводиться користувачем, стає доступної тільки після натискання клавіші "уведення" по закінченні заповнення форми. Питання про тім, чи треба перевіряти відповідь чи безпосередньо відкласти перевірку до закінчення уведення усіх відповідей, вирішити непросто: повідомлення про помилки, виведені безпосередньо після відповіді, можуть відвернути увага, але можуть зробити і позитивний вплив. Взагалі в тих випадках, коли інформація для уведення вибирається з деякого цілісного документа, перевірку краще відкласти до кінця заповнення форми, щоб не переривати процес уведення; якщо ж такої цілісності ні, те перевірку варто виконувати відразу після уведення відповіді (після заповнення чергового полючи).

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

Таким чином, цю структуру доречно застосовувати там, де джерелом даних служить існуюча вхідна ("паперова") форма документа.

Не обов'язково, щоб зовнішній вигляд цих форм збігався (це навіть може погіршити сприйняття даних на екрані), але всі елементи даних, що вводяться, повинні розташовуватися в тім же відносному порядку і мати такий же формат, що й у вихідному документі.

Часто всі необхідні одиниці введення не можна відобразити одночасно в межах одного екрана (чи вікна), і їх необхідно розділити на групи, що відображаються па послідовності екранів (вікон). Важливо, щоб ця розбивка зберігала логічні зв'язки і не приводилася до поділу зв'язаних частин документа.

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

26

відповіді. Ця структура дозволяє підвищити швидкість уведення даних у порівнянні зі структурою типу "питання - відповідь" і маніпулювати більш широким діапазоном вхідних даних, ніж меню; крім того, з нею можуть працювати користувачі будь-якої кваліфікації. Оскільки ця структура має послідовну, а не деревоподібну організацію, вона в меншому ступені підходить для роботи в режимі вибору варіантів. Ще однією областю застосування екранних форм є завдання параметрів запитів у базах даних. Цей механізм іноді називають запитом за зразком (Query by Example).

Одним з типів заповнення форм є також різноманітні меню. У таких меню користувачу надається список варіантів і він не обмежений можливістю єдиного вибору; можна вказати кілька варіантів.

ДІАЛОГ НА ОСНОВІ КОМАНДНОЇ МОВИ

Структура діалогу на основі командної мови настільки ж поширена, що і структура типу меню. Вона дуже часто використовується в операційних системах і розташовується на іншому кінці спектра структур діалогу стосовно структури типу меню. Історично це перша з реалізованих структур діалогу.

При такій організації діалогу програмна система не виводить нічого, крім постійної підказки (запрошення на введення команди), що означає готовність системи до роботи. Кожну команду вводять з нового рядка і звичайно закінчують натисканням клавіші "уведення". Відповідальність за правильність команд, що задаються, лягає на користувача. Система інформує про неможливість виконання невірної команди, не пояснюючи, як правило, причин.

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

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

Оскільки дана структура припускає великий обсяг мата-ріала, що запам'ятовується, імена команд варто вибирати так, щоб вони несли значеннєве навантаження і легко запам'ятовувалися. Розроблювач повинний прагнути уникати зайвої функціональності, що відбуває від бажання створити власну команду для кожної функції, виконуваною системою, тобто не варто створювати безліч

27

різноманітних команд із часто перекриваються функціями. Такі "благі" на-мерения нерідко приводять до появи великої кількості ключових слів для позначення команд і синтаксичних правил, багато хто з який рідко использу-ются і лише ускладнюють роботу.

Діалог повинний керувати даними. В інтерфейсах на основі мов команд це звичайно досягається за допомогою складених командних рядків, де ключове слово для позначення команди (що робити) передує списку параметрів (вхідним даним). Параметри в списку можна задавати в одній із двох форм - у позицион-ной чи ключовий. У першому випадку призначення параметра визначається по його ме-сту в командному рядку. У випадку ключових параметрів кожне значення предваря-ется визначеним ідентифікатором, що визначає його призначення.

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

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

М ногие командні мови підтримують макроси, що розширюють функ-циональные можливості діалогу без збільшення кількості команд. Макрос з-тримає кілька окремих командних рядків. При звертанні до нього в процесі дна.півдня окремі рядки команд макросу виконуються одна за іншою, як якби вони вводилися з клавіатури. Це істотно скорочує діалогові сеанси, що містять часто повторювані послідовності команд, що, собствен-но, і оформляються у виді макросів.

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

Викладене можна представити у формі так називаної "таблиці выбо-ра" [2] (мал. 2.1).

• 28

* - використання цього типу діалогу даною категорією користувачів вимагає наявності системи допомоги;

** - використання засобів системи можливо тільки в обмеженому обсязі. Рис. 2.1. Варіант таблиці вибору

Поряд із зазначеними в таблиці, у неї можуть бути включені й інші критерії вибору (наявність інструментальних засобів розробки інтерфейсу, характер користувача, обмеження по наявних ресурсах і т.д.).

Вибір найбільш придатної структури діалогу на основі таблиці выполняет-ся в такий спосіб.

1. Закрити графи "Тип діалогу".

2. У графі "Вибір користувача" позначити критерії, що відносяться до рассмат

риваемому застосування.

3. Для кожного типу діалогу підрахувати число випадків, коли позначені соответ

ствующие пункти й у графі "вибір користувача", і в графі "тип діалогу".

4. Підрахувати число збігів для кожного типу діалогу.

29

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

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

2.2.2. РОЗРОБКА СЦЕНАРІЮ ДІАЛОГУ

Розвиток діалогу в часі можна розглядати як послідовність переходів системи з одного стану в інше. Очевидно, що жодне з цих станів не повинне бути "тупиковим", тобто користувач повинний мати можливість перейти з будь-якого поточного стану діалогу в необхідне (за один пли кілька кроків). Для цього в ході розробки інтерфейсу необхідно визначити всі можливі стани діалогу і шляху переходу з одного стану в інше. Іншими словами, необхідно розробити сценарій діалогу.

Цілями розробки сценарію діалогу є:

o виявлення й усунення можливих тупикових ситуацій у ході розвитку діалогу;

o вибір раціональних шляхів переходу з одного стану діалогу в інше (з

поточного в необхідне);

o виявлення неоднозначних ситуацій, що вимагають надання додаткової

допомоги користувачу.

Складність розробки сценарію визначається в основному двома факторами: функціональними можливостями створюваного додатка (тобто числом і складністю реалізованих функцій обробки інформації) і ступенем невизначеності можливих дій користувача.

У свою чергу, ступінь невизначеності дій користувача залежить від обраної структури діалогу. Найбільшої детерминированностью володіє діалог на основі меню, найменшої - діалог типу "питання-відповідь", керований користувачем.

Зі сказаного випливає, що сценарій діалогу можна спростити, знизивши ступінь невизначеності дій користувача. Можливими способами рішення цієї задачі є:

використання змішаної структури діалогу (застосування меню з метою "огра-ничения волі" користувача там, де це можливо);

застосування вхідного контролю інформації, що вводиться, (команд і даних).

Додаткові можливості по зниженню невизначеності дій пользо-вателя надає об'єктно-орієнтований підхід до розробки інтерфейсу, при якому для кожного об'єкта заздалегідь установлюється перелік властивостей і

30

припустимих операцій. Найбільш ефективний такий підхід при створенні графи-ческого інтерфейсу; більш докладно ці питання обговорюються в розділі "Особен-ности графічного інтерфейсу".

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

Спосіб опису сценарію діалогу залежить від ступеня його складності. Суще-ствующие методи опису сценаріїв можна розділити на дві великі групи: неформальні і формальні методи.

Головне достоїнство формальних методів полягає в тому, що вони дозволяють автоматизувати як проектування діалогу, так і його модифікацію (адапта-цию) відповідно до характеристик користувача.

В даний час найбільш широко використовуються формальні методи описа-ния сценаріїв на основі мереж Петри і їхніх розширень, а також на основі систем представлення знань (фреймові моделі і продукционные системи).

Незалежно від способу опису сценарію його основною структурною одиницею є крок діалогу, що відповідає одному акту взаємодії користувача із системою. Схематично крок діалогу можна представити так, як показано на мал. 2.2.

Рнс. 2.2. Крок діалогу

Сценарій діалогу дозволяє описати процес взаємодії користувача з додатком на рівні розв'язуваної їм прикладної задачі. Однак для програмної реалізації інтерфейсу такий опис носить занадто загальний характер. Тому на етапі реалізації необхідно перейти на рівень опису відповідних процесів за допомогою використовуваних інструментальних засобів розробки додатка.

31

ТЕМП ВЕДЕННЯ ДІАЛОГУ

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

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

Темп ведення діалогу залежить від характеристик апаратних і програмних засобів ЕОМ, а також від специфіки розв'язуваних задач. Вимога відповідності темпу ведення діалогу психологічним особливостям людини висуває обмеження на значення цих характеристик не тільки "зверху", але і "знизу". 11оясним це твердження.

Час відповіді (відгуку) системи визначається як інтервал між подією і реакцією системи на нього. Дана характеристика інтерфейсу визначає затримку в роботі користувача при переході до виконання наступного кроку завдання.

Важливість обліку темпу ведення діалогу була усвідомлена ще в 60-х роках, коли з'явилися перші інтерактивні системи. Повільна відповідь системи не відповідає психологічним потребам користувача, що при водить до зниження ефективності його діяльності. Занадто швидка відповідь також може створити несприятливе представлення про систему.

Вимоги до часу відповіді залежать від того, що очікує користувач від рабо-ты системи, і від того, як взаємодія із системою впливає на виконання його завдань. Дослідження показали [3], що якщо час відповіді менше очікуваного, точність вибору операції з меню збільшується зі збільшенням часу відповіді системи. Це зв'язано з тим, що зайво швидка відповідь системи як би "підганяє" користувача, змушує його метушитися в прагненні "не відставати" від більш розторопного партнера по спілкуванню. Замічено, що початківець користувач боїться працювати із системою, якщо, витративши кілька хвилин на введення, воно моментально одержує від її відповідь з повідомленням про помилку.

Час відповіді повинен відповідати природному ритму роботи пользовате-лей. У звичайній розмові люди очікують відповіді близько 2 секунд і чекають того ж при роботі з комп'ютером. Час чекання залежить від їхнього стану і намірів. 11а представлення користувача впливає також його попередній досвід роботи із системою.

32

Звичайно людина може одночасно запам'ятати зведення про п'ять-дев'ять предметів. Вважається також, що збереження даних у короткочасній пам'яті обмежено за часом: близько 2 секунд для мовної інформації і .'"50 секунд для сенсорної. Тому люди мають схильність розбивати свою діяльність на етапи, що відповідають порціям інформації, що вони можуть зберігати одночасно в пам'яті. Завершення чергового етапу називається клаузой. Затримки, що перешкоджають настанню клаузы, дуже шкідливі і неприємні, тому що вміст короткочасної пам'яті вимагає постійного відновлення і легко стирається під впливом зовнішніх факторів. Зате після клаузы подібні затримки цілком при-емлемы і навіть необхідні. Завершення задачі, що веде до відпочинку, називають зак-рытием. У цей момент зникає необхідність подальшого збереження інформації і людина одержує істотне психологічне полегшення. Тому що користувачі інтуїтивно прагнуть до закриття у своїй роботі, варто поділяти діалоги на фрагменти, щоб користувач міг "вчасно" забувати проміжну інформацію.

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

Наявні результати досліджень дозволили виробити наступні рекомендації з припустимого часу відповіді інтерактивної системи:

0,1...0 ,2 з - для підтвердження фізичних дій (натискання клавіші, робота зі світловим пером, "мишею");

0,5...1 ,0 з - для відповіді на прості команди (наприклад, від моменту введення команди, вибору альтернативи з меню до появи нового зображення на екрані):

1...22 з - при веденні зв'язного діалогу (коли користувач сприймає серію взаємозалежних питань як одну порцію інформації для формування одного чи декількох відповідей, затримка між наступними друг за другом питаннями не повинна перевищувати зазначену тривалість);

2...44 з - для відповіді на складний запит, що складається в заповненні деякої форми. Якщо затримка не впливає на іншу роботу користувача, зв'язану з першої, можуть бути прийнятні затримки до 10 з;

більш 10 з - при роботі в мультизадачном режимі, коли користувач сприймає дану задачу як фоновий процес. Прийнято вважати, що якщо користувач не одержує відповідь протягом 20 з, те це не інтерактивна система. У такому випадку користувач може "забути" про завдання, зайнятися рішенням іншої задачі і повертатися до нього тоді, коли йому буде зручно. При цьому програма повинна повідомляти користувачу, що затримка відповіді не є наслідком виходу системи з ладу (наприклад, шляхом регулярного відновлення рядка стану чи системи ведення протоколу виконання завдання користувача).

2 Задо.747 33

МЕТОДИ РОЗРОБКИ ГНУЧКОГО ІНТЕРФЕЙСУ

1 [редварительный аналіз (хоча б і на якісному рівні) можливого сценарію діалогу дозволяє уникнути багатьох проблем на етапі реалізації додатка. Однак у випадку якщо додаток може використовуватися групою користувачів, що мають різний ступінь підготовки, ряд питань залишається невирішеним. Тому вкрай бажано, щоб у ході діалогу забезпечувалася достатня гнучкість. Вона повинна полягати в здатності додатка адаптуватися ( чикористувачем автоматично) до будь-якого можливого рівня підготовки користувача.

Існують три види адаптації: фіксована, повна і косметична.

При фіксованій адаптації користувач явно вибирає рівень діалогової підтримки. Найпростіший варіант такої адаптації заснований на використанні правила двох рівнів, відповідно до якого система забезпечує два види діалогу:

докладний (для починаючого користувача);

короткий (для підготовленого користувача).

Правило двох рівнів може бути розширене до правила N рівнів діалогу. Однак такий підхід має кілька недоліків:

1) не враховується той факт, що навички накопичуються поступово;

2) користувач може добре знати одну частину системи і зовсім не знати іншу;

3) користувач сам визначає рівень своєї підготовки, що знижує объек

тивность оцінки.

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

В даний час повна (автоматична) адаптація практично в жодній діалоговій системі не реалізована.

Косметична адаптація покликана забезпечити гнучкість діалогу без обліку поводження користувача, але і без однозначного вибору їм конкретного стилю діалогу.

Така адаптація може бути досягнута за рахунок застосування наступних методів:

o використання умовчань;

o використання скорочень;

o випереджальний уведення відповідей;

o багаторівнева допомога;

o многоязычность.

Використання умовчань. Сутність умовчання полягає в тому, що система використовує деяке споконвічно задане значення якого-небудь параметра, поки користувач не змінить його. У цьому випадку мають місце два аспекти адаптації системи:

по-перше, що починає користувач має можливість використовувати боль-шинство параметрів системи за замовчуванням,

по-другу, система може запам'ятовувати значення, лиоо задані при останньому сеансі роботи (наприклад, ім'я файлу, що редагується,), або найбільше часто використовувані.

Для зручності починаючих користувачів значення, використовувані за замовчуванням, можуть виводитися на екран разом з відповідним питанням системи, наприклад: "Дата реєстрації документа? [поточна]".

Найпоширеніший спосіб прийняття значень за замовчуванням - це нуль-виття введення, тобто просте натискання клавіші "Уведення" як відповідь на питання Систе-мы. Якщо використовується командна мова, те користувач просто пропускає параметр, використовуваний за замовчуванням.

Використання скорочень припускає, що користувач замість повного імені команди може вводити її бу-яку припустиме скорочене позначення. На перший погляд може показатися, що скорочене введення більш зручне для починаючого користувача. Алі це не зовсім так. Щоб користувач міг не задумуючись замінити команду коректним скороченням, він повинний досить добрі представляти наявний набір команд, засвоїти "лексику" системи. Наприклад, якщо в системі маються команди Сміттю і Compare, ті начи-нающему простіше набрати повне ім'я, чим вибрати коректний варіант скорочення.

Однієї з модифікацій цього підходу є випереджальне введення символів, при якому система, "довідавшись" по перших символах команд}', "дописує" її сама. Прикладом може служити інтерфейс системи GPSS/PC, у якій при введенні початкових символів команди на екран виводиться її повне ім'я, а курсор автоматично переміщається в потрібну позицію для введення параметрів цієї команди. Зрозуміло, користувач, особливо початківець, випробує почуття "глибокої вдячності" такій системі за "посильну допомогу".

Ідея випереджального уведення відповідей полягає в тім, що користувач має можливість на черговому кроці діалогу вводити не одну відповідь, а ланцюжок последо-вательных відповідей, випереджаючи можливі питання системи.

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

Сутність многоязычности інтерфейсу полягає в тому, що структура і семантика діалогових повідомлень, що видає й одержує користувач, повинні відповідати нормам рідної мови користувача і не залежати від того, на якій мові розроблені інструментальні засоби, що він використовує.

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

2* 35

2.2.3. ВІЗУАЛЬНІ АТРИБУТИ ВІДОБРАЖУВАНОЇ ІНФОРМАЦІЇ

До візуальних атрибутів відображуваної інформації відносяться:

o взаємне розташування і розмір відображуваних об'єктів;

o колірна палітра;

o засобу залучення уваги користувача.

Проектування розміщення даних на екрані припускає виконання следу-ющих дій:

1) Визначення складу інформації, що винна з'являтися на екрані;

2) Вибір формату представлення цієї інформації;

3) Визначення взаємного розташування даних (чи об'єктів) на екрані;

4) Вибір засобів залучення уваги користувача;

5) Розробка макета розміщення даних на екрані;

6) Оцінка ефективності розміщення інформації.

Процес проектування повторюється доти , поки розроблювач і потенційні користувачі не будуть задоволені.

Загальні принципи розташування інформації на екрані повинні забезпечувати для користувача:

можливість перегляду екрана в логічній послідовності;

простоту вибору потрібної інформації;

можливість ідентифікації зв'язаних груп інформації;

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

Питання про ті, яка інформація підлягає відображенню, зважується в зависимо-сти від специфіки виконуваного користувачем завдання. Отут істотну роль грає правильна розбивка завдання на операції (етапи), не потребуючої одночасної присутності великого обсягу даних на екрані. Ця умова випливає з такої психофізіологічної особливості людини, як обмеженість його короткочасної пам'яті, спсобной зберігати одночасно не більш п'яти - дев'яти об'єктів. Якщо вся інформація вихідного документа не міститься на одному екрані, деякі елементи даних можуть повторюватися на інших екранах для збереження цілісності і послідовності обробки. Як правило, повторювана інформація не винне змінювати свого розташування на всіх кроках виконання завдання.

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

Властивість природності інтерфейсу припускає, що інформація відображається на екрані у виді, придатному для безпосереднього використання. Не випливає заставши-

36

лять користувача додатково обробляти цю інформації, наприклад уточнювати по довідниках значення кодів, робити які-небудь перетворення, перерахування і т.п. Формат для висновку дати, години й інших подібних стандартизованих даних повинний бути загальноприйнятим, а не індивідуальним для даної системи. Загальноприйнята система сполучення великих і малих букв у тексті поліпшує його сприйняття.

Дуже серйозним питанням, багато в чому визначальним якість сприйняття ін-формації, є раціональне розміщення даних на екрані. Необхідна плот-ность розташування даних - поняття суб'єктивне. Вона залежить від конкретного користувача і розв'язуваної задачі. Однак існують деякого правила, ре-гулирующие щільність розташування даних на екрані (чи в межах вікна):

залишати порожнім приблизно половину екрана (вікна);

залишати порожній рядок після шкірного п'ятого рядка таблиці;

залишати чотири-п'ять пробілів між стовпцями таблиці.

Фрагменти тексту повинні розташовуватися на екрані так, щоб погляд пользова-теля сам переміщався в потрібному напрямку. Уміст полів винний не "при-жиматься" до краю екрана, а розташовуватися біля його горизонтальних чи верти-кальных осей. Меню, що містить щодо невеликий обсяг інформації, повинне зміщатися в ліву верхню частину екрана. Щоб підкреслити симетрію, вміст і найменування полів, що відносяться до однієї групи, повинні вырав-ниваться по вертикалі. По можливості необхідно вирівнювати всі логічно зв'язані групи даних.

Інший набір рекомендацій визначається факторами, зв'язаними з прав-лівою асиметрією головного мозку людини. Відомо, що ліва і права півкулі по-різному беруть доля в сприйнятті і переробці інформації. Зокрема , при запам'ятовуванні слів ведучу роль грає ліва півкуля, а при запам'ятовуванні образів більш активно праві. Інформація з правої частини екрана надходити непос-редственно в ліву півкулю, а з лівої частини - у праві (природно, при бінокулярному зорі оператора). У зв'язку з цим можна рекомендувати текстові повідомлення групувати праворуч, а зображення - ліворуч. У деяких людей цей розподіл функцій півкуль протилежно, у жінок асиметрія выра-жена слабкіше, ніж у чоловіків. Цей факт ще раз підтверджує необхідність індивідуалізації характеру відображення інформації. Облік прав-лівої асиметрії пам'яті має істотне значення, якщо інтервали проходження повідомлень не перевищують 10 с. Томові приведені рекомендації випливає в першу чергу враховувати в інтерфейсах програм, що працюють у режимі реальної години.

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

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

37

мерехтіння і застосування різних шрифтів для виведених символів. Часто для виділення інформації використовують підкреслення, висновок в інверсному виді, різні рамки і "тіні". Ефект застосування цих атрибутів різний, а їхніх сполучень - часто непередбачений і залежить від індивідуальних особливостей користувачів. У літературі з цього приводу приведене значне число рекомендацій, основний зміст яких зводиться до наступного положенню: варто намагатися використовувати мінімально необхідне число атрибутів (щоб привернути увагу людини, досить лише легонько його "торкнутися").

Чи існують об'єктивні критерії оцінки щільності заповнення екрана, збалансованості даних і інших показників якості форматування екрана? Проблема полягає в тім, що на бу-яку Людину, що дивуватися на екран, впливає зміст інформації, утрудняючи таку оцінку. Один з можливих підходів до рішення цієї проблеми - відокремити зміст від форми. Для цього застосовуються два методи - прямокутників і виділених крапок.

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

Метод виділених крапок дозволяє визначити число і розміщення областей екрана, до яких буде притягнута увага користувача (через підвищену яскравість, чи кольори мерехтіння символів). Для цього кожна область, що вимагає підвищеної уваги, моделюється групою символів, відмінних від пробілу.

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

Деякі технічні аспекти використання візуальних атрибутів відображуваної інформації розглядаються в наступній главі.

Розділ 3

ПРОЕКТУВАННЯ ГРАФІЧНОГО КОРИСТУВАЛЬНИЦЬКОГО ІНТЕРФЕЙСУ