Помощничек
Главная | Обратная связь


Археология
Архитектура
Астрономия
Аудит
Биология
Ботаника
Бухгалтерский учёт
Войное дело
Генетика
География
Геология
Дизайн
Искусство
История
Кино
Кулинария
Культура
Литература
Математика
Медицина
Металлургия
Мифология
Музыка
Психология
Религия
Спорт
Строительство
Техника
Транспорт
Туризм
Усадьба
Физика
Фотография
Химия
Экология
Электричество
Электроника
Энергетика

Розробка сценарію діалогу



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

Метою розробки сценарію діалогу є:

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

– вибір раціональних шляхів переходу з одного стану діалогу в інший (з поточного в потрібне);

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

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

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

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

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

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

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

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

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

Темп ведення діалогу

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

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

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

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

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

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

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

 

Рекомендації по допустимому часу відповіді інтерактивної системи:

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

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

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

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

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

 

 




Поиск по сайту:

©2015-2020 studopedya.ru Все права принадлежат авторам размещенных материалов.