
- •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. Етика і керування розробкою інтерфейсів
5.4.2. Одиниці взаємодії
Покроковий пошук є одним із прикладів використання загального принципу розробки человекоориентированных інтерфейсів, що полягає в наступному: програма повинна взаємодіяти з користувачем на основі найменшої значимої одиниці введення. Взаємодія з даними, що вводяться за допомогою клавіатури, повинне бути познаковым, а не порядковим. Взаємодія з даними, що вводяться за допомогою голосових пристроїв, повинне бути послівним, а для деяких додатків навіть може бути поморфемным і т.д.
Взаємодія за допомогою послідовного введення рядка тексту, тобто рядка, відділеної знайомий Return, - це пережиток часів телетайпа, що повинний бути переданий у музеї разом з устаткуванням того часу36. Сьогодні ми можемо і повинні мати можливість користатися інтерфейсами, здатними реагувати на кожен символ, що вводиться, у всіх випадках, коли така реакція може поліпшити якість взаємодії. Як і завжди, розроблювачі повинні бути уважні - наприклад, посимвольное взаємодія не повинна приводити до видачі повідомлень про орфографічні помилки в середині набору слова, що може ускладнити роботу користувача, що володіє сліпим методом набору.
У маленьких текстах, для яких пошук рядків був споконвічно придуманий, він звичайно проходив від поточної позиції курсору до кінця тексту. У текстах більшого розміру у випадку, якщо до кінця документа шуканий об'єкт так і не був виявлений, звичайно зручніше продовжити пошук з початку документа до позиції курсору, якщо користувач забув, що шуканий об'єкт знаходиться вище. Неопубліковане тестування, проведене в компанії Іnformatіon Applіance, показало, що якщо пошук виробляється швидко, те цикличный пошук виявляється особливо зручним. "Швидкий" означає тут, що між запуском пошуку і його успішним або неуспішним закінченням не залишається часу на дії користувача. Як правило, цей час складає порядку 250 мс. У багатьох системах користувач може вибрати, яким образом буде проходити пошук - або циклично (по колу), або з зупинкою наприкінці документа. Це породжує типову проблему модальності. Якщо встановлений нецикличный пошук, і користувач не знає про це, повідомлення "рядок не виявлений" може привести до невірного розуміння, що в тексті немає екземплярів по запитаному шаблоні пошуку. Часто я спостерігав, що в цьому випадку користувачі кілька разів запускали пошук повторно, тому що ясно пам'ятали, що бачили такий екземпляр у тексті, і не розуміли, чому пошук закінчується безрезультатно. Може пройти кілька чи секунд навіть хвилин, перш ніж користувач догадається, у чому складається проблема, чи ж так і залишиться в здивуванні. Якщо необхідно мати різні види пошуку, можна уникнути використання режимів, передбачивши для кожного виду пошуку відповідну чи команду екранну кнопку для запуску.
У багатьох випадках модальності можна уникнути за допомогою набору кнопок для запуску кожного виду пошуку. Такий набір може бути передбачений замість вікна установки параметрів пошуку, постаченого один-єдиною кнопкою запуску пошуку по заданих умовах. Такий підхід дозволяє не тільки усунути модальність, але і скоротити число натискань. Крім того, у локусі уваги користувача в цьому випадку знаходиться задача, що він хоче виконати, а не настроювання для її виконання. На мал. 5.5 показане типове діалогове вікно з настроюваннями і кнопкою запуску, що використовується в Mіcrosoft Word. З малюнка видно, що з діалоговими вікнами цього типу зв'язана й інша проблема: чи належні кнопки перемикача завжди знаходитися в зазначеному положенні при відкритті вікна? Чи належні вони бути в положенні, у якому користувач залишив їх при останнім використанні? Чи ж вони повинні бути в деякім положенні, установленому користувачем за замовчуванням?
Рис. 5.6. Більш ефективне діалогове вікно з декількома кнопками запуску
Усі три варіанти є помилковими. Якщо користувач завжди обновляє зміст цілком, то при першому варіанті йому доведеться робити щораз по двох щиглика мишею (чи один щиглик і одне натискання на кнопку <Return>). Якщо перемикач залишається в тім положенні, у якому вікно використовувалося останній раз, користувач не зможе користатися цим вікном звичним образом, оскільки щораз йому доведеться зупинятися і перевіряти, у якім положенні перемикач знаходиться. Якщо ж перемикач може встановлюватися користувачем у положення за замовчуванням (див. роздягнув 3.2.2), то тим самим включається режим.
Діалогове вікно, зображене на мал. 5.6, дозволяє вирішити відразу всі ці проблеми. Крім того, за законом Фитса кнопки великого розміру мають перевага в порівнянні з набором перемикачів. Якщо таке вікно зробити прозорим, то можна також відмовитися від використання кнопки <Cancel> (див. роздягнув 5.2.3). У цьому випадку використовувані дві кнопки не повинні бути прозорими, щоб користувач міг бачити, що вони є активними.
Діалогові вікна для пошуку з роздільниками звичайно постачені пристроєм для збереження поточного шаблона відразу після виявлення останнього екземпляра. Такий пристрій можна назвати "шукати ще" чи "знайти далі". У деяких варіантах воно запускається за допомогою тієї ж кнопки, що використовувалася для початкового пошуку. Якщо пошук є покроковим, то команда для повторного пошуку того ж об'єкта є необхідної, оскільки в цьому варіанті немає ніякої команди для запуску початкового пошуку. Застосовувати для повторного пошуку клавішу включення квазирежима <Search> не бажано, тому що користувач може натиснути цю клавішу, а потім передумати і відпустити її. У цьому випадку буде початий пошук, що користувач не хотів запускати. У результаті користувач може втратити місце в тексті, у якому він знаходився. Хоча використання системи глобального відкоту може виправити ситуацію, усе-таки краще взагалі не створювати цієї проблеми. Спеціальний метод для виконання повторного пошуку буде розглянутий у розділі 5.6.
У великих по розмірі текстах пошук може здійснюватися по колу (циклично) не тільки в локальному документі, але і далі, в автоматично розширюються областях аж до усього Інтернету.37 Після того як пошук був виконаний по всьому локальному документі, він може бути продовжений у відношенні наступних документів папки, а потім перейти на початок першого документа папки і продовжитися до поточного, уже переглянутого документа. Після циклічного пошуку усередині папки розглядається наступна локальна область пошуку і т.д. Якщо під час покрокового пошуку, виконуваного таким чином, користувач зрозуміє, що процес пошуку занадто розширився, він може зупинити його, переконавши, що в ближніх областях шуканого екземпляра немає. Поточну область пошуку визначити звичайно легко, тому що користувач може бачити результати пошуку у своїх контекстах, а не просто список файлів, як це робиться в багатьох сучасних пошукових системах.
У загальному випадку користувачі будуть застосовувати більш ефективні стратегії пошуку, чим просто покладатися на такий метод автоматично розширюється пошуку. Наприклад, якщо ви шукаєте якийсь документ у поточній папці, то, швидше за все, ви станете шукати символи документів, щоб швидко переглянути чи початок заголовок кожного документа. Якщо потрібний документ виявлений, запускається покроковий пошук у відношенні цільового об'єкта. Таким чином, забезпечується порядок, по якому пошук виробляється в першу чергу в обраному документі, що дозволяє застосовувати більш короткий шаблон на меншій площі пошуку. Якщо ж ви не знаєте, у якому документі шуканий об'єкт знаходиться, чи якщо ви не хочете шукати з початку документа, ви можете застосувати суцільний пошук, що у будь-якому випадку знайде шуканий об'єкт.