Відмінності між версіями «Вибір структури діалогу»
(не показано 3 проміжні версії 2 учасників) | |||
Рядок 1: | Рядок 1: | ||
+ | ---- | ||
+ | [[category:РІС]] | ||
+ | <b>Вибір структури діалогу</b> - це перший з етапів розробки інтерфейсу. | ||
+ | Розглянуті нижче чотири варіанти структури діалогу є різновидами структури типу «питання - відповідь», проте кожна з них має свої особливості і найбільш зручна для певного класу завдань. | ||
+ | <br><br><br> | ||
+ | '''Діалог типу «питання - відповідь»''' | ||
+ | Структура діалогу типу «питання - відповідь» (Q&a) заснована на аналогії із звичайним інтерв'ю. Система бере на себе роль інтерв’юера і отримує інформацію від користувача у вигляді відповідей на питання. Це найбільш відома структура діалогу; всі діалоги, керовані комп'ютером, в тому або іншому ступені складаються з питань, на які користувач відповідає. Проте в структурі Q&a цей процес виражений явно. У кожній точці діалогу система виводить як підказку одне питання, на який користувач дає одну відповідь. Залежно від отриманої відповіді система може вирішити, яке наступне питання ставити. Структура Q&a забезпечує природну форму введення як повідомлень (команд), що управляють, так і даних. Ніяких обмежень на діапазон або тип вхідних даних, які можуть оброблятися, не накладається. Існують системи, відповіді в яких даються на природній мові, але частіше використовуються пропозиції з одного слова з обмеженою граматикою. Діалог у вигляді питань і відповідей достатньою мірою забезпечує підтримку користувача, оскільки навіть коротке навідне питання при розумній побудові може бути таким, що само пояснює.<br><br> | ||
+ | З появою графічного інтерфейсу структура Q&a дещо застаріла, проте, у неї є певні переваги. Ця структура може задовольнити вимоги різних користувачів і типів даних. Зокрема, така структура особливо доречна при реалізації діалогу з безліччю «відгалужень», тобто в тих випадках, коли на кожне питання передбачається велике число відповідей, кожний з яких впливає на те, яке питання буде поставлено наступним. З цієї причини структура Q&a часто використовується в експертних системах. | ||
+ | <br><br><br> | ||
+ | '''Діалог на основі меню''' | ||
− | + | Меню є, мабуть, найбільш популярним варіантом організації запитів на введення даних під час діалогу, керованого комп'ютером. | |
+ | Існує декілька основних форматів представлення меню на екрані: | ||
− | + | • список об'єктів, вибираних прямою вказівкою або вказівкою номера (або мнемонічного коду); | |
+ | |||
+ | • меню у вигляді блоку даних; | ||
+ | |||
+ | • меню у вигляді рядка даних; | ||
+ | |||
+ | • меню у вигляді піктограм. | ||
+ | <br><br> | ||
+ | Користувач може вибрати потрібний пункт, вводячи текстовий рядок, який ідентифікує цей пункт, указуючи на нього безпосередньо або проглядаючи список і вибираючи з нього. Система може виводити пункти меню послідовно, при цьому користувач вибирає потрібний йому пункт натисненням клавіші або клацанням миші.<br><br> | ||
+ | Меню можна з рівним успіхом застосовувати для введення, як повідомлень, що управляють, так і даних. Прийнятна структура меню залежить від його розміру і організації, від способу вибору пунктів меню і реальної потреби користувача в підтримці з боку меню.<br><br> | ||
+ | <b>Меню</b> - це найбільш зручна структура діалогу для непідготовлених користувачів; жорстка черговість відкриття і ієрархічна вкладеність меню може викликати роздратування професіонала, уповільнювати його роботу. Традиційна структура меню недостатньо гнучка і не повною мірою узгоджується з методами адаптації діалогу, такими, наприклад, як випереджаюче введення, за допомогою якого можна прискорити темп роботи підготовленого користувача. | ||
+ | <br><br><br> | ||
+ | '''Діалог на основі екранних форм''' | ||
+ | |||
+ | Як структура типу «питання - відповідь», так і структура типу меню припускає на кожному кроці діалогу обробку єдиної відповіді. Діалог на основі екранних форм допускає обробку декількох відповідей на одному кроці діалогу. На практиці форми використовуються в основному там, де облік якої-небудь діяльності вимагає введення достатньо стандартного набору даних. Людина, що заповнює форму, може вибирати послідовність відповідей, тимчасово пропускати деяке питання, повертатися назад для корекції попередньої відповіді і навіть «порвати бланк» і почати заповнювати новий. Він працює з формою до тих пір, поки не заповнить її повністю і не передасть системі. Програмна система може перевіряти кожну відповідь безпосередньо після введення або почекати і вивести список помилок тільки після заповнення форми цілком. У деяких системах інформація, що вводиться користувачем, стає доступною тільки після натиснення клавіші «Введення» після закінчення заповнення форми. Питання про те, чи треба перевіряти відповідь безпосередньо або відкласти перевірку до закінчення введення всіх відповідей, вирішити непросто: повідомлення про помилки, що виводяться безпосередньо після відповіді, можуть відвернути увагу, але можуть зробити і позитивний вплив. Взагалі, в тих випадках, коли інформація для введення вибирається з деякого цілісного документа, перевірку краще відкласти до кінця заповнення форми, щоб не переривати процес введення; якщо ж такої цілісності немає, то перевірку слід виконувати відразу після введення відповіді (після заповнення чергового поля).<br><br> | ||
+ | Якщо зустрілася яка-небудь помилка, застосування не повинне наново виводити порожню форму; виводиться форма з попередніми відповідями і допущеними помилками. Новий «бланк» видається лише у разі відповідного запиту користувача.<br><br> | ||
+ | Часто всі необхідні одиниці введення не можна відобразити одночасно в межах одного екрану (або вікна) і їх необхідно розділити на групи, які відображаються на послідовності екранів (вікон). Важливо, щоб це розбиття зберігало логічні зв'язки і не приводило до розділення зв'язаних частин документа.<br><br> | ||
+ | Структура діалогу на основі екранної форми забезпечує високий рівень підтримки користувача: для кожного питання форми можуть бути передбачені повідомлення про помилки і довідкова інформація. Користувачеві можна також надати допомогу, включивши деякі елементи формату відповіді в питання або в полі відповіді. Ця структура дозволяє підвищити швидкість введення даних в порівнянні із структурою типу «питання - відповідь» і маніпулювати ширшим діапазоном вхідних даних, ніж меню; крім того, з нею можуть працювати користувачі будь-якої кваліфікації. Оскільки ця структура має послідовну, а не деревовидну організацію, вона у меншій мірі підходить для роботи в режимі вибору варіантів. Ще однією областю застосування екранних форм є завдання параметрів запитів в базах даних. Цей механізм іноді називають запитом за зразком (Query by Example). | ||
+ | <br><br><br> | ||
+ | '''Діалог на основі командної мови''' | ||
+ | |||
+ | Структура діалогу на основі командної мови така ж поширена, що і структура типу меню. Вона дуже часто використовується в операційних системах і розташовується на іншому кінці спектру структур діалогу по відношенню до структури типу меню. Історично це перша з реалізованих структур діалогу.<br><br> | ||
+ | При такій організації діалогу програмна система не виводить нічого, окрім постійної підказки (запрошення на введення команди), Яка означає готовність системи до роботи. Кожну команду вводять з нового рядка і зазвичай закінчують натисненням клавіші «Введення». Відповідальність за правильність команд, що задаються, лягає на користувача. Система інформує про неможливість виконання невірної команди, не пояснюючи, як правило, причин.<br><br> | ||
+ | Подібно до меню, діалог на базі команд зручний для введення повідомлень, що управляють, проте він забезпечує ширші можливості вибору в будь-якій крапці діалогу і не вимагає ієрархічної організації обслуговуючих його програм.<br><br> | ||
+ | Програмна система може підтримувати чималу кількість команд, але на практиці слід обмежувати їх число, щоб не перенавантажувати пам'ять користувача. Структура на базі командної мови не відрізняється хорошою підтримкою користувача і придатна в основному для підготовлених фахівців. Оскільки дана структура припускає великий об'єм матеріалу, що запам'ятовується, імена команд слід вибирати так, щоб вони несли смислове навантаження і легко запам'ятовувалися. Розробник повинен прагнути уникати зайвої функціональності, що походить від бажання створити власну команду для кожної функції, виконуваною системою, тобто не варто створювати безліч різноманітних команд з функціями, що часто перекриваються. Такі «благі» наміри нерідко приводять до появи великої кількості ключових слів для позначення команд і синтаксичних правил, багато хто з яких рідко використовується і лише ускладнює роботу. |
Поточна версія на 10:24, 10 грудня 2009
Вибір структури діалогу - це перший з етапів розробки інтерфейсу.
Розглянуті нижче чотири варіанти структури діалогу є різновидами структури типу «питання - відповідь», проте кожна з них має свої особливості і найбільш зручна для певного класу завдань.
Діалог типу «питання - відповідь»
Структура діалогу типу «питання - відповідь» (Q&a) заснована на аналогії із звичайним інтерв'ю. Система бере на себе роль інтерв’юера і отримує інформацію від користувача у вигляді відповідей на питання. Це найбільш відома структура діалогу; всі діалоги, керовані комп'ютером, в тому або іншому ступені складаються з питань, на які користувач відповідає. Проте в структурі Q&a цей процес виражений явно. У кожній точці діалогу система виводить як підказку одне питання, на який користувач дає одну відповідь. Залежно від отриманої відповіді система може вирішити, яке наступне питання ставити. Структура Q&a забезпечує природну форму введення як повідомлень (команд), що управляють, так і даних. Ніяких обмежень на діапазон або тип вхідних даних, які можуть оброблятися, не накладається. Існують системи, відповіді в яких даються на природній мові, але частіше використовуються пропозиції з одного слова з обмеженою граматикою. Діалог у вигляді питань і відповідей достатньою мірою забезпечує підтримку користувача, оскільки навіть коротке навідне питання при розумній побудові може бути таким, що само пояснює.
З появою графічного інтерфейсу структура Q&a дещо застаріла, проте, у неї є певні переваги. Ця структура може задовольнити вимоги різних користувачів і типів даних. Зокрема, така структура особливо доречна при реалізації діалогу з безліччю «відгалужень», тобто в тих випадках, коли на кожне питання передбачається велике число відповідей, кожний з яких впливає на те, яке питання буде поставлено наступним. З цієї причини структура Q&a часто використовується в експертних системах.
Діалог на основі меню
Меню є, мабуть, найбільш популярним варіантом організації запитів на введення даних під час діалогу, керованого комп'ютером. Існує декілька основних форматів представлення меню на екрані:
• список об'єктів, вибираних прямою вказівкою або вказівкою номера (або мнемонічного коду);
• меню у вигляді блоку даних;
• меню у вигляді рядка даних;
• меню у вигляді піктограм.
Користувач може вибрати потрібний пункт, вводячи текстовий рядок, який ідентифікує цей пункт, указуючи на нього безпосередньо або проглядаючи список і вибираючи з нього. Система може виводити пункти меню послідовно, при цьому користувач вибирає потрібний йому пункт натисненням клавіші або клацанням миші.
Меню можна з рівним успіхом застосовувати для введення, як повідомлень, що управляють, так і даних. Прийнятна структура меню залежить від його розміру і організації, від способу вибору пунктів меню і реальної потреби користувача в підтримці з боку меню.
Меню - це найбільш зручна структура діалогу для непідготовлених користувачів; жорстка черговість відкриття і ієрархічна вкладеність меню може викликати роздратування професіонала, уповільнювати його роботу. Традиційна структура меню недостатньо гнучка і не повною мірою узгоджується з методами адаптації діалогу, такими, наприклад, як випереджаюче введення, за допомогою якого можна прискорити темп роботи підготовленого користувача.
Діалог на основі екранних форм
Як структура типу «питання - відповідь», так і структура типу меню припускає на кожному кроці діалогу обробку єдиної відповіді. Діалог на основі екранних форм допускає обробку декількох відповідей на одному кроці діалогу. На практиці форми використовуються в основному там, де облік якої-небудь діяльності вимагає введення достатньо стандартного набору даних. Людина, що заповнює форму, може вибирати послідовність відповідей, тимчасово пропускати деяке питання, повертатися назад для корекції попередньої відповіді і навіть «порвати бланк» і почати заповнювати новий. Він працює з формою до тих пір, поки не заповнить її повністю і не передасть системі. Програмна система може перевіряти кожну відповідь безпосередньо після введення або почекати і вивести список помилок тільки після заповнення форми цілком. У деяких системах інформація, що вводиться користувачем, стає доступною тільки після натиснення клавіші «Введення» після закінчення заповнення форми. Питання про те, чи треба перевіряти відповідь безпосередньо або відкласти перевірку до закінчення введення всіх відповідей, вирішити непросто: повідомлення про помилки, що виводяться безпосередньо після відповіді, можуть відвернути увагу, але можуть зробити і позитивний вплив. Взагалі, в тих випадках, коли інформація для введення вибирається з деякого цілісного документа, перевірку краще відкласти до кінця заповнення форми, щоб не переривати процес введення; якщо ж такої цілісності немає, то перевірку слід виконувати відразу після введення відповіді (після заповнення чергового поля).
Якщо зустрілася яка-небудь помилка, застосування не повинне наново виводити порожню форму; виводиться форма з попередніми відповідями і допущеними помилками. Новий «бланк» видається лише у разі відповідного запиту користувача.
Часто всі необхідні одиниці введення не можна відобразити одночасно в межах одного екрану (або вікна) і їх необхідно розділити на групи, які відображаються на послідовності екранів (вікон). Важливо, щоб це розбиття зберігало логічні зв'язки і не приводило до розділення зв'язаних частин документа.
Структура діалогу на основі екранної форми забезпечує високий рівень підтримки користувача: для кожного питання форми можуть бути передбачені повідомлення про помилки і довідкова інформація. Користувачеві можна також надати допомогу, включивши деякі елементи формату відповіді в питання або в полі відповіді. Ця структура дозволяє підвищити швидкість введення даних в порівнянні із структурою типу «питання - відповідь» і маніпулювати ширшим діапазоном вхідних даних, ніж меню; крім того, з нею можуть працювати користувачі будь-якої кваліфікації. Оскільки ця структура має послідовну, а не деревовидну організацію, вона у меншій мірі підходить для роботи в режимі вибору варіантів. Ще однією областю застосування екранних форм є завдання параметрів запитів в базах даних. Цей механізм іноді називають запитом за зразком (Query by Example).
Діалог на основі командної мови
Структура діалогу на основі командної мови така ж поширена, що і структура типу меню. Вона дуже часто використовується в операційних системах і розташовується на іншому кінці спектру структур діалогу по відношенню до структури типу меню. Історично це перша з реалізованих структур діалогу.
При такій організації діалогу програмна система не виводить нічого, окрім постійної підказки (запрошення на введення команди), Яка означає готовність системи до роботи. Кожну команду вводять з нового рядка і зазвичай закінчують натисненням клавіші «Введення». Відповідальність за правильність команд, що задаються, лягає на користувача. Система інформує про неможливість виконання невірної команди, не пояснюючи, як правило, причин.
Подібно до меню, діалог на базі команд зручний для введення повідомлень, що управляють, проте він забезпечує ширші можливості вибору в будь-якій крапці діалогу і не вимагає ієрархічної організації обслуговуючих його програм.
Програмна система може підтримувати чималу кількість команд, але на практиці слід обмежувати їх число, щоб не перенавантажувати пам'ять користувача. Структура на базі командної мови не відрізняється хорошою підтримкою користувача і придатна в основному для підготовлених фахівців. Оскільки дана структура припускає великий об'єм матеріалу, що запам'ятовується, імена команд слід вибирати так, щоб вони несли смислове навантаження і легко запам'ятовувалися. Розробник повинен прагнути уникати зайвої функціональності, що походить від бажання створити власну команду для кожної функції, виконуваною системою, тобто не варто створювати безліч різноманітних команд з функціями, що часто перекриваються. Такі «благі» наміри нерідко приводять до появи великої кількості ключових слів для позначення команд і синтаксичних правил, багато хто з яких рідко використовується і лише ускладнює роботу.