Евристичні правила Якоба Нільсена, Комерція, Різне, статті

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

Одними з найбільш цитованих в книгах по HCI є десять так званих евристичних правил найвідомішого американського фахівця в галузі проектування інтерфейсів Якоба Нільсена (Jakob Nielsen), розроблених ним спільно з іншим дослідником, Рольфом Молічем (Rolf Molich). Формулювання цих принципів в оригіналі можна прочитати за адресою http://www.useit.com/papers/heuristic/heHristic_list.html. Це десять головних заповідей будь-якого розробника комп’ютерних інтерфейсів, тобто мінімальні критерії, яким повинен відповідати інтерфейс будь-якої програми.

Видимість стану системи (правило зворотного зв’язку)

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

Інформованість користувача

Користувач завжди повинен мати інформацію про поточний статус роботи програми – наприклад, скільки часу пройшло від початку процесу копіювання файлів, коли буде завершено кодування звукової доріжки CD-диска в МРЗ-файл і т. п. Крім цього, користувач обов’язково повинен бачити, до чого привело будь-яке його дію: введення даних, натискання кнопки і т. п.

Засоби забезпечення зворотного зв’язку

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

Інформація, при розгляді даного питання, ділиться на типи в залежності від її призначення і ступеня важливості. Наприклад, повідомлення про критичні помилки, що призводять до неможливості продовження роботи, зазвичай виводяться в окремому діалоговому вікні. При цьому робота програми зупиняється до тих пір, поки користувач не закриє вікно з інформацією про помилку (так зване модальне вікно), а повідомлення про незначні помилки – в статусному рядку вікна програми без зупинки його роботи. Характерний приклад браузера Microsoft Explorer: якщо відкрити запитувану Web-сторінку в даний момент неможливо (Наприклад, не з’єднані з Інтернетом), то на екрані з’являється модальне вікно з повідомленням про критичну помилку. Якщо ж сторінка була успішно завантажена, але при цьому виникли незначні помилки, то відповідне повідомлення відображається в рядку стану програми.

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

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

Крім текстових повідомлень, що виводяться у вікні програми, для організації зворотного зв’язку можуть бути використані і інші засоби. Найпопулярніше з них – звук. Звукове сповіщення може бути корисним в самих різних ситуаціях “. Найбільш часто звук допомагає тоді, коли поява на екрані модальних вікон небажано, а повідомлення в статусному рядку можуть бути lie помічені (наприклад, якщо головне вікно програми, як таке, відсутній). Це є типовим, наприклад, для утиліт, періодично перевіряють e-mail-ящики на наявність свіжої пошти. Інше корисне застосування звуку – сповіщення користувача, знаходиться не за комп’ютером, а десь поблизу. Також звуковий супровід надасть допомогу користувачам з обмеженими можливостями (наприклад, з поганим зором).

Важливо пам’ятати, що звукове сповіщення не повинно бути основним засобом організації зворотного зв’язку. Звук повинен лише доповнювати текстові повідомлення. Інакше користувач може пропустити повідомлення – адже на комп’ютері може бути відсутнім звукова карта або звук може бути відключений. Таким чином, зникне єдиний засіб організації зворотного зв’язку, і робота з програмою стане дуже незручною або взагалі неможливою. Цікаво, що ця особливість інтерфейсу спеціально використовується деякими shareware-авторами для стимуляції користувачів оплачувати реєстрації. Наприклад, в незареєстрованої версії програми отримання повідомлень по мережі Vypress Auvis (http://www.vypress.com) оповіщення про приходять повідомленнях за допомогою спливаючих вікон вимкнено – до реєстрації можна користуватися тільки звуковим оповіщенням. Як наслідок, робота з програмою стає дуже некомфортною, тому що основна область її застосування – локальні офісні мережі, де кількість комп’ютерів, не оснащених звуковими картами, досить велике.

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

Серед інших засобів організації зворотного зв’язку можна згадати запис повідомлень в log-файл, відправку повідомлень по e-mail. Природно, вони застосовуються в якості додаткових способів оповіщення – наприклад, для збору статистики або доступу віддалених користувачів, що підключаються до системи по каналах зв’язку.

Час оповіщення

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

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

Рівність між системою і реальним світом

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

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

Найпоширеніший приклад реалізації цього принципу – побудова інтерфейсів, що імітують об’єкти реального світу. Годинники, калькулятори, програвачі компакт-дисків, записні книжки – більшість з програм, здійснюють ці функції, виглядають майже точно так само, як їх матеріальні аналоги. А знаменита Сміттєва корзина на Робочому столі Windows або Macintosh, в яку можна “кинути” непотрібний файл або папку – Майже хрестоматійний приклад побудови інтерфейсу на основі об’єктів реального світу. Та й сам спосіб “перетягни і кинь” (Drag-and-Drop) – прекрасна ілюстрація цього принципу, абсолютно природна операція навіть для тих користувачів, хто вперше сів за комп’ютер.

Однак таке запозичення ідей з навколишнього світу потрібно робити дуже обережно. Справа в тому, що програми, які вже знайомі користувачеві – теж частина його світу, частина його знань, навичок і звичок. Тому деякі деталі комп’ютерних інтерфейсів є для користувачів більш звичними, ніж об’єкти реального світу – це особливо стосується елементів інтерфейсу, що реалізують функції, що не мають прямих аналогів в реальному світі. Як приклад можна привести відомий мультимедійний програвач WinAmp. Для управління відтворенням музичних композицій програма використовує кнопки Play, Stop, Pause та ін, дуже нагадують аналогічні за призначенням кнопки на програвачах, що стоять в наших квартирах. Але от кнопка, розташована праворуч від них, яка на “сьогоденні” апараті відкриває лоток CD-плеєра, в WinAmp, всупереч очікуванням, не відкриває лоток CD-ROM-дисковода, а викликає вікно Відкрити файл. Це дещо збиває з пантелику, тому що в дуже багатьох аналогічних комп’ютерних програмах така кнопка якраз служить для відкриття / закриття лотка дисковода CD-ROM.

Тому інтерфейси, які повністю, тобто без всяких виключень, копіюють об’єкти реального світу, майже завжди в результаті виходять не дуже зручними, оскільки користувач витрачає досить багато часу, намагаючись освоїти абсолютно новий інтерфейс. Наприклад, експеримент компанії IBM в області інтерфейсів, які використовують в якості своєї основи моделі реальних матеріальних об’єктів – програма RealPhone, вважається повним провалом: число проблем, що виникають при освоєнні “реального телефону”, дуже велике.

А ось дизайн популярної програми Lotus Organizer, навпаки, вважається класичним прикладом вдалого запозичення об’єктів реального світу. Головне вікно програми виконано у вигляді щоденника з закладками – Об’єкта, до якого користувачі вже давно звикли. Але, тим не менш, у вікні Lotus Organizer присутні традиційні, чисто “комп’ютерні” елементи ~ кнопкова панель інструментів і меню. Справа як раз в слові “традиційний” – до панелі кнопок і меню користувачі давно вже звикли, і це допомагає їм швидко освоїти програму. А якби дизайнери Lotus в своїх експериментах пішли далі і замінили б меню і панель кнопок на, скажімо, зображення офісного шафи з парою десятків ящікоі і поличок, то інтерфейс програми став би громіздким і заплутаним.

Свобода дій користувача

Користувач повинен мати контроль над системою і можливість змінити поточний стан програми. Дуже часто користувач дає різні команди помилково (наприклад, випадково натиснувши не ту кнопку або “промахнувшись” мишею мимо потрібного пункту меню), і у нього повинен бути “аварійний вихід” з цієї ситуації, чітко позначений у програмі. Найчастіше такий “вихід” реалізується у вигляді кнопки Cancel (Скасувати), розташованої в діалоговому вікні та дозволяє припинити виконання поточної операції або закрити це діалогове вікно. Крім цього, натискання на клавіатурі клавіші є традиційним і тому звичним для більшості користувачів засобом “аварійного виходу”. Характерно, що “escape” в перекладі з англійської означає “втеча, догляд”. Воно [також незамінне тоді, коли кнопка Cancel (Скасувати) недоступна – Найчастіше за все в Головному вікні програми, адже розміщення кнопок OK, Cancel, Help та інших тут, на відміну від діалогових вікон, не допускається. Зокрема, Microsoft Word при виконанні трудомістких і тривалих за часом операцій, наприклад читання дуже великих файлів, виводить в рядок стану індикатор, що відображає хід процесу і повідомлення:

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

Хорошим тоном вважається, якщо дозволяє поточна ситуація, поєднувати обидва ці способи – кнопку Cancel (Скасувати) і клавішу : сучасні системи розробки додатків для Windows при проектуванні форм діалогових вікон дозволяють призначити кнопці властивість спрацьовування при натисненні клавіші . Як наслідок, для користувача звичним дією при попаданні в ситуацію, з якої йому скоріше хочеться вибратися, є саме натискання клавіші . Що може бути простіше: не потрібно шукати очима якусь там кнопку Cancel (Скасувати), досить вдарити по клавіші у верхньому лівому кутку клавіатури – і готово!

Ще одне, причому важливе, засіб виходу з помилковою ситуації – функції Undo (Відмінити) і Redo (Повторити). Вони є настільки зручними і підтримуються такою великою кількістю програм, що користувачі вже звикли до них і підсвідомо очікують, що будь-яке вироблене дію можна скасувати, повернувшись до попереднього стану. Функція Undo (Повторити) навіть стала предметом багатьох жартів та історій про те, як звик до комп’ютера людина, в реальному світі розбивши далеко не віртуальну вазу, або зробивши помилку в простому, “паперовому”, листі, мимоволі шукає кнопку Undo (Скасувати).

Все це просто зобов’язує розробника якісного інтерфейсу комп’ютерної програми підтримувати функції Undo і Redo. Якщо ж з якихось причин дія, на виконання якого дав команду користувач, не можна буде скасувати, то на екран повинне буде виведено відповідне попередження, а також прохання підтвердити виконання команди.

Послідовність і стандарти

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

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

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

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

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

Попередження помилок

Цей принцип широко поширений і в звичайному житті, поза сферою комп’ютерів та інтерфейсів для них. “Пожежа легше попередити, ніж загасити” – говорив один з плакатів, виданих в кінці дев’яностих років Міністерством внутрішніх справ для навчання людей техніці пожежної безпеки. “Злочин легше попередити, ніж розкрити” – свідчить одне з правил науки кримінології.

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

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

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

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

Розуміння краще, ніж запам’ятовування

При розробці інтерфейсу потрібно робити всі об’єкти, функції, дії видимими і легко доступними користувачеві. Мінімізуйте запам’ятовування – користувач не повинен постійно намагатися утримати в пам’яті інформацію з однієї частини програми, щоб застосувати її в інший. В будь-який момент користувачеві повинно бути ясно, що потрібно робити в даний момент. У хорошому інтерфейсі інструкції з використання системи завжди видимі або легко доступні для виклику в будь-який час, коли це потрібно. Це може бути реалізовано як у вигляді продуманої організації елементів інтерфейсу, так і безпосередньо у вигляді підказок користувачеві. Хороший і дуже відомий приклад – анімована напис, який з’являється на панелі завдань Windows і “під’їжджає” до кнопки Пуск:

“Почніть роботу з натискання цієї кнопки”.

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

Гнучкість і ефективність використання

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

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

Розробники системи програмування Microsoft Quick Basic, яка була дуже популярна ще у вісімдесятих і на початку дев’яностих років, пішли ще далі: вони передбачили два варіанти головного меню програми: повний і скорочений, між якими можна перемикатися одним клацанням.

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

Ще одна складова частина правила “Гнучкість і ефективність використання” – необхідність надавати користувачеві можливість швидкого виконання частих дій. Варіанти реалізації цього дуже різноманітні: це і вже згадувані “гарячі клавіші”, і команди для виклику останніх відкритих файлів, і меню, в яких спочатку показуються найбільш часто виконуються команди, і макроси, і навіть цілі мови програмування, що вбудовуються в додатки, на зразок Visual Basic for Applications в продуктах сімейства Мicrosoft Office.

Естетичний і мінімалістичний дизайн

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

Розпізнавання та виправлення помилок

“Допомагайте користувачеві розпізнавати і виправляти помилки” – каже Якоб Нільсен. Це правило визначає проектування повідомлень про помилки. Гарні повідомлення про помилки – це повідомлення, які пояснюють, в чому полягає проблема і, саме головне, як її виправити. Таким чином, гарне повідомлення про помилку повинно складатися з двох частин.

Опис помилки

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

Найпростіше рішення – створити в довідковій системі програми відповідний розділ, що роз’яснюють зміст проблеми та причини її виникнення. У самому ж діалоговому вікні з повідомленням про помилку може бути присутнім кнопка Довідка для виклику цього розділу. Чисто технічно реалізувати це дуже просто: в сучасних системах програмування для її створення таких дружніх повідомлень про помилки досить при виконанні функції MessageBox вказати прапор наявності кнопки Довідка та ідентифікатор відповідного розділу довідки. А ось складання докладних описів помилок, яких, до того ж, може бути дуже багато, для shareware-програмістів набагато більше нудне і неприємне заняття.

Ще один приклад рішення, причому більш витонченого, даної проблеми є кнопка Детальніше, при натисканні на яку діалогове вікно з повідомленням про помилку “розорюється”, відображаючи більш детальну інформацію про причину виникнення збою. Так, наприклад, організовані багато повідомлення про помилки в 32-розрядних версіях Windows, найвідоміше з яких – “Програма виконала неприпустиму операцію і буде закрита”. За кнопкою Докладніше у цьому повідомленні ховається ім’я програми-винуватця, а також адреса місця виникнення помилки.

Зауваження

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

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

Дуже важливо пам’ятати те, що повідомлення про помилку повинно містити її опис нормальним людським мовою, а не її числовий код. Деякі програмісти цілком серйозно вважають, що такі лаконічні повідомлення, в стилі відомого в Інтернеті “Error 404”, виробляють на користувача незабутнє враження: чим “загадковіше” програма, тим вона складніша і, в кінцевому підсумку, “крутіше”. Але, насправді, ефект схожий на той, що був уже описаний вище: незрозумілі помилки виникають лише в неякісних виробах.

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

Опис вирішення проблеми

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

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

Справа в тому, що не псу користувачі здогадуються натиснути рятівну кнопку Довідка, хоча це було б цілком природним кодом (як відомо, в англійських версіях Windows в цих випадках використовується слово “Help” – “Допомога”).

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

Довідка та документація

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

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*