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

ПОБУДОВА ТА ПРОГРАМНА РЕАЛІЗАЦІЯ МОДЕЛЕЙ, ЩО ВИКОРИСТОВУЮТЬСЯ У ПРОЦЕСІ РОЗРОБКИ ІНТЕРФЕЙСІВ.

 

Мета роботи

 

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

1.2 Методичні вказівки з організації самостійної роботи студентів

 

При підготовці до лабораторної роботи рекомендується повторити лекційний матеріал та ознайомитися з інформацією, яка наведена в [1, стор. 3-27, 2, стор. 15-26 ]

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

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

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

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

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

Якість інтерфейсу оцінюється за такими критеріями:

- наскільки розробники розуміють потреби та завдання користувачів;

- чи є цей продукт результатом ретельно продуманого проектування;

- чи наочно відображені всі особливості продукту;

- наскільки продукт відповідає вимогам практичності та доцільності;

- чи задовольняє використання цього продукту естетичне почуття;

- наскільки інтерфейс може змінюватися при взаємодії з різними особами та групами;

- чи сприяє він спрощенню концептуальної моделі користувача.

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

Підсвідомо користувачі завжди створюють такі моделі, коли починають користуватися будь-яким новим приладом для того, щоб:

- передбачити події;

- знайти причини помічених подій;

- виявити дії, що необхідні для здійснення потрібних змін;

- для забезпечення розуміння аналогічних пристроїв.

Для виявлення моделі користувача існують такі методи збору інформації:

- аналіз завдань користувачів;

- інтерв’ю з потенціальними користувачами;

- спостереження за користувачем у процесі виконання завдання;

- тести придатності.

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

Робота проектувальника подібна роботі архітектора при будуванні оселі (він збирає ідеї майбутнього власника дому («користувача»), уточнює їх, пропонує сучасні матеріали («стандарти проектування та новітні технології»), поєднує ці дані з можливостями будівельників («програмісти») та пропонує конструкцію, яка відповідає будівельним нормам та правилам.

Таким чином, проектувальник є ланкою, що поєднує, та яка розташована в ієрархії на одну сходинку вище над користувачем і програмістом (рис. 1).

 

 

 

Рисунок 1 - Місце моделі проектувальника при розробці програмного інтерфейсу

 

Зміст звіту

Звіт має містити:

- титульний лист;

- мету роботи;

- опис обраної системи, для якої розроблений програмний інтерфейс;

- концептуальна модель користувача

- модель проектувальника програмного інтерфейсу;

- скриншоти програми;

- висновки по роботі.

Мета роботи

Навчитися проектувати інтерфейси з урахуванням методів квантифікації: за допомогою моделі GOMS та законів Хіка і Фітса.

 

2.2 Методичні вказівки з організації самостійної роботи студентів

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

Для кожної задачі, яку необхідно вирішити, завжди існують декілька варіантів рішення. Створення інтерфейсу для заданої проблемної області можливо як за допомогою комбінацій стандартних елементів, так і за допомогою поєднання графічних примітивів, малюнків з технологіями click-to-choose, click-to-activate, drag-and-drop, можливостями Web-інтерфейсів для дескопів або смартфонів.

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

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

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

Знання законів Хіка і Фітса дозволяє кількісно визначити деякі важливі характеристики інтерфейсів.

При підготовці до лабораторної роботи рекомендується повторити лекційний матеріал та ознайомитися з інформацією, яка наведена в [1, стор. 97-124],[ 2, стор. 145-146, 159-179 ]

 

Зміст звіту

Звіт має містити:

- титульний лист;

- мета роботи;

- опис варіантів розроблених інтерфейсів для обраної дії;

- обґрунтування області застосування кожного варіанту;

- скриншоти варіантів;

- розрахунки зробленого квантифікаційного аналізу;

- пояснення застосування у роботі законів Хіка і/або Фітса

- висновки по роботі.

Мета роботи

 

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

 

3.2 Методичні вказівки з організації самостійної роботи студентів

 

При підготовці до лабораторної роботи необхідно повторити матеріал відповідних лекцій та ознайомитися з [1, стор. 72- 101, 145-153, 210-213, ], [2, стор. 202-216]. До лабораторної роботи рекомендується виконати практичне заняття №3.

 

Зміст звіту

 

Звіт має містити:

- титульний лист;

- мету роботи;

- варіант завдання;

- опис обраної системи, для якої розроблений програмний продукт;

- модель користувача або storyboard;

- скриншоти програми;

- обґрунтування обраної кольорової схеми, із числовими значеннями кольорів;

- скриншоти створених піктограм, перелік аналогій або афордансів, що були використані для їх створення;

- числові значення розмірів або координат, які були обрані за принципом «золотого перерізу»;

- наведіть приклади використання/невикористання в розробленій програмі кожного з 10 основних принципів юзабіліті;

- висновки по роботі.

 

Мета роботи

 

Навчитися застосовувати на практиці при розробці інтерфейсів такі методи тестування: когнітивний наскрізний перегляд (контроль), Back-of-the-Еnvelope та евристичний аналіз.

 

4.2 Методичні вказівки з організації самостійної роботи студентів

 

1. При підготовці до лабораторної роботи необхідно повторити матеріал відповідних лекцій та ознайомитися з [Мандел Т. Разработка пользовательского интерфейса: Пер. с англ. –М.: ДМК Пресс, 2001, стор. 112 - 134], [http://hcibib.org/tcuid/chap-4.html (in English)], [http://usethics.ru/service/expert_review/], [ Константайн Л., Локвуд Л. Разработка программного обеспечения: Пер. с англ. - Питер, 2004, стор. 424 - 450 ], http://www.nngroup.com/articles.

 

4.2.1 Важливість тестування на зручність користування ПП

 

Тестування на зручність користування проводиться абсолютною більшістю компаній з розробки програмного забезпечення починаючи з 90-х років минулого сторіччя.

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

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

- інформація, що отримується від користувачів телефоном або електронною поштою, не є достатньою для проведення оцінки якості ПП;

- час, фінанси та людські ресурси, що використовуються в процесі тестування, завжди окупаються;

- програми, що створені з декількох частин, зазвичай, виявляються несумісними;

- проблеми, які виявляються на кінцевій стадії розробки, складніше й дорожче виправляти;

- оцінка зручності використання може дати перевагу над конкурентною розробкою.

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

Спеціалістам відомі багато методів, за допомогою яких на різних етапах можна оцінити зручність використання. Такі перевірки проводяться як самими розробниками без участі користувачів (на етапі прототипів), так і з залученням користувачів з можливої цільової аудиторії (на наступному етапі).

 

Зміст звіту

 

Звіт має містити:

- титульний лист;

- мету роботи;

- опис програмної системи, інтерфейс якої підлягає тестуванню;

- звіт проведеного когнітивний наскрізного перегляду (контролю);

- звіт проведеного Back-of-the-Еnvelope аналізу;

- звіт проведеного евристичний аналізу з поясненням використання або невикористання кожної з 10 евристик,

- перелік з вказівкою (+/-) пунктів з Додатку В;

- висновки по роботі.

 

 

Мета роботи

Навчитися створювати прототипи (у вигляді wireframe) інтерфейсів web-додатків для пристроїв різних розмірів (для смартфону, планшету та ноутбуку)

 

5.2 Методичні вказівки з організації самостійної роботи студентів

 

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

- розмірами екранів;

- можливостями введення даних користувачем;

- сценаріями використання тощо.

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

Ще зовсім недавно дизайнери розробляли свої веб-інтерфейси для стандартного екрану нотбука 1024 на 768. Але тепер існує багато інших розмірів. Так само важливо не призначати елементам фіксовані розміри, неважливо для якого пристрою вони проектуються.

РІШЕННЯМ ДЛЯ ВСІХ ЦИХ ПРОБЛЕМ Є СТВОРЕННЯ РОДИНИ ЕКРАННИХ ФОРМ, ЯКІ В ПРИНЦИПІ СХОЖИ ОДНА НА ІНШУ, АЛЕ «ПРИСТОСОВАНІ» ДО КОЖНОГО ПРИСТРОЮ.

Головна ідея, яка повинна бути реалізована полягає в тому, щоб:

- зробити різним то, що має виглядати по-різному на різних пристроях.

АЛЕ всі варіанти дизайнів все ж повинні бути схожими один на одного, для того, щоб:

 

1) міг бути «відсканованим» брендинг - щоб люди розуміли, що це все таки один і той же сайт;

2) НАЙБІЛЬШ ВАЖЛИВА ПРИЧИНА – User Experience - щоб люди змогли переносити свій колишній досвід і припущення від одного пристрою до іншого.

 

Зміст звіту

 

Звіт має містити:

- адресу сайту та скриншот головної сторінки;

- опис завдання, яке можна виконати за допомогою цього сайту

- скриншоти 2 wireframe-ів, кожен з котрих містить альтернативний варіант дизайну рішення поставленого завдання;

- кожен з wireframe-ів є адаптивним варіантом прототипу дизайну для різних пристроїв (для телефону, планшету або ноутбуку). Кожен з wireframe-ів складається не менш ніж з двох екранних форм.

РЕКОМЕНДОВАНА ЛІТЕРАТУРА

 

 

1. Человеко-машинное взаимодействие: теория и практика. Учебное пособие / О.С. Логунова, И. М. Ячиков, Е.А. Ильина. -Ростов н/Д: Феникс, 2006.-285 с.

2. Раскин Д. Интерфейс: новые направления при проектировании компьютерных систем, Пер. с англ., -СПб: Символ-Плюс, 2006, -272 с.

3. Головач В. В. Дизайн пользовательского интерфейса, 2005. -141 с.

4. Мандел Т.: Разработка пользовательского интерфейса Пер. с англ. –М.: ДМК Пресс, 2001, - 416 с.

5. http://hcibib.org/tcuid/chap-4.html, http://hcibib.org/tcuid/chap-5.html

6. Круг С. Веб-дизайн: книга Стива Круга или «не заставляйте меня думать!», 2-е издание. – Пер. с англ. – СПб: Символ-Плюс, 2008. – 224 с.: цв. ил.

7. Дональд Норман "Дизайн обыденных вещей“ (Donald Norman, Design of everyday things).

8. http://www.nngroup.com/articles

9. About Face 3: the essentional og interaction design / Alan Cooper, Robert Reimann, Dave Cronin, Wiley Publishing, 2007

10. The Inmates Are Running the Asylum / Alan Cooper, Sams Publishing, 2004

11. Buxton William Sketching User Experiences, Morgan Kaufmann Publishing, 2007

 

Додаток А

Можливі варіанти завдань на першу лабораторну роботу:

 

1.	Бронювання місць у театр.
2.	Запис на прийом до зубного лікаря.
3.	Бронювання залізничних послуг.
4.	Підбор гармонійних кольорових схем, підбір одягу,..
5.	АРМ менеджера «Заказ металопластикових вікон»
7.	Створення фоторобота.
8.	АРМ медсестри у лікарняному відділенні.
9.	Підбір варіантів для студії з дизайну штор.
10.	Навчальна система «Англійська мова для малюків».
11.	Ознайомлення з прогнозом погоди.
12.	Система «Вибір туристичної подорожі».
13.	Запис на прийом у посольстві для отримання візи
14.	Бронювання номера в готелі
15.	Навчальна система з астрономії
16.	Автомат для продажу напоїв або товарів*
17.	Переведення чисел з однієї системи в іншу*
	Дистанційне керування кухонними приладами*
	Керування засобом пересування(скутер, літаюча тарілка,..)*
	Ваша власна тема…

* - завдання для однієї людини

 

Додаток Б

Приклад інтерфейсу ПП, моделі якого були розглянуті на лекції

(користувача, програміста та проектувальника)

 

-1-

 

-2-

 

 

 

-3-

 

 

-4-

 

 

-5-

 

-6-

 

-7-

 

-8-

Додаток В

 

Кнопки

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

· Між кнопками, що розміщені поруч, має бути порожній простір, клацання по якому не спрацьовується;

· Недоступні команди не зникають із екрана, а стають заблокованими;

· Частотні кнопки супроводжуються не тільки текстом, але й піктограмами; кнопки, що використовуються рідко - тільки текстовими підписами.

 

 

Поля уведення

· Полях уведення вже мають найбільш імовірні значення;

· Якщо в полі вводиться чисельне значення, границі діапазону виводяться в спливаючій підказці;

· Якщо в полі вводиться чисельне значення з обмеженого діапазону, поле супроводжується Spіnner-ом;

· Довжина полів не менше, і, по можливості, не більше, довжини даних, що вводяться в них.

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

 

Списки

· Списки вже мають найбільш імовірні значення;

· Якщо список містить більше 50 елементів, використовується фільтр або режим пошуку;

· Немає коротких списків (менш п'яти елементів); такі списки представлені як групи радіокнопок або чекбоксів;

· Ширина списків не менше ширини вхідних у них елементів;

· Елементи списку відсортовані; або структурно, тобто по загальних ознаках, або за алфавітом, або по частотності (тільки списки менше 7 елементів);

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

 

Чекбокси й радіокнопки

· Якщо чекбоксів у групі більше 10, вводиться додатковий, що виставляє/знімає всі чекбокси;

· Чекбокси й радіокнопки усередині своїх груп розставлені по вертикалі;

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

 

Взаємодія

· Система, завершивши тривалу операцію (більше мінути роботи), пищить через вбудований динамік комп'ютера;

· Якщо в інтерфейсі не використовується безпосереднього маніпулювання, система не має своїх курсорів. Якщо безпосереднє маніпулювання є, свої курсори застосовуються тільки якщо аналогів з ОС не існує.

 

Клавіатура

· Обробка форми запускається не тільки по натисканню на термінаційну кнопку, але й по натисканню клавіші Enter на кожному полі цієї форми;

· Для найбільш частотних елементів керування (включаючи меню) установлені клавіші швидкого виклику;

· Кожному пункту меню призначені ALT-комбінації (виділені підкресленням);

· ALT-комбінації й гарячі клавіші стандартні;

· Якщо гарячих клавіш більше 40, в інтерфейсі є спосіб їх змінити;

· По натисканню клавіші Tab перехід від елемента до елемента усередині форми здійснюється зверху вниз ліворуч праворуч.

 

Візуалізація

Напрямок тіней у всіх елементах керування має бути однаковим: знизу праворуч.

 

Індикація

Індикація кольором не є єдиною; якщо вона використовується, система супроводжується й іншою індикацією (звук, анімація тощо).

 

Піктограми

· У групах піктограм немає піктограм, за кольором й формою подібних між собою;

· Немає піктограм зі стандартними значеннями, але нестандартними сюжетами.

 

Вікна

· На вікнах, що розтягуються, є індикатор розтягування;

· Заголовки вікон відповідають назвам елементів, за допомогою яких вікна були викликані. Якщо вікно викликається елементом, що не має явної назви, у заголовку вікна відбивається назва екранної форми;

· Тип вікна (модальна, немодальне, можливість мінімізації/максимізації) обирається свідомо, відповідно до завдань користувачів;

· У діалогових вікнах відсутні меню або інструментальні панелі.

 

 

Рядок статусу

· У рядку статусу виводиться інформація тільки про поточний стан системи;

· Індикатори виконання виводяться в рядку статусу. Виключення: «вікна-майcтри», - у них індикатори виконання можна виводити усередині самих вікон.

 

Меню

· Перша буква в назві пунктів меню – заголовна;

· Всі пункти меню першого рівня активізують меню, що розкриваються;

· Використаються не більше двох підрівнів меню;

· Якщо в меню є піктограми, ними супроводжуються тільки самі частотні елементи;

· Елементи, що відкривають вкладені меню, виглядають інакше, чим термінальні елементи.

 

Контекстні меню

· На всіх об'єктах, видимих в інтерфейсі, є специфічне для кожного об'єкта контекстне меню;

· У контекстні меню не більше 10 елементів;

· У контекстні меню елементи відсортовані по убуванню частоти їх використання

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

 

Структура форм інтерфейсу

· У групах інтерактивних елементів (поля форм, елементи меню й т.п.) цих елементів не більше семи;

· Кнопка "Скасування" завжди сама права;

· Багатосторінкові форми мають вказівка на те, що вони багатосторінкові; користувач завжди бачить кількість екранів, що залишилися (приклад: "Екран x з y");

· Якщо у формі є кілька кнопок, одна є кнопкою за замовчуванням. Небезпечні для користувача кнопки не є кнопками за замовчуванням;

· Якщо у вікні є вільне місце, найбільш частотна термінаційна кнопка більше інших;

· Кнопки перебувають у секції, на яку вони роблять безпосередній вплив;

· Термінаційні кнопки (що керують вікном) розташовані або знизу в ряд, або праворуч у стовпчик.

· Кнопки, що впливають на декілька блоків, розташовані за межами цих блоків;

· Якщо вікно або вкладка має автоматично поповнюваний вміст, наприклад, у ньому перераховані повідомлення, що надходять, у назві елемента інтерфейсу, що відкриває вікно або вкладку, виводиться число об'єктів у цьому вікні й окремо число нових об'єктів. Приклад: Документи (3/8);

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

· Підписи до елементів інтерфейсу розміщені одноманітно;

· Недоступні в цей момент елементи інтерфейсу заблоковані, а не сховані;

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

 

Форми введення

· У форми введення є назва;

· У всіх формах, що служать для збору інформації, є пункт "Інше" або подібний;

· Всі поля, обов'язкові для заповнення, позначені, і є відповідне пояснення;

· Багатосторінкові форми уведення мають кнопки "Назад" і "Далі";

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

 

Текст

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

· В інтерфейсі відсутні жаргонізми;

· В інтерфейсі відсутні негативні формулювання (наприклад, чекбокс "Не показувати примітки" неприйнятний, замість нього потрібно виводити чекбокс "Показувати примітки");

· Жоден елемент не називається по-різному в різних місцях (глосарій інтерфейсу не просто зроблений у явній формі, але й вивірений);

· У тексті всіх підтверджень дається найменування об'єкта, над яким відбувається підтверджувана дія;

· Для ясності довгі числа розбиваються нерозривним пробілом по три цифри: 1 234 567;

· Будь-якому списку передує, щонайменше, один абзац тексту;

· У таблицях всі стовпці із цифрами вирівнюються по правому краї;

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

 

 

Додаток Г

 

Варіанти тем, що пропонуються на третю лабораторну роботу:

 

1. Медична навчально-лабораторна система «Визначення групи крові».

2. Система для служби 1562 (фіксування та моніторинг несправностей ЖКХ).

3. Навчально-лабораторна система з флористики «Складання ікебани».

4. Логістична система: відображення, калькуляція та моніторинг вантажів.

5. Комп’ютерна гра для дітей «Виготовлення та оздоблення тортів».

6. Комп’ютерна гра «Автомобільні гонки»./ Умный дом

7. Навчально-лабораторна система з фізики «Закони тяжіння»; (~гра «Tim»).

8. Навчально-лабораторна система «Ландшафтний дизайн».

9. Комп’ютерна гра для дітей «Лабіринт»./ Служба доставки

10. Програмна система для калькуляції витрат (кілометражу,…) та наочного перегляду маршруту туристичної подорожі/походу.

11. Програмна система для бажаючих схуднути (калькуляція та наглядне відображення калорій, що були отримані та/або витрачені, …).

12. Програмна система для обліку даних про студентів (внесення даних, перегляд, формування звітів та документів за критеріями).

13. Програмна система «Конструктор мапи міста/ місцевості».

14. Програмна система «Моделювання систем за допомогою мереж Петрі».

15. Програмна система «Конструктор верстки книг рецептів».

16. Навчально-лабораторна система для молодших школярів «Основи програмування».

17. Програмна система «Інтерактивний музей (музичний, археологічний, художній)»

18. Програмна система «Велопаркування онлайн» або «Міський прокат велосипедів».

19. Ваша власна тема (після її обговорення з викладачем).

Додаток Д

 

Рис Д.1 Подання кольору за допомогою його основних складових

 

Рис Д.2 Яскравість кольору

Рис Д.3 Шкала яскравості кольорів

Суміжно-комплементарна

 

 

Триадна

 

Рис Д.4 Приклади колірних схем

 

Методичні вказівки

до лабораторних робіт

З дисципліни

«ЛЮДИНО-МАШИННА ВЗАЄМОДІЯ»

 

для студентів усіх форми навчання

напряму 6.050103 – Програмна інженерія

 

 

Авторська редакція

 

 

[1] Технологія здачі лабораторної роботи №4 передбачає, що лабораторна робота №3 була захищена на попередньому занятті та.exe+інші файли, необхідні для запуску цієї програми надані викладачу до дати захисту л.р. №4. Таким чином, захистити л.р. № 3 та № 4 на одному занятті неможливо.

ПОБУДОВА ТА ПРОГРАМНА РЕАЛІЗАЦІЯ МОДЕЛЕЙ, ЩО ВИКОРИСТОВУЮТЬСЯ У ПРОЦЕСІ РОЗРОБКИ ІНТЕРФЕЙСІВ.

 

Мета роботи

 

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

1.2 Методичні вказівки з організації самостійної роботи студентів

 

При підготовці до лабораторної роботи рекомендується повторити лекційний матеріал та ознайомитися з інформацією, яка наведена в [1, стор. 3-27, 2, стор. 15-26 ]

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

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

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

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

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

Якість інтерфейсу оцінюється за такими критеріями:

- наскільки розробники розуміють потреби та завдання користувачів;

- чи є цей продукт результатом ретельно продуманого проектування;

- чи наочно відображені всі особливості продукту;

- наскільки продукт відповідає вимогам практичності та доцільності;

- чи задовольняє використання цього продукту естетичне почуття;

- наскільки інтерфейс може змінюватися при взаємодії з різними особами та групами;

- чи сприяє він спрощенню концептуальної моделі користувача.

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

Підсвідомо користувачі завжди створюють такі моделі, коли починають користуватися будь-яким новим приладом для того, щоб:

- передбачити події;

- знайти причини помічених подій;

- виявити дії, що необхідні для здійснення потрібних змін;

- для забезпечення розуміння аналогічних пристроїв.

Для виявлення моделі користувача існують такі методи збору інформації:

- аналіз завдань користувачів;

- інтерв’ю з потенціальними користувачами;

- спостереження за користувачем у процесі виконання завдання;

- тести придатності.

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

Робота проектувальника подібна роботі архітектора при будуванні оселі (він збирає ідеї майбутнього власника дому («користувача»), уточнює їх, пропонує сучасні матеріали («стандарти проектування та новітні технології»), поєднує ці дані з можливостями будівельників («програмісти») та пропонує конструкцію, яка відповідає будівельним нормам та правилам.

Таким чином, проектувальник є ланкою, що поєднує, та яка розташована в ієрархії на одну сходинку вище над користувачем і програмістом (рис. 1).

 

 

 

Рисунок 1 - Місце моделі проектувальника при розробці програмного інтерфейсу