Загальні принципи побудови

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

Як легко здогадатися з назви, складовими частинами HCI є:

• людина (користувач)

• комп'ютер

• їх взаємодія.

Користувальницький інтерфейс (англ. Userinterface, UI) є своєрідним комунікаційним каналом, по якому здійснюється взаємодія користувача і комп'ютера.

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

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

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

Західні дослідники в області HCI сформулювали основні принципи проектування користувацьких інтерфейсів комп'ютерних програм. Як і в будь-який інший науці, існує досить багато різних методик і класифікацій, які можна знайти в книгах по HCI, облямованих за кордоном, а також на іноземних Web-сайтах.

Якщо говорити про найбільш загальні принципи проектування користувацьких інтерфейсів, то можна назвати три основні положення:

1. Програма повинна допомагати виконати завдання, а не ставати цим завданням.

2. При роботі з програмою користувач не повинен відчувати себе дурнем.

3. Програма повинна працювати так, щоб користувач не вважав комп'ютер дурнем.

Досить емоційні формулювання, але, тим не менш, разюче вірні.

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

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

По-перше, традиційним злегка зарозумілим ставленням програмістів до простим користувачам. Це ще можна було зрозуміти у вісімдесятих і на початку дев'яностих років XX століття, коли звичайні персональні комп'ютери не мали доступних широкій аудиторії програмних і апаратних засобів для побудови привабливих графічних інтерфейсів і роботи з ними. Найпоширенішою операційною системою на той час була MS DOS, заснована на інтерфейсі командного рядка. Тому ефективно працювати з персональним комп'ютером могли люди тільки з досить серйозною підготовкою. Крім того, парк "персоналок" був відносно невеликий навіть у США, не кажучи вже про інші країни, і, як наслідок, число користувачів комп'ютерів було невеликим.

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

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

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

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

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

Один із прикладів такого неправильного ставлення до користувача є відмова програми виконати цілком природну з точки зору користувача програмних продуктів такого роду операцію і висновок діалогового вікна, що вимагає виконати якусь іншу послідовність дій. Цим "прославився", наприклад, відомий текстовий редактор "Блокнот" зі складу Windows95. Якщо користувач відкривав цю програму і вирішував перед початком набору тексту дати створюваному "Блокнотом" за замовчуванням файлу "Untitled" яке-небудь ім'я, вибравши з меню команду Зберегти як, редактор відмовлявся зробити це, показуючи повідомлення: "Ви не ввели який-небудь текст, щоб його можна було зберегти. Наберіть який-небудь текст, а потім спробуйте [зберегти його] знову ". Цим творці "Блокнота" не тільки відкинули стиль роботи дуже багатьох користувачів (перед початком набору тексту дати ім'я файлу), але збили з пантелику і тих, хто був знайомий з "Блокнотом" по попередніх версіях Windows. Наприклад, в Windows 3.1 "Блокнот" дозволяв зберігати порожні файли без жодних проблем. Досвідчені користувачі, знайомі з принципами роботи операційної системи, теж були здивовані: якщо з контекстного меню Провідника Windows в меню Створити вибрати пункт Текстовий документ, то вийшов файл довжиною 0 байт відкривається "Блокнотом" без будь-яких ускладнень. На щастя, у наступних версіях Windows "Блокнот" став більш дружні до користувача.

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

І, нарешті, третій принцип - "Програма повинна працювати так, щоб користувач не вважав комп'ютер дурнем".

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

Примітка

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

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

А цей приклад особливо часто наводиться в якості ілюстрації до розповіді про "тупих" інтерфейсах. Утиліта перетворення текстових файлів, включена в Microsoft Word, здатна розпізнати формат файлу, що відкривається. Але, тим не менш, вона просить користувача підтвердити, що структура файлу була визначена правильно. У багатьох випадках (наприклад, коли людина відкриває файл, створений не їм, або просто при нестачі знань) він не може вказати, який формат файлу насправді. Але, т. К. Його все-таки просять зробити вибір, він починає коливатися, вибирати зі списку інші формати, що призводить до некоректних результатів.

Ще один відомий приклад інтерфейсу, який дає привід здивуватися "дурості" комп'ютера. Якщо в текстовому редакторі WordPad відкрити звичайний текстовий файл і, навіть нічого в ньому не змінюючи, спробувати зберегти його, то програма повідомить, що така операція "призведе до втрати форматування". Особливу пікантність цій ситуації додає той факт, що в текстовому (ASCII) файлі яке-небудь форматування відсутня спочатку.

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

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

Види побудови інтерфейсів

Золотий перетин

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

У математиці пропорцією називають рівність двох відносин: a: b = с: d.

Відрізок прямої АВ можна розділити точкою С на дві частини наступними способами:

• на дві рівні частини АВ: АС = АВ: ВС,

• на дві нерівні частини в будь-якому відношенні (такі частини пропорції не утворюють);

• таким чином, коли АВ: ВС = ВС: АС.

Останнє і є золотий розподіл або розподіл відрізка в крайньому і середньому відношенні.

Золотий перетин - це таке пропорційне ділення відрізка на нерівні частини, при якому весь відрізок так відноситься до більшої частини, як сама велика частина відноситься до меншої; або іншими словами, менший відрізок так відноситься до більшого, як більший до всього.

а: b = b: с чи з: b = b: а.

Відрізки золотої пропорції виражаються нескінченним ірраціональним дробом 0,618 ..., якщо з прийняти за одиницю, а = 0,382. Ставлення ж відрізків а і b становить 1,618.

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

Є і золотий трикутник (трикутник, у якого відношення довжини бічної сторони до довжини підстави дорівнює 1,618), і золотий кубоід (прямокутний паралелепіпед з ребрами, що мають довжини 1,618, 1 і 0,618).

Золотий перетин не є штучним явищем. Воно дуже широко поширене в природі: золотий перетин можна знайти в пропорціях тел багатьох рослин і тварин, а також морських раковин і пташиних яєць. Але найбільш вражаючий приклад "застосування" природою принципу золотого перетину - людське тіло. Воно цілком і його частини (обличчя, руки, кисті рук і т. П.) Наскрізь пронизані пропорцією 1,618.

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

З розвитком дизайну і технічної естетики дія закону золотого перетину поширилася на конструювання машин, меблів і т. Д. Проектування комп'ютерних інтерфейсів - не виняток. Форми діалогових вікон і елементів управління, сторони яких відносяться як 1,618, дуже привабливі для користувачів. Наприклад, дуже багато захоплень у користувачів програми ChameleonClock (http://www.softshape.com) викликає така, здавалося б, буденна річ, як вид діалогового вікна Властивості. А все тому, що при його проектуванні використовувався саме принцип золотого перетину.

Гаманець Міллера

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

Якщо необхідно протягом короткого часу зберегти інформацію, що включає більше семи елементів, мозок майже несвідомо групує цю інформацію таким чином, щоб число запам'ятовуються елементів не перевищував гранично допустимого. Наприклад, номер банківського рахунку 30637402710, що складається з одинадцяти елементів, буде, швидше за все, запам'ятовуватися як 30 63740 27 жовтня, т. Е. Як п'ять числових елементів, або вісім слів (тридцять, шістдесят, три, сімсот сорок , двадцять, сім, десять).

Застосовуючи принцип гаманця Міллера в дизайні інтерфейсів, слід групувати елементи в програмі (кнопки на панелях інструментів, пункти меню, закладки, опції на цих закладках і т. П.) З урахуванням цього правила- т. Е. Не більше семи в групі, в крайньому випадку - дев'яти. Погляньте, наприклад, на головне вікно програми-словника ABBYY Lingvo 6.0: чотирнадцять кнопок на верхній панелі, між якими немає жодного роздільник, сприймаються набагато гірше, ніж кнопки на панелі внизу, які розділені на групи.

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

Принцип угрупування

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

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

Бритва Оккама або KISS

Філософський принцип, що носить назву "Бритва Оккама", говорить: "Не множити сутності без потреби". Або, як кажуть американці, KISS ("KeepItSimple, Stupid" - "He ускладнюй, бовдур").

Мовою інтерфейсів це означає, що:

• будь-яка задача повинна вирішуватися мінімальним числом дій;

• логіка цих дій повинна бути очевидною для користувача;

• руху курсора і навіть очей користувача повинні бути оптимізовані.

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

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

Видимість відображає корисність

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

Це питання вже трохи порушувалося при розмові про принцип Якоба Нільсена "Естетичний і мінімалістичний дизайн", правда, в прив'язці до відбиття корисності.

Відмінність принципу "Видимість відображає корисність" якраз і полягає в тому, що інтерфейс програми повинен бути побудований навколо об'єктів, з якими маніпулює користувач, і відображати стан поточного об'єкта. Реалізацію цього принципу ви бачите кожен раз, коли користуєтеся комп'ютером: контекстні панелі інструментів у програмах пакетаMicrosoft Office, які змінюються в залежності від того, з якою частиною програми (редактором, попереднім переглядом, малюванням і т. П.) І даний момент працює користувач. Ще один приклад - вже згадуване меню Пуск вWindows ME і Windows 2000: за замовчуванням в них видимі найбільш часто використовувані, т. Е. Корисні для користувача, пункти.

Розумне запозичення

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

Запозичення чужих інтерфейсних знахідок не є чимось непристойним. Програми, лідируючі па ринку, є невичерпним джерелом натхнення для розробників більш дрібних програм, разюче нагадують легендарний NortonCommander: FAR, VolcovCommander, DOS Navigator, DISCoCommander

Особливості реалізації інтерфейсу власного «Індивідуального проекту»

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

На головному діалоговому вікні буде реалізовано кнопкову форму в якій користувач зможе задати точку відправлення та точку прибуття. В наступному вікні йому відобразиться вікно з графічним малюнком Рис1.

Рис1. Одна з можливих реалізацій інтерфейсу запиту

Висновок

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

Література

1. http://citforum.ck.ua/cfin/prcorpsys/infsistpr_02.shtml