Windows Phone: Формата не следва функцията

Около 2 години ползвах Windows Phone. Преди няколко седмици си взех нов телефон. Този път с Андроид.

Основната причина за промяната беше дизайнът на приложенията. Буквално ме вбесява безрасъдното похабяване на пространство в най-основните приложения, които ползвам.

Ето един пример:

фацебоок фор Виндовс Пхоне facebook 6 for android

Фейсбук за Windows Phone (вляво) и Фейсбук за Android (вдясно).

Вижда се колко място се губи за иначе внимателно подбраната картинка и заглавието на страницата в приложението за WP. Заема приблизително 1/4 от екрана. Комбинирано с други дребни детайли – като ненужно големия акцент върху имената на хората (наличието на профилна снимка обезсмисля големия шрифт, използван за името) и твърде голямото пространство около всеки един пост – прави трудно достъпно основното в приложението. А именно съдържанието.

Това ме фрапира толкова не случайно. Ако се зачете човек в дизайн гайдлайните на Майкрософт за приложения за Windows Phone, ще открие една от основните концепции:

more with less

Create a clean and purposeful experience by leaving only the most relevant elements on screen. When it comes to designing great app experiences, we believe in content, not chrome.
Focusing on content over chrome reduces unnecessary elements, allowing your app’s content to shine. Let people be immersed in what they love and they’ll explore the rest.

А то точно обратното. И то точно в приложения правени от самите Майкрософт.

Още един пример. Къде по-добре би могъл човек да използва тая идеология ако не в чат. Където основното е комуникацията между хората и съобщенията, които си разменят.
ff34115d-430a-4c63-8656-63fc6227411c  skype-android
Skype за Windows Phone (вляво) и Skype за Android (вдясно).
Content is king както се казва. Не само за уеб сайтове обаче важи това правило.

Затова – ако правите подобно приложение — особено ако е за такива малки екрани — внимателно преценявайте кое е най-важното и скрийте всичко, което не е абсолютно необходимо да присъства на екрана постоянно.

Най-типичен пример за това е навигацията. Често дизайнерите в желанието си да накарат хората да разгледат всяка страница от сайта (“Ние толкова време ги мислихме тия странции и нкой да не ги гледа…”) слагат линкове от всяка страница към всяка страница. Обаче хората пропускат навигацията почти както пропускат и рекламните банери. Просто защото обикновено тя е пълна с купчина линкове на най-общи теми, които нямат много връзка с търсеното от човека нещо.

Всъщност това правило важи и не само за малки екрани. Чудесен пример е скорошния редизайн на картите на Гугъл:
Screenshot 2013-05-15 at 12.38.58 AMЦелият екран е една карта. Няма го дори логото на Гугъл. Няма я и лентата с полето за търсене еднаква във всчики други приложения на компанията.

Поне за мен всичко това изглежда така сякаш хората от Гугъл са чели по-внимателно гайдлайните на Майкрософт от самите Майкрософт.

Добре че ги има обаче и добрите и лошите примери, за да се поучим от тях :)

Три извода от events tracking в Google Analytics (втора част)

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

Хората не разцъкват табове

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

За падащите менюта съм писал преди – не ги харесвам и не ги препоръчвам.

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

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

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

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

Което е по-интересно е, че общият брой на кликовете върху новините във всички скрити табове е една пета от броя на кликовете върху новините от показания дефолтен таб. Представете си че ако в показания таб хората цъкат на 100 новини, то в останалите 5 таба са цъкнали на общо 20. Показателно за ефективността. От друга страна обаче е по-добре от това да имаме само един таб и вместо 120 да получим само 100 клика.

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

PS. Тук отново трябва да направя уточнението, че резултатите са за този конкретен дизайн. В друг контекст табовете могат да имат и по-добри резултати.

Три извода от events tracking в Google Analytics (първа част)

От доста време вече в Google Analytics има възможност да се отчитат не само показвания на цели страници, но и отдлени интеракции в самата страница. Например, ако в дадена страница има видео плеър, човек може да следи колко от хората кликат на бутоните за плей, пауза и стоп.

Едва наскоро обаче реших да използвам тая функционалност в реален и сравнително посещаван  сайт (btv.bg), за да проверя с реални данни предположенията си за дизайна.

Как се ползва event tracking

Google Analytics има метод _trackEvent, който може да се вика и му се предават няколко параметъра по този начин:

_trackEvent(category, action, opt_label, opt_value)

Какво означават отделните параметри си пише в документацията на Analytics – супер кратко, ясно и пълно описание на event tracking.

Иначе с jQuery тракера се вика така:

$(document).ready(function(){
  $('#Logo a').click(function(){
    pageTracker._trackEvent("Navigation", "Click Logo",  document.title);
  });
});

Накратко това означава, че когато документът се зареди, javascript почва да следи за всеки клик върху линка и когато иам такъв ивент, записва в Google Analytics.

Резултати за някои интерфейсни елементи

Никой не споделя линкове по имейл

В тествания сайт под всяка новина, видео, анкета и т.н. има по няколко линка за споделяне в социални мрежи от сорта на Facebook, Twitter и т.н. Един от линковете беше „Препрати по имейл”, което означава да изпратиш на някой по имейл линк към съответната новина.

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

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

Факт е обаче, че ефектът от един линк споделен във Facebook или Twitter е доста по-голям, тъй като всичките познати на човека, споделил линка биха го видели и евентуално кликнали обратно към вашия сайт. Докато при случая със споделянето по имейл единствено получателят на имейла би кликнал и посетил вашия сайт. С други думи – макар и кликовете по линковете за споделяне в социалните мрежи да не привличат кой знае колко повече внимание, ефектът от тях е доста по-голям.

Нещо, което би могло да влияе върху този резултат е начинът, по който е кръстен линка. „Препрати по имейл” е един вариант. По големите български новинарски сайтове най-често се използва или иконка с писмо без допълнитлен текст, или иконка с писмо и текст „Изпрати”, или „Изпрати по e-mail”. В  англоезичните сайтове изглежда има възприет стандарт  – иконка на писмо и текст „E-mail”. На английски обаче “e-mail” може и да е глагол, за който няма превод с една дума на български  – „имейлнѝ”/”имейлване”. Честно казано обаче се съмнявам да има достатъчно добър вариант, който драстично да повиши кликанията върху този тип линкове (остава си добър повод за мултивариантно тестване).

Продължението следва

Видео: Семинар по ползваемост, Ноември 2009, София

Днес имах удоволствието да направя сравнително кратка презентация на семинара по ползваемост, организиран от Лукрат.

Ето и видеото:

Звукът може да е кофти, затова препоръчвам използването на слушалки и по-голямо внимание ;)

Слайдовете от презентацията качих в SlideShare:

Падащите менюта

Моя статия за българското списание .net.

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

Те са един от най-старите елементи на графичните операционни системи. Въведени са масово за пръв път в компютрите Apple и тяхната MacOS. Най-голяма популярност придобиват заради продуктите на Майкрософт, където основната „навигация” е т.нар. файл меню. И макар Майкрософт и Епъл дълго да се съдиха, кой от кого е откраднал интерфейса, всъщност трябва да благодарим на хората от Xerox, които в началото на 70-те изобретиха първият графичен потребителски интерфейс за операционната система PARK.

В уеб падащите навигационни менюта се подвизават от доста време. Преди десетина години те бяха едно от първите превъплъщения на DHTML технологията. Уеб дизайнерите се надпреварваха да правят такива менюта и да ги използват в сайтовете си, за да покажат „високотехнологичните” си умения и да създадат усещането за неограничените технологични възможности на уеб като медия. Използването на този вид менюта се оправдаваше и с пестенето на място и опростяването на дизайна.

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

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

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

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

Разбира се изборът, кога да ползвате изскачащи навигационни менюта в дизайна си остава изцяло ваш, но следващият път, когато ви засърби да използвате един от тия „яки” JavaScript компоненти, помислете дали това е наистина необходимо и дали няма по-малко стресиращ начин да осигурите навигационен избор на потребителите си.

Хензел, Гретел и навигацията

Моя статия за българското списание .net.

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

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

Едно често срещано решение на проблема с изгубването (особено в по-големите сайтове) е използването на пътечки от линкове. В английския език терминът e breadcrumbs и буквално се превежда като пътечка от трохи. И както вече се досещате произлиза именно от приказката за Хензел и Гретел, които докато бягат от къщи в гората, оставят по пътя си трохи от хляб, за да могат после да се върнат обратно.

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

Бредкръмбовете са особено полезни, когато сайтът има повече нива в йерархията си и основната навигация не може адекватно да покаже на къде точно се намира някоя страница от по-долните нива в йерархията. Те могат да помогнат на потребителите да си отговорят на два от най-важните навигационни въпроси – „Къде съм?” и „Къде мога да отида от тук нататък?”.

Някои препоръки при оформянето на пътечката:

  • Първият линк да не е просто “Начало”, а нещо по-специфично, например името на сайта, защото „Начало” или „Home” е прекалено общо и нищо незначещо понятие.
  • Отделните имена се разделят със знак за по-голямо – „>”. Често се използват и други символи за разделяне като вертикална черта „|”, наклонена черта „/” или „\”, две точки и всякакви други варианти. Най-добре въпреки това е да се използва знакът за по-голямо, защото интуитивно подсказва значението на всяка страница в списъка и принадлежността и по-горното ниво. Т.е. началната страница е най-важна, следващата страница е по-малка и част от по-горното ниво и т.н. Всеки друг символ означава по-скоро разделение, а наклонените черти говорят нещо само на хора, които са виждали команден ред на операционна система.
  • Името на страницата, на която си в момента се включва в пътечката. Ако пътечката и заглавието са разделени визуално потребителят може да не разбере, че представляват едно цяло и имат комбинирано значение – да показват къде се намираш в момента и принадлежността на настоящата страница към някаква по-сложна и многопластова структура.

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

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

Новият ми фаворит измежду най-смотаните интерфейси favit.bg днес ме учуди с още нещо:

favit-search

Искат да въведа информацията, която търся.

Ако имах информацията, която търся, защо да я търся и още повече защо да я въвеждам в някакво поле?

Чудесно доказателство, че писането в интерфейса не е проста работа и не трябва да се пренебрегва.

Напомняне за смяната на времето във Vista

Скрийншот на системния календар в Windows Vista

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

Бутон или линк

Моя статия от брой 183 на българското списание .net.

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

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

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

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

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

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

Разбира се има и изключения от тези правила. Така например, когато имаме процес, в който се минава през няколко екрана (или страници) няма нужда да използваме линкове, а вместо това в интерфейса да имаме бутони „Напред” или „Нататък”. Или пък обратното: когато става въпрос за команди, които са оформени като линкове – „Назад” или „Отмяна”. Такива командни линкове са много популярни в уеб2.0 приложенията и намериха приложение дори в Windows Vista.

И това не е случайно. Изследванията за ползваемост показват, че в една уеб форма могат успешно да се комбинират и двата подхода – използване на бутони за основното действие (напр. „Изпращане”) и командни линкове за второстепенното (напр. „Отмяна”). Това помага на потребителите да се ориентират по-бързо и чисто визуално по-лесно да открият елемента, чрез който да реализират най-важното за тях действие.

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