П’ять основних критеріїв оцінки діалогу

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

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

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

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

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

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

4) Підтримка користувача

Це міра допомоги, яку діалог надає користувачу при його роботі із системою. Цей критерій має 3 основні аспекти:

– кількість і якість наявних інструкцій для користувача;

– характер повідомлень про помилки, які видаються;

– підтвердження довільних дій системи.

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

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

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

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

5) Гнучкість

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

25 Діалог типу Q&A

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

26 Критерії розробки діалогу Q&A

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

Для полегшення сприймання довжину повідомлення треба обмежити приблизно 40 символами, які виводяться в лівій частині екрана, яка складає 2/3 частини екрана.

Питання системи повинні чітко відрізнятися від відповідей користувача. Структура діалогу типу Q&A в достатній мірі розрізняє підтримку користувача, оскільки навіть коротке навідне питання, при розумній побудові, може бути таким, що пояснює само себе.

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

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

27. Реалізація діалогу Q&A

В найпростішому випадку можна реалізувати на мові Pascal з використанням Write/Read. Але такий спосіб не дає можливості в повній мірі використати можливості обладнання.

В структурі діалогу 3 кроки:

1) Виведення питання.

2) Введення відповіді.

3) Контроль правильності.

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

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

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

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

Може бути наприклад проконтрольована наявність самих даних, а не їх формат, і тоді вхідні дані будуть запитуватись доти, доки не буде введена можлива відповідь.

Висновки до Q&A. В цій структурі діалогу є певні переваги перед іншими структурами діалогу – це проміжна структура, яка може задовольнити вимоги різних користувачів при вводі різних типів даних, вона досить гнучка і в достатній степені може підтримувати користувача. Ця структура може бути з багатьма відгалуженнями, тоді коли на кожне питання передбачається велика кількість відповідей, кожна з яких впливає на те, яке питання буде задане наступне, тому ця структура діалогу використовується в експертних структурах.