Facilitant la web

De tots és bviagra conegut que ser el més popular de la classe no vol dir pas que siguis el més bo, ni el més educat, i encara menys, el més efectiu. Doncs això és principalment el que li passa a l’Internet Explorer.

Si treballem amb JavaScript d’una forma intensiva és normal usar alguna biblioteca que ens ajudi en algunes tasques del dia a dia d’interacció amb DOM, events i demés; i una de les biblioteques més populars actualment és jQuery (que és també la que uso jo normalment als meus projectes).

El cas que ens ocupa és una de les funcions de principals de manipulació del DOM: append. Imaginem-nos que tenim un codi semblant a aquest:

$('div.el-que-interessa').append('<span class="foo">');

Doncs bé, des de Firefox, per exemple, l’element /span sí que serà afegit, però en canvi a Internet Explorer no ho serà pas. Aquest darrer requereix que el fragment que es vulgui afegir mitjançant aquesta funció sigui XHTML. Així hauria de quedar una cosa com aquesta:

$('div.el-que-interessa').append('<span class="foo"><\/span>');

No sembla pas una cosa gaire complexa de detectar i solucionar, oi? Doncs donem-li una volta més de rosca…

Imaginem-nos que volem afegir opcions a una llista desplegable de forma dinàmica, i tenim un codi com el següent:

$.each(opcions, function(clau, valor) {
    $llista.append(new Option(valor, clau));
});

És correcte o no és correcte aquest codi? Per saber-ho, hauríem de modificar la pregunta i fer-la més o menys així: quin HTML ens retorna el constructor de la classe Option?

var opt = new Option('Catalunya', 'CT');
// opt: <option value="CT">Catalunya

Doncs bé, com podeu veure, el codi retornat per l’objecte no és pas en format XHTML, i per tant, no funcionarà a Internet Explorer. Per aconseguir el correcte funcionament, no tenim cap més opció que inserir l’opció en format text:

$.each(opcions, function(clau, valor) {
    $llista.append('<option value="' + clau + '">' + valor + '<\/option>');
});

Sovint ens interessa amagar contingut de la nostra pàgina a l’ull humà com pot ser el cas dels menús per a saltar a continguts de la pàgina, en l’ús de tècniques de reemplaçament de contingut per imatges o per ocultar capçaleres o elements estructurals de la pàgina. És veritat que ens interessa amagar-ho de l’ull humà, però el que no volem de cap de les maneres, és amagar-ho dels lectors de pantalla.

El típic error

Si donem una volta per la xarxa, el que sovint trobem escrit i recomanat, és l’ús de la propietat display: none per a ocultar elements. Amb això satisfem la nostra voluntat de que l’ull humà no percebi el contingut, però el problema és que sovint, els lectors de pantalla tampoc n’interpreten res.

Podríem dir que display: none significa que l’element no existeix: ni es mostra, ni s’imprimeix, ni es llegeix el seu contingut.

La solució

Una tècnica alternativa que es pot considerar és la de posicionar l’element que volem amagar de forma absoluta fora del viewport. Així, l’element existeix però no es percep per l’ull humà. El CSS que podem usar és:

.access {
    left: -9999px;
    position: absolute;
}

Amb això aconseguim el mateix efecte visual però sense ignorar a una part dels usuaris.

Tot això no és pas invenció meva, sinó que és una adaptació d’un article que vaig llegir fa uns dies.

No us ha passat mai que voleu obrir un petit diàleg amb algun company que manteniu conversa a través de la missatgeria instantània sobre un tros de codi font? I què ham hagut de fer fins ara? Doncs enganxar el codi a la conversa i esperar que el receptor l’interpreti d’alguna forma. Doncs bé, gràcies a Pastie ja no cal fer aquestes bajanades!

Pastie neix com una aplicació per a compartir porcions de codi. Així de bàsic, de senzill i de majestuós. És tan senzill com:

1. Accedir a la pàgina principal de l’aplicació.
2. Enganxar el tros de codi que vols compartir, escollir el llenguatge de programació que uses per a fer el coloreig del codi i enviar el formulari.
3. Compartir la URL generada amb els que t’interessi.

Oblideu-vos ja de llegir codi a través de la finestra de missatgeria instantània. Ara tot és més senzill, més agradable i més productiu amb Pastie!

Per temes de feina avui he hagut de fer un llistat d’arguments a favor i en contra de l’ús d’iframe en un desenvolupament web i m’he decidit a fer-la pública perquè tothom que vulgui pugui opinar-ne.

A favor

• Integració d’aplicacions. Permet integrar aplicacions externes a dins de la nostra pàgina.
• Disminució de peticions a servidor. Si tenim una part de la nostra pàgina que és costosa de construir (dins d’un entorn de pagines dinàmiques), podem posar-la dins d’un /iframe fent que no s’hagi de refrescar cada cop que canviem de pàgina (seguint una mica el model del ja deprecat element /frame).

En contra

• Forat negre. Al poder-hi posar tot el que vulguem, un /iframe pot arribar a ser un problema de seguretat si no som nosaltres els creadors del seu contingut.
• Accessibilitat. Existeixen navegadors que no suporten l’ús de l’element iframe.
• Lectors de pantalla. Hi ha navegadors que per defecte donen el focus al iframe en el moment de carregar la pàgina. Això és un problema per a la correcta lectura del document pels lectors de pantalla.
• Cercadors. Les aranyes dels cercadors no saben navegar correctament per les pàgines que usen marcs. Per tant, pot ser que el nostre lloc no sigui correctament indexat.
• Estructura del contingut. L’ús de l’element iframe trenca l’estructura lògica del contingut de la pàgina.
• Gran confusió al interactuar amb el navegador. Diverses interaccions de l’usuari amb el navegador es veuen greument modificades per l’ús de l’element iframe en una pàgina:
  • URL. La URL que es veu al navegador no és sovint la que correspon a la d’una pàgina creada amb marcs: si anem navegant dins del marc, la URL del navegador no canvia, però en canvi, la de la pàgina que estem veient sí que “ha canviat”.
  • Adreces d’interès. Lligat amb el punt anterior, si volem desar l’adreça de la plana, la que desarem serà la que es veu al navegador. Al tornar-hi veurem  que no és pas la mateixa plana que havíem desat (haurem perdut la navegació dins del marc). Tot i que hi ha navegadors que ens donen la possibilitat d’esbrinar l’adreça d’un marc, pot ser que l’usuari sigui no especialitzat i per tant, no sàpiga de l’existència d’aquesta possibilitat. Igualment, un usuari de la plana no ha de saber com està feta la pàgina, i per tant, saber com ha de fer-s’ho per desar l’enllaç  “correcte” a la plana en qüestió.
  • Resultats d’una cerca. Si accedim a una pàgina feta amb marcs des d’un resultat d’un cercador extern, pot dur-nos a una adreça  “incorrecte”: podem anara a l’adreça d’un marc, on veurem el contingut d’aquest però sense el contingut del seu “pare”.
• Alçada fixa. Un iframe té alçada fixa, i per tant, pot ser que ens aparegui una barra de desplaçament lateral en cas que el contingut ocupi més espai del reservat per l’atribut @height del marc.

Alternatives

En cas que usem marcs només per temes estètics no tenim excusa per abandonar-los, ja que el seu aspecte es pot replicar 100% amb CSS.

Si usem marcs per tal de poder deixar una part de la nostra pàgina fixa mentre fem scroll de la pàgina, podem usar la propietat position: fixed de CSS tal i com s’explica en aquest article.

En canvi, si el que volem és que cert contingut de la pàgina tingui una barra lateral per poder navegar dins seu, podem usar la propietat overflow tal i com s’explica en aquest altre article.

Conclusions

A data d’avui, i a no ser que sigui algun motiu de rendiment o d’integració, l’ús de marcs no està justificat en un inici, ja que provoca més desavantatges que no pas avantatges. Sovint la necessitat d’aquest element recau més per un tema gràfic que no pas per un tema funcional, cosa que com ja hem vist, es pot resoldre amb l’ús de fulls d’estils.

Portada del llibre Don't make me think

Aquest és un llibre que, sota el meu punt de vista, tota persona que es dediqui a la maquetació web o directament al desenvolupament de sistemes basats en web, s’ha de llegir. Dic això, perquè crec que tots els que ens dediquem a aquest món cal que tinguem unes nocions bàsiques d’usabilitat, més que res, per poder comprendre l’usuari i fer dels nostres treballs, feines de qualitat.

I no recomano aquest llibre en va. Ho faig perquè ja fa un temps, quan vaig veure que em calia endinsar-me una mica en el món de la usabilitat per comprendre més a l’usuari final, vaig demanar-li consell a una especialista en el tema, i ella fou qui me’l recomanà.

“No em facis pensar” és, a més a més del títol del llibre, el que pensa qualsevol usuari de qualsevol tipus de pàgina o aplicació web. Un usuari al entrar a un lloc web no vol haver de pensar en què ha de fer, com ho ha de fer i demés, sinó que senzillament vol i espera que l’aplicació o la pàgina el condueixi. Hem de tenir clar que si per usar la nostra pàgina cal pensar, llavors, estem condemnats al fracàs.

Amb aquest llibre, el seu autor, Steve Krug, vol transmetre les idees bàsiques de la usabilitat dins del món web. És un llibre de lectura més que fàcil, i que gràcies als seus exemples, que a primera vista poden semblar absurds, ens guiarà cap a l’aprenentatge de certes idees bàsiques per tal de fer dels nostres llocs, uns productes de qualitat tot esent de fàcil ús per als nostres usuaris.

Si donem un cop d’ull a l’índex del llibre, podem veure que aquest està dividit en quatre parts que duen com a títol:

Guiding principles

En aquesta primera part, formada per cinc capítols, l’autor ens mostrarà els principis bàsics de la usabilitat a la web. Es posa molta referència en temes com els hàbits de lectura al món web, les estructures típiques de certs components (cercador, etc.), entre d’altres temes.

Things you need to get right

Aquest segon apartat, format per dos capítols, engloba el disseny de la navegació del lloc, a més a més, del disseny de la portada. Ambdós temes, segons l’autor, són dels més importants.

Making sure you got them right

El tercer apartat, format també per dos capítols, ens fa centrar en com convèncer el nostre equip sobre la importància de la usabilitat. A part d’aquest tema, també trobem un capítol centrat en per què fer tests d’usuaris i quina repercussió poden tenir en el nostre projecte.

Larger concerns and outside influences

En aquest quart i darrer apartat, format per tres capítols, l’autor exposa altres temes vinculats amb l’usabilitat, com poden ser l’accessibilitat, entre d’altres.

Per acabar, només dir que és un llibre curt, de lectura ràpida i que personalment, em va ajudar molt en la meva carrera professional.

Personalment, crec que és una molt bona compra.