Днес имах удоволствието да направя сравнително кратка презентация на семинара по ползваемост, организиран от Лукрат.
Ето и видеото:
Звукът може да е кофти, затова препоръчвам използването на слушалки и по-голямо внимание ;)
Слайдовете от презентацията качих в SlideShare:
Моя статия за българското списание .net.
Малко са интерфейсните елементи, които създават много проблеми и едновременно с това са толкова популярни като падащите навигационни менюта.
Те са един от най-старите елементи на графичните операционни системи. Въведени са масово за пръв път в компютрите Apple и тяхната MacOS. Най-голяма популярност придобиват заради продуктите на Майкрософт, където основната „навигация” е т.нар. файл меню. И макар Майкрософт и Епъл дълго да се съдиха, кой от кого е откраднал интерфейса, всъщност трябва да благодарим на хората от Xerox, които в началото на 70-те изобретиха първият графичен потребителски интерфейс за операционната система PARK.
В уеб падащите навигационни менюта се подвизават от доста време. Преди десетина години те бяха едно от първите превъплъщения на DHTML технологията. Уеб дизайнерите се надпреварваха да правят такива менюта и да ги използват в сайтовете си, за да покажат „високотехнологичните” си умения и да създадат усещането за неограничените технологични възможности на уеб като медия. Използването на този вид менюта се оправдаваше и с пестенето на място и опростяването на дизайна.
Сред експертите по ползваемост обаче падащите менюта съвсем не се тачат с особена популярност. И това не е случайно. Тестовете с потребители показват, че макар този интерфейсен елемент да е познат на потребителите, той създава доста повече проблеми (и то критични) отколкото решава.
Основният проблем с падащите менюта е, че спират естествения поток от действия на потребителя. Как? Представете си как отивате на една страница и я преглеждате. Въз основа на информацията, която виждате в тази страница вие вземате решение какво да направите по-нататък. Ако решите да кликнете върху линк от падащо меню изведнъж пред вас се показва скрита до момента информация (линковете в падащото подменю). Тази нова информация трябва да бъде преосмислeна и едва тогава отново бихте решили – дали да кликнете на някой от новите линкове или да огледате отново страницата за по-добър избор. С други думи нормалният процес на разглеждане на един сайт е прекъснат, а потребителят е разколебан в способността си да взема решения въз основа на видимото върху екрана.
В някои случаи падащи менюта може да е адекватно решение (напр., когато става въпрос за система, която хората ползват често, знаят структурата и имат нужда от бърз начин да се придвижват от страница на страница). В други случаи клиентът или дизайнерът не искат за нищо на света да се простят с любимото си елементче. Тогава е важно да се спазват добрите практики при дизайна.
Основно правило е да се направи така, че линковете, които предизвикват появата на падащо меню да се различават от останалите. Стандартен начин за тяхното диференциране в такъв случай е използването на стрелка или триъгълник, които сочат надолу или надясно (зависи накъде ще се покаже менюто. Освен това е важно навигацията в самите падащи менюта да не изисква голяма сръчност и упоритост, за да уцелиш точно тази връзка, която ти трябва. Много често неправилното движение кара падащото меню да се скрие или пък да се покаже съседното меню и така потребителят може да кликне върху погрешен линк. Добър пример в това отношение е навигацията на Flickr, където падащото меню се показва единствено, когато потребителят кликне стрелкичкаа надолу, а не, когато мине с мишката или кликне върху някои от основните линкове.
Разбира се изборът, кога да ползвате изскачащи навигационни менюта в дизайна си остава изцяло ваш, но следващият път, когато ви засърби да използвате един от тия „яки” JavaScript компоненти, помислете дали това е наистина необходимо и дали няма по-малко стресиращ начин да осигурите навигационен избор на потребителите си.
Моя статия за българското списание .net.
Много от нас сигурно си спомнят братята Грим и по-скоро историите и света, който описват в своите прочути приказки. Услужливите редактори и преводачи са смекчили достатъчно зловещите образи на вещици, говорещи животни, всякаквите мутанти с огромен или миниатюрен ръст и прочее малформаци, които скитат из тъмни гори и странни земи, кроят си пъклени планове, тук там се поизяждат. Сега децата се радват, когато всичко свършва добре и всички заживяват в мир.
В света на уеб дизайна обаче сме все още като че ли все още в първите и непреработени варианти на приказките. В гората наречена интернет, потребителите все още често се губят и отвсякъде ги дебнат куп опасности – огромното количество безполезни сайтове, агресивните рекламни банери, вдебилените SEO експерти.
Едно често срещано решение на проблема с изгубването (особено в по-големите сайтове) е използването на пътечки от линкове. В английския език терминът e breadcrumbs и буквално се превежда като пътечка от трохи. И както вече се досещате произлиза именно от приказката за Хензел и Гретел, които докато бягат от къщи в гората, оставят по пътя си трохи от хляб, за да могат после да се върнат обратно.
Пътечките представляват хоризонтален списък от имена на страници, които описват всяко ниво от йерархията на сайта от най-горната (началната) страница на сайта до страницата, на която се намира потребителя. Всяко име в списъка е линк към съответната страница.
Бредкръмбовете са особено полезни, когато сайтът има повече нива в йерархията си и основната навигация не може адекватно да покаже на къде точно се намира някоя страница от по-долните нива в йерархията. Те могат да помогнат на потребителите да си отговорят на два от най-важните навигационни въпроси – „Къде съм?” и „Къде мога да отида от тук нататък?”.
Някои препоръки при оформянето на пътечката:
В крайна сметка обаче е важно да се спомене, че пътечките рядко се използват от потребителите. За дизайнерите това означава, че не бива да разчитат прекалено много на тях и не е необходимо насочват прекалено много визуално внимание към тях. Вместо това е добре да се инвестира повече време в измислянето на по-добра структура и навигация.
Новият ми фаворит измежду най-смотаните интерфейси favit.bg днес ме учуди с още нещо:
Искат да въведа информацията, която търся.
Ако имах информацията, която търся, защо да я търся и още повече защо да я въвеждам в някакво поле?
Чудесно доказателство, че писането в интерфейса не е проста работа и не трябва да се пренебрегва.
Хитро са добавили информация, че тази седмица се сменя времето. Кога точно, с колко и в коя посока. Стори ми се много полезно, защото абсолютно всеки път, когато се преминава от лятно в зимно време и обратно се питам точно това.
Моя статия от брой 183 на българското списание .net.
Последните няколко седмици се занимавам с редизайна на системата за онлайн банкиране на една от популярните български банки. Преди няколко месеца те я смениха с нова, доставена от голям индийски разработчик на банков софтуер.
И макар да бе нова, тя съвсем не беше посрещната добре от потребителите. Някой може да каже, че хората не обичат радикалните промени в интерфейсите на продуктите, които ползват, защото трябва да ги разучават отново и съответно да губят време. Истината обаче е, че ако дизайнът не беше толкова объркващ и не нарушаваше толкова много от основните правила за оформяне на интерфейсните елементи, то посрещането съвсем нямаше да е толкова негостоприемно.
Едно от най-странните неща беше оформлението на бутоните, линковете и заглавията в приложението. Всички те бяха син подчертан текст. Единственият начин да направиш разлика между тях беше размерът на шрифта – линковете бяха със стандартен размер, бутоните с малко по-голям и удебелени, а заглавията най-големи. В резултат потребителите не знаеха кой елемент каква функция изпълнява. Хората трудно се ориентираха в екраните, защото всичко изглеждаше еднакво и окото на човек нямаше за какво да се хване, за да разплете плетеницата от текст и контроли и да налучка правилния път напред. Може ли да се клика на заглавията? Ако натисна този линк ще изпратя ли формата?
Но нищо чудно, че индийските дизайнери бяха допуснали такава грешка. Просто поради някаква причина сляпо са следвали принципа, че щом става въпрос за уеб сайт трябва да се използват линкове за всичко. Да, обаче конвенцията в интернет е, че линковете служат за предвижване от една страница на друга. А целта на потребителите в едно приложение (било то и уеб) е основно да променят някакви данни. Т.е. когато си попълнил цяла страница полета за едно платежно нареждане най-малкото, което искаш да ти се случи е да натиснеш някакъв линк и да отидеш някъде другаде и да изгубиш всичките въведени данни.
За да не поставяме потребителите в подобни неприятни ситуации, чудещи се какво да правят е хубаво да се следват основните правила за използване на интерфейсните елементи линк и бутон.
Когато става въпрос за промяна на някакви данни е правилно да се използват бутони. Пример за това е функционалността „Добави в пазарската кошница”, която увеличава броя на артикулите, които потребителят си е поръчал от даден онлайн магазин. Когато обаче става за навигиране е напълно погрешно да се използват бутони – линковете са най-естественият начин да обозначиш възможността за преминаване към нова страница.
Разбира се има и изключения от тези правила. Така например, когато имаме процес, в който се минава през няколко екрана (или страници) няма нужда да използваме линкове, а вместо това в интерфейса да имаме бутони „Напред” или „Нататък”. Или пък обратното: когато става въпрос за команди, които са оформени като линкове – „Назад” или „Отмяна”. Такива командни линкове са много популярни в уеб2.0 приложенията и намериха приложение дори в Windows Vista.
И това не е случайно. Изследванията за ползваемост показват, че в една уеб форма могат успешно да се комбинират и двата подхода – използване на бутони за основното действие (напр. „Изпращане”) и командни линкове за второстепенното (напр. „Отмяна”). Това помага на потребителите да се ориентират по-бързо и чисто визуално по-лесно да открият елемента, чрез който да реализират най-важното за тях действие.
А точно това е основната задача на дизайнера. Затова изборът дали даден елемент да бъде линк или бутон трябва да бъде воден от това, колко внимание искаме да насочим към него и каква функционалност искаме да комуникираме чрез него.
Няколко месеца след като Гугъл пуснаха подробни карти на България и по-големите градове в страната вече започнаха да се появяват първите сайтове, които използват възможностите им.
Building.bg е сайт за недвижими имоти, който представя новострощяи се сгради в цялата страна. На специална страница потебителите на сайта могат да видят местоположението на всички оферти в сайта, разположени върху карта на Гугъл.
Building.bg – Карта на новите сгради
Географската информация може да бъде полезна в много случаи и да обогати потребителското изживяване и този сайт е добро доказателство за това. Чакаме да видим още подобни реализации.
Внезапно обзелият ме ентусиазъм днес привечер се изля във формата на уебкаста, който можете да гледате по-долу.
Логично е да имате очаквания за нещо повече от предишния път, един вид да съм се поучил от грешките си. Уверявам ви, че такова нещо няма и този втори мой продукт се оказва дори по-смотан и от първия.
Но пък от друга страна ми стана жал да похабявам материала като го архивирам някъде из компютъра си и затова все пак реших да го споделя тук. Предварително се извинявам за откровените глупости, които в последствие се чух че съм изприказвал, за липсата на всякаква подготовка и за реализацията. И ако на някой му се струва, че съм на няколко ракийки по време на записа, то трябва да знае, че не е точно така.
Иначе говоря за различни неща и най-вече различни проблеми, които са свързани със скролването в уеб страниците.
По време на презентацията се споменават следните уеб ресурси:
Ето и самото видео:
Наскоро имах възможност да наблюдавам как хора свалят нелегално филми от интернет. За всеки филм разбира се им трябваха субтитри на български език. За щастие имаха на разположение subs.unacs.bg – сайт предназначен единствено да предлага български субтитри за огромно количество филми.
Каква изненада обаче. Хората не успяваха да намерят субтитрите, които им трябваха и доста се фрустрираха от неуспехите си. Но защо?
Сайтът има добра търсачка, която при въвеждане на заглавието на филма връща доста резултати. Звучи чудесно: търсачката работи, хората я намират и изплзват лесно.
Проблемът обаче беше в представянето на резултатите.
За търсените субтитри имаше 6 резултата, които не се отличаваха почти по нищо смислено – единствено по името на ъплоудъра, броя сваляния и неразгадаемите жълти точки.
Изправени пред подобен избор хората започваха да свалят всички субтитри подред и да ги пробват. Разбира се повечето бяха неподходящи. Изнервящо.
Ключът от палатката се крие в допълнителната информация, която се показва, когато човек мине с мишката върху заглавието на даден ред:
Един от редовете в тази допълнителна информация – “Доп. инфо” съдържа и името на файла, за който се отнасят субтитрите. Единственото, което трябва да направи човек, разполагащ с това доп. инфо и сваления преди това файл с филма е да сравни двата текста. Лесно? Не съвсем.
Повечето хора въобще не разбираха, че трябва да минат с мишката върху заглавието, камо ли да обърнат внимание на това, което се появява като данни в новопоявилото се прозорче.
Съвсем просто решение на този сериозен проблем с ползваемостта на страницата с резултати е точно това парченце допълнителна информация – заглавието на файла – да се показва директно в таблицата, без нужда от движения с мишката.
Подобен е проблемът и с падащите менюта, които все още често се срещат по сайтовете. И причината потребителите да не се справят добре с подобни дизайнерски решения е в техните когнитивни навици. Както Джарид Спуул пише “Потребителите първо вземат решение и след това кликат“, т.е. преди да мръднат с мишката, за да посочат заглавието на филма (в нашия случай), те вземат решение за това на кой линк да кликнат. Когато не разполагат с необходимата информация да вземат правилно решение, те налучкват. Което очевидно не е добре, защото повишава риска от грешки и съответно раздразнение и загуба на време.
P.S. [1 юни 2007] Стори ми се да напиша това, защото този сайт правен очевидно от geeks за geeks е достигнал завидна популярност и влиза топ 50 на най-посещаваните от българи сайтове според класацията на alexa.com.
Хохо! This Is What Happens When You Let Developers Create UI от Coding Horror. Между другото се зачетох и в друготе постове от тоя блог, защото ми звучат полезни и логични.
Loading ...