xposible

El título suena raro, ¿verdad?
También sería raro que se buscase a una contable para trabajar como directora de orquesta. O un operario de una cadena de montaje para trabajar de controlador aéreo.

El problema en el fondo es el mismo: buscar o contratar a un profesional que no es adecuado para un trabajo. El riesgo en los tres casos, es altísimo. Aunque las consecuencias, obviamente no tienen nada que ver:

• En el caso del director de orquesta, lo peor que puede ocurrir es que los músicos estén mal dirigidos. Que no marque adecuadamente el ritmo de la partitura. Que suene mal. Tal vez la orquesta pierda prestigio y los posibles asistentes al concierto se enfaden.
• En el caso del trasplante, estamos hablando de un riesgo más elevado: una vida. La cosa cambia. El paciente probablemente morirá.
• ¿Y qué decir del controlador aéreo? Podrían morir cientos de personas en un posible accidente. El riesgo es bastante más elevado. Y las posibilidades de que ocurra un desastre es muy alta.

Obviamente para los trabajos antes mencionados harían falta profesionales cualificados y con experiencia.

Pero demos una vuelta de tuerca.

• ¿Dejarías al gerente del hospital, pongamos un profesional cualificado en la gestión empresarial, a realizar el transplante?
• ¿Dejarías a la ministra de cultura que dirijiese la orquesta? Supongamos que tiene gran experiencia, por ejemplo, en el ramo editorial.
• ¿Dejarías que la directora del aeropuerto estuviese dirigendo el tráfico aéreo en la sala de control? Tiene una larga carrera como política.

Supongo que en los tres casos la respuesta sería NO. Me da igual el cargo que tienen y el dinero que ganen. Me da igual los subordinados que tengan debajo en el organigrama. Me da igual que una decisión suya se pueda traducir en millones de euros en gastos o inversiones. No están cualificados para esas labores. No tienen los suficientes conocimientos. Carecen de la experiencia suficiente. Sería un error que podría tener consecuencias trágicas.

Cambiemos de tema, y traslademos las reflexiones anteriores a la Web. A un proyecto profesional. Donde se invierte dinero. Mucho dinero.

Empecemos por los riesgos: ¿Qué puede ocurrir si un proyecto no ha sido realizado por profesionales cualificados en cada uno de los aspectos? Me refiero a las labores de arquitectura de información, diseño de interacción, experiencia de usuario, prototipado, diseño gráfico, maquetación, programación,…

Se me ocurren muchas consecuencias: sitios feos, mal diseñados, confusos, complicados de navegar, donde es difícil realizar tareas básicas, no funciona adecuadamente en algunos navegadores, aparecen raros errores de programación, los buscadores son incapaces de encontrar contenido útil, la gente no utiliza los sites, pocas visitas, alta tasa de abandonos,… la consecuencia breve y que todo el mundo entiende: se ha tirado el dinero a la basura. Y que queréis que os diga, jode y mucho que en muchas ocasiones los verdaderos responsables de auténticos desastres y atrocidades, no asuman sus errores y mantengan su profesionalidad y credibilidad intactas. Pero volvamos a las consecuencias:

• En el caso de una empresa, es malo, porque no hay que malgastar los recursos, y menos en época de crisis. Probablemente no se hayan cumplico las espectativas, y una o varias decisiones así, pueden mandar a una empresa a la quiebra. O tal vez no genere más beneficios.
• Si hablamos del sector público hay dos consecuencias inmediatas: se ha malgastado el dinero de los contribuyentes, y no se ha empleado el dinero de forma adecuada para ofrecer servicios públicos útiles para los ciudadanos.

Si no es demasiado tarde, tal vez, pueda haber soluciones. Por ejemplo, de estos tres tipos:

• Se abandona el proyecto. Al menos no se invirte o pierde más dinero. Es una putada, pero podría ser peor.
• Se invierte más dinero para intentar arreglar o parchear, siguiendo una metodología de trabajo similar: siguen tomando decisiones técnicas quien no debe (yo mando y digo que el logo usa la fuente comic sans y te callas) y/o siguen realizando las tareas técnicas quien no sabe, o no sabe lo suficiente (de la maquetación se encargará el programador, que dió un curso de Dreamwaver de 20 horas hace diez años).
• Se reconoce el error, y se contrata a la gente adecuada para realizar las labores técnicas, y dejando las decisiones técnicas en sus manos.

Sobra decir, que si se toma la última decisión, al menos se va por el buen camino. Aunque signifique tirar todo el trabajo anterior a la basura y empezar de nuevo. Aún puede haber esperanzas.

La segunda opción, a pesar de que probablemente siga siendo un fracaso, tiene consecuencias interesantes desde el punto de vista económico: generan riqueza. Quiero decir, se está volviendo a tirar dinero a la basura, pero se está contratando gente, que aunque no tenga ni puta idea, dedicará su dinero a comprar comida, viajar, comprarse un coche (con un crédito a un cómodo interés),… y a su vez los que reciben ese dinero se lo pueden gastar, e incluso el dinero que no tienen (con un crédito a un cómodo interés). Es lo que se llama el efecto multiplicador de la demanda (o multiplicador keynesiano). Al final, se va generando empleo. Aumenta el Producto Interior Bruto. Pero es un crecimiento que se sostiene en pilares de aire. No es bueno. Es una mierda.

Por eso, desde un punto de vista bastante perverso y muy poco eficiente desde un punto de vista profesional, es bueno, que los incompetentes realicen ciertos trabajos: porque luego habrá que arreglarlos, y a veces se pueden sacar nuevos proyecto y facturas más horas. Eso sí, pobre del que le toque arreglar las chapuzas de otros, especialmente si tiene que estar solucionado “para ayer” y es necesario mucho café para mantenerse despierto (y sin cobrar horas extras, por supuesto).

Moraleja: zapatero a tus zapatos.

Ups, que no se me olvide mencionar que esta mierda de artículo ha sido inspirado por El diseño no es un extra de queso, escrito por Luis Villa (grancomo), el artículo Vilaweb y el desarrollador tonto del haba, escrito por Choan Gálvez, y por supuesto, mi experiencia personal (que a pesar de mis pecados, intento aprender siempre para reducir mi desconocimiento e incompetencia en eso que llaman desarrollo web).

Creativity is not design. Creativity has nothing to do with design. Creativity is bound by no laws, rules, or strictures …which is perhaps why it’s so intoxicating (sometimes to the point of delusion). Design, on the other hand, is based entirely on math, psychology, human perception, and a host of rigid rules and laws that can be broken by only a highly skilled few. Those unfamiliar with these laws and rules, and the associated sciences are by no definition designers.

Andy Rutledge: Creativity is Not Design (Design Test 2)

Y al leerlo, no puedo evitar recordar algunos artículos de Ale Muñoz, como La mayor cualidad de un diseñador… o Aprende a preguntar.

Pero volviendo a los dos test a los que hago referencia en el título, son los siguientes, y ambos de Andy Rutledge:

1. How Well Do You Understand Design?
2. Creativity is Not Design (Design Test 2)

El primero de ellos, un examen tipo test, con las respuestas justo después de las preguntas. El siguiente test, no viene con las respuestas (él mismo explica el motivo), y lo cierto es que personalmente me va a tener entretenido durante semanas.  Motiva y estimula la materia gris.

Que dice Ale Muñoz que el libro Universal Principles of Design te puede ayudar a conocer las respuestas :)

La gente de mobiforge ha escrito un completo artículo en los que recopila emuladores de teléfonos móviles. Y tiene mérito, porque encontrarlos por nuestra cuenta es un trabajo no siempre sencillo.
El artículo: A Guide to Mobile Emulators.

Por encargo de IAB Spain, la agencia The Cocktail Analysis ha elaborado el Estudio de Internet en Móviles y Dispositivos Portátiles (2 MB en formato PDF), con el objetivo principal de: identificar los espacios‐modos de presencia de la publicidad interactiva en un acceso móvil y distribuido a internet. Sus objetivo son (cita textual):

• Las tendencias que emergen vinculadas a la movilidad.
• La determinación de los facilitadores y frenos hacia Internet Móvil.
• El rol de las redes sociales como drivers para la conexión a internet a través del móvil y otros dispositivos.
• Las pautas diferenciadas de uso de servicios de internet conforme al dispositivo de acceso.
• Las pautas diferenciadas de uso de servicios de internet conforme al dispositivo de acceso.
• La penetración y uso efectivo que se está haciendo de los smartphones.
• El interés que suscitan los sistemas de geolocalización.
• La incidencia, conocimiento y actitudes ante diferentes modalidades de Mobile marketing y Publicidad Interactiva.

Estudio de Internet en Móviles y Dispositivos Portátiles

Viendo la información técnica del estudio (tamaño muestral, muestreo empleado, ponderación, análisis cualitativo y cuantitativo, técnicas multivariantes empleadas, y otros términos en los que sólo nos fijamos los estadísticos y poco más), se aprecia un buen punto de partida, y los resultados son interesantes: no sólo es un cuestionario de hábitos dentro de la web móvil – que ya de por sí justificaría un estudio así – sino que también nos habla de actitudes (¡vivan los estudios cualitativos!).

Un par de aspectos que me interesan especialmente:

• El uso del análisis factorial de correspondencias para describir la relación entre las variables utilizadas, y que han servido, junto con el análisis cualitativo, para detectar unos determinados perfiles sobre el uso de internet en el móvil, que han denominado “limitado/básico“, “lúdico/social“, “internauta” y “profesional“. La detección de estos perfiles pueden ser de una gran ayuda en la elaboración la técnica de personas y escenarios dentro de la Experiencia de Usuario. Aprovecho para incluir una pequeña reflexión personal: sigo pensando que el análisis multivariante está infrautilizado en el contexto de la experiencia de usuario y el SEO.
• El segundo aspecto que me ha gustado, ha sido de el uso de una hipótesis bastante interesante, y creo que nada arriesgada si contemplamos de forma objetiva los últimos años de la web móvil. Parten de la idea que los hábitos y actitudes de los usuarios actuales de smartphones, puede ser un reflejo del futuro inmediato (como cuentan en el estudio: Desde el target usuario de smartphones, aquellos que de alguna forma anticipan el recorrido que potencialmente recorrerá el conjunto del mercado [...]). Teniendo en cuenta que las características de los terminales, cada vez más avanzadas, y su difusión, nos obliga a mirar con atención los datos obtenidos.

Un estudio interesante y recomendable, donde se puede encontrar mucha más información de la que yo hago referencia aquí :)

En Twitter, podemos encontrar un mensaje de mamuso (¡gracias!), en el que vincula el artículo Ultimate IE6 Cheatsheet: How To Fix 25+ Internet Explorer 6 Bugs, al que antes hizo referencia smashingmag. Twitter mola.

The best strategy for dealing with Internet Explorer 6 is not to support it.

Stop. Ok, I feel your frustration. You’re a web developer and you’re ready to tear your hair out because you have to support Internet Explorer 6, but, to put it tactfully, IE6 doesn’t support you. You’ve spent hours on it, but you just can’t seem to get your layout right. I can empathize. I can also help.

Benjamin, Ultimate IE6 Cheatsheet: How To Fix 25+ Internet Explorer 6 Bugs

Como dice en el artículo, no se trata de una campaña contra el navegador que salió a la luz en el año 2001 y por diversos motivos, todavía tiene un respetable número de usuarios. Uno de esos motivos, de los muchos que hay: se trata del navegador oficial y corporativo y no se puede actualizar debido a que los trabajadores no tienen privilegios para hacerlo, y en las versiones más modernas o en otros navegadores, las intranets o aplicaciones webs que se usan, hacen catacroker (¡qué gran visión de futuro!, podemos decir ahora). Simplemente, toca ser realista, e intentar que nuestros desarrollos webs se muestren correctamente en navegadores que aunque no se lo merecen, sí se lo merecen las personas que obligados o no, usan el mencionado navegador.

De todas formas no está de más recordar que resulta una temeridad seguir utilizando un navegador tan antiguo, con numerosos problemas de seguridad, que no respeta adecuadamente los estándares webs y que exige tiempo -y por tanto, dinero – adicional para que se comporte de forma similar a los navegadores más actuales, seguros y con un mejor soporte de estándares. Ya sabéis que en Windows hay disponibles un buen puñado de buenos navegadores: Firefox, Opera, SeaMonkey, K-Meleon, Safari,….

Si por casualidad (todo es posible):

• usas Windows
• no puedes actualizar el navegador
• tampoco tienes privilegios para instalar ningún programa, y por tanto otro navegador,…

prueba a descargar Firefox Portable, un buen navegador, actual y más seguro, que no hace falta instalar, sólo hay que descomprimir, y listo para funcionar.

Y si estás desarrollando webs, da un vistazo a Ultimate IE6 Cheatsheet: How To Fix 25+ Internet Explorer 6 Bugs.

En WordPress Mobile Plugins, Jeff Van Campen analiza de forma exhaustiva (validadores de HTML, CSS y Mobile OK) tres pluggins de WordPress para adaptar el contenido y presentación de un blog a los teléfonos móviles. Ninguno de esos pluggins requiere APIs o aplicaciones externas para funcionar, por lo tanto son bastante transparentes y fáciles de modificar y adaptar. Los pluggins son:

• WordPress Mobile Edition
• MobilePress
• WordPress Mobile Pack , de dotMobi, que a juicio de Jeff Van Campen es el mejor de los tres

Recuerda, WordPress Mobile Plugins.

Que escribir en un teléfono móvil con el teclado numérico típico puede ser una pesadilla, no es ninguna novedad. La recomendación de evitar, en la medida de lo posible, obligar a los usuarios a escribir en input type="text" ó textarea hay que tenerla muy presente.

Pero ya sabemos como funciona el mundillo de la web: basta con que no sea recomendable usarlo, para que sea un requisito imprescindible.

Cuando se publicó – por fin – XHTML 1.1 Basic como recomendación del W3C, una de las novedades que más me llamó la atención fue el módulo de inputmode (XHTML inputmode Attribute Module). Brevemente es un atributo que se incluye en el código fuente como atributo de un campo de texto en un formulario, para “obligar” a que el teclado del móvil escriba, por ejemplo, números (inputmode="latin digits") usando tokens o valores predefinidos (lo puedes ver en List of tokens).

La teoría es muy bonita, pero en la práctica, no está muy extendido entre los terminales móviles la interpretación del módulo en cuestión. Y es un problema gordo y que puede producir mucha frustración a los usuarios. Imaginemos que tenemos que escribir un código postal, cinco dígitos en total. Puede suponer pulsar veinte veces las teclas, ya que los números suelen situarse detrás de las letras. ¿Y si es un número de cuenta con 20 dígitos? Y si estás pensando: “se puede configurar para escribir sólo números y ya está…” pero no siempre es así (pruebas con unos veinte terminales me lo confirman).

¿Solución?

Hasta que los agentes de usuario implementen el módulo (¿a qué me suena ésto?), podemos usar un estándar algo más viejo, pero con mejor soporte (a mis pruebas me remito).  Estoy hablando de WCSS Input Extension, que mediante el uso de la propiedad -wap-input-format en la hoja de estilos, o insertado directamente como valor del atributo style, nos permite forzar a que los teclados de los teléfonos escriban sólo números, números con símbolos, texto en minúsculas con símbolos, texto en mayúsculas con símbolos,  y todo junto. E incluso la longitud del campo. Puedes ver más en Controlling the Type and Number of Characters to be Entered in Text Fields (-wap-input-format Property). Y lo bueno, es que es compatible con XHTML 1.1 Basic.

Algunos ejemplos:

• Código postal (5 dígitos): -wap-input-format: "NNNNN"
• Código wadus (hasta 5 dígitos)-wap-input-format: "5N" (ojo, que no es lo mismo)
• Importe (números y símbolos)-wap-input-format: "*n" (permitiría números y los símbolos separadores de miles y decimales)
• Texto wadus -wap-input-format: "*A" (letras en mayúsculas y símbolos, sin límite)
• Texto wadus prima -wap-input-format: "*a" (letras en minúsculas y símbolos, sin límite)

¿Es útil? Sí y mucho. Pero recomendaría mucha precaución antes de usarlo. Algunos motivos:

• Si nos equivocamos en el tipo de datos, la cagamos. No es posible cambiar de números a letras, por ejemplo.
• Si nos equivocamos en la longitud del campo, también la cagamos (como he dicho antes, no es lo mismo <code>NNNNN</code> que <code>5N</code>). Además, si hay que introducir en el campo, por ejemplo 5 letras mayúsculas obligatoriamente (<code>5A</code>), no puedes salir de la caja ó área de texto del formulario hasta que cumplas lo exigido.
• Si usamos la propiedad -wap-input-format en una hoja de estilos externa, hay que tener mucho cuidado que afecta sólo a los elementos de formularios que queremos (y no fastidie a otro). Hay que tener una buena planificación en la nomenclatura de clases e identificadores.
• La propiedad de la que hablamos, no se interpreta siempre a la hora de escribir en aquellos terminales que tienen teclado tipo QWERTY ya sea físico o en pantalla. Lo cuál no significa que pueda aparecer un mensaje de error bastante críptico al intentar hacer submit, diciendo algo así como El contenido de un campo de formulario no coincide con el formato que rquiere el autor de la página. Modifique el texto y vuelva a intentarlo. Cómo véis, un mensaje muy claro, corto y sencillo. Ésta joya de texto aparece en una HTC.

La otra propiedad que podemos usar es -wap-input-required, con los posibles valores true y false, que no creo que requiera mucha explicación.
Como he dicho antes, la información completa y bien explicada la puedes encontrar en Controlling the Type and Number of Characters to be Entered in Text Fields (-wap-input-format Property), con algunos “extras” como el uso de caracteres de escape.

Si alguna vez has visto a Chaals en un evento, sabrás porqué tienes que ir. Y si no lo has visto, tienes que verlo: no es una sugerencia, es casi una obligación.

En cualquiera de los dos casos, tenemos suerte los que tengamos un hueco para estar, entre los días 27 y 30 de Abril de este año 2009, en las universidades de Salamanca, Carlos III (campus de Leganés), Oviedo o León. ¿Por qué? Porque Chaals, dentro de los eventos en los que participa Opera Software bajo la denominación de University tours, estará hablando de:

Opera Software’s university tours explore:

• the history and future of the Web
• the browser industry
• open Web standards
• Web applications
• the role of the Web and mobile browsing, particularly in developing countries

Opera can also deliver specific tutorials and tailor the content of each seminar to address topics most relevant to each university and the learning of its students.

Students can gain new perspectives on technology trends, direct questions to Opera Software developers and product managers in panel discussions, and network with people leading the IT industry.

University tours

La conferencia de Chaals – Charles McCathieNevile - se titula “Nuevas tecnologías para la web como plataforma para desarrollar aplicaciones potentes” y hablará entre otras cosas de HTML5, widgets, Bondi, web móvil y su lugar en el entorno web :

• 27 de Abril 12:30 : 14:00 : Opera University Tour en la Universidad de Salamanca (Aula D-3, Facultad de Ciencias)
• 28 de Abril 18:00 : 19:30 : Opera University Tour en la Universidad Carlos III de Madrid (Campus de Leganés, Salón de Grados, edificio Padre Soler)
• 29 de Abril 18:00 : 19:30 : Opera University Tour en la Escuela Universitaria de Ingenieria Tecnica Informatica de Oviedo (Salón de Actos)
• 30 de Abril 18:00 : 19:30 : Opera University Tour en la Universidad de León (TBA)

En tinysrc.mobi puedes encontrar un interesante servicio, que además es gratuíto, para adaptar imágenes grandes a las pequeñas pantallas de los terminales.

¿En qué consiste? simplemente es un servicio web, que al indicar la ruta de una imágen (en su atributo src), acompañado de ciertos parámetros opcionales, te permite obtener una nueva imagen más adecuada para teléfonos móviles: hablamos de tamaño (en pixels) y peso (kilobytes)… incluso permite elegir el formato (gif, jpg y png). Manteniendo siempre las proporciones de la imagen.

Entre los parámetros opcionales, permite especificar el tamaño en pixels (ancho ó ancho y alto) o de forma genérica en tipo de dispositivos (ultra, hight, medium, low, poor), el formato de la imagen (gif, jpg y png).

En las pocas pruebas que he estado haciendo, funciona. No pierdas más tiempo y visita tinysrc.mobi: merece la pena.

Nadie me podrá convencer que el diseño y desarrollo de sitios web para dispositivos móviles es muchísimo más complicado que la web para dispositivos de sobremesa. Nos podemos quejar que en la web de “monitores grandes” es complicado, porque no todos los usuarios tienen la misma resolución, navegadores, configuración, o sistema operativo… pero en el caso de la web móvil la fauna es mucho más variada y desconocida.

El éxito, la difusión y presencia navengado por internet del iPhone e iPod Touch, facilita y justifica bastante los desarrollos para éstos dispositivos: hay muchos, sus características están muy bien documentadas. Además al contar con wi-fi y estar asociados en casi siempre a un plan de datos (en el caso del iPhone), son dispositivos desde los que se navega y mucho por internet. Y, cáspita, tienen una experiencia de usuario brutal.

¿Y el resto de los dispositivos? La teoría dice que se deben diseñar los sitios web para un número limitado de tipos dispositivos con unas características comunes (tamaño de pantalla, soporte de lenguajes de marcado, estilos, scripts,…), y tras el prototipado, en la fase de desarrollo, detectar las características de los dispositivos gracias a su user-agent, y enviar el código y contenido optimizado.

Entre la opción anterior, y dejar que el navegador del pequeño dispositivo se las apañe como pueda para mostrar una página plagada de tablas para maquetar, hay un amplio espectro de posibilidades en el desarrollo de web móvil (no todas recomendables, por supuesto).

Pero hay que ser realista, y la web todavía no está lejos de ser un entorno agradable para dispositivos móviles navegando por internet (salvo excepciones, y afortunadamente cada vez más).

Teniendo en cuenta que no todos los sitios web están preparados para recibir visitas de pequeñas pantallitas (por no hablar de usuarios con discapacidades y sistemas operativos-navegadores-configuración diferentes), hay pocas formas de navegar con una experienca de usuario no-demasiado-penosa:

• Usando navegadores del tipo Opera Mini o Bolt, en los que un gateway o pasarela actúa como intermediario entre el sitio web y el dispositivo, enviando el contenido adaptado (y en el caso de Opera Mini, ni siquiera es una página web, sino un fichero de tipo OBML). Ahorra mucho peso y permite a muchos terminales mejorar notablemente las capacidades de navegación y la experiencia de usuario.
• Navegar a través de sitios web o portales – en muchas ocasiones de las propias operadoras de telefonía o carriers – que adaptan el código y contenido a los terminales.

En los dos casos, surge un elemento de gran importancia, y que al igual que los árbitros en un partido de fútbol, es mejor que no se hagan notar. Hablo de los proxys y transcodificadores.

El funcionamiento, si no lo conoces, te lo puedes imaginar: hay una web y un navegador que si se juntan, hacen catacrocker. Solución: que algo actúe como intermediario para adaptar el código y contenido original del sitio web al navegador del dispositivo móvil:

• si sólo admite 10 Kbs y la página pesa 100 Kbs, pues se “trocea”.
• si hay imágenes PNG mayores que la pantalla y además el terminal no las soporta, pues la reduce y transforma en GIF.
• …

Si un sitio web no está preparado para recibir a internautas móviles – exceptuamos aquí a los navegadores que muestran la web miniaturizada en pantalla y no la “trocean” en diferentes páginas -, un transcodificador puede ser la diferencia entre una visita y un en error (con la lógica frustación del usuario).

Pero… ¿y los sitios web que están preparados para los dispositivos móviles? En principio no debería hacer nada “intrusivo”, como cambiar la lenguaje de marcado, estilos, cabeceras HTML, user-agent,… y no hablemos de modificar el diseño o el contenido: por ejemplo cambiando los colores corporativos, añadir una barra de navegación propia, o incluso incluir publicidad sin el consentimiento y participación en los posibles beneficios del sitio web que se está visitando. ¿Y qué pasa con las páginas web seguras?

Consecuencia: algo que en principio puede ser “útil”, puede acabar siendo siendo algo deleznable y vil si no se actúa de manera responsable.

Si quieres saber cuáles son los límites “tolerables” para los transcodificadores ajenos (no hablo obviamente de los que están actuando del lado del servidor), puedes dar un vistazo al Rules for Responsible Reformatting: A Developer Manifesto, de Luca Passani.