5.2.2. Команди

Я як письменник-фантаст упевнен, що цей чортовий робот повинний говорити людською мовою, а не навпаки.

Спайдер Робинсон

Деякі команди (як, наприклад, Скасувати) не обов'язково можуть застосовуватися до вибірок. Інші команди діють тільки стосовно поточного вибірці - як, наприклад, команда, що видаляє поточну вибірку. Деякі з цих команд уводяться з клавіатури. Однак число клавіш на клавіатурі менше, ніж кількість можливих команд. Кожна додаткова клавіша-модифікатор (як, наприклад, <Shіft>, <Alt>, <Command>, <Control> чи <Optіon>) дозволяє подвоїти число клавіатурних команд. Повна клавіатура, у якій будь-яка комбінація клавіш може бути сприйнята комп'ютером, допускає астрономічне число сполучень клавіш. Наприклад, програмне забезпечення, у якому передбачене використання будь-яких трехклавишных дваждыквазимодальных сполучень на 110-клавішній клавіатурі, дозволяє передати більш одного мільйона команд за допомогою тільки одного жесту. Однак широке використання клавіш-модифікаторів, особливо в сполученнях клавіш, дуже часто приводить до появи надзвичайно складних комбінацій, у яких можна просто "зламати пальці". Крім того, комбінації рідко бувають що запам'ятовуються чи зрозумілими. ( чиЗнаєте ви, яке дія виконує на вашому комп'ютері сполучення <Control>+<Shіft>+<Optіon>+<\>?) Запам'ятати різні сполучення клавіш не просто. Таке запам'ятовування є неприпустимою вимогою до пам'яті користувача. Крім того, такі команди порушують критерій видимості, якщо тільки в системі якимсь образом не відображається те, який результат буде отриманий при застосуванні тієї чи іншої команди. Звичайно, якщо в окремих випадках якоїсь з цих жестів не може бути виконаний чи якщо жест має різні значення в різні моменти, це означає модальність системи стосовно даного жесту, що приводить до проблем, що обговорювалися в главі 3.

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

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

Command? v? ??

яке використовується для вставки, крім того, що клавіша v розташована поруч із клавішею c, використовуваної в сполученні

Command? c? ??

яке запам'ятовується трохи краще, оскільки з може нагадувати слова "вирізувати" (cut) чи "скопіювати" (copy).

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

Я хочу купити 3+4 сорочок

При натисканні на клавішу <Обчислити> він буде перетворений у наступний текст:

Я хочу купити 7 сорочок

До натискання на клавішу <Обчислити> 3+4 було звичайним текстом, Він нічим не відрізнявся від іншого тексту, за винятком того, що він був виділений. П'ять символів (включаючи пробіли), з яких складалася вибірка, можна було чи перемістити видалити, чи ж до них могла бути застосована будь-яка інша звичайна команда текстового процесора. Але в даному випадку була використана операція Обчислити. Користувачу не треба було відкривати вікно чи калькулятора викликати спеціальний додаток.

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

Перед обговоренням такого механізму розглянемо вимоги, яким повинний відповідати новий метод виклику команд:

" Цей механізм не повинний бути модальним

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

" Користувач повинний мати можливість викликати команду безпосередньо з клавіатури

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

" Використання механізму не повинне вимагати достатку спеціальних клавіш

" Механізм не повинний породжувати великої кількості квазирежимов

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

Я хочу купити 3+4 сорочок обчислити

Виділимо суму 3+4, і потім виділимо слово обчислити, при цьому сума стане старою вибіркою.

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

Я хочу купити 7 сорочок

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

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

Такий підхід має ряд переваг. Наприклад, онлайновые керівництва автоматично містять приклади використання команд, що у ньому описуються. У сучасних системах команди, що маються в меню, можуть як мати, так і не мати свого клавіатурного аналога. Однак при такому підході кожна команда, описана в меню послідовністю символів, має свій клавіатурний еквівалент. Це забезпечується не завдяки старанням розроблювачів, а по самій природі такої системи. Як команда з меню, так і клавіатурний еквівалент мають однакове написання. І більшість користувачів будуть частіше використовувати саме клавіатурний еквівалент. Іншою перевагою цього підходу є те, що ви можете скласти меню тільки з тих команд, що ви використовуєте, просто набравши їх у список за допомогою текстового процесора. Звичайно, якщо ви постійно змінюєте список, а не просто, скажемо, додаєте до нього нові команди, то губиться перевага їхнього звичного розташування.

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

Якщо для команд не використовувати особливий чи шрифт колір, то прийдеться передбачати іншого правила для позначення того, що якесь чи слово послідовність слів варто розглядати як єдину команду. Розумніше було б уникнути використання якихось з існуючих сьогодні умовностей, що використовуються для угруповання окремих слів в одну одиницю, розділену чи пробілами іншими символами. Наприклад, якби в нас була команда, що ми б хотіли назвати "перетворити зображення у формат JPEG", те за існуючими правилами нам довелося б написати її у виді перетворити.зображення.в.формат.JРЕ, <перетворити зображення у формат JPEG> чи перетворити_зображення_у_формат_JРЕ. Такі способи написання є занадто "комп'ютерними", незручними і сумовитими, особливо для тих, хто тільки знайомиться з комп'ютерами. Синтаксис, що ми вибираємо для написання команд, не повинний виключати чи пробіли символи нового рядка. Будь-які обмеження, що накладаються на набір припустимих символів, використовуваних для набору команд, у майбутньому приведуть до проблем. Більш того, будь-які подібні обмеження користувачу прийдеться враховувати при призначенні команді імені. Варто також мати на увазі й інший принцип, що полягає в тім, що використання звичаїв, що не збігаються з традиціями звичайної мови, приводить до виникнення нерозуміння між користувачем і комп'ютером. Варто зробити так, щоб машина підбудовувалася під нас, а не підбудовувати звичаї природної мови під те, що простіше вирішити з погляду програмування.

Ще одна взаємодія введення з клавіатури і створення вибірки викликає проблеми в сьогоднішніх інтерфейсах. У человекоориентированном інтерфейсі введення з клавіатури не заміщає виділений текст і не скасовує виділення поточної вибірки. Це відрізняється від розповсюдженого правила, відповідно до якого введення символів заміщає вміст поточної вибірки, що час від часу приводить до проблем у тих випадках, коли новий матеріал несподіваним для користувача образом видаляє текст, що він не збирався видаляти. Ідея, що при введенні символів вони повинні заміщати вибірку, стала використовуватися для того, щоб заощадити на одному натисканні клавіші - у більшості редакторів, щоб замістити текстовий блок, ви можете просто виділити його і почати введення. Без цього правила користувачу прийдеться спочатку виділити деякий текст, потім натиснути <Backspace> чи <Delete> і потім уводити новий текст. У способі, що використовується сьогодні, заощаджується тільки лише натискання на клавішу <Backspace>, при цьому при першому натисканні текст зникає і заміщається текстом, що вводиться далі. Це відбувається незалежно від того, знаходився текст, що чи заміщається, на чи екрані ні і (звичайно) чи складався він з декількох чи символів трьох чвертей вашого документа. Таким чином, поза локусом вашої уваги ви можете видалити текст у 40 сторінок. Якщо ви вчасно заметете це, то, напевно, зможете скасувати дію. Але якщо ж ви не заметете видалення, і якщо нічого не підкаже вам, що текст був вилучений, вам може не повезти. Человекоориентированный інтерфейс ніколи не піддає роботу користувача ризику. Економія одного натискання на клавішу куплена за занадто велику ціну. Випадкова втрата хоча б одного символу може означати втрату частини телефонного чи номера адреси електронної пошти, що не може бути відновлена з частини, що залишилася. Видалення тексту повинне проходити явно за бажанням користувача і не бути побічним ефектом іншої дії.

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

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

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

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

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

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