МЕТОДИЧНА РОЗРОБКА відкритого заняття СКЛАДОВІ ЧАСТИНИ ПРОГРАМНОГО ІНТЕРФЕЙСУ. ЕЛЕМЕНТИ УПРАВЛІННЯ

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

МАРІУПОЛЬСЬКИЙ МАШИНОБУДІВНИЙ КОЛЕДЖ

ДЕРЖАВНОГО ВИЩОГО НАВЧАЛЬНОГО ЗАКЛАДУ

«ПРИАЗОВСЬКИЙ ДЕРЖАВНИЙ ТЕХНІЧНИЙ УНІВЕРСИТЕТ»

МЕТОДИЧНА РОЗРОБКА

відкритого заняття

СКЛАДОВІ ЧАСТИНИ ПРОГРАМНОГО ІНТЕРФЕЙСУ.

ЕЛЕМЕНТИ УПРАВЛІННЯ

з дисципліни «Людино-машинний інтерфейс»

Галузь знань: 0501 «Інформатика та обчислювальна техніка»

Спеціальність: 5.05010301 «Розробка програмного забезпечення»

2015

Методична розробка відкритого заняття за темою «Складові частини програмного інтерфейсу. Елементи управління» з дисципліни «Людино-машинний інтерфейс». Підготувала М.В. Галла – викладач другої категорії Маріупольського машинобудівного коледжу ДВНЗ «ПДТУ».

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

Для викладачів навчальної дисципліни «Людино-машинний інтерфейс» вищих навчальних закладів 1-2 рівнів акредитації.

Рецензенти:

Демидова Л.М. – викладач вищої математики, спеціаліст вищої категорії Маріупольського машинобудівного коледжу ДВНЗ «ПДТУ»

Кондрашов В.М. – викладач, спеціаліст вищої категорії Маріупольського машинобудівного коледжу ДВНЗ «ПДТУ»

Розглянуто та схвалено на засіданні циклової комісії «Програмна інженерія» ММК ДВНЗ «ПДТУ» (протокол № ___ від ___.___.20___ р.)

ЗМІСТ

Вступ	4
План заняття	6
Хід заняття	8
Додатки
Додаток А Тестове завдання з теми «Критерії якості інтерфейсу»	11
Додаток Б Ключ до тесту	12
Додаток В Критерії оцінювання тестового завдання	13
Додаток Г Конспект лекції	14
Додаток Д Домашнє завдання	33

ВСТУП

Дисципліну «Людино-машинний інтерфейс» студенти коледжу вивчають в останньому семестрі на останньому курсі. Створення якісного людино-комп’ютерного інтерфейсу, який можна назвати точкою зв’язку між людиною і комп’ютером, є кінцева мета вивчення цієї дисципліни.

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

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

Вивчення предмета базується на знаннях, які отримали студенти з основ інформатики, основ програмування, комп’ютерних мереж і проводиться у зв’язку з предметами спеціального циклу: «Основи програмної інженерії», «Конструювання програмного забезпечення», «Інструментальні засоби візуального програмування».

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

Заняття за темою «Складові частини програмного інтерфейсу. Елементи управління» (2 години) систематизує, узагальнює знання та вміння студентів вірно розташовувати елементи меню та вікон на них та придавати візуальному інтерфейсу естетичного дизайну та логічно завершеного виду. Від дизайну інтерфейсу програмного продукту залежить зручність використання програми, підвищує ефективність роботи з нею, що в кінцевому підсумку призводить до успіху розробленого додатка. У користувача повинно бути повне розуміння для чого призначений той чи інший елемент керування. Які елементи активні і неактивні, які можна переміщати, а які ні і т.п. Добре розроблений інтерфейс легко і швидко запам’ятовується користувачем. Варто знати, що нехтування візуальним оформленням програми призводить до того, що додаток виглядає непрофесійно, робота з нею незручна, що веде до подразнення користувача і осуд розробника.

У результаті вивчення зазначеної теми студенти повинні:

знати:

• основні принципи розробки користувацького інтерфейсу;

• властивості людино-машинного інтерфейсу;

• пріоритетні напрямки застосування набутих знань у своїй спеціальності.

вміти:

• застосовувати набуті знання у навчальному процесі та на виробництві;

• аналізувати та проектувати якісний людино-машинний інтерфейс;

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

ПЛАН ЗАНЯТТЯ

Навчальна дисципліна: Людино-машинний інтерфейс

Курс: ІІ

Група: РПЗ 13-02 ПП

Дата: 18.02.2014

Час: згідно з розкладом.

Тема заняття: Складові частини програмного інтерфейсу. Елементи управління

Мета заняття:

Методична: удосконалення методики проведення лекції з формування уміння і навичок оформлення користувальницького інтерфейсу.

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

Виховна: вміння презентувати свої знання, формувати інформаційну компетентність, виховувати акуратність, уважність, ввічливість і дисциплінованість, підвищення рівня відповідальності студента за якісне навчання

Вид заняття: лекція

Тип заняття: Інструктивна лекція.

Форма і методи контролю: фронтальне опитування, самостійна робота, мультимедійні презентації.

Міжпредметні зв’язки:

Забезпечуючи: Основи програмування та алгоритмічні мови, Конструювання програмного забезпечення

Забезпечувані: Об’єктно-орієнтоване програмування, Інструментальні засоби візуального програмування, Дипломування

Методичне забезпечення: робоча програма з дисципліни, план заняття, конспект (Додаток Г), роздатковий матеріал (тестове завдання), мультимедійні презентації з повторення теми.

Обладнання: мультимедійний проектор, екран, комп’ютер, хмарна технологія dropbox.com, соціальна мережа twitter.com

Література:

Базова:

1. Ганеев, Р. Проектування інтерфейсу користувача засобами Win32 API / Р. Ганеев. - 2-е вид. - М: Гаряча Лінія - Телекому, 2007. – 360 с.

2. Гультяев, А. Проектування та дизайн користувальницького інтерфейсу / А. Гультяев, В. Машин. - 2-е вид. - СПб .: КОРОНА-принт, 2007. - 352 с.

3. Мандел, Т. Дизайн інтерфейсів / Т. Мандел. - М: ДМК 2005. – 416 с.

4. Тідвелл, Дж. Розробка користувальницького інтерфейсу / Дж. Тідвелл. - СПб .: Питер, 2008. - 416 с.

5. Флоренсов, А. Програмування для графічного інтерфейсу. Семантичний підхід: навч. посібник / А. Флоренсов. - Омськ: Видавництво ОмГТУ. - 2003. - 128 с.

Додаткова:

1. Гук, М. Апаратні інтерфейси ПК / М. Гук. - СПб: Пітер, 2002. – 528 с.

2. Гук, М. Інтерфейси пристроїв зберігання: ATA, SCSI і інші. Енциклопедія / М. Гук. - СПб: Питер, 2006. - 448 с.

3. Раскін, Дж. Інтерфейс: нові напрямки в проектуванні комп'ютерних систем / Дж. Раскін. - СПб: Символ-Плюс, 2003. - 272 с.

4. Торрес, Р. Практичний посібник з проектування та розробки користувальницького інтерфейсу / Р. Торрес. -М: Вільямс, 2002. - 400 с.

Інтернет ресурси:

1. Історія створення і розвитку графічного інтерфейсу користувача. Електронний ресурс http://toastytech.com/guis/guitimeline.html. Вільний доступ. Мова англійська

ХІД ЗАНЯТТЯ

1 Організаційний момент

1.1 Підготовка аудиторії до заняття

1.2 Привітання студентів

1.3 Перевірка наявності студентів і їх готовності до заняття.

2 Ознайомлення студентів з темою та навчальними цілями заняття (план заняття)

2.1 Тема: Складові частини програмного інтерфейсу. Елементи управління

2.1.1 Меню. Типи меню. Пристрій меню. Групування елементів.

2.1.2 Вікна. Типи вікон. Елементи вікна. Вкладки.

2.2 В результаті вивчення теми студент повинен:

знати:

• основні принципи розробки користувацького інтерфейсу;

• властивості людино-машинного інтерфейсу;

• пріоритетні напрямки застосування набутих знань у своїй спеціальності.

вміти:

• застосовувати набуті знання у навчальному процесі та на виробництві;

• аналізувати та проектувати якісний людино-машинний інтерфейс;

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

3 Мотивація навчання (може проводитися як до актуалізації, так і після неї. Вказується значущість теми у майбутній професійний діяльності; наводяться дані, спрямовані на формування позитивної мотивації, пізнавального інтересу до що вивчається)

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

4 Актуалізація опорних знань

4.1 Самостійна робота у вигляді тестового завдання з теми «Критерії якості інтерфейсу» (Додаток А).

Після виконання завдань студенти обмінюються самостійними роботами й здійснюють взаємооцінювання згідно з правильними відповідями та критеріями оцінювання. (Додаток Б, Додаток В).

4.2 Фронтальне опитування студентів за раніше вивченими поняттями

4.2.1 Кнопки та їх оформлення. Стани кнопок.

4.2.2 Чекбокси і радиокнопки. Взаємодія з ними.

4.2.3 Списки. Види списків. Комбобокси.

4.2.4 Поля введення та вимоги до них.

4.2.5 Смуги прокрутки, повзунковий регулятор, крутилки.

Питання 4.2.5 розкриває викладач.

СМУГИ ПРОКРУТКИ

С

Рисунок 1 - Компоненти смуги прокрутки

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

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

Якщо при виконанні прокрутки користувач утримує курсор на стрілці при натиснутій кнопці миші, переміщення інформації повинно виконуватися до тих пір, поки що кнопка не відпущена.

Повзунок виконує дві основні функції:

• відображає розмір і розташування у вікні фрагмента, що проглядається, щодо меж всього документа;

• служить засобом прискореної прокрутки інформації.

ПОВЗУНКОВИЙ РЕГУЛЯТОР

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

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

Повзунковий регулятор складається з шкали, яка визначає діапазон можливих значень регульованої величини, і індикатора, положення якого показує поточне значення величини (рис. 2); індикатор використовується також для установки нового значення.

Рисунок 2 - Повзунковий регулятор

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

Для повзункового регулятора підтримуються багато які додаткові параметри налаштування: орієнтація (вертикальна або горизонтальна), розміри індикатора, дискретність зміни величини і т.д. (рис.3).

Рисунок 3 - Приклади повзунків. Видно, що кількість параметрів
в повзунку може бути досить значним.

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

КРУТІЛКИ

Крутілка (spinner, little arrow) є поле введення, не дозволяє вводити текстові дані, але зате володіє двома корисними можливостями.

Рисунок 4 - Крутилка.

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

5 Коментар відповідей та робіт студентів

6 Запис плану лекції (тези або конспект лекції) та викладення (вивчення) нового матеріалу (Додаток Г)

7 Коментар роботи студентів

Виставлення оцінок.

8 Підсумок заняття

Тема заняття актуальна тому що вам знадобляться знання та вміння з вивченої теми. Мета заняття досягнута, знання узагальнені

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

9 Домашнє завдання

Мета домашнього завдання - узагальнити наявні знання та отримати знання що випереджають з наступної теми. (Додаток Г).

Посилання у Twitter: #РПЗ-13-02 Домашнее задание 18.02.2015 https://www.dropbox.com/sh/hkkysjc73b5o5b6/AADbGycFAreipf-UyGPNJD2ba?dl=0 …

Посилання у Facebook: #‎РПЗ‬-13-02 Домашнее задание 18.02.2015 https://t.co/TH7F1IGVSp

Додаток А

Тестове завдання з теми «Критерії якості інтерфейсу»

ПІБ______________________Група________________Дата______________

Тестові питання можуть містити одну і більше правильних відповідей.

Якщо позначені не всі правильні відповіді, бал за питання не зараховується.

1. Перерахувати основні критерії якості інтерфейс

1. Швидкість роботи користувачів;

2. Кількість людських помилок;

3. Швидкість навчання користувача;

4. Ергономічність і читаність;

5. Суб'єктивне задоволення користувачів;

6. Надійність і коректність.

2. Перерахувати типи помилок

1. Помилки, викликані недостатнім знанням предметної області;

2. Логічна помилка;

3. Не зчитування показань системи;

4. Моторні помилки;

5. Опечатки;

6. Втрата фокусу уваги.

3. Чи вірно твердження - Час досягнення мети обернено пропорційно розміру мети і дистанції до мети

1. Так; б) Ні.

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

1. Так; б) Ні.

5. Втрата фокусу уваги пов'язана:

1. З тим, що у людини є кілька фокусів уваги;

2. З тим, що у людини один фокус уваги;

3. З наявністю зовнішніх відволікаючих чинників;

4. З непрацездатністю програми.

6. Взаємодія користувача з системою складається з декількох кроків, скільки цих кроків:

1. 2;

2. 5;

3. 6;

4. 10;

5. 7.

7. Чого потрібно уникати при розробці інтерфейсу:

1. Уникати яскравих кольорів;

2. Уникати розробки інтерфейсу;

3. Уникати гострих кутів у візуальному оформленні інтерфейсу;

4. Намагатися зробити інтерфейс максимально більш легким і повітряним;

5. Уникати великої кількості елементів, які повторюються.

Додаток Б

Ключ до тесту

№ питання	Вірні відповіді
1	а), б), в), д)
2	а), в), г), д)
3	а)
4	б)
5	б), в), г).
6	д)
7	а), в), д)

Додаток В

Критерії оцінювання тестового завдання

Оцінка	Кількість вірних відповідей
«5 (відмінно)»	7
«4 (добре)»	5-6
«3 (задовільно)»	4
«2 (незадовільно)»	4

Додаток Г

Конспект лекції з теми

«Складові частини програмного інтерфейсу. Елементи управління»

Меню

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

Типи меню

Існують декілька різних таксономій меню, але основний інтерес представляють лише дві з них. Перша таксономія ділить меню на два типи:

- Статичні меню, тобто меню, постійно присутні на екрані. Характерним прикладом такого типу меню є панель інструментів.

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

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

Друга таксономія також ділить меню на два типи:

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

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

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

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

Влаштування меню

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

Влаштування окремих елементів

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

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

Піктограми в меню.

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

Не постачайте піктограмами всі елементи меню, постачайте тільки найважливіші

Елементи, що перемикаються.

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

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

Передбачуваність дій.

Користувачів потрібно постачати почуттям контролю над системою. Стосовно до меню це означає, що по виду елемента користувачі повинні здогадуватися, що станеться після вибору. Зробити це неймовірно важко, оскільки на екрані немає місця під такі підказки. Можна зробити тільки одне, але зробити це потрібно обов'язково: потрібно показати користувачам, який елемент запускає дію або змінює параметр, а який відкриває вікно c продовженням діалогу. Майже у всіх ОС стандартним індикатором продовження діалогу є три крапки після тексту елемента, так що користуватися цією ознакою варто скрізь, включаючи інтернет. Також необхідно показувати, який елемент спрацьовує відразу, а який відкриває елементи меню нижнього рівня (в будь ОС це робиться автоматично, в Інтернеті потрібно не забувати робити це вручну).

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

Угрупування елементів

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

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

Як угруповувати елементи

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

Як розділяти групи між собою.

Існує два основних способи розділяти групи: між групами можна поміщати порожній елемент (роздільник) або ж розміщувати окремі групи в різних рівнях ієрархії. Другий спосіб створює більш чіткий поділ: в меню Файл, наприклад всі елементи більш близькі один одному (незважаючи на роздільники), ніж елементи інших меню. У той же час вибір конкретного способу диктується результатами карткового сортування, так що інтерес представляє тільки питання «як повинні виглядати і діяти роздільники».

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

Глибина меню.

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

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

1 Вибираючи елемент першого рівня, він вибирає елемент, «потрібність» якого здається йому максимальною.

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

3 Якщо жоден з елементів не здається користувачеві досить імовірним, користувач повертається на перший рівень.

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

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

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

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

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

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

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

Не робіть контекстні меню єдиним способом виклику якої-небудь функції

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

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

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

Вікна

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

Типи вікон

Сучасна наука знає кілька типів вікон, а саме:

- Головні вікна програми

- Вікна документа

- Режимні діалогові вікна

- Безрежімние діалогові вікна

- палітри

-вікна браузера (оскільки використовувана в інтернеті технологія істотно відрізняється від технології ПО, цей тип вікон стоїть дещо окремо).

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

Недовга історія вікон на екрані

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

Типи вікон на прикладі MS Word.

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

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

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

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

Уникайте режимів роботи

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

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

Приклад палітри з програми Adobe PageMaker.

Як легко здогадатися, проблема була знайдена і в палітрах. Існує неформальний, але напрочуд вірний закон, який говорить, що суб'єктивна важливість інформації, що перекривається діалоговим вікном (палітрою зокрема), не залежить ні від розмірів, ні від положення вікна, а залежить тільки від периметра. В результаті постійно виявляється, що користувачі, намагаючись відкрити потрібну інформацію, перекладають вікна з місця на місце, що знижує продуктивність (несуттєво) і суб'єктивне задоволення (суттєво). При цьому якщо зробити палітру маленькою, знизиться ймовірність її вимушеного перетягування, але зате виросте суб'єктивне незадоволення від її перетягування («така маленька, а так дратує»). Більше того. Набагато частіше виявляється так, що палітра перекриває не всю потрібну інформацію, але її частину; при цьому все одно палітру доводиться переміщати. Єдиним способом позбутися цього ефекту є зменшення периметра палітри, а досягти цього можна, тільки прикріпивши палітри до краю екрана.

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

Паралельно з народженням складних панелей інструментів відбувається ще одна драма боротьби за виживання. Вікна документів вимирають. Вимирають вони з двох простих причин. По-перше, вони погано узгоджуються з ментальної моделлю більшості користувачів. По-друге, неможливо придумати скільки-небудь ефективних способів перемикатися між ними. Найефективніший (з точки зору розробників операційної системи, зрозуміло) спосіб звичайно віддається переключенню між програмами, відповідно, переключенню документів дістається свідомо найгірший спосіб. У Windows, через різнобій у способах перемикання між документами (оскільки всі розробники самостійно намагалися знайти якийсь прийнятний або неприйнятний спосіб), виникають казуси: у MS Word, наприклад, для клавіатурного перемикання між документами використовується комбінація клавіш Ctrl + F6. Спробуйте використовувати цю комбінацію клавіш однією рукою, і ви зрозумієте, що це неможливо.

Для того щоб запустити дві однакові програми, кожна з одним документом всередині, не вистачало ресурсів комп'ютера, от і доводилося запускати одну програму з двома документами. Зараз, навпаки, пам'яті достатньо, до того ж з'явилися технології програмування, що дозволяють ні про що таке навіть не думати. Так що вікна документів поступово стають непотрібними.

Елементи вікна

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

Рядок заголовка вікна

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

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

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

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

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

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

Панелі інструментів

Всі панелі мають такі переваги:

- Вони дозволяють користувачам швидко викликати потрібні функції мишкою

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

- Вони підвищують візуальне багатство інтерфейсу

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

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

Панель інструментів небажано робити єдиним способом виклику функції

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

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

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

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

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

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

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

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

Смуги прокрутки і їх альтернатива

Коли графічних інтерфейсів ще не було, користувачі переміщалися по документу за допомогою клавіатури. З тих далеких часів на клавіатурі залишилися клавіші Home і End, так само як Page Up і Page Down. В цілому, користувачі були задоволені своєю долею. Потім з'явилися графічні інтерфейси. Насамперед були придумані смуги прокрутки. На жаль, виявилося, що вони працюють не дуже добре.

Проблема смуг прокрутки полягає в наступному: для маленьких документів вони не дуже потрібні, оскільки користувачам, що тримає руки на клавіатурі, набагато легше переміститися до потрібного фрагмента за допомогою клавіш зі стрілками. Навпаки, у великих документах мале переміщення повзунка приводить до істотного зрушення області перегляду, так що після переміщення потрібно ще й підправляти або клавіатурою, або стрілками на смузі прокрутки. Більше того: у багатьох випадках неможливо реалізувати динамічну зміну області перегляду під час переміщення повзунка, а значить, переміщатися по великих документам доводиться в кілька кроків. І ще раз більш того: припустимо, що це динамічна зміна все-таки є. Тоді користувачеві потрібно: спершу перевести погляд на повзунок, потім курсор на повзунок, потім погляд на документ і тільки потім, переміщаючи мишу вгору або вниз, стежити за областю перегляду, на тему «чи не час відпустити курсор».

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

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

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

Смуги прокрутки без індикації розміру документа практично марні

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

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

З появою мишей з коліщатками, смуги прокрутки сміливо можна зробити тонше

На жаль, зовсім не використовувати смуги прокрутки в ПО важко, MS Windows User Experience прямо змушує розробника ними користуватися. В інтернеті ситуація інша - ніхто нікого не змушує. Залишилося розібратися, як же зробити гортання документа ідеальним.

Якщо все-таки доводиться залишати смуги прокрутки, вкрай бажано домогтися декількох властивостей смужок:

- Розмір повзунка повинен показувати загальний обсяг перегортати документа.

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

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

- Необхідно забезпечити обробку похибки переміщення курсора. Коли користувач курсором переміщає повзунок, а дивиться в цей час на документ, курсор може зійти з смуги. До певного моменту (зміщення на 30-70 пікселів) система повинна таке зміщення ігнорувати.

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

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

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

Приклад читаємого вікна.

Читається він таким чином: «Текст вирівнюється по лівому краю, рівень п'ятий, відступ зліва 3 см, праворуч 0 см, перший рядок немає, на 5 і так далі».

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

Вікно має читатися, як текст

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

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

Збільшуємо площу

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

Перша вкладка і інші вкладки. Крім уміщених максимальної кількості елементів управління в діалоговому вікні, вкладки можуть виконувати ще одну роль, а саме приховувати від недосвідчених користувачів не дуже потрібну їм функціональність. Проблема полягає в тому, що коли потрібно просто вмістити у вікно побільше елементів, вкладки приховують від користувачів функціональність, можливо, що і потрібну. Колись в Windows було два способи помістити в діалогове вікно більше, ніж у нього могло влізти. Можна було скористатися вкладками, а можна було натиснути на спеціальну кнопку, яка збільшувала розмір вікна і відкривала досі приховані елементи управління. Microsoft ці кнопки перестала подобатися і, починаючи з Windows 95, вона планомірно видалила їх з усіх своїх продуктів, замінивши вкладками. Це і породило проблему. Раніше різні вкладки містили приблизно однаково важливі елементи, просто не всі вміщувалися в одне вікно, а кнопка з трикутником приховувала елементи, про які починаючий користувач твердо знав, що вони йому не потрібні або користуватися ними небезпечно. Тепер все у вкладках, тому користувачі часто впевнені, що відразу невидно небезпечно.

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

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

Схоже, що Microsoft сама усвідомила шкоду від втрати зростаючих вікон, викликаний недовірою користувачів до вкладок.

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

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

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

Існує і третій спосіб вирішення проблеми - можна просто прибрати вкладки, замінивши їх списком. Цей спосіб теж не дуже хороший, оскільки не надто візуальний і до того ж порівняно повільний.

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

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

Не старайтесь рассортировать элементы так, чтобы в каждой вкладке их был одинаковое количество

Термінаційні кнопки. У діалоговому вікні з вкладками термінаційні кнопки обов'язково повинні розташовуватися поза області вкладок.

Переміщення в межах вікна

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

З клавіатурою складніше. Користувач може переміщатися між елементами управління двома різними способами: клавішею Tab і гарячими клавішами. Переміщатися клавішею Tab повільно, але зате для цього не потрібно звертатися до пам'яті або видивлятися клавіатурну комбінацію для потрібного елемента. Навпаки, гарячі клавіші дозволяють швидше переміщатися вглиб екрану, але вимагають запам'ятовування клавіш. Таким чином, користувачі, які часто вводять дані в який-небудь екран, намагаються використовувати клавішу Tab і тільки зрідка користуються гарячими клавішами. Відповідно, будь-яка форма введення, якої часто користуються, зобов'язана коректно працювати з Tab, при цьому бажано, щоб вона працювала і з гарячими клавішами.

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

Послідовні вікна

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

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

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

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

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

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

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

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

Додаток Д

Домашнє завдання

Підготуватися до самостійної роботи за темою «Складові частини програмного інтерфейсу. Елементи управління»:

• Вікна;

• Меню;

• Кнопки.

Поверхнево ознайомитися з поняттями:

1 Основні етапи розробки

2 Первісне проектування

3 Створення прототипу

В зошит законспектувати:

4 Тестування і модифікація прототипу

Бажаючи отримати додаткову оцінку можуть підготувати реферат на тему: «Процес розробки інтерфейсу»

32