1. Принципи на проектирането на потребителски интерфейс 5 Взаимодействие с потребителя



Дата18.11.2017
Размер341.85 Kb.
Размер341.85 Kb.





Съдържание:

1. Принципи на проектирането на потребителски интерфейс 5

2. Взаимодействие с потребителя (User interaction) 11

3. Представяне на информацията (Information presentation) 17

3.1. Цветове при проектиране на интерфейси 26

4. Система за помощ (User support) 29

4.1. Съобщения за грешки 31

4.2. Проектиране на система за помощ (Help system design) 34

4.3. Потребителска документация 39

5. Оценка на интерфейса (Interface evaluation) 42

Проектирането на компютърни системи обхваща спектър дейности, включващ от проектиране на хардуер до потребителски интерфейс. Докато за проектиране на хардуер се подбират специалисти, то малко организации набират интерфейс дизайнери. Затова софтуерните проектанти често отговарят за дизайна на потребителския интерфейс, както за разработката на самия софтуер. В големи организации в помощ могат да бъдат Human Factor – специалистите, докато малките не разполагат дори с такива.

Добре разработеният потребителски интерфейс е решаващ за успеха на една система.Интерфейс, който е труден за използване, в най-добрия случай ще донесе много потребителски грешки. В най-лошия случай, потребителите просто ще откажат да използват системата без значение на нейната функционалност. Ако информацията е представена по объркващ или подвеждащ начин, потребителите може да не разберат нейния смисъл.Те може да предприемат поредица от действия, които да изопачат данните или дори да доведат до катастрофални грешки.

В началото на 80-те стандартното средство за комуникация между потребителя и компютъра беше комуникационен терминал, изцяло в текстов режим на монохромен монитор. В най-добрия случай можеше да се импровизира с т.нар. псевдографика, която използваше текстови символи. Възможностите за определяне на езика се ограничаваха до базираните на стандартните латински символи. Днес почти всеки потребител разполага с персонален компютър. Използва се графичен интерфейс (Graphic User Interface, GUI) с реалистична цветна картина при висока разделителна способност и средства за въвеждане освен клавиатура, така и мишка, таблет, джойстик, дори контактни екрани.

Въпреки, че текст-базираните интерфейси все още са широко разпространени, особено при наследени системи (legacy systems - разработени първоначално по старите стандарти и периодично обновявани), компютърните потребители вече очакват от приложните системи поне някакъв базов графичен интерфейс. Може да групираме основните му характеристики в следната таблица:


Характеристика

Описание

Прозорци

(Windows)

Повече прозорци позволяват множествена информация да се представи на потребителския екран.


Икони

(Icons)

Иконите могат да представят различна по тип информация. За някои системи иконите представляват файлове, за други – процеси.


Менюта

(Menus)

Командите се избират посредством менюта вместо да се въвеждат на команден език.


Показване

(Pointining)

Показващото устройство (като мишка) се използва за избор от меню или за маркиране на желани елементи от прозорец.


Графики

(Graphics)

Графичните елементи могат да се комбинират с текст върху екрана.

Предимствата на GUI са:



  1. Относително лесен за разучаване и използване. Дори потребители с базови компютърни умения могат да се научат да използват интерфейса след кратко обучение.

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

  3. Бързина – работа върху целия екран позволява незабавен достъп до коя да е област или елемент.

Задача на тази глава е да обърне внимание на софтуерните разработчици за значението на потребителския интерфейс. Проектантите често са компетентни потребители в използването на технологии като Java’s Swing classes или HTML, които са фундаментални за имплементирането на потребителски интерфейс. Все пак често се случва те да не използват тази технология по подходящ начин, създавайки решения, които са неуместни и трудни за използване.

По тези причини, нека фокусираме върху базови принципи за проектиране на потребителския интерфейс, вместо върху средствата за имплементирането му. Ще се спрем основна на графичните интерфейси, като не отделяме внимание на частни случаи, когато е необходим специален вид поради извънредни ограничения (например мобилни телефони, видео/DVD плеъри, копирни и факс-апарати).

На следната схема илюстрираме итеративния процес за разработване на потребителски интерфейс.



Изследователският подход е най-ефективния начин за разработване на потребителски интерфейс. Изготвянето на предварителни прототипи може да започне с моделиране на лист преди да се премине към разработване на екранно-базиран интерфейс, който да симулира взаимодействие с потребителя. Потребителски централизирания похват означава, че крайният клиент играе активна роля в процеса на проектиране. В някои случаи потребителят играе само контролна роля, в други – участва като пълноправен член на проектния екип.

Критичен момент при разработката на GUI е преценяването на потребителската дейност, която ще се поддържа от софтуерната система. Без разбиране какво потребителя желае да прави с програмата, няма реалистична перспектива за разработване на ефективен интерфейс. За да се развие това умение, трябва да използвате похвати като анализ на задачите (task analysis), етнографско изследване, интервюта и наблюдение на клиентите или обобщено – по малко от всичко.

1. Принципи на проектирането на потребителски интерфейс

Дизайнерите трябва да вземат предвид физическите и мисловни способности на потребителите, които ще използват софтуера. Хората имат ограничена кратковременна памет и правят грешки, особено когато трябва да работят с много информация или са в състояние на стрес. Различните хора имат различни физически способности. Всичко това трябва да се вземе предвид, когато се разработва потребителския интерфейс.

Човешките способности са основа за принципите на проектиране, както е показано на следната таблица:


Принцип

Описание

Пригодност

(User familiarity)

Интерфейсът трябва да използва термини и концепции, извлечени от опита на хората, които най-много използват системата


Цялостност

(Consistency)

Интерфейсът би следвало да бъде цялостен по отношение на това, че подобните операции трябва да се активират по аналогичен начин


Минимална изненада

(Minimal surprise)

Потребителите не трябва никога да остават изненадани от поведението на системата


Възстановимост

(Recoverability)

Интерфейсът да включва механизми, които да позволяват на потребителите лесно да възстановят състоянието в нормален режим, след грешки


Направляване на потребителя

(User guidance)

Интерфейсът би следвало да предоставя смислена обратна връзка при възникване на грешки и да предлага контекстно-зависими средства за помощ


Разнородност на потребителите

(User diversity)

Желателно е да има подходящ набор от възможности за комуникация с различни категории потребители

Това са основни принципи, които са приложими за всички потребителски интерфейси и обикновено би требвало да се детайлизират за съответните организации или типове софтуерни системи.

Принципът на запознаване на потребителя със съответната програма предполага, че от него няма да се очаква да се адаптира към интерфейса, а точно обратното. Интерфейсът трябва да използва термини, познати на потребителя и обектите, които би трябвало да използва термини, познати на потребителя и обектите, които ще се манипулират чрез системата би трябвало да са свързани с потребителската среда (User familiarity). Например при проектиране на система за въздушен контрол, обектите, които се манипулират би трябвало да са самолети, въздушни пътища, семафори и пр., а съответните операции: настройки на курса и промяна на височината. Вътрешната интерпретация на интерфейса във файлове и структури от данни би трябвало да е скрито за крайния потребител.

Принципът за цялост на интерфейса (Consistency) означава, че системните команди и менюта би трябвало да имат един и същ формат и синтаксис, параметрите да се предават към всички команди по един и същи начин. Еднородните интерфейси намаляват времето за обучение на потребителя. Знанията, придобити за една команда (или програма) са приложими и за други части от системата.

Интерфейсната цялост за подсистеми е също важна. Доколкото е възможно команди с подобна функция би трябвало да се изразяват по подобен начин за различните подсистеми. Честа причина за грешки е, когато един и същ бърз бутон (shortkey) означава различни действия за различни системи. Например ако в една текстообработваща програма + означава да се удебели текста, докато в графична програма за създаване на диаграми + премества избрания обект над друг, то при едновременно използване на 2-те програми едновременно, може да възникнат особени грешки, като например ако опитаме удебелим текст в диаграма, той ще изчезне под припокриващия го обект. Графичните операционни системи обикновено дефинират стандартни бързи клавиши (shortkeys) и би следвало потребителския интерфейс да е съобразен с това, за да се избегнат потребителски грешки от този вид.

Разгледаната цялост може да се счита от ниско ниво. Очаква се от проектантите винаги да се стремят да го постигнат в своя потребителски интерфейс. Целостта на високо ниво често е също много желателна. Например може да е уместно да се поддържат едни и същи операции като например печат (Print), копиране (Copy) и др. за всички типове системни слоеве. Въпреки това трябва да изтъкнем, че пълна цялост не е нито възможна нито желателна. Ако например е удобно да изтриваме обекти от desktop-а като ги влачим до кошчето, то би било неестествено да изтриваме текст от текстообработваща програма по този начин.

Принципът за минимизиране на т.нар. елемент на изненадата (Minimal surprise) е също уместен, защото потребителите много се дразнят когато системата се държи по неочакван за тях начин. Докато използват системата, потребителите си изграждат мислен модел за това как тя работи. Ако действие в един контекст водят до някаква промяна, оправдано е да се очаква, че същото действие в друг контекст ще доведе до подобна промяна. Ако се случи нещо съвсем различно, потребителят е както изненадан, така и объркан. Следователно проектантите на интерфейса трябва да гарантират, че подобните действия ще имат и подобен ефект.

Принципът на възстановимост (Recoverability) е важен, защото потребителите неизбежно правят грешки, когато използват системата. Интерфейсът трябва да ги минимизира (например използването на командно меню избягва грешките при писане), но те не могат никога напълно да се елиминират. Потребителските интерфейси трябва да съдържат средства, позволяващи потребителите да възстановяват данните ако сгрешат. Това може да се осъществи по 2 начина:



  1. Потвърждение на деструктивни операции. Ако потребителите изберат действие, което е потенциално деструктивно, би следвало от тях да се поиска потвърждение дали те наистина желаят това и едва тогава да се унищожава каквато и да е информация.

  2. Предоставяне на Undo-средства. Undo възстановява до състояние на системата, каквото е било преди извършеното действие. Множествени нива на undo са още по-полезни, тъй като потребителите не винаги веднага разпознават грешката, която са направили.

Удобен принцип е принципът за ръководене на потребителя (User guidance). Желателно е интерфейсите да имат вградено подпомагане на потребителя или помощни средства. Те трябва да са интегрирани със системата и да предоставят различни нива за помощ. Нивата трябва да са разделени от базова информация за начинаещи потребители до пълно описание на системните средства. Помощните средства трябва да са структурирани и не би трябвало потребителя да се претрупва с информация, когато поиска за помощ.

Принципът за разнородност на потребителите (User diversity) се основава на факта, че много интерактивни системи може да се използват от различни категории потребители. Някои може да са случайни потребители, които прецедентно работят със системата, други може да са опитни (power users), които да използват системата няколко часа всеки ден. Случайните потребители се нуждаят от интерфейси, които да ги ръководят, докато опитните изискват бързи бутони, които да им позволява да работят колкото е възможно по-бързо. Други потребители може да имат различни увреждания и ако е възможно, интерфейсът трябва да бъде приспособим и към тях. Следователно може да е необходимо да се предоставят средства за представяне на увеличен текст, замяна на звук с текст или за уголемени бутони и т.н.

Принципът за разнородни потребители може да бъде в конфликт с други принципи за разработка на GUI, защото някои типове потребители може да предпочитат бързото взаимодействие с програмата вместо (например) да държат на цялостност на интерфейса. По подобен начин, нивото на ръководене на потребителя може да бъде различно за различните категории потребители. Следователно може да се окаже невъзможно разработване на помощ за всички категории. Проектантът на интерфейса трябва неизбежно да направи компромис в зависимост от реалните потребители за съответната система.

2. Взаимодействие с потребителя (User interaction)


Проектантът на потребителския интерфейс е изправен пред 2 основни въпроса: Как може информацията от потребителя да се въведе в компютърната система и обратно – как данните от системата да се представян на потребителя? Кохерентният потребителски интерфейс може да обедини взаимодействието с потребителя и представянето на информацията.

В тази секция ще разгледаме взаимодействието с потребителя. Това представлява въвеждане на команди (и свързани с тях данни) на компютърната система. При ранните компютри единственият начин да се извърши това бил през интерфейс с команден ред, където се използва специален команден език за комуникиране с машината. Това било приложимо само за експерти, докато се разработвали множество допълнения, които да улесняват работата. Тези различни форми на взаимодействие може да се класифицират в 5 основни стила:



  1. Директно въвеждане (direct manimulation), където потребителят директно работи с обектите на екрана, например за да изтрие файл, потребителят може да влачи в кошчето.

  2. Избор от меню (menu selection), където потребителят избира команда от списък с възможности (меню). Често в този случай, в това време се избира друг екранен обект и командата работи с него. При този метод, за да се изтрие файл, потребителят го маркира и избира команда "изтрий" (delete).

  3. Попълване на форми (Form fill-in), където потребителя попълва полета във форма. Някои полета, може да имат асоциирани менюта и формата може да има командни бутони, които при натискане да изпълнят операция. Би изглеждало изкуствено да се изтрива файл от форма-базиран интерфейс (form-based interface). Това би било свързано с изписване на името на файла и последващо натискане на бутон за изтриване.

  4. Команден език (command language), където потребителят въвежда специални команди и съответни параметри, за да укаже на системата какво да прави. За да изтрие файл, потребителят въвежда delete-команда с името на файла, като параметър.

  5. Естествен език (natural language). Потребителят използва естествен език. В този случай, за да изтрие файл, потребителят може да напише "Изтрий файла с име ...".

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


Стил въвеждане на данните

Основни предимства

Основни недостатъци

Приложни примери

Директно манипулиране

(Direct manipulation)

Бързо и интуитивно въвеждане; Лесно за заучаване

Може да е трудно за вграждане; Подходящо само когато има визуален манипулатор на задачи и обекти


Видео игри;

CAD системи



Избор от меню

(Menu selection)

Предотвратява потребителски грешки;

Изисква малко писане



Бавно за опитни потребители;

Може да стане сложно при много опции на менюто




Повечето системи с общо предназначение

Попълване на форми

(Form fill-in)

Лесно за въвеждане на данни;

Лесно за заучаване




Отнема много екранно пространство

Складова база;

Финансови операции



Команден език

(Command language)

Мощен и гъвкав

Труден за заучаване;

Слаб контрол на грешките



Операционни системи;

Системи за извличане на справочна информация




Естествен език

(Natural language)

Достъпен за случайни потребители;

Свободен за разширяване



Изисква много писане;

Системите за работа на естествен език са ненадеждни



Системи за разписания;

Системи за извличане на информация от интернет


Разбира се, тези категории на потребителски вход могат да се смесват и да се използват различни подходи в едно и също приложение. Например Microsoft Windows поддържа директно манипулиране на иконите на файловете и директориите, меню-базирани команди, а за някои команди, като конфигурационните, потребителя може да попълва и специално предоставени форми.

Потребителските интерфейси в интернет са базирани основно на HTML (описателния език, използван за WEB страници) заедно с езици като Java, която може да асоциира програми с компоненти на страницата. Докато тези WEB-базирани интерфейси често се проектират за случайни потребители, те често използват форма-базирани интерфейси. Възможно е да се конструира интерфейс за директно въвеждане в WEB-страницата, но това все още е сложна програмна задача.

По принцип е възможно да се раздели подхода за взаимодействие с потребителя от вътрешните програмни слоеве, които се манипулират от този интерфейс. Това е база за Seeheim-модела. В този модел представянето на информацията, управлението на диалозите и приложението са отделени. Реално този модел е по-скоро идеален отколкото практичен, но предоставя сигурна възможност да се отделят интерфейси за различните типове потребители (например случайни потребители и опитни такива), които взаимодействат с една и съща вътрешна подсистема. Това е илюстрирано на следната фигура, която демонстрира интерфейс с команден език и графичен такъв към обща операционна подсистема, като Linux.



Това разделяне на представянето, взаимодействието и елементите, които са замесени в потребителския интерфейс е фундаментално за принципа "Модел-Изглед-Управление" (Model-View-Controller, накратко MVC). Той е сравним с Seeheim-модела, но се използва за интерфейс на обекти, вместо за цели приложения.



3. Представяне на информацията (Information presentation)

Всички интерактивни системи трябва да предоставят по някакъв начин информацията на потребителя. Това може да бъде директно извеждане на данните (както в текстообработваща програма) или чрез графично изобразяване. Добра практика е разделянето на софтуера, който се изисква за представяне на данните от самата информация. За някои специфични приложения, това противоречи на обектно ориентирания принцип, който предполага, че операциите върху данните се дефинират заедно със самите данни. Въпреки това се предполага, че проектантът на обектите знае най-добрия начин за представяне на информацията, макар че реално не винаги е така. Често е трудно да се открие най-добрия начин за представяне на данни, когато те вече са дефинирани и ако обектните структури трябва да не са твърдо свързани с представящите операции.

С разделяне на изходната система от данните, представянето на потребителския екран може да се смени, без да се налага промяна на вътрешната изчислителна система. Това е илюстрирано на следната фигура:

MVC-метода, който е бил достъпен най-напред в Smalltalk, е ефективен начин да се поддържат множество представяния на данни. Потребителите могат да взаимодействат с всяко от тях, посредством стил, който да им съответства. Данните, които се представят са капсулирани в моделен обект. Всеки от тях може да е асоцииран с множество отделни визуални обекти, всеки от които да има собствено представяне на модела на екрана.



Всеки визуален обект има асоцииран контролен обект, който управлява потребителския вход и средствата за взаимодействие. Затова моделът, който представя числови данни, може да има изглед, който да представя данните като хистограма, както и изглед в табличен вид. Моделът може да се редактира с промяна на стойностите в таблицата или с удължаване/скъсяване на стълбовете на хистограмата.

Намирането на най-добрия начин за представяне изисква познаване на самата информация, на компетентността на потребителите и начина по който те използват системата. При решаване как да се представи информацията, дизайнерът трябва да вземе предвид няколко фактора:


  1. Дали потребителят се интересува от прецизиране на информацията или от връзки между различните стойности?

  2. Колко бързо данните се променят? Би ли трябвало промените в стойностите да се индицират веднага на потребителя?

  3. Трябва ли потребителят да предприеме някакви действия в отговор на промени на информацията?

  4. Трябва ли потребителят да взаимодейства с изобразената информация посредством интерфейс за директен вход?

  5. Дали информацията, която се изобразява е текстова или числова? Дали конкретните стойности на елементите са толкова важни?

Информацията, която не се променя по време на сесията, може да се представи както графично, така и чрез текст (в зависимост от приложението). Текстовото представяне изисква по-малко екранно пространство, но не може да се възприема веднага. Информацията, която не се променя би трябвало да се разграничава от динамичната информация посредством различен стил на изобразяване. Например цялата статична информация може да се изведе в различен шрифт или да се открои, посредством различен цвят или винаги да има асоциирана с нея икона.

Информацията би трябвало да се представя като текст, когато се изисква прецизиране на числови данни, които се променят относително бавно. Ако се променят бързо или ако връзките между данните са важни, обикновено се използва графично представяне.

Например може да разгледаме система, която записва и сумира месечните продажби на една компания. Следната фигура илюстрира как една и съща информация може да се представи в текстов и в графичен вид.

Мениджърите, които разучават продажбите обикновено се интересуват от тенденцията или от необичайни промени, вместо точни стойности. Графичното представяне на тази информация като хистограма, прави забележими аномалните промени през м. Март и м. Май. Тази фигура още илюстрира как за една и съща информация, текстовото представяне изисква по-малко място отколкото графичното.

Информацията с динамично променящи се числови стойности най-добре се представя графично с използването на аналогови елементи. Постоянно менящите се цифрови индикатори са объркващи, тъй като прецизната информация не се асимилира бързо. При необходимост, графичните дисплеи могат да се предложат с конкретни числови стойности. На следната фигура са показани различни начини за представяне на динамично променяща се числова информация.

Непрекъснатите аналогови изображения дават на потребителя усещането за относителна стойност. На следната фигура стойностите за температурата и налягането са приблизително еднакви (като числа). Въпреки това, графичният дисплей показва, че температурата е близко до своята максимална стойност, докато налягането не е достигнало и четвърт от своя максимум.



Получавайки само цифри, потребителят отделно ще трябва да знае и максималните стойности, а относителната позиция – да изчислява наум. Това допълнително мислене, което се изисква в този случай, води до човешки грешки или до стресови ситуации, когато резултатите са от критично значение.

При специфициране с текстова информация, графиката може да се използва като фон за приблизителна ориентация. Вместо представяне на ред информация, може да се използва прозорец с икона. Той припокрива текущата екранна сесия и потребителското внимание неминуемо се прехвърля върху него.

Графичното осветяване (graphical highlighting) може също да се използва за привличане на потребителското внимание върху отделни части от екрана. Въпреки това, ако тези промени се случват бързо, визуализацията може да се възприеме като мигане. Това разсейва и дразни потребителите.

Когато трябва да се представи голям обем информация, може да се използва абстрактна визуализация, която да представи взаимосвързани данни. Това може да са връзки, които не са очевидни от необработените данни. Дизайнерите на потребителския интерфейс би трябвало да са наясно с възможностите за визуализация, особено когато системния потребителски интерфейс, се отнася за реални физически обекти. Примери за визуализиране на данни са:


  1. Когато информацията, събрана от множество източници се показва като климатологична карта с изобари и климатични фронтове и др.

  2. Телефонна мрежа може да се изложи графично като свързани множество възли в мрежов управляващ център.

  3. Състоянието на химически завод се визуализира с представяне на налягания и температури в свързано множество съдове и тръбопроводи.

  4. Молекулярен модел се представя и манипулира в 3 измерения (3D), с използването на система за виртуална реалност.

  5. Множество WEB страници се представя като хиперболично дърво.

Shneiderman (1998) класифицира методите за представяне в различни класове в зависимост от тяхното предназначение. Те включват визуализиране на данни посредством 2D и 3D, както и дървовидни структури или мрежи. Повечето от тях са свързани с представяне на големи обеми информация, която се управлява чрез компютъра. Въпреки това, най-общият начин за използване на визуализацията при потребителските интерфейси е да се представи някаква физическа структура (като молекулярната формула на ново лекарство), връзките в телекомуникационна мрежа и др. Тримерните представяния (3D), които може да използват специално оборудване за виртуална реалност са практически ефективни при визуализация на отделни продукти. Директното манипулиране на тези обекти е много ефективен начин за взаимодействие с данните.

3.1. Цветове при проектиране на интерфейси


Всички интерактивни системи (освен специализираните), дори системите с малки екрани поддържат цветни дисплеи и потребителските интерфейси могат да ги използват по различни начини. В някои системи (като текстовите редактори) цветът е просто използван за осветяване, в други (като CAD системите), се използват за да се разграничат различни слоеве при проектирането.

Цветът може да подобри интерфейсите, подпомагайки потребителите да разберат и управляват по-сложни представяния. Въпреки това, някои дизайнери лесно пропускат тази възможност и създават интерфейс, който е визуално неатрактивен и предразполагащ към грешки. Независимо от това, като основен принцип, дизайнерите на интерфейсите трябва да подхождат консервативно в използването на цветовете. Shneiderman (1998) дава 14 основни насоки за ефективно прилагане на цветовете в интерфейсите. Най-важните са:




  1. Ограничете броя използвани цветове и бъдете консервативен в използването им. Не е желателно да използвате повече от 4 различни цвята в един прозорец и не повече от 7 за целия интерфейс.

  2. Използвайте промяна в цвета за да означите промяна на състояние в системата. Ако имаме смяна на цвят на екрана, то това би означавало настъпване на значимо събитие. Така за показателя за горивото, смяната на цвета може да означава че то е на привършване. Цветовото осветяване е особено важно за комплексни екрани, където се визуализират стотици различни елементи.

  3. Използвайте цветови означения в задачите, които потребителите опитват да изпълнят. Ако те трябва да открият някои аномалии в данните - оцветете съответните данни; аналогично използвайте цветове за да се открият лесно подобия и аналогии.

  4. Влагайте отделните цветове (color coding) обмислено и обобщавайте схемите на цветоразделяне за цялата система. Ако една част на системата изобразява съобщения за грешки в червено, то и останалите подсистеми трябва да следват това правило. Тогава не би следвало да използвате червено за нищо друго. Ако го направите, потребителят може да го възприеме като съобщение за грешка. Трябва да сте наясно, че някои категории потребители правят предположения за определени цветове.

  5. Бъдете внимателни в подбора на цветни комбинации (color pairings). Поради физиологията на окото, хората не могат да фокусират червено и синьо едновременно. Естествено, има и други цветови съчетания, които също да са визуално смущаващи или трудни за възприемане. Последователното редуване на тези цветове може да доведе до умора на очите.

Двете най-чести грешки, които правят дизайнерите, когато влагат цветове в интерфейса са да свържат определени цветове с определен смисъл и да използват твърде много цветове на екрана.

Един цвят не можа да се използва за две неща. Около 10 процента от хората имат някаква форма на далтонизъм и може да не разберат смисъла, който сте заложили. Човешките възприятия за цвят са различни и има различни конвенции в различните професии за смисъла, който носят определени цветове. Потребителите от различни среди може подсъзнателно да разберат един и същ цвят по различни начини. Например, за шофьора червеното обикновено означава опасност, докато за химика то означава горещо.



Ако се използват твърде много цветове или ако са твърде ярки, екранът може да изглежда объркващ. Многото цветове може да смутят потребителя (точно както една абстрактна картина не може да се гледа спокойно за дълго време) и да провокират умора. До объркване може да доведе и безразборното използване на един цвят за различни обстоятелства

4. Система за помощ (User support)


Принцип на проектиране, който предложихме още в началото е, че потребителските интерфейси би трябвало винаги да предоставят някаква форма навременна на система за помощ (help). Help-системите са само част от големия дял от проектирането на потребителския интерфейс, а именно ръководене на потребителя, което покрива три области:

  • съобщенията, издавани от системата в отговор на потребителски действия;

  • своевременната система за помощ (help);

  • документацията, предоставена заедно със системата.

На разработването на съдържателна информация би трябвало да се гледа сериозно и би трябвало да е предмет на същия качествен процес както дизайна или програмния алгоритъм. Ръководителите трябва да предвидят достатъчно време и усилия за разработването на съобщения и може би ще е уместно за се замесят професионални филолози и графични дизайнери в този процес. При това разработване трябва да се вземат предвид следните фактори:


Фактор

Описание

Контекст

(Context)

Системата за ръководене на потребителя трябва да е наясно какво той прави в момента. Тя трябва да адаптира изходните съобщения към текущия контекст.


Компетентност

(Experience)

След като потребителите свикнат със системата, те се дразнят от дълги “безсмислени” съобщения. Въпреки това, за начинаещите е трудно да разберат сбито излагане на проблема. Системата за ръководене на потребителя би трябвало да предоставя и двата типа съобщения и да позволява на потребителя да настройва степента на изразителност.


Умения

(Skill level)

Съобщенията трябва да се съставят според уменията на потребителя както и според неговия натрупан опит. За различните типове потребители трябва да се използват изразни средства, съответстващи на ниво и тяхната среда на работа.


Стил

(Style)

Съобщенията трябва да носят позитивен смисъл вместо негативен. Би трябвало да са адресирани към потребителя вместо безлични. Никога не трябва да бъдат обидни или да опитваме да ги правим забавни.


Националност

(Culture)

Когато е възможно, би било добре ако дизайнера е запознат с местната култура и манталитет за региона, където се продава софтуерната система. Има специфични разлики между културите на Европа, Азия и Северна Америка. Съобщение, което е подходящо за една култура може да бъде неприемливо за друга.




4.1. Съобщения за грешки


Първото впечатление, което потребителите може да получат за софтуерната система са системните съобщения за грешки. Неопитен потребител може да започне работа, да направи инициализираща грешка и да се наложи да разбере от каква е.

Образователното ниво и опита би трябвало да са предвидени когато се разработват съобщенията за грешки.

Пример: Да предположим, че системен потребител е мед. сестра в интензивно отделение. Състоянието на пациентите се следи от компютърна система. За да се разгледат текущите данни (температура, пулс и др.) за даден пациент, системният потребител трябва да избере "Покажи" (Display) и да въведе името на пациента в диалога, както е показано:

В този случай, да предположим, че името на пациента е Pates вместо Bates и въведеното от сестрата име не може да бъде разпознато. Системата генерира съобщение за грешка. Съобщенията за грешки би трябвало винаги да са учтиви, стегнати и съдържателни. Не трябва да бъдат обидни или да издават звукови сигнали, които биха смутили потребителя. Когато е възможно, съобщението трябва да предлага начин за коригиране на грешката. Съобщенията трябва да са свързани с контекстно ориентирана система за помощ.

Следната фигура показва примери за добри и лоши съобщения за грешки:

Съобщението вляво е лошо разработено. Има негативен смисъл (индиректно обвинява потребителя за направената грешка), не е пригодено към уменията на потребителя и нивото му компетентност и не е съобразено с контекста. То не предлага начин за решаване на проблема, Използва термини, специфични за системата (ID) вместо потребителски-ориентиран език. Съобщението вдясно е по-добро. Позитивно е, загатвайки, че проблемът е системен, вместо потребителски. Описва го с термини, от средата на мед. сестра и предлага лесен начин да се коригира грешката единствено с натискането на бутон. Контекстно-ориентирана система за помощ може допълнително да се извика.



4.2. Проектиране на система за помощ (Help system design)


Когато на потребителя се представи съобщение за грешка, което той не разбира, той се обръща за повече информация към системата за помощ. Може да имаме пример за "Помощ!", което да означава "Помощ! Имам проблем(и).". Също така може да получим заявка от вида "Помощ?" със смисъл на "Помощ, искам повече информация.". Необходими са различни системни средства и структури съобщения за различните видове помощ.

Помощните системи (help systems) би следвало да предлагат много входни точки. Те би трябвало да позволяват на потребителя да влезе в помощната система от върха на йерархията и да проследява принципа за работа. Освен това обаче, те може да влязат в системата за да получат обяснение за системна грешка или да искат информация за определена команда.

Всички изчерпателни системи за помощ имат сложна мрежова структура, където всяка информация може да адресира към няколко други секции. Структурата на тази мрежа обикновено е йерархична, многосвързана, както е показано на примерната схема. Обобщената информация е предимно около върха, разклоненията надолу конкретизират различните детайли от дизайна.

Може да възникне проблем, когато потребителят влезе в системата след допускане на грешка и впоследствие да продължи, следвайки вътрешните връзки. За кратко време той може безнадеждно да се изгуби. Тогава трябва да напусне системата и да влезе отначало от позната вече входна точка.

Показването на помощната информация в няколко прозореца може да облекчи тази ситуация.

На фигурата е показан екран с три помощни прозореца.



Трябва обаче да се отчита и факта, че екранното пространство винаги е ограничено и показването на допълнителни прозорци може да закрие друга важна информация.

Текста в помощната система трябва да се подготвя заедно с приложен специалист. Помощната секция не би трябвало да е просто извадка от потребителското ръководство тъй като информацията от хартиен носител и от дисплея се възприема по различни начини. Текстът сам по себе си, разположението му и стила трябва да бъдат внимателно подбрани за да се гарантира, че ще е четим в сравнително малък прозорец. От показаната фигура, секцията "Пренасочване на е-писмо" (Mail redirection) е сравнително кратка. Не би трябвало да претрупвате потребителя с информация в която и да е секция. Предоставени са три бутона: за подробности по тази тема, препратка към следваща секция и показване на списък от наличните помощни теми.

Прозорецът "История" (History) показва секциите, които вече са били посетени. Би трябвало да е възможно връщане към тях с избиране на елемент от списъка. Навигационния прозорец (Map) е своеобразна карта на разпределението на мрежата на помощната система. Текущата позиция би следвало да е осветена с различен цвят, със сянка или (както е в нашия случай) отбелязана с анотация.

Потребителите трябва да могат да се местят по секциите посредством препратките от настоящата, чрез избор от "История" (за да препрочетат предишна или да сменят направлението) или с маркиране директно от "Карта" (Map).

Помощните системи може да се вграждат като набор от взаимосвързани интернет страници или с използване на обща hypertext система, която може да се интегрира в приложението. Йерархията може лесно да се интерпретира с отделни части от съобщението, които да представляват препратки (links). Интернет системите имат предимството, че могат лесно да се вградят и не изискват специален софтуер. Въпреки това може да се окаже сложно да се свържат към приложението като контекстно-ориентирана помощ.



4.3. Потребителска документация


Потребителската документация не е задължително част от потребителския интерфейс, но е добра практика да се разработва заедно с помощната система. Системните ръководства би трябвало да предоставят по-детайлна информация от помощната система и би следвало да се проектират така, че да се използват от различни нива крайни потребители.

За да се гарантира това трябва да има поне пет свитъка (или различни глави в общ документ), които да се доставят със софтуерната система.

Тези документи са:


  1. Функционално описание (functional description), което би трябвало съвсем накратко да описва услугите, които системата предлага. Потребителите могат да четат този материал като въвеждащо ръководство и да решат дали системата е това от което имат нужда.

  2. Инсталационно ръководство (installation document), което да подпомага потребителя при инсталацията на продукта. То следва да описва инсталационните дискове, които доставят системата, файловете (или поне структурата от папки) на тях, минималните и препоръчителни хардуерни изисквания и др. От него се очаква да инструктира при инсталацията, а също и да укаже как да се настроят конфигурационните файлове.

  3. Въвеждащо ръководство (introductionary manual), което да представлява неформално въведение в системата, описвайки нейното "класическо" приложение. То описва как да се навлезе и как крайните потребители могат да извлекат полза от общите системни средства. Препоръчително е да бъде илюстрирано с примери, също и как да се коригират допуснати грешки и как да се върнем обратно към нормален процес. Caroll (1982) предполага, че възстановяването от грешки и минимизиране на информацията, която потребителите трябва да четат (с елиминиране на излишеството) е ефективен начин да се организират въвеждащи ръководства.

  4. Справочно ръководство (reference manual). То има за задача да опише системните средства и тяхното използване, предоставя списък от системни съобщения и възможни причини, както и описва как да се възстанови работния режим при откриване на грешки.

  5. Ръководство на администратора (administrator's manual) е необходимо само за някои типове системи. То описва съобщенията, генерирани, когато системата взаимодейства с други такива и как да се реагира в съответните ситуации. Ако работата на системата е пряко свързана с определен хардуер, то би трябвало да обяснява как да се възстановява от хардуерни проблеми, как да се подвържат нови периферни устройства и т.н.



5. Оценка на интерфейса (Interface evaluation)


Оценката на интерфейса е процесът на преценка на полезността му и проверка дали покрива потребителските изисквания. Следователно той би трябвало да е част от нормалната проверка и процес на валидиране на софтуерните системи.

В идеалния случай оценката се води съобразно спецификацията за полезност, базирана на следните атрибути:




Атрибут

Описание

Научимост (Learnability)

Колко време е необходимо на потребителя за да стане продуктивен със системата?


Ефективност

(Speed of orientation)

До каква степен реакцията на системата съответства на натрупания опит на потребителя? Неопитният потребител би губел време със система, ориентирана към бързи клавиши, както и обратно – опитният ще се отегчи от класическите командни менюта.


Яснота

(Robustness)

До колко системата е толерантна към потребителски грешки?


Възстановимост

(Recoverability)

До колко системата може да се възстанови от потребителски грешки?


Адаптивност

(Adaptability)

Колко тясно е обвързана системата с единствен модел за работа?

Мерните единици за атрибути за полезност могат да се предефинират. Например единица за научимост (Learnability) може да изразява, че оператор, който е запознат с естеството на работа би трябвало да е в състояние да използва 80 % от функционалността на системата след тричасова сесия на обучение. Много по-общо е качествено да се специфицира полезността (ако изобщо е специфицирана), вместо да се използват мерни единици. Следователно проектантите на интерфейса трябва да използват тяхната преценка и опит при оценката на интерфейса.

Систематичната проверка на потребителският интерфейс може да бъде скъп процес, включващ специалисти от съответната приложна област и графични дизайнери. Тя може да включи разработване и провеждане на значителен брой статистически експерименти с типични потребители в специално създадени лаборатории, оборудвани с апаратура за наблюдение. Оценка на потребителски интерфейс от този род е икономически нереална за системи, разработени от малки организации с ограничени ресурси.

Има много по-прости, по-евтини техники за оценка на потребителски интерфейс, които да открият недостатъците на отделен потребителски интерфейс:



  1. Въпросници (questionnaires), които събират информация какво потребителите мислят за интерфейса;

  2. Наблюдение на потребителите (observation of users) по време на работа със системата "разсъждавайки на глас" за това как те опитват да използват системата за да извършат определена задача;

  3. Кадри от видеозаписите (video snapshots) от типично използване на системата;

  4. Включването в софтуера на код, който събира информация за най-използваните средства и най-честите грешки (instrumenting code).

Изследване на потребителите с използването на въпросници (questionnaires) е относително евтин начин за оценяване на интерфейса. Въпросите трябва да са по-скоро конкретни отколкото общи. Безполезно е да се задават въпроси като: "Моля, коментирайте полезността на интерфейса!" понеже отговорите може да варират толкова, че да е невъзможно да се обобщят. Вместо това, конкретни въпроси като: "Моля оценете разбираемостта на съобщенията за грешки по скала от 1 до 5 (1 – напълно ясни, 5 - непонятни)!" са много по-добри. Те са едновременно лесни за отговаряне и много по удобни за извличане на информация за подобряване на интерфейса.

При попълване на въпросника, потребителите трябва да бъдат запитани и да оценят собствените си опит и образователно ниво. това позволява на дизайнера да открие дали потребители от определено образователно ниво имат проблеми с интерфейса. Въпросниците могат да се използват дори преди да е доставена изпълнимата версия на продукта ако им се предложи предварителен прототип на хартия.

Методът, базиран на наблюдение (observation) просто включва наблюдение на потребителите докато те работят със системата, следейки за средствата, които използват, грешките, които правят и т.н. Това може да бъде допълнено от сесии с "размисли на глас", където потребителите говорят за това какво опитват да постигнат, как разбират системата и как опитват да използват системата за да изпълнят задачите си.

Относително евтино видео-оборудване означава, че може да се поддържа пряко наблюдение пряко наблюдение със записване на потребителски сесии за по-късен анализ. Пълният видео анализ е скъп и изисква специално оборудвано място с няколко камери, фокусирани върху потребителя и екрана му. Видео записите на действията на определен потребител могат да бъдат от полза за откриване на проблеми. Другите методи за оценка трябва да се използват за да се открие кои операции създават трудности на потребителите.

Анализът на записи позволява на дизайнера да разбере, ако интерфейсът изисква твърде често движение на ръката (проблем с някои системи е, че потребителите трябва редовно да местят ръцете си от клавиатурата на мишката и обратно) и да проследи дали е наложително неестествено местене на погледа. Интерфейс, който изисква честа смяна на фокуса може да означава, че потребителят прави повече грешки, защото пропуска части от дисплея.

Прилагането на стробиращ код (instrumenting code), който да събира статистики за използване позволява на интерфейсите да се подобрят по много начини. Могат да се установят най-общите операции. Интерфейсът може да бъде организиран така, че те да бъдат най-бързите за избор. Например ако се използват контекстното и/или падащото меню, най-често използваните операции би следвало да са най-горе, докато деструктивните – в долния край. Стробиращият код позволява още, откриване на команди, предразполагащи към грешки.

Накрая, средство за бърз потребителски отговор може да се предостави с добавянето на всяка програма на "прихващаща" (gripe) команда, която да се използва за изпращане на съобщения към поддържащия системата. Това създава усещането на потребителите, че тяхното мнение се взема предвид. Проектантът на интерфейса и другите инженери могат да получат бърза обратна връзка за индивидуални проблеми.



Никой от тези относително прости методи а оценка на потребителски интерфейс не е устойчив на некомпетентно използване и те са неспособни да открият проблемите на всички потребители. Въпреки това, техниките могат да се прилагат с група доброволци преди системата да се издаде на пазара, без особен разход на средства. Така много от най-лошите проблеми при проектирането на потребителски интерфейс могат предварително да бъдат открити и коригирани.


Сподели с приятели:


©zdrasti.info 2017
отнасят до администрацията

    Начална страница