Un error que toca els…

Un dels punts clau a l’hora de fer un web adaptatiu (en anglès, responsive web design) és el meta viewport introduït per HTML5. Dit de manera simple, aquest meta ens permet dir al navegador que el web s’ha de carregar a escala 1, sense necessitat de redimensionar-lo. Això és especialment útil pels smartphones, tauletes i dispositius mòbils en general, que acostumen a redimensionar els webs, però també pels navegadors de sobretaula.

En principi, amb introduïr la següent línia al head seria suficient per a que el nostre web es carregui correctament a escala 1, alhora que permetem que l’usuari pugui redimensionar-lo si ho necessita:



FIG 1. Problema amb el redimensionament a iOS Safari
Opera Mini error redimensionament
FIG 2. Problema amb el redimensionament a Opera Mini

Una “solució” barroera és no permetre que l’usuari pugui redimensionar el web. Això ho podem fer afegint amb unes petites modificacions al meta que abans hem introduït. Concretament, podem dir al navegador que l’escala 1 és l’escala màxima, de manera que no es pugui redimensionar per damunt seu:


No feu això, està malament!

Accessibilitat über alles

Però això és una mala pràctica, ja que estem impedint que l’usuari pugui redimensionar el web a discreció. I què passa si el nostre usuari troba que el text és massa petit? O si vol veure amb més detall la imatge que hem posat? La voluntat de control dels dissenyadors web sobre les seues criatures no pot mai anar en detriment de les bones pràctiques d’accessibilitat. La nostra prioritat absoluta ha de ser sempre servir un bon producte a l’usuari, sense culpabilitzar-lo per tenir una mala vista o utilitzar un navegador que ens causa problemes. En conclusió, doncs, penso que cal acceptar aquest error dels navegadors, pressionar els fabricants per tal que es solucioni el problema, i com a desenvolupadors buscar solucions que no restringeixin les capacitats de l’usuari.

Un web per tothom

web-per-tothom

Encara massa sovint trobem webs que han estat «optimitzats» per a navegadors, dispositius o tamanys de pantalla concrets. Generalment, la pràctica de l’optimització es sintetitza en una o vàries (FIG. 1) d’aquestes possibilitats:

  • web optimitzat per a navegadors d’última generació, és a dir, les versions més actualitzades dels navegadors,
  • web optimitzat per a navegadors que segueixen els estàndards (Firefox, Chrome, Safari…) i desatenció als que no, és a dir, Internet Explorer 6-8.
  • web optimitzat per al navegador amb més quota de mercat (generalment alguna versió d’IE), i desatenció a la resta.
  • web optimitzat per a tamanys de pantalla concrets.
El web bredstik.com suma unes quantes «optimitzacions»
FIG. 1. El web bredstik.com suma unes quantes «optimitzacions»

Per altra banda, és també massa habitual trobar webs que es recolzen principalment o exclusiva en tecnologies que, en cas de no estar presents o habilitades al dispositiu de l’usuari, en dificulten la visualització. És el cas de webs fets amb tecnologia Flash o que utilitzen javascript a muntó sense haver previst l’escenari amb javascript inhabilitat.

Els webs fets en Flash requereixen que l’usuari tingui instal·lades extensions addicionals al seu dispositiu; extensions, recorde-m’ho, que tot i ser gratuïtes són privades. L’usuari que no tingui l’extensió oportuna de Flash instal·lada, o el que navegui des d’un dispositiu que no la tolera, com és el cas de molts dispositius mòbils, no podran accedir al nostre web. Alguns desenvolupadors que treballen amb aquesta tecnologia encara tenen el “detall” de posar un enllaç per a descarregar l’extensió, però no és estrany trobar-se davant una pàgina en blanc, sense cap mena de notificació d’error, que deixa l’usuari desorientat i sense saber perquè no pot accedir al nostre web.

En el cas de webs que es recolzen amplament en l’ús de javascript, els problemes poden ser menors o majors en funció de la previsió que hagi fet el desenvolupador. Si s’ha menyspreant l’escenari sense javascript, aleshores el web pot esdevenir un lloc francament inhòspit (FIG. 2).


FIG. 2. Intenteu visitar el web zennaware.com sense javascript habilitat. Mola!

Millora progressiva

Aquestes pràctiques foren amplament denunciades des de 2003 per Steve Champeon i Nick Finck en una presentació titulada “Inclusive Web Design For the Future“, en un moment en el qual era molt generalitzada la pràctica de fer webs «optimitzats» per a determinats navegadors. La presentació començava amb les següents paraules:

Web design must mature and accept the developments of the past several years, abandon the exclusionary attitudes formed in the rough and tumble dotcom era, realize the coming future of a wide variety of devices and platforms, and separate semantic markup from presentation logic and behavior.
The goal of Web design is not merely to dazzle, but to deliver information to the widest audience possible.

Champeon i Finck posaren un nom a la pràctica de «fer arribar la informació a la màxima audiència possible»: millora progressiva (Progressive Enhancement). Simplificant-ho, aquesta consistiria en construir els webs a partir del contingut, cap enfora. És a dir, partint del punt que el més important és fer arribar el contingut a l’usuari (fonamentalment en forma de text), crear webs amb una sòlida base d’HTML d’alt contingut semàntic, embellir-lo amb disseny mitjançant fulles d’estil (CSS), i tan sols addicionalment utilizar javascript per tal d’enriquir o dinamitzar certs elements. Una separació clara i marcada entre continguts i presentació de continguts, de tal manera que cada nova capa enriqueix l’anterior, però preservant sempre el valor dominant del contingut.

No culpis el dispositiu, culpa el desenvolupador

Comentaris del tipus «aquest mòbil és una merda, no es veuen bé els webs» o «m’hauria de comprar un Mac perquè sempre veig els webs de pena» denoten que la mala pràctica dels desenvolupadors traspassa la culpa als usuaris i els seus dispositius quan, de fet, els usuaris haurien d’estar maleïnt els desenvolupadors per no haver fet bé la seua feina. Deixe-m’ho clar: qualsevol navegador, qualsevol dispositiu que ha estat pensat per navegar per internet és capaç de mostrar correctament webs fets en la lingua franca del web: HTML/CSS. Són els desenvolupadors que, ja sigui per deixadesa o per mandra, han abandonat les bases universalment vàlides per centrar-se en tecnologies que fan del web un lloc més divertit però menys accessible. Però nosaltres no fem webs per a màquines concretes, sinó per a persones que utilitzen màquines molt diverses, i el nostre objectiu ha de ser arribar a les persones, independentment de les seues màquines.

Pragmatic Responsive Design

pragmatic-responsive-design

La gent de Yiibu, un minúscul estudi de desenvolupament web d’Escòcia, està liderant la transició cap al web adaptatiu. En fan un resum en una presentació que, en síntesi, planteja el següent repte: com podem fer webs que siguin realment adaptatius, és a dir, que no només es redimensionin ajustant-se al tamany de la pantalla, sinó que s’adatpin també a les limitacions del dispositiu?

La segona part de la qüestió és la realment fonamental. Fer webs adaptatius no és excessivament complicat: tan sols cal una bona planificació i bastanta més feina de desenvolupament. Però si per adaptatiu entenem alguna cosa més que el redimensionament dels continguts del web, aleshores ja comença la veritable dificultat. Perquè tenim eines per detectar el tamany de la pantalla del dispositiu, fins i tot de la finestra del navegador; però ara per ara no tenim manera de saber la velocitat de connexió d’un dispositiu determinat. I aquest és el gran «què».

A rel de llegir atentament la presentació de Yiibu, em sorgeix la següent pregunta: és suficient el tamany del dispositiu per prendre decisions sobre quin web servim a l’usuari? És a dir, si decidim mostrar un web d’una determinada manera, amagar certs continguts o ampliar-ne d’altres tan sols en base al tamany del dispositiu, no estem fent potser massa suposicions sobre l’usuari? En principi, pensem que si el tamany del dispositiu és petit la velocitat de connexió és baixa, i si és gran, la velocitat és alta. Però bé, podem navegar des d’un iPhone connectats a una wi-fi de 50M i podem navegar des d’un MacBook Air de més de 1400px utilitzant el mòbil com a router. Per tant, en el segon cas estariem oferint un web gran i pesat a un usuari que té poca velocitat de connexió.

Tot això genera molts reptes i, sobretot, molts nous problemes als quals haurem d’anar trobant solucions. La gent de Yiibu està marcant el full de ruta. Podeu descarregar la presentació sencera (en anglès) aquí.

Control, control, control

Spend some time on web design newgroups or mailing lists, and you’ll find some common words and ideas repeated time after time. Question after question, of course, is “how do I?”. But beneath questions like “how do I make my pages look the same on every platform” and “how can I make my fonts appear identical on the Macintosh and Windows” is an underlying question – “how do I control the user’s browser?” Indeed, the word control turns up with surprising frequency.

– John Allsopp, A Dao Of Web Design

We have no control.

– Bad Religion, No Control

Working with clients #1

It’s only natural that clients will do their own design research. They will make aesthetic judgments and have their own taste. However, it’s worth understanding the difference between the two: an aesthetic judgement is often inexplicable, like an emotional reaction; it’s instinctive and can defy explanation and resist attempts at persuation. To the client, something is either beautiful or it is not. Taste is more rational and can evolve reationally based on appreciation of what something is for, why it is designed in such a way, what the result will be, and even how it is made. In a good, collaborative client relationship, we should always be able to influence taste.

Jon Tan, «Taxidermista», The Manual #1, p. 36

Wake Up, and make something

A voltes necessitem tirar endavant projectes propis però els treballs dels clients ens xuclen tot el temps. És bo que destinem tot el nostre temps professional als clients; al cap i a la fi, si paguem les factures i marxem un mes a la Índia és gràcies a ells. No hem de ser garrepes en el temps que destinem als seus projectes.

Però no ens convé oblidar que els nostres propis projectes —aquell nou web que ens volem fer, aquell logo que mai he acabat, aquelles targetes que seran la polla— també són molt importants. Gràcies a ells millorarem la nostra imatge professional, o ens hi sentirem més còmodes. Gràcies a ells trobarem nous clients i projectes interessants als que treballar. Gràcies a ells mantindrem els clients que ja tenim, perquè veuran que estem vius, que investiguem, que no ens aturem ni ens conformem amb el que ja hem assolit. I no obstant… costa trobar el moment per treballar per a un mateix.

 

— Lleva’t d’hora, però ben d’hora ben d’hora

Aquests dies em trobo en aquesta situació. Tinc uns quants treballs de clients que han de tirar endavant, però alhora vull enllestir un nou web per Joan i Elena i un parell de webs específics per promocionar noves coses que estic fent. Quina solució he trobat per compaginar-ho tot? Doncs fer-me un règim horari.

Cada dia em llevo a les 6:30 i treballo en els meus propis projectes fins l’hora d’esmorzar. Després vaig a córrer per trencar el matí, i després d’una bona dutxa —ejem, ejem— treballo exclusivament en projectes de clients. Així, en una setmana he aconseguit quasi enllestir dos dels tres webs que em volia fer, a més d’acabar aquell logo, pensar en aquelles targetes…

Ja ho deia en Guardiola. Cal llevar-se ben d’hora.

Minimum screen resolution: a little white lie

Instead of exploring the benefits of flexible web design, we rely on a little white lie: “minimum screen resolution.” These three words contain a powerful magic, under the cover of which we churn out fixed-width layout after fixed-width layout, perhaps revisiting a design every few years to “bump up” the width once it’s judged safe enough to do so. “Minimum screen resolution” lets us design for a contrived subset of users who see our design as god and Photoshop intended. These users always browse with a maximized 1024×768 window, and are never running, say, an OLPC laptop, or looking at the web with a monitor that’s more than four years old. If a user doesn’t meet the requirements of “minimum screen resolution,” well, then, it’s the scrollbar for them, isn’t it?

target ÷ context = result

Si en voleu més, aquest article d’Ethan Marcotte no té desperdici. Com sempre, A List Apart marca el camí.

Samarreta IE

joan_elena_ie_fuck_you

We all know: Internet Explorer sucks! Whether you’re a web developer or just a user, we’ve all had awful experiences with IE. How many times did you have to rewrite a code just to make your site look pretty on IE? How many IE-only CSS files have you created in your life?

Okay okay, maybe I’m being too tough. After a few years developing websites I kinda know when I have to do something this or that way in order to make it work properly in IE. It’s just something you need to learn.

However, wouldn’t it be great if all IE users just said: let’s get something better?