Saturday, January 17, 2009
Saturday, January 10, 2009
B/W sau W/B?
Bine înţeles că nu există nici o soluţie perfectă şi că schema de culori trebuie să se armonizeze cu restul de elemente grafice, cu conceptul prezentat şi aşa mai departe. Trebuie avut însă în vedere următorul aspect: în condiţiile în care există mult text, este mult mai recomandat ca alegerea să fie text de culoare închisă pe fundal deschis. Varianta inversă este foarte obositoare pentru ochi şi produce o foarte neplăcută „remanenţă” pe retină. Pentru un exemplu foarte grăitor, încercaţi să citiţi tot textul de aici.
Tuesday, January 6, 2009
Lights off - un „împrumut” foarte util
Am totuşi o reţinere legată de generalizarea acestui feature. Prin înlăturarea „zgomotului” din pagină, scade şi interesul utilizatorului către (eventualele) reclame inserate în pagină. Deşi, o dată cu introducerea suportului pentru captions şi a reclamelor în video, problema este, aparent rezolvată.
Sunt tare curios să văd cu ce o să mai vină YouTube, cu atât mai mult cu cât unii prevestesc sfârşitul video-ului pe web (dar despre asta, în alt episod).
Thursday, December 25, 2008
Nu aduce anul ce aduce ceasul.
Sunday, December 14, 2008
Bounce rate
Conform paginii de pe wikipedia, bounce rate-ul reprezintă ce procent din vizitatorii care ajungând iniţial pe prima pagină a unui site (sau pe o pagină oarecare), pleacă pe un alt site în loc sa continue navigarea pe alte pagini ale aceluiaşi site. Se consideră ca un user a „sărit” (nu găsesc o traducere mai bună pentru bounced) dacă a navigat pe un alt site înainte de expirarea unui timeout - stabilit de obicei de software-ul de tracking.
Care e relevanţa bouce rate-ului? Conform lui Avinash Kaushik: „It is really hard to get a bounce rate under 20%, anything over 35% is cause for concern, 50% (above) is worrying.” Cu toate astea, în condiţiile în care o proporţie mare din trafic vine pe canale indirecte (userul nu scrie de mână URL site-ului în bara de adrese a browserului), vine următoarea întrebare: nu cumva un bounce-rate mare poate însemna şi faptul că userul a găsit repede şi „din prima” ceea ce căuta?[1] Şi de aici poate deriva uşor următoarea chestiune de fond: când realizăm o interfaţă este de preferat să îi dăm utilizatorului din prima mai multă informaţie în speranţa că va găsi „din prima” ceea ce caută sau e de preferat rafinarea succesivă a prezentării informaţiei.
Motivul pentru care am afirmat că problema caracterizează atât interfeţele web cât şi cele desktop ţine de latenţă. În web, în ciuda creşterii vitezei medii de acces la resurse, latenţa poate fi o problemă - fiind inerentă atât protocolului folosit (HTTP), dar şi modului în care o interfaţă este proiectată. În cazul aplicaţiilor desktop, latenţa efectivă de acces este cu nişte ordine de mărime mai mică, dar în acelaşi timp volumul de date prezentat sau implicat în prelucrări creşte considerabil.
Este de preferat un timp de încărcare iniţial mai ridicat, urmat de o experienţă ulterioară „fără sughiţuri”, sau „încărcările mici şi dese-s cheia marilor succese”? Întrebarea este bineînţeles una deschisă (retorică nu cred că e :) ), dar poate face diferenţa între un serviciu de succes şi unul folosit când şi când. (În situaţia asta sunt eu cu mailul - motivul pentru care am trecut de pe Yahoo!Mail pe GMail este că în GMail, am acces la mail încă de la prima încărcare a paginii, în timp ce pe Yahoo! mă separă un click de mouse şi două încărcări de pagină până la accesarea Inbox-ului - and don't get me started cu noua
____
[1] după cum se menţiona şi în articolul de pe Wikipedia, această metrică are mai multă relevanţă şi este de dorit să aibă o valoare mică în cazul site-urilor care aduc valoare din timpul petrecut de către user în site - de exemplu site-urile de eCommerce.
2 comentarii Categorii: analytics, design, interactiuni, interfeţe, web 2.0
Wednesday, November 26, 2008
De ce iubim f...acebook-ul?

Trebuie să mărturisesc că în urmă cu 10 minute habar n-aveam lucrurile astea şi că până în iulie nu auzisem de Facebook decât de pe la alţii. Recent, discutând cu unii prieteni şi dând peste tot felul de aplicaţii care mai de care mai integrate, am decis să fac un efort de voinţă şi să investesc un pic de timp în fenomenul Facebook.
Vă veţi întreba poate, de ce e nevoie de un efort de voinţă? Sunt o persoană care are simpatii şi antipatii destul de puternice şi - de multe ori - greu de argumentat logic (aşa se face că Java e un limbaj care îmi place deşi nu prea înghit conceptul de JSP, la fel cum .NET şi C# îmi plac la nebunie dar nu suport ideea de WPF). Aşa se face că şi Facebook şi-a câştigat destul de repede şi cam fără drept de apel eticheta de „mdeah, să fiţi sănătoşi voi cu Facebook-ul vostru”.
Asta cu toate că, tehnic şi... social Facebook mi se pare un exemplu foarte bun de ce se poate face cu o interfaţă web bine gândită, susţinută de o arhitectură robustă şi modulară. Sunt chiar de părere că, alături de GMail şi Flickr, Facebook a dus conceptul de interfaţă web până în punctul de maximă forţă, dovedind cam tot ce se poate face cu actualele tehnologii web. Aici discutăm atât de AJAX, de diverse integrări, mash-up-uri dar şi de folosire deşteaptă a tehnologiilor mai „rich” orientate pe client, ca Adobe Flash.
Arhitectura deschisă şi extensibilă a Facebook permite dezvoltatorilor de aplicaţii să se lege practic în orice punct esenţial din interfaţa web, pentru a oferi facilităţi noi. În acelaşi timp, majoritatea funcţionalităţilor sunt expuse într-o manieră standard astfel că pot fi uşor create diverse interfeţe, web sau stand-alone care să agrege informaţiile din profile Facebook şi din alte surse.
Şi aici cred că rezidă succesul Facebook: posibilitatea de-a adăuga funcţionalităţi extrem de bogate şi de variate, păstrând însă o interfaţă web uşor de înţeles, folosit şi - de ce nu - înţeles.
Cu toate acestea (şi-n ciuda recentei explozii de activitate) pe mine nu mă atrage Facebook. Opinii? Sfaturi pentru rătăciţi? :)
3 comentarii Categorii: interactiuni, interfeţe, social, web 2.0
Monday, November 24, 2008
Crawlere şi interfeţe web Flash
Multe companii preferă să-şi impresioneze vizitatorii site-urilor lor prin realizarea de interfeţe în totalitate în Flash. Această platformă oferă experienţe multimedia superioare unui conţinut exclusiv HTML+CSS şi în plus, în ultima vreme, odată cu lansarea framework-ului de aplicaţii rich client Adobe Flex, a devenit accesibilă unei baze mult mai largi de dezvoltatori.
Una din problemele cu care totuşi aceste site-uri s-au confruntat până recent a fost invizibiltatea pe motoarele de căutare. Crawler-ele lor nu erau capabile decât să indexeze conţinut HTML (text), în timp ce obiectele SWF integrate in pagină erau total opace. Adobe era conştient de acest lucru, astfel încât în această vară a lansat o variantă simplificată de Flash Player, capabilă să parseze conţinutul text din clipurile SWF, şi pe care a pus-o la dispoziţie principalelor motoare de căutare (Google şi Yahoo), pentru ca acestea să poată indexa inclusiv conţinutul Flash.
Astfel, astăzi am pornit un mic experiment pentru a verifica dacă într-adevăr Google sau Yahoo indexează conţinutul Flash. Pentru acest experiment, am avut nevoie de:
- O pagină cu conţinut Flash/SWF. Pentru aceasta, cel mai la îndemână a fost să realizez o aplicaţie Flex simplă, care conţine câteva componente cu conţinut text (Label-uri).
- Un search term oarecum original (ca să nu stăm să căutam acul în carul cu fân... I mean în search results pages :) ). Imaginaţia mea debordantă a ales Any Donkey Owns Basically Everything.
- Un link către pagina noastră, pentru ca Google crawler-ul să poată ajunge la ea şi s-o indexeze. La asta e bun post-ul acesta.
Puteţi oricând verifica dacă textele din clipul SWF au fost indexate căutând pe Google search term-ul magic. Este de aşteptat ca acest lucru să se întâmple (dacă este cazul), peste câteva zile. Voi reveni şi eu oricum, cu un post cu rezultatele mele, so stay tuned!
10 comentarii Categorii: adobe, crawlers, experiments, flash, flex