
- •1. Передумови
- •1.1. Визначення інтерфейсу
- •1.2. Простої повинне залишатися простим
- •1.3. Орієнтація на людину і на користувача
- •1.4. Інструменти, що перешкоджають новим ідеям
- •1.5. Розробка інтерфейсу як частина загального циклу розробки
- •1.6. Визначення человекоориентированного інтерфейсу
- •2. Когнетика і локус уваги
- •2.1. Ергономіка і когнетика: що ми можемо і чого не можемо
- •2.2. Когнітивне свідоме і когнітивне несвідоме
- •2.3. Локус уваги
- •2.3.1. Формування звичок
- •2.3.2. Одночасне виконання задач
- •2.3.3. Сингулярность локусу уваги
- •2.3.4. Джерела локусу уваги
- •2.3.5. Експлуатація єдиного локусу уваги
- •2.3.6. Поновлення перерваної роботи
- •3.2. Режими
- •3.2.1. Визначення режимів
- •3.2.2. Режими, користувальницькі настроювання і тимчасові режими
- •3.2.3. Режими і квазирежимы
- •3.3. Моделі "іменник-дієслово" і "дієслово-іменник"
- •3.4. Видимість і заможність
- •3.5. Монотонність
- •3.6. Міф про дихотомію "новачок-експерт"
- •4.2. Модель швидкості печатки goms
- •4.2.1. Тимчасові інтервали в інтерфейсі
- •4.2.2. Розрахунки по моделі goms
- •4.2.3. Приклади розрахунків по моделі goms
- •4.2.3.1. Інтерфейс для Хола: варіант 1. Діалогове вікно
- •4.2.3.3. Інтерфейс для Хола: варіант 2
- •4.3.1. Продуктивність інтерфейсу для Хола
- •4.3.2. Інші рішення інтерфейсу для Хола
- •4.4. Закон Фитса і закон Хика
- •4.4.1. Закон Фитса
- •4.4.2. Закон Хика
- •5.1. Уніфікація й елементарні дії
- •5.2. Каталог елементарних дій
- •5.2.1. Підсвічування, вказівка і виділення
- •5.2.2. Команди
- •5.2.3. Екранні стани об'єктів
- •5.3. Імена файлів і файлові структури
- •5.4. Пошук рядків і механізми пошуку
- •5.4.1. Роздільники в шаблоні пошуку
- •5.4.2. Одиниці взаємодії
- •5.5. Форма курсору і методи виділення
- •5.7. Ліквідація додатків
- •5.8. Команди і трансформатори
- •6.1. Інтуїтивні і природні інтерфейси
- •6.2. Поліпшена навігація: ZoomWorld
- •6.3. Піктограми
- •6.4. Способи і засоби допомоги в человекоориентированных інтерфейсах
- •6.4.1. Вирізувати і вставити
- •6.4.2. Повідомлення користувачу
- •6.4.3. Спрощення входу в систему
- •6.4.4. Автоповтор і інші прийоми роботи з клавіатурою
- •6.5. Лист від одного користувача
- •7.1.2. Важливість ведення документації при створенні програм
- •7.2. Режими і кабелі
- •7.3. Етика і керування розробкою інтерфейсів
3.3. Моделі "іменник-дієслово" і "дієслово-іменник"
Великий клас команд передбачає застосування деякої дії до деякого об'єкта. Наприклад, при використанні текстового процесора ви можете вибрати якийсь абзац і змінити його шрифт. У цьому випадку об'єктом є абзац, а дією - вибір нового шрифту, при цьому в інтерфейсі можуть використовуватися дві послідовності: або (1) спочатку вибір дієслова (змінити шрифт), а потім виділення іменника (абзац); або (2) спочатку іменник, а потім дієслово. На перший погляд може показатися, що обидва варіанти є симетричними, і порядок не важливий. Однак для більшості інтерфейсів ситуація не є симетричної, і порядок ( чидієслово дієслово-іменник)15 має велике значення з погляду юзабилити інтерфейсу.
У більшості посібників з розробки інтерфейсів рекомендується саме модель взаємодії іменник-дієслово (Apple, 1987; Hewlett Packard, 1987; ІBM, 1988; Mіcrosoft. 1995). Аналіз, проведений з погляду локусу уваги користувача, показує переваги такої моделі:
" Зменшення кількості помилок. Послідовність дієслово-іменник установлює режим. Якщо ви вибрали команду зміни стилю, то вона буде відразу застосована до тексту, що ви виділите. Якщо між призначенням команди і виділенням тексту відбудеться чи затримка увага користувача відвернеться, але після того як текст буде виділений, результат може виявитися для нього несподіваним. При використанні моделі іменник-дієслово команди виконуються відразу, поки ще знаходяться в локусі уваги користувача.
" Швидкість. Користувачу не потрібно переключати своя увага зі змісту (яке і викликало необхідність виконання операції) до самої команди і потім знову до змісту, щоб можна було виділити необхідну ділянку тексту. У моделі іменник-дієслово ви спочатку виділяєте текст, що знаходиться в локусі вашої уваги, і потім переключаєте увагу на команду. Таким чином, число переключень локусу уваги зменшується на одиницю.
" Простота й оборотність. При використанні моделі дієслово-іменник повинний бути передбачений можливість чи скасування відкоту команди. Якщо користувач призначає команду і потім вирішує змінити її, варто враховувати, що він знаходиться в цей момент у режимі, і система очікує, що буде зроблене виділення тексту для застосування вже призначеної команди. Тому повинний бути передбачений механізм подачі системі сигналу про те, що ви не хочете виділяти текст і хочете призначити іншу команду. У моделі іменник-дієслово, для того щоб вибрати інший текст, не потрібно натискати кнопку чи відкоту застосовувати який-небудь інший спосіб скасування дії.
Проте , у кожнім з побачених мною посібників з розробки інтерфейсів, у яких рекомендується модель іменник-дієслово, використання моделі дієслово-іменник також допускається. У керівництві Mіcrosoft говориться, що модель дієслово-іменник необхідно використовувати для палітр, наприклад, у виборі стилю кисті в графічних редакторах (Mіcrosoft, 1995). Узагалі, це не зовсім правильно. У даному випадку також можна використовувати чисту модель іменник-дієслово. Ви можете малювати з використанням набору параметрів, прийнятого за замовчуванням (наприклад, тонка лінія чорного кольору), і потім за допомогою команд змінювати колір, ширину, текстуру й інші параметри лінії. Однак насправді ми хочемо відразу бачити, як виглядає кожен мазок, що ми робимо, із усіма його параметрами.
Загальноприйнятий спосіб, при якому користувач спочатку вибирає атрибути з однієї чи декількох палітр, - аналогічно тому, як ви можете перед початком малювання вмочати кисть у ту чи іншу банку з фарбою, - приводить до модальних помилок, що, як ми вже бачили, неминуче повинні тут виникати. Має сенс робити так, щоб обраний режим зберігався доти , поки користувач спеціально не перемінить його. У цьому випадку ви можете почати малювання і зненацька знайти, що для цього використовуються інші атрибути, але, на щастя, результат малювання в даний момент знаходиться в локусі вашої уваги. Програмне забезпечення, що у нашій термінології ми можемо назвати человекоориентированным, у цьому випадку дозволить вам відразу скасувати не улаштовує вас результат, змінити атрибути і продовжити роботу. Модальні помилки завжди викликають роздратування, тому модель чи дієслово інший немодальний метод було б більш ефективним у цій ситуації, але поки, наскільки я знаю, ніхто ще не знайшов удалого рішення цієї проблеми.
У цілому, підхід "іменник-дієслово" є більш кращим. Застосування методів "дієслово-іменник" повинне обмежуватися тільки вибором з палітр, якщо вони призначені для безпосереднього використання.
________________________________________
Приклад приведення проблемної моделі "дієслово-іменник" до моделі "іменник-дієслово"
Працівники різних відділів однієї транснаціональної корпорації використовували спеціальну комп'ютерну систему для розміщення замовлень на товари. На її прикладі ми розглянемо один зі способів переходу з природної, на перший погляд, моделі "дієслово-іменник" на модель "іменник-дієслово". Така зміна допомогла на практиці усунути ті помилки, що виникали при використанні першого варіанта інтерфейсу, і прискорило процес виконання замовлення на товари.
У вихідному варіанті процес складався з трьох кроків:
1. Необхідно вибрати відділ, для якого замовлення було призначено. Для цього випливало поставити прапорець поруч з назвою відділу. Один із прапорців, що відповідає відділу, у якому знаходився даний комп'ютер, був установлений за замовчуванням.
2. Було потрібно вибрати необхідні товари з прокручиваемого списку. Поруч з кожним товаром знаходилося текстове вікно введення, у которое можна було занести кількість кожного товару, що замовляється.
3. Необхідно клацнути по одній із двох кнопок унизу дисплея: або "Скасувати замовлення", або "Підтвердити замовлення".
Перша проблема полягала в тому, що користувачі не могли вибрати свій відділ, якщо вони робили замовлення не зі свого робочого місця. Розроблювачі компанії запропонували скасувати установку відділу за замовчуванням, змушуючи користувачів щораз спочатку вибирати відділ. Вони помітили, що в цьому випадку єдино можлива помилка зв'язана тільки з вибором неправильного відділу. Проте , таке рішення дратувало тих користувачів, що звичайно працювали за своїм комп'ютером, і необхідність щораз вводити інформацію, що вже була доступна системі, викликала роздратування.
По суті справи, проблемою була усі та ж ситуація "дієслово-іменник". Спочатку необхідно було ввести, що ви хочете зробити (доставити ці товари в цей відділ), і потім вибрати, що саме ви хочете доставити. Однак при відкритті вікна замовлення в локусі вашої уваги знаходяться (чи тільки що знаходилися) чи товар товари, що вам потрібні.
Частина рішення полягала в тім, щоб розмістити список товарів нагорі вікна замовлення. Таким чином, користувач міг почати з виділення потрібних товарів. А список відділів, що раніш не мав ніяких написів, одержав заголовок у формі питання: "У який відділ варто доставити замовлені товари?"
Якщо система могла визначити власний відділ користувача (на основі журналу роботи користувача), у перший рядок списку відділів автоматично додавався елемент за назвою "Мій відділ", що так само, як і інші елементи списку, мав прапорець.
Всі інші відділи, розташовані за абеткою , складали іншу частину списку. Поруч з кожним відділом знаходився прапорець. При установці прапорця з'являлося повідомлення: "Відзначені товари замовлені", що зникало відразу після будь-якої дії користувача.
У зміненому варіанті інтерфейсу вибір відділу був дією, тобто дієсловом, після якого інформація про відзначений товаpax відправлялася для обробки. Психологічно це стало дією, що завершує всю операцію замовлення, а не випереджає його. Крім того, слід зазначити, що до цього моменту бланк замовлення вже заповнений, і увага користувача змістилося із самих товарів на необхідність їхньої доставки. Таким чином, хід роботи став відповідати тому, куди звичайно випливає увага користувача.
Відпала необхідність в установці місця доставки за замовчуванням, тому що інтерфейс надавав чітке психологічне закінчення процесів вибору товарів і відправлення замовлення. У початковому варіанті інтерфейсу було потрібно підтвердження замовлення, тоді як у новому варіанті кількість щигликів миші скоротилася, тому що від користувача не було потрібно робити ще одного зайвого щиглика. З уведенням нового варіанта інтерфейсу в користувачів з'явилася можливість сформувати звичку вибирати зі списку відділів звичайне місце доставки, але залишалася імовірність того, що користувач у рідких випадках міг забути відзначити при необхідності й інші відділи, у які товари повинні бути доставлені. Проте , навіть з наявністю цієї потенційної помилки новий варіант інтерфейсу була істотно поліпшена в порівнянні з попереднім.
________________________________________