Роздрукувати сторінку
Главная \ Методичні вказівки \ Методичні вказівки \ 5141 Лабораторна робота №4 з курсу HCI на тему Проектування програмного прототипу інтерфейсу застосунку або WEB-сайту

Лабораторна робота №4 з курсу HCI на тему Проектування програмного прототипу інтерфейсу застосунку або WEB-сайту

« Назад

ЗМІСТ

ЛАБОРАТОРНА РОБОТА № 4. ПРОЕКТУВАННЯ ПРОГРАМНОГО ПРОТОТИПУ ІНТЕРФЕЙСУ ЗАСТОСУНКУ АБО WEB-САЙТУ.. 3

Завдання до роботи. 3

Зміст звіту. 3

Контрольні запитання. 3

Варіанти завдань на лабораторну роботу: 3

1. Загальні вимоги до проектування інтерфейсів. 4

2. Видимість стану системи (правило зворотного зв'язку). 4

3. Інформованість користувача. 4

4. Засоби забезпечення зворотного зв'язку. 5

5. Час реакції системи. 6

6. Рівність між системою і реальним світом. 7

7. Свобода дій користувача. 8

8. Послідовність і стандарти. 9

9. Попередження помилок. 10

10. Розуміння краще, ніж запам'ятовування. 11

11. Гнучкість і ефективність використання. 12

12. Естетичний і мінімалістичний дизайн. 13

13. Розпізнавання та виправлення помилок. 13

14. Довідка та документація. 15

ЛАБОРАТОРНА РОБОТА № 4. ПРОЕКТУВАННЯ ПРОГРАМНОГО ПРОТОТИПУ ІНТЕРФЕЙСУ ЗАСТОСУНКУ АБО WEB-САЙТУ

Мета роботи: Дослідити принципи розробки інтерфейсу головних сторінок програмних застосунків, WEB-сторінок і отримати практичні навички розробки.

Завдання до роботи

1. Описати процес навігації по головній сторінці і сторінки з діями лабораторної роботи №3.

2. Описати процес виправлення помилок користувача.

3. Описати засоби помочі (help).

4. Розробити програмний прототип інтерфейсу для графічних макетів з лабораторної роботи №3 з використанням засобів розробки WEB-застосувань або мобільних застосувань або Visual Studio або подібних.

Зміст звіту

1. Тема та мета роботи.

2. Завдання до роботи.

3. Опис процесу навігації по сторінкам.

4. Опис процесу виправлення помилок користувача.

5. Опис засобів помочі (help).

6. Екранні форми навігації і дій користувача.

Контрольні запитання

1. Принципи проектування інтерфейсу по Нільсену.

Варіанти завдань на лабораторну роботу:

1. Бронювання місць у театр;

2. Переклад чисел з однієї системи в іншу;

3. Запис на прийом до зубного лікаря;

4. Керування кухонними приладами;

5. Керування засобами пересування (скутер, літаюча тарілка, …);

6. Підбор гармонійних кольорових схем;

7. Навчальна система "Столиці держав";

8. Створення фоторобота;

9. АРМ медсестри в лікарняному відділенні;

10. Підбір варіантів для студії з дизайну штор;

11. Навчальна система "Англійська мова для малюків";

12. Ознайомлення з прогнозом погоди;

13. Перевірка знань з географії, сольфеджіо, хімії.

14.Ваша власна тема.

1. Загальні вимоги до проектування інтерфейсів

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

2. Видимість стану системи (правило зворотного зв'язку)

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

3. Інформованість користувача

Користувач завжди повинен мати інформацію про поточний статус роботи програми – наприклад, скільки часу пройшло від початку процесу копіювання файлів, коли буде завершено кодування звукової доріжки CD-диска в МРЗ-файл і т. п. Крім цього, користувач обов'язково повинен бачити, до чого призвела будь-яка його дія: введення даних, натискання кнопки і т. п.

4. Засоби забезпечення зворотного зв'язку

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

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

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

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

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

5. Час реакції системи

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

При розробці більшості додатків забезпечення миттєвої реакції на події та дії користувача не представляє ніякої складності. Проте в деяких випадках це може бути складним. Наприклад, багато користувачів просять доповнити існуючий Web-інтерфейс e-mail-інтерфейсом – тобто можливістю управляти системою за допомогою повідомлень електронної пошти. Технічна реалізація цього не представляє складності, однак це ставить під загрозу стабільність роботи системи. Справа в тому, що при управлінні серверним програмним забезпеченням за допомогою e-mail, минає чимало часу між моментом відправки листа і моментом його обробки на сервері. При виявленні помилки (наприклад, запит користувача був сформульований неправильно) сервер висилає користувачеві лист, який буде отримано користувачем ще через деякий час. Таким чином, час реакції стає занадто великим, щоб можна було впевнено працювати зі складним серверним додатком, де будь-яка операція повинна здійснюватися тільки з урахуванням того, що всі попередні завершені успішно.

6. Рівність між системою і реальним світом

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

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

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

Однак таке запозичення ідей з навколишнього світу потрібно робити дуже обережно. Справа в тому, що програми, які вже знайомі користувачеві - теж частина його світу, частина його знань, навичок і звичок. Тому деякі деталі комп'ютерних інтерфейсів є для користувачів більш звичними, ніж об'єкти реального світу - це особливо стосується елементів інтерфейсу, що реалізують функції, які не мають прямих аналогів у реальному світі. Як приклад можна навести відомий мультимедійний програвач WinAmp. Для управління відтворенням музичних композицій програма використовує кнопки Play, Stop, Pause і ін, дуже нагадують аналогічні за призначенням кнопки на програвачах, що стоять в наших квартирах. Але от кнопка, розташована праворуч від них, яка на "справжньому" пристрої відкриває лоток CD-плеєра, в WinAmp, всупереч очікуванням, не відкриває лоток CD-ROM- дисководу, а викликає вікно Відкрити файл. Це дещо збиває з пантелику, тому що в дуже багатьох аналогічних комп'ютерних програмах така кнопка якраз служить для відкриття / закриття лотка дисковода CD-ROM.

Тому інтерфейси, які повністю, тобто без будь-яких винятків, копіюють об'єкти реального світу, майже завжди в результаті виходять не дуже зручними, тому що користувач витрачає досить багато часу, намагаючись освоїти абсолютно новий інтерфейс. Наприклад, експеримент компанії IBM в області інтерфейсів, які використовують в якості своєї основи моделі реальних матеріальних об'єктів - програма RealPhone, вважається повним провалом: число проблем, що виникають при освоєнні "реального телефону", дуже велике.

7. Свобода дій користувача

 Користувач повинен мати контроль над системою і можливість змінити поточний стан програми. Дуже часто користувач дає різні команди помилково (наприклад, випадково натиснувши не ту кнопку або "промахнувшись" мишею повз потрібний пункт меню), і у нього повинен бути "аварійний вихід" з цієї ситуації, чітко позначений у програмі. Найчастіше такий "вихід" реалізується у вигляді кнопки Cancel (Скасувати), розташованій в діалоговому вікні і дозволяє припинити виконання поточної операції або закрити це діалогове вікно. Крім цього, натискання на клавішу <Escape> є традиційним і тому звичним для більшості користувачів засобом "аварійного виходу". Характерно, що "escape" у перекладі з англійської означає "втеча, догляд". Вона також незамінна тоді, коли кнопка Cancel (Скасувати) недоступна - найчастіше за все в Головному вікні програми, адже розміщення кнопок OK, Cancel, Help і інших тут, на відміну від діалогових вікон, не допускається. Зокрема, Microsoft Word при виконанні трудомістких і тривалих за часом операцій, наприклад читання дуже великих файлів, виводить у рядок стану індикатор, що відображає хід процесу і повідомлення:

"Для скасування натисніть <Escape>. Клавіша <Escape> аналогічно працює і в Adobe Photoshop, дозволяючи перервати завантаження великого файлу або виконання складного фільтра, і в багатьох інших додатках.

Гарним тоном вважається, якщо дозволяє поточна ситуація, поєднувати обидва ці способи - кнопку Cancel (Скасувати) і клавішу <Escape>: Сучасні системи розробки додатків для Windows при проектуванні форм діалогових вікон дозволяють призначити кнопці властивість спрацьовування при натисканні клавіші <Escape>. Як наслідок, для користувача звичайною дією при попаданні в ситуацію, з якої йому скоріше хочеться вибратися, є саме натискання клавіші <Escape>. Що може бути простіше: не потрібно шукати очима якусь там кнопку Cancel (Скасувати), досить вдарити по клавіші у верхньому лівому куті клавіатури - і готово!

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

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

8. Послідовність і стандарти

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

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

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

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

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

9. Попередження помилок

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

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

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

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

10. Розуміння краще, ніж запам'ятовування

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

"Почніть роботу з натискання цієї кнопки".

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

11. Гнучкість і ефективність використання

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

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

Розробники системи програмування Microsoft Quick Basic, яка була дуже популярна ще у вісімдесятих і на початку дев'яностих років, пішли ще далі: вони передбачили два варіанти головного меню програми: повний і скорочений, між якими можна перемикатися одним клацанням.

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

Ще одна складова частина правила "Гнучкість і ефективність використання" - необхідність надавати користувачеві можливість швидкого виконання дій, що часто повторюються. Варіанти реалізації цього дуже різноманітні: це і вже згадувані "гарячі клавіші", і команди для виклику останніх відкритих файлів, і меню, у яких спочатку показуються найбільш часто виконувані команди, і макроси, і навіть цілі мови програмування, що вбудовуються в додатки, зразок Visual Basic for Applications в продуктах сімейства Мicrosoft Office.

12. Естетичний і мінімалістичний дизайн

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

13. Розпізнавання та виправлення помилок

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

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

Найпростіше рішення - створити в довідковій системі програми відповідний розділ, що роз'яснює зміст проблеми та причини її виникнення. У самому ж діалоговому вікні з повідомленням про помилку може бути присутнім кнопка «Довідка» для виклику цього розділу. Чисто технічно реалізувати це дуже просто: у сучасних системах програмування для створення таких дружніх повідомлень про помилки достатньо при виклику функції MessageBox вказати прапорець наявності кнопки «Довідка» та ідентифікатор відповідного розділу довідки. А ось складання детальних описів помилок, яких, до того ж, може бути дуже багато, для shareware- програмістів набагато більш нудне і неприємне заняття.

Ще один приклад вирішення даної проблеми є кнопка «Детальніше», при натисканні на яку діалогове вікно з повідомленням про помилку "розгортається", відображаючи більш докладну інформацію про причини виникнення збою. Таким чином, наприклад, організовані повідомлення про помилки в 32-розрядних версіях Windows, найвідоміше з яких - "Програма виконала неприпустиму операцію і буде закрита". За кнопкою «Детальніше» в цьому повідомленні ховається ім'я програми-винуватця, а також адреса місця виникнення помилки.

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

На жаль, такі витончені повідомлення про помилки в прикладних програмах для Windows зустрічаються не дуже часто, тому що їх включення вимагає хоча і нескладної, але кропіткої роботи. Дуже важливо пам'ятати те, що повідомлення про помилку мусить утримувати її опис нормальною людською мовою, а не її числовий код. Деякі програмісти цілком серйозно вважають, що такі лаконічні повідомлення, в стилі відомого в Інтернеті "Error 404", справляють на користувача незабутнє враження: чим "загадковіше" програма, тим вона складніша і, в кінцевому підсумку, "крутіше". Але, насправді, ефект схожий на той, що був вже описаний вище: незрозумілі помилки виникають тільки в неякісних виробах.

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

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

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

14. Довідка та документація

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

З повагою ІЦ "KURSOVIKS"!