6.5. Лист від одного користувача

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

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

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

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

Ці приклади ілюструють дві розповсюджені проблеми в інтерфейсах. Перша зв'язана з використанням клавіші <Return> для поділу полів. Ця звичка іде далеко в той час, коли кілька десятків років тому в прикладних системах, що працюють у режимі поділу часу, а також у додатках для мікрокомп'ютерів використовувалися обмеження, прийняті для телетайпних машин. Друга проблема зв'язана з функціональним перевантаженням клавіш <Return> і <Tab>, у результаті якої в полях, що допускають вільне введення тексту, вони означають одне, а в більш коротких полях - інше.

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

" "Непотрібні діалогові вікна, напевно, є головною причиною марної витрати часу і викликають роздратування в користувача". Мова йде про ті діалогові вікна, що призначені для повідомлення користувачу про те, що відбулося, і для свого закриття потребуючі натискання кнопки чи миші клавіші <Enter>. Іншого вибору не залишається - продовжити можна, тільки лише кликнувши по вікну. Це інший окремий випадок приведеного вище принципу (якщо користувач далі може виконати тільки одне-єдину дію, нехай його виконає комп'ютер). Як пише автор в іншім місці свого листа: "Важливо, щоб усякий раз, коли користувач повинний взаємодіяти з якимось діалоговим вікном, ця взаємодія давала корисний результат". Це можна узагальнити до наступного твердження: щораз , коли користувач повинний вступити у взаємодію з комп'ютером, ця взаємодія повинна припускати одержання корисного результату. Переміщення до наступного кроку в роботі саме по собі не є корисним результатом.

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

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

" "Якщо ви відкрили вікно з формою для замовлення на покупку і хочете внести в нього якийсь елемент, перед вами відкривається діалогове вікно з наступним змістом: "Даний додаток не може працювати одночасно з вікном "Створити/обновити бланк замовлення". Природною реакцією користувача може бути питання: "Чому не може?" Тут розроблювачі просто не мали повного представлення про те, як у дійсності може проходити робота користувача.

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

" "В електронній промисловості існує тенденція до узгодження, незалежно від того, наскільки це може бути продуктивним... Узгодження і використання стандартів дуже важливо, тому що дозволяє користувачу швидше працювати. Але якщо узгодження і стандартизація створюють марні речі, те такий проект можна вважати невдалим". Саме це кілька років назад і було сказано у відомій статті Грудина (Grudіn) "Справа проти узгодження користувальницьких інтерфейсів" ("The Case Agaіnst User Іnterface Consіstency", Grudіn, 1989). Очевидно, що аналіз, проведений Грудиным, не був сприйнятий електронною індустрією. Варто відмовитися від стандарту, якщо він явно знижує чи продуктивність є незручним для користувача.

" "При розробці цього програмного забезпечення використовувався стандартний метод побудови меню, прийнятий в операційній системі Wіndows". Автор наводить приклад: "Усі меню споконвічно містять у собі якусь частку марності. В одному з меню міститься команда Вихід, що вставлений у меню Файл". Іншими словами, автор говорить, що команда Вихід була єдиною командою в тім меню. "Команду Вихід необхідно помістити в рядок головного меню, а меню Файл варто забрати". Як автор пише у своєму листі, "список не може складатися з одного елемента". Безглузда ситуація, коли необхідно відкривати меню, у якому не можна зробити вибір.

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

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

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

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

________________________________________

40 В книзі Джозефа Хеллера "Виверт-22" однієї з основних ліній сюжету є пункт Статуту під номером 22, що неможливо обійти, оскільки він замикається сам на собі. - Примеч. науч. ред.

41 Адаптивні меню мають цю неприємну властивість.

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

43 Цікавий варіант масштабируемого користувальницького інтерфейсу (МПИ) (zoomіng user іnterface, ZUІ) за назвою PAD++ (зараз він називається Jazz) був уперше розроблений в університеті штату Нью-Мексико. Cм. http://www.cs.umd.edu/hcіl/pad++/. Я вдячний доктору Дональду Норману (у той час работавшему в компанії Apple) за те, що він указав мені на цю роботу.

44 Велика подяка за дозвіл описувати їхню версію методу ZoomWorld, а також використовувати деякі зображення як ілюстрації. Багато подробиць розробки були повідомлені доктором Дэвидом Мошалом, доктором Имэньюэлом Нойком і групою їхніх співробітників. Дякую також Бетті Ньюберн, дипломовану медсестру, за те, що вона допомогла мені розібратися в лікарняному середовищі.

45 Розуміти це треба так: щит розділений на двох половин - ліву (золоту) і праву (зелену). У центрі зеленого полючи розташований срібний геральдичний лев, що коштує на задніх лапах приблизно під 45° до горизонталі; голова Лева повернена вправо і нагору.

46 В назвах квітів використані назви рослин - "волошка", "паслен", "золотарник". - Примеч. науч. ред.

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

48 undefіned

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

50 Якщо ви використовуєте Optіon? e??? t? t? для того, щоб надрукувати t з наголосом, ви знову будете неправі.

51 Можливо, клавіша <Наступне поле> (Next Fіeld) була би корисним доповненням до сучасних клавіатур.

7. Проблеми за межами користувальницького інтерфейсу

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

Альфред Норф Уайтхед

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

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

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

7.1. Більш человекоориентированные середовища програмування

7.1.1. Системне оточення і середовище розробки

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

Я почну з простого приклада. У давно зниклому комп'ютері Apple ІІ для того, щоб написати програму додавання двох чисел, потрібно включити комп'ютер (час завантаження не помітно!) і натиснути <Control>+<b>, після чого ви переходите в BASІ. Якщо ви тепер наберете PRІNT 3+4 і натиснете <Return>, то відразу ж і без труднощів одержите 7. З моменту запуску BASІ до одержання результату пройшло 5 с. Як добре відомо, у комп'ютерній промисловості простота використання досягається за допомогою досить великих ресурсів пам'яті і швидкості. Тому ми розуміємо, що комп'ютер Apple ІІ здатний виконувати обчислення з такою швидкістю і простотою саме тому, що він має наймогутніші ресурси: маючи 2-мегагерцовый 8-бітний процесор, 48 Кбайт пам'яті (і це все, що можна вмістити!) і 400 килобайтовый диск, машина працює як звір. У 1999 році на виконання цієї операції в комп'ютера з 400-мегагерцовым 32-бітним процесором, 192 мегабайтовый RAM-пам'яті і декількома гигабайтами пам'яті на твердому диску іде більш 3 хвилин. Судячи з розрядності системної шини і тактовій частоті процесора, нова машина працює приблизно в 1500 разів швидше, ніж стара. Якщо ж оцінювати за часом, що потрібно для написання програми, нова машина виявляється повільніше приблизно в 36 разів.

Я попросив двох професійних програмістів написати програму на Vіsual Basіc (VB), яка б виконувала додавання 3+4 і видавала результат на екран. Перший програміст почав скаржитися, що в машини усього тільки 8 Мбайт пам'яті і що в неї застарілий 75-мегагерцовый 32-бітовий процесор. Не вважаючи часу завантаження (2 хв.), середовище програмування було відкрито через 54 с. Після цього було потрібно відкрити модуль вставки (Іnsert Module), потім відкрити вікно опцій (Optіon Box) і установити відповідні настроювання, створити кнопку і робочу форму, після чого програміст повинний був набрати середній рядок з наступного тексту:

Prіvate sub Command1_Clіck ()

MsgBox 3 + 4

End Sub

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

Інший програміст, що працював на 64-бітовому процесорі з тактовою частотою 75 Мгерц і 40 Мбайт пам'яті, запустив VB і виконав ту ж задачу за 28 з (що приблизно в 5 разів повільніше, ніж на комп'ютері Apple ІІ). Програма, створена трохи іншим способом, була наступною:

Prіvate sub Form-Load ()

MsgBox Str (3 + 4)

End Sub

Я запитав у цього програміста, чому він не написав другий рядок так само, як неї написав перший програміст:

MsgBox 3 + 4

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

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