Метафора

Як було сказано, щоб навчитися користуватися системою, користувачеві потрібно побудувати ментальну модель цієї системи. Щоб позбавити його і від цієї роботи, потрібно домогтися застосування метафори, яка дозволяє користувачеві не створювати нову модель, а скористатися готовою моделлю, яку він раніше побудував з іншого приводу. Найпростішим прикладом метафори в інтерфейсі є пристрій програм для програвання звуків на комп'ютері. Історично склалося, що вся аудіотехніка має майже однаковий набір кнопок: кілька кнопок зі стрілками (назад / вперед), кнопка з трикутником (відтворення), кнопка з двома дощечками (пауза), кнопка з квадратиком (повна зупинка) і червоний гурток (запис). Про них можна сказати, що вони абсолютно зрозумілі, але навчитися їм можна без праці. При цьому зазвичай життя складається так, що спочатку людина навчається користуватися цими кнопками на матеріальних пристроях, а вже потім починає користуватися комп'ютером. Відповідно, при проектуванні програми аналогічного призначення розумно скопіювати існуючу систему маркування кнопок. Завдяки цьому користувачам для використання програми нічому не доводиться вчитися (і навіть не доводиться переучуватися, що удвічі образливо, оскільки повністю заперечує повернення інвестицій в навчання). Недоліки метафор. По-перше, не для будь функціональності можна підібрати підходящу метафору, причому заздалегідь дізнатися, чи є хороша метафора чи ні, неможливо, так що можна витратити час на пошуки і нічого не знайти. Це, як мінімум, неефективне. По-друге, навіть підходяща метафора може виявитися марною, якщо її не знає істотна частина аудиторії або її важко однозначно передати інтерфейсом. По-третє, майже завжди метафора буде сковувати функціональні можливості. Що робити, якщо проектована система володіє великою кількістю функцій, ніж копійований зразок? Слідування метафорі в таких умовах буде тільки шкодити, оскільки збігається функціям буде вчитися легше, а незбіжним - складніше (вони будуть занадто інакше влаштовані). Навіщо тоді система, чому б користувачеві не скористатися її вихідним зразком? По-четверте, зовсім необов'язково, що сам по собі копійований зразок працює ідеально. Якщо його копіювати, виявиться, що система не зможе бути ефективніше свого прабатька. Наприклад, Adobe PageMaker багато в чому копіює традиційні верстальний гранки, наслідуючи їх популярність користувачам разом з їх обмеженнями. Завдяки цьому він став надзвичайно популярний. По-п'яте, майже завжди метафору можна використовувати в документації, не переносячи її в інтерфейс, при цьому з тим же успіхом. Досить просто написати, що «система багато в чому нагадує ...» і потрібний результат буде досягнутий. Таким чином, метафора, будучи кращим засобом для позбавлення користувача від навчання, не є засобом хорошим. З іншого боку, метафори іноді все-таки працюють (взяти ті ж музичні програми), так що певну користь від них отримати можна. Аналізуючи досвід успішних випадків їх застосування, можна вивести наступні правила:

• небезпечно повністю копіювати метафору, достатньо взяти з неї найкраще

• не обов'язково брати метафору з реального світу, її сміливо можна придумати самому

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

• якщо метафора хоч якось обмежує систему, від неї необхідно негайно відмовитися.