Uporabniška izkušnja in subjektivno dojemanje kvalitete

November 2nd, 2009 by Krof Drakula Leave a reply »

Zadnje čase se veliko posvečam knjigam, člankom in ostalim gradivom na temo oblikovanja in optimiziranja uporabniških vmesnikov – najsibodo ti vmesniki spletne aplikacije, nadzorne plošče fizičnih naprav ali igre. Naj že na začetku povem: to ni trda znanost, je nekje med veščino in mehko znanostjo, saj pravila in načela vsebujejo ogromno število izjem in protiprimerov. Je pa par pravil, ki vseeno držijo, ne glede na to, kdaj in kako so implementirani.

Prvo izmed teh je očitno – ko uporabnik izvede neko operacijo (klikne link, pritisne gumb, z drag’n'drop operacijo prenese datoteko, ipd.), se mora ta operacija izvesti čimprej. Če je operacija sinhrona (uporabniški vmesnik čaka na rezultat operacije), ta operacija ne sme trajati več kot sekundo, dve. Če je uporabniški vmesnik dalj časa neodziven, se to na različnih napravah različno kaže – v Windows okolju se klik operacije postavljajo v vrsto za izvajanje in čakajo, da jih aplikacija pohendla. Če window manager zazna, da je preveč teh eventov v čakanju (ali čakajo predolgo), površino aplikacije delno posivi in v naslovno vrstico doda napis “(Not responding)”. Ne ravno uporabniku prijazno. V primeru mobilnih naprav se zaradi omejenih resursov kaj takega ne zgodi, ampak se dejansko cela naprava takorekoč obesi. Isto velja tudi za spletne aplikacije, ampak tu gre za druge efekte glede na operacijo, ki se izvaja.

Rešitev tega problema je preprost: uporabimo princip asinhronega izvajanja, navadno z uporabo več niti znotraj enega procesa.  Pomaga tudi, če lahko operacijo razdelimo na več korakov. Vse skupaj pa podpremo z neko povratno informacijo, s katero uporabniku damo vedeti, koliko časa se bo izvajala operacija in/ali koliko korakov v postopku je še ostalo. Recimo kazalnik napredka (ugh! – za vse tiste, ki sovražite ta izraz, progress bar):

Vsem dobro poznani kazalnik napredka oz. progress bar.

V tem primeru se lahko odločimo, ali bomo uporabniku predstavili takšen element kot modalni dialog ali pa kot stransko informacijo, s čimer mu dopustimo izvajati druge operacije znotraj vmesnika, dokler te spremembe ne vplivajo na trenutno izvajane operacije.

Skratka, velja pravilo, da če je uporabnik po pritisku gumba/klika linka/začetku izvajanja operacije pripravljen izvesti naslednjo operacijo, preden je uporabniški vmesnik na voljo, moramo prikazati povratno informacijo, ki nakazuje, da se operacija izvaja. Dober primer v tem primeru je Photoshop, ki za operacije, ki trajajo več kot par sekund, prikaže modalni dialog s progress barom napredka izvajanja filtra, slab primer pa je recimo spletna aplikacija, ki po kliku linka bodisi predolgo nalaga naslednjo stran ali pa čaka na AJAX operacijo brez vizualne povratne informacije. V tem primeru človek ne ve, ali je padla povezava, obesil brskalnik ali pa povezava pač ne dela zaradi nepopolno naloženih skript in ostalih resursov.

V primeru spletnih aplikacij moramo pa biti pazljivi, da na pravilen način posredujemo te informacije. Če izvajamo dolge operacije na sinhron način (v brskalniku z izjemo workerjev in Gears NI pravih asinhronih operacij, razen XHR operacij), potem moramo paziti, da se te operacije ne izvajajo predolgo, ker te blokirajo vse na strani. Kliki na linke, izvajanje drugih skript in animacij (ki povečini tečejo s pomočjo setInterval in setTimeout) so v tem primeru prekinjeni oz. izvedeni z znatnim zamikom, kar se izraža kot trzajoč vmesnik.

Rešitev v primeru dolgih Javascript operacij je segmentacija operacij, o čemer je pisal John Resig v tej kratki objavi. Princip je preprost; razdeli operacijo na posamezne korake in izvajaj korake zaporedno, po vsakem koraku pa izvedi setTimeout na izvajanje naslednjega koraka z nekim zamikom, recimo 10 ms. S tem dopustimo brskalniku, da izmenično izvaja našo daljšo operacijo in hkrati dopusti vmesniku, da se odziva na spremembe in dogodke v dokumentu.

Na tej točki pa je treba tudi omeniti, da se je treba izogniti elementom, ki izgledajo, kot da uporabniški vmesnik v ozadju počne časovno zahtevne operacije. Konkreten primer tega je Facebook Suggestion Box v zgornjem desnem kotu, kjer se uporabniku po kliku na ‘×’ v zgornjem desnem kotu celotna škatla posvetli:

Normalno stanje predloga za prijateljstvo v Facebooku. Posvetljen predlog po kliku na '×'

S tem ni nič narobe, ker nam Facebook s tem da vedeti, da se je nekaj zgodilo – pričakujemo, da bomo predlog izbrisali. Problem je sama izvedba povratne informacije. Prehod je v dveh korakih, najprej se posvetli, potem pa izgine, brez postopnih prehodov. Mogoče se to zdi banalno, ampak ljudje smo že dolgo navajeni gladkih animacij znotraj brskalnika, najsibo to Flash, Silverlight ali Javascript efekt. In izkušnje nam pravijo, da če ni postopnih in gladkih animacij, se nekaj zatika. In če se zatika, je nekaj v ozadju počasnega, neučinkovitega, to pa vodi v subjektivno sodbo o kvaliteti izdelka.

Če bi prehod bil gladek, v obliki animacije, kot se je to dogajalo pred zadnjo prenovo Facebooka, potem uporabniki vedo, da morajo čakati animacijo, da se odvrti, ne pa samega sistema. In to je tista navidezna razlika, ki da uporabniku vedeti, da uporabniški vmesnik vedno čaka na uporabnika, da bo pripravljen narediti naslednji korak, in ne obratno.

Torej, splošno pravilo: uporabnik je zadovoljen, ko je uporabniški vmesnik podrejen njemu, ne obratno. Če se izvaja dolga operacija, želi vedeti, koliko časa bo moral čakati na izvajanje, tudi če to ni opredeljeno v časovnih enotah.

To velja tudi za zadeve, ki se dogajajo v fizičnem svetu – če naročiš paket, hočeš vedeti, kdaj bo prispel na naslov. Če stojiš pred okencem v banki, želiš od delavca za pultom vsaj namig, kaj se dogaja, ne da se ta enostavno zatopi v svoje delo, medtem ko ti nemočno opazuješ njegove/njene poteze. Isto velja za interakcijo s katerokoli napravo in/ali aplikacijo. Ne pustite uporabnikov čakati.

Advertisement

Comments are closed.