9. 3. Діалог
Виділяють чотири основні структури типів діалогу: запитання і відповідь; меню; екранних форм; на базі команд.
Придатність структури до діалогу можна оцінювати за такими основними критеріями: природністю; послідовністю; стислістю (короткий); підтримкою користувача; гнучкістю.
Природним діалогом є такий, який не змушує користувача, котрий взаємодіє із системою, суттєво змінювати свої традиційні прийоми роботи. Тому діалог має вестися державною мовою, розмовним стилем, а не письмовим; окрім того, слід уникати як надмірної пишномовності, так і «фамільярності».
Наприклад: коротка підказка у вигляді: ВАРІАНТ? більш інформативна і більш зручна, ніж підробна чемність фрази: МОРОЗ, БУДЬ ЛАСКА, ВИБЕРІТЬ ПОТРІБНИЙ ВАРІАНТ.
Фрази, по можливості, не повинні потребувати додаткових пояснень (краще «ДРУК» «КОПІЮВАННЯ», ніж «PRINT» ^ «COPY»).
Жаргон припустимий лише за умови, що він використовується в середовищі користувача.
Наприклад: не «КОРЕКЦІЯ ІСНУЮЧОГО ФАЙЛА», а «ОБРОБКА ВИМОГ».
Порядок запиту має бути таким, у якому користувач звичайно обробляє інформацію.
Неприродний діалог часто є наслідком того, що розробник нео-знайомлений з тими прийомами, якими користувач звичайно розв’язує задачу без підтримки системи. Тому слід розробити і випробувати дослідний зразок системи. Наприклад, додаткову роботу користувача з підготовки даних перед уведенням–виведенням видно, коли він у процесі роботи за терміналом буде користуватися олівцем і папером.
Діалог, який відрізняється логічною послідовністю, гарантує, що користувач, котрий освоїв одну частину системи, легко розбереться з особливостями іншої частини системи.
1. Послідовність у побудові фраз передбачає, що коди, які вводяться, наприклад ключові слова, завжди трактуються однаково. Наприклад: допомогу від системи користувач отримає, натиснувши клавішу F1, якщо виникне будь-яке інше питання, він також повинен натиснути клавішу F1, тобто ця клавіша не може мати інших функцій, крім виклику довідкової інформації.
2. Послідовність у використанні формату даних означає, що аналогічні поля завжди будуть подані системою в одному і тому самому форматі.
3. Послідовність у розміщенні даних на екрані в різних ситуаціях, схожих за функціями, які реалізуються, є гарантією того, що користувачеві відомо, де шукати на екрані інструкцію, повідомлення про помилку і т. ін.
Стислий діалог потребує від користувача введення лише мінімуму інформації, яка необхідна для роботи системи. І тому:
1) чим меншою буде кількість потрібних натискань на клавішу, тим швидше відбувається діалог із меншою кількістю помилок;
2) у діалозі не слід вимагати інформацію, яку можна сформувати автоматично, наприклад: за кодом назву чи прізвище з бази даних, чи інформацію, яка введена раніше (наприклад, поточну дату);
3) вихідні повідомлення повинні містити лише ту інформацію, яка потрібна користувачеві, у вигляді, прийнятному для сприйняття, із залученням мінімуму засобів для виділення частини інформації.
Підтримка користувача в процесі діалогу – це та допомога, яку користувач отримує від діалогу під час його роботи із системою. Три основні частини підтримки користувача:
кількість і якість наявних інструкцій;
характер повідомлень про помилки, які видаються;
підтвердження яких-небудь дій системи.
Інструкції для користувача виводяться у вигляді підказок чи довідкової інформації. Характер і кількість інструкцій мають відповідати досвіду роботи користувача із системою і його намірам. Довідкова інформація має з’являтися тоді, коли вона потрібна, і в доступній формі.
Повідомлення про помилки мають точно пояснювати, в чому помилка і які дії потрібно зробити, аби її виправити, а не обмежуватися загальними фразами «синтаксична помилка» чи таємничими кодами типу «ОС1».
Повідомлення, що підтверджують які-небудь дії системи, потрібні для того, щоб користувач міг переконатися в тому, що система виконує, виконала чи виконуватиме необхідну дію. Наприклад: підтвердження дії є необхідним, коли можуть виконатися незворотні дії (видалення запису із файла); коли вводиться код і потрібно підтвердити, вибрано той запис чи ні (табельний номер працівника і підтвердження правильності прізвища).
Гнучкий діалог – це міра того, наскільки добре він відповідає рівню підготовки і продуктивності роботи користувача. Так, гнучкість передбачає, що діалог може змінювати свою структуру чи вхідні дані.
Усі чотири структури діалогу різною мірою відповідають переліченим критеріям і забезпечують різний рівень підтримки користувача.
Структура діалогу типу «запит – відповідь» грунтується на аналогії зі звичайним інтерв’ю:
ЯКА ОПЕРАЦІЯ? ПОСТАВКА
КОМАНДА? ВІДІСЛАТИ
ТИП ОБ’ЄКТА? РАХУНОК
НОМЕР РАХУНКА? 12543
КЛІЄНТ? МП «ПРОГРЕС»
Існують системи, де відповіді дають природною мовою, але більше використовують речення із одного слова з обмеженою граматикою.
Для полегшення сприйняття довжину повідомлення потрібно обмежити приблизно 40 символами, які виводяться в лівій частині екрана, становлячи 2/3 ширини екрана; крім того, запитання системи мають відрізнятися від відповідей користувача (наприклад, зміна регістру, колір відповідей, контрастність, інверсія, розділові знаки).
У цій структурі виділяють три основних кроки: виведення запитання, введення відповіді та контроль вірогідності відповіді.
Структура діалогу типу «меню» відображає точний список варіантів і дає можливість користувачеві вибрати один із них у такий спосіб:
уведенням ідентифікатора з клавіатури;
уведенням мнемонічних кодів;
перегляданням списку на екрані з наступним вибором;
прямою вказівкою на екрані.
Меню може мати вигляд блоку даних, рядка даних: піктограм; спливаючого (додаткового) меню, яке з’являється в процесі переміщення курсора по екрану з меню верхнього рівня (рис. 9.3).
Рис. 9.3. Структура діалогу типу «меню»
Кожне меню може мати необов’язковий заголовок, необов’язковий кінцевий текст, і основний текст меню, який складається зі списку об’єктів вибору і необов’язкового додаткового тексту, що описує якості кожного пункту.
У структурі діалогу типу екранних форм перед користувачем ставиться одразу кілька запитань і відповідь на попереднє не впливає на те, яким буде наступне. Подібні форми широко використовуються при замовленні товарів, білетів, складанні анкет, заповненні форми вхідного повідомлення тощо. Форми заповнюють зліва направо і згори вниз. Можна вибрати послідовність заповнення форми і працювати доти, доки не буде прийнято рішення про вірогідність даних і закінчено її формування. Система може перевіряти кожну відповідь після введення чи виводити список помилок після заповнення всієї форми. Ця структура будується в два етапи:
форма відображується повністю;
питання повторюються доти, доки не закінчиться заповнення форми.
Уведення відповіді на запитання можна завершити двома способами.
1. При явному завершенні користувачеві потрібно ввести для кожного поля відповіді повний символ завершення.
2. При автоматичному завершенні перехід до наступного виконується одразу, тільки-но буде заповненим поле для введення відповіді.
Структура діалогу типу «мови команд» будується на основі мови програмування чи операційної системи. Вона широко використовується так, як і тип меню, але особливо в операційних системах. Відповідальність за достовірність команд, які подаються, покладено на користувача. Вона забезпечує ширші можливості вибору в будь-якому місці діалогу і не потребує ієрархічної організації фонових завдань. Розробник повинен уникати надмірної функціональності, виходячи з бажання створити свій командний рядок для кожної функції.
Усі чотири структури мало різняться, є різновидом структури типу «запитання – відповідь» і застосовуються залежно від специфіки задачі, вимог користувача і можливостей обчислювальної техніки.
Структура типу «запитання – відповідь» — це розумний компроміс для різних рівнів підготовки користувачів. Вона використовується в таких випадках:
діапазон вхідних величин надто великий для структури типу «меню» чи надто складний для структури на основі мови команд;
наступне запитання залежить від відповіді на попереднє, діалог має багато відгалужень і на кожне запитання передбачається багато відповідей.
Часто використовується в експертних системах.
Структура типу «меню» використовується там, де:
1) діапазон можливих відповідей досить невеликий, і всі вони можуть бути явно відображені;
2) користувач повинен бачити всі можливі варіанти відповідей.
Структура типу екранних форм зручна там, де можемо передбачити стандартну послідовність уведення даних.
Структура типу мови команд використовується там, де:
1) кількість значень для введення невелика і їх можна запам’ятати;
2) обмежена кількість відповідей достатня для того, щоб іденти-фікувати як необхідну задачу, так і необхідні дані.
Діалог для всієї системи важко побудувати, використовуючи лише тип діалогу. Для різних частин діалогу залежно від їх конкретних характеристик вибирають найбільш придатний. Так, більшість пакетів використовують мішані структури: WINDOWS, LOTUS 1–2–3, WORD, ТВІР, LEXICON, NORTON COM тощо.
- Основи створення інформаційних систем
- Передмова
- Розділ 1. Основні поняття
- 1.1. Значення та напрямки розвитку інформаційних систем
- 1.2. Основні поняття дисципліни
- 1.3. Класифікація інформаційних систем
- Контрольні запитання
- Розділ 2. Системотехнічні аспекти теорії створення інформаційних систем
- 2.1. Організаційно-економічна модель економічного об’єкта
- 2.2. Мета, задачі та принципи створення інформаційних систем
- Гарантія
- Рис 2.3 Створення іс
- 2.3. Системний підхід до створення інформаційної системи
- 2.4. Декомпозиція інформаційних систем
- 2.5. Надійність та ефективність інформаційних систем
- Розділ 3. Процес створення інформаційної системи
- 3.1. Життєвий цикл інформаційної системи
- 3.2. Трудомісткість стадій створення інформаційної системи
- 3.3. Структура проектної документації
- 3.4. Учасники процесу створення інформаційної системи
- 3.5. Методи та засоби створення інформаційної системи
- 3.6. Технологія створення інформаційної системи
- Контрольні запитання
- Розділ 4. Технологія підготовки загальних рішень щодо створення інформаційної системи
- 4.1. Склад і зміст робіт на стадії «Формування вимог до інформаційної системи»
- 4.2. Склад і зміст робіт на стадії «Розробка концепції інформаційної системи»
- 4.3. Склад і зміст робіт на стадії «Технічне завдання»
- 4.4. Передпроектна документація
- 4.5. Методи і засоби організації збирання та обробки матеріалів обстеження об’єкта
- 4.6. Методи і засоби аналізу матеріалів обстеження
- 4.7. Розробка пропозицій щодо вдосконалення інформаційної системи
- Методика проведення обстеження інформаційної системи
- Контрольні запитання
- Розділ 5. Технологія техноробочого проектування інформаційних систем
- 5.1. Склад і зміст робіт на стадії «Технічний проект»
- 5.2. Склад і зміст робіт на стадії «Робоча документація»
- 5.3. Склад проектної документації на стадіях «Технічний проект» і «Робоча документація»
- Загальносистемні рішення
- 5.5. Розподіл функцій обробки інформації між людиною і еом
- 5.6. Розробка постановки задач
- 5.7. Основні поняття автоматизованого робочого місця
- Контрольні запитання
- Розділ 6. Основні принципи проектування інформаційного забезпечення
- 6.1. Поняття інформаційного забезпечення інформаційних систем
- 6.2. Організація інформаційної бази
- 6.3. Види інформаційних масивів
- 6.4. Методика проектування інформаційного забезпечення
- Контрольні запитання
- Розділ 7. Розробка класифікаторів техніко-економічної інформації
- 7.1. Основні поняття класифікації інформації
- 7.2. Кодування інформації
- 7.3. Класифікатори техніко-економічної інформації
- 7.4. Методика створення класифікаторів
- Контрольні запитання
- Розділ 8. Проектування вихідних і вхідних інформаційних повідомлень
- 8.1. Поняття системи документації
- 8.2. Класифікація форм і методів виведення інформації
- 8.3. Методика проектування форм вихідної інформації
- 8.4. Загальні вимоги до проектування форм первинних документів
- 8.5. Форми побудови зон первинних документів
- 8.6. Сполучення первинних і машинних документів
- 8.7. Методика проектування вхідних інформаційних повідомлень
- Контрольні запитання
- Розділ 9. Проектування зв’язку користувач – пеом
- 9.1. Складові зв’язку користувач – пеом
- Приклад двох діалогів
- 9.2. Процеси введення – виведення
- 9. 3. Діалог
- 9.4. Розміщення даних на екрані дисплея
- 9.5. Підтримка користувача
- Контрольні запитання
- Розділ 10. Впровадження, супроводження та модернiзацiя iс
- 10.1. Організація і планування робіт з уведення в дiю системи
- 10.2. Дослідна експлуатація і введення в дію інформаційних систем
- 10.3. Супроводження і модернізація інформаційних систем
- Контрольні запитання
- Розділ 11. Управління процесами проектування інформаційної системи
- 11.1. Рівні управління проектування інформаційної системи
- 11.2. Контур управління
- 11.3. Структура арм – організатора проектування іс
- 11.4. Розробка текстових і табличних документів
- Відображення логічної моделі документа на його геометричну модель називається алгоритмом формування текстових документів.
- Контрольні запитання
- Розділ 12. Типове проектування інформаційних систем
- 12.1. Загальна характеристика елементного підходу до створення інформаційної системи
- 12.2. Методи елементного проектування інформаційних систем
- 12.3. Суть компонентної технології створення інформаційних систем
- 12.4. Способи прив’язки пакета прикладних програм
- 12.5. Особливості методу об’єктного проектування
- 12.6. Характеристика асу «Сігма»
- Контрольні запитання
- Розділ 13. Автоматизація проектування інформаційних систем
- 13.1. Задачі й принципи автоматизації проектування інформаційних систем
- Особливості сапр іс
- 13.2. Характеристика сапр «марс»
- 13.3. Характеристика сапр «плюс»
- Контрольні запитання
- 14.1. Технологія проектування іс на основі баз даних
- 14.2. Технологія проектування іс на основі використання електронних таблиць
- 14.3. Технологія проектування ssаом
- 14.6 Технологія проектування іс на мережах еом
- 14.7. Об'єктно-орієнтоване проектування іс
- Документи План Оперативний облік Звіти
- Аналіз за рік Оперативний аналіз
- 14.7. Системи управління документацією в іс
- Контрольні запитання
- Навчальне видання
- Основи створення інформаційних систем
- 252057, М.Київ, проспект Перемоги, 54/1.