Entradas en la categoría “Análisis”

Charla de Nate Koechley, desarrollador front de Yahoo! – quinta entrega -

5 de junio, 2009 - por | | Análisis, Frontend

El 18 de marzo se publicó en YUI Theater la charla de Nate Koechley, primer ingeniero front de yahoo! Grosshat ha pensado que sería interesante traducir al español algunas partes con mucha sustancia de la transcripción de la charla, ya que resultan muy esclarecedoras sobre el desconocido papel que desempeña el desarrollador front en las empresas que se dedican a la web (frontend engineer en USA).

Nuestra traducción de la quinta parte de la charla

Vamos a tratar un poco más de este tema ahora – algunos de sus aspectos más destacados. Fundamentalmente, queremos mantener las cosas separadas. No queremos que el código JavaScript estorbe a lo demás, no queremos que sea molesto, así que no ponemos JavaScript en el archivo HTML – lo llamamos más tarde como un recurso externo. Como estamos construyendo nuestra interfaz, no podemos depender de JavaScript – puede que no sea importante, pero tienes que trabajar como si sí lo fuera. Además, no podemos confiar en JavaScript – aunque trabajar del lado del cliente presenta agradables ventajas para la usabilidad, a nivel de servidor, no podemos confiar en que la validación sea correcta. Podemos hacer comprobaciones rápidas del lado del cliente para mantener al usuario feliz, pero siempre debemos recordar que hay que validar esas cosas de nuevo del lado del servidor, donde tenemos más control y confianza. A medida que escribimos JavaScript, e interactuamos con diversos objetos en la página, es una buena práctica testear para asegurarse de que esos objetos existen antes de hacer algo con ellos. Quieres escribir JavaScript de forma segura, que no falle. En cuarto lugar, debido a las características del JavaScript, tenemos que estar seguros de pensar en nuestras costumbres. Esto significa no llevar el espacio de nombres con variables globales y cosas por el estilo, preocupándose por su ámbito, sus funciones y sus objetos. Y luego, finalmente, apoyar actividades paralelas. No todos los usuarios interactuan con el ratón, y no todos los usuarios interactúan con un teclado, por lo que es importante proporcionar puntos de interacción en paralelo. Si algo ocurre cuando pasas el ratón por encima de algo, quizás también debería ocurrir a través de otra opción alternativa.

Uno de mis motivos personales de queja estos días, un ejemplo de JavaScript obstrusiva, es cuando se quita un HREF para sustituirla por una interacción sólo JavaScript. Así que es una de las primeras cosas que busco cuando reviso código estos días. La web está construida mediante enlaces; Los HREF son la base de la web, lo que mantiene la relación entre los sitios. Cada vez que nos saltamos este punto en lugar de poner algo con sentido allí – ya sea un protocolo de JavaScript o un marcador de posición – hemos roto la interacción para algunas personas. Una vez más, no podemos depender de JavaScript – queremos ser capaces de navegar, y enlazar, sin necesidad de código JavaScript en la página. Por lo tanto, no queremos tener protocolos de JavaScript, no queremos tener que hacer clic en el JavaScript. Hablaremos de esto en un poco más en detalle en unos minutos.

La tercera técnica – y de nuevo, la mejora progresiva, JavaScript no obstructivo, el apoyo gradual al navegador – son todas piezas del mismo rompecabezas, son el soporte para la consecución de los mismo objetivos. Antes de la noción del apoyo gradual al navegador, considerábamos el apoyo al navegador de forma binaria. Cuando trabajaba de gestor, antes de incorporarse a Yahoo!, me pregunta a menudo, al comienzo de un proyecto: “¿Qué navegadores tenemos que soportar en este proyecto? ¿Vamos a soportar Explorer 5 en Mac?” Y siempre se preguntaba en un sentido binario, donde la respuesta era sí o no. Con el tiempo nos dimos cuenta de que eso es contrario a nuestro objetivo de máxima disponibilidad – cada vez que elegimos no soportar a un determinado navegador, significa que estamos eligiendo tener menos disponibilidad. Así que esto fue la primero que hemos tenido que entender, que el soporte no es binario. La segunda cosa que hemos tenido que comprender es que el soporte no significa identidad. Obligar a que cada píxel se comporte de la misma forma para cada usuario en el mundo no significa que soporte al usuario. En cambio, soportar un navegador, queremos establecer lo que el navegador puede manejar de la manera más eficiente posible.

Y, por lo tanto, con estas dos cosas en mente, hemos llegado al concepto de soporte gradual al navegador, en lugar de soporte binario. Y hemos definido tres formas de soporte. En el nivel más bajo, una base estable, nuestra red de seguridad, es la experiencia de grado C. Metemos en una lista negra a los navegadores de grado C y son identificados como navegadores incapaces de manejar la tecnología moderna. Si no puede manejar CSS, si no puede manejar Javascript, ni cosas de la misma naturaleza, entonces le ponemos en una lista negra para que se sepa que se trata de un navegador que no puede manejar dichas tecnologías. Cuando un navegador de la lista negra llega a Yahoo!, el código JavaScript se oculta, se oculta el código CSS, y sólo le damos HTML significativa. Así que no tienen la experiencia de diseño visual que se pretende, ni el comportamiento de DHTML, pero tienen acceso a los todos los contenidos – pueden hacer búsquedas web, puede leer las noticias, pueden enviar un mensaje de correo electrónico. Y eso es soportar el navegador.

En un extremo tenemos una lista negra con el grado C de soporte al navegador. En el otro extremo tenemos una lista blanca de grado A de soporte al navegador. Estos son los navegadores que son capaces de comprometerse con un control de calidad riguroso. Estos navegadores pueden interpretar todo el código CSS y JavaScript que se añade al HTML y, básicamente, ofrecen una experiencia perfecta al píxel, tanto en el diseño como en el desarrollo.

Y así – además de tener nuestra lista negra por un lado, y nuestra lista blanca por otro – en el centro están los navegadores de grado X, una especie diferente a los demás. No son capaces, y podrían estar en la lista de grado C, pero no están bien probados así que terminan en la lista de grado X. Y algunas personas se sorprenderán al saber que hay miles y miles y miles de navegadores en esta lista. La mayoría de las personas pueden nombrar Firefox, Internet Explorer, Safari, Opera y – quizás también Camino, Flock, SeaMonkey, Galeon y alguno más. Pero esas son sólo las marcas más comunes – tal vez los 30 más comunes. Pero, en realidad, en un mes determinado en Yahoo! vemos por el barrio más de 10.000 usuario diferentes que solicitan nuestras páginas. Y el grado X es el de alcance general para eso. Si, con el tiempo, nos damos cuenta de que alguno de estos navegadores raros es incapaz de manejar tecnología moderna le damos la experiencia de grado C, pero si no, asumimos que puede manejarlo, somos optimistas para el diseño. Le damos toda la experiencia y esperamos que sirva bien. Y así por haber clasificado de esta manera, en un proceso de soporte continuo, somos capaces de invitar a todos a experimentar nuestro sitio web, manteniendo el 100% de disponibilidad.

Yahoo! publica, periodicamente, una tabla con el soporte gradual a los navegadores de grado A. Esta es la tabla actual: Firefox 2 y 3, IE 6, 7 y 8, Opera y Safari, a través de sistemas operativos comunes. Es importante recordar que el hecho de que un navegador con un determinado sistema operativo no aparezca en la lista, no significa que no esté soportado. Sólo significa que no estamos dedicando toneladas de recursos al control de calidad de dicho informe. Navegadores como Flock comparten Gecko de Firefox como motor y renderiza los sitios de forma idéntica. Así que permite tener una gran experiencia; no sólo son tratados como un navegador con soporte de grado A.

Puedes comprender el concepto pero ¿qué significa en la práctica? Aquí tenemos una captura de la pantalla de Yahoo! Search en la experiencia de grado C, donde todos los JavaScript y CSS están desactivados. Puedes ver que estamos usando marcado significativo – tenemos una lista ordenada de enlaces, estamos usando las cabeceras, mantenemos el mismo cuadro de búsqueda en la parte superior de la página, pero de hecho sólo vemos un diseño lineal, no hay CSS para el control de la disposición. Así que no tienes la segunda columna, no hay DHTML alrededor de la caja y, si haces clic en “imágenes” en lugar de “búsqueda en la Web” lo que realmente va a hacer el servidor es un viaje de ida y vuelta devolviendo una nueva búsqueda vertical. Como contraste, aquí tenemos una experiencia de grado A. Puedes ver que el diseño de multi-columna aparece, la iconografía y un mejor control tipográfico – además, no puedes verlo en esta captura de pantalla estática, pero ahora el cuadro de búsqueda se basa en DHTML y cambia el contexto de la búsqueda cuando haces clic en las pestañas. Así, la experiencia de grado C está ahí y es funcional para todo el mundo – aunque la mayoría de la gente obtiene la experiencia de grado A con todas sus campanas y silbatos.

Aquí tenemos otro ejemplo del sitio para fotos de Yahoo! Aquí, estamos tratando de puntuar un determinado tipo de foto. Y si lo piensas, conceptualmente, estamos en una puntuación interactiva – tengo una lista ordenada de opciones de puntuación, y cuando hago clic en una de ellas se envía mi voto al servidor, y mi puntuación se registra y, a continuación, se muestra en la página. Sin JavaScript y CSS, sólo se muestran los enlaces que permiten respuesta del servidor. Cuando nos fijamos en un grado de experiencia A – vemos CSS para suprimir los enlaces de texto, y en su lugar se remplazó por un widget muy familiar de estrellas, que utiliza Ajax, JavaScript entre bastidores, para registrar la votación sin actualizar la página. Así que incluso para interfaces muy sofisticados es posible este enfoque gradual cuando se están siguiendo este tipo de técnicas de mejora progresiva.

Charla de Nate Koechley, desarrollador front de Yahoo! – cuarta entrega -

6 de mayo, 2009 - por | | Análisis, Frontend

El 18 de marzo se publicó en YUI Theater la charla de Nate Koechley, primer ingeniero front de yahoo! Grosshat ha pensado que sería interesante traducir al español algunas partes con mucha sustancia de la transcripción de la charla, ya que resultan muy esclarecedoras sobre el desconocido papel que desempeña el desarrollador front en las empresas que se dedican a la web (frontend engineer en USA).

Nuestra traducción de la cuarta parte de la charla

La primera de las técnicas tiene que ver con la noción de mejora progresiva. Con frecuencia, en una votación a mano alzada, si pregunto por cuántas personas están familiarizadas con la mejora progresiva, pocos levantan la mano. No obstante, si pregunto por cuántos están familiarizados con el concepto de degradación elegante, entonces, casi todos levantan la mano. La mejora progresiva es la otra cara del concepto de degradación elegante – son usados en la misma dirección pero en sentidos opuestos. Si en vez de pensar en la degradación elegante piensas en construir un sitio o un proyecto pensando en las cosas que no van a funcionar bajo determinadas circunstancias, es decir, le damos la vuelta y comenzamos aumentando progresivamente la fuerza del núcleo. Así que construimos nuestro núcleo fuerte y, después, desarrollamos las mejoras hasta llegar al mismo sitio. Pero como hemos comenzado desde dentro hacia fuera sabemos que nos sostenemos sobre pies sólidos. Algunas veces, si seguimos una filosofía de degradación agradecida, cuando llegamos al final del proyecto no tenemos tiempo para tener en cuenta aquéllas cosas y asegurarnos de que no ocurra. Si lo haces en sentido opuesto, comienzas por las pequeñas cosas y luego construyes, te aseguras una red segura por debajo.

Entonces, ¿qué es exactamente la mejora progresiva? ¿Cómo lo haces y cuáles son sus reglas? A continuación, algunas de ellas. Implicaría comenzar por el centro, como hemos dicho, y construir tu desarrollo. Lo primero es el uso de marcado para enriquecer el contenido. Empezamos con el contenido de nuestra página y le damos más significado mediante marcado. Una vez que tenemos esta base, podemos probar que todo funciona bien y esta es nuestra red de seguridad. Hablaremos de por qué es una red de seguridad dentro de unos minutos. Una vez que hayamos hecho eso, podemos comenzar con CSS para diseñar la página – la disposición de las columnas, distribución de imágenes, color y topografía. Una vez que tenemos esas dos piezas del puzzle, entonces desarrollamos el JavaScript para el DHTML, el comportamiento, la comunicación Ajax, que hace que las cosas sean más rápidas para aquellas personas que tienen acceso.

A lo largo de este proceso, estamos respetando las preferencias de los usuarios, tanto conceptualmente, dejando elegir e interactuar con las capas, como en la práctica, siendo conscientes de que se puede cambiar el tamaño de la fuente, el tamaño y resolución de la pantalla, etc., y tener en cuenta estas cosas apoya la construcción del sitio desde el principio. Además, nos esforzamos para no crear barreras a nadie que entre. Puedes construir – cuando construyes, cualquiere puede entrar en cualquier parte del proceso sin la necesidad de llegar de un bar determinado. Construimos una base sólida, la gente puede interactuar a cualquier nivel. Así que estos son algunos de las cuestiones que están detrás del concepto de mejora progresiva.

Relacionado a la mejora progresiva, pero más específicamente relacionado con el JavaScript, es la noción de Javascript discreto. Si haces una búsqueda en la Web para saber más del Javascript discreto, tendrás la oportunidad de encontrar en este enlace. Nuestro colega, Christian Heilmann, escribió esto que es un hermoso tutorial autodidacta para adentrarte en los aspectos y técnicas de Javascript discreto.

Charla de Nate Koechley, desarrollador front de Yahoo! – tercera entrega -

1 de abril, 2009 - por | | Análisis, Frontend

El 18 de marzo se publicó en YUI Theater la charla de Nate Koechley, primer ingeniero front de yahoo! Grosshat ha pensado que sería interesante traducir al español algunas partes con mucha sustancia de la transcripción de la charla, ya que resultan muy esclarecedoras sobre el desconocido papel que desempeña el desarrollador front en las empresas que se dedican a la web (frontend engineer en USA).

Nuestra traducción de la tercera parte de la charla

Así que ahí queda un poco de historia y de definición sobre lo que hacemos. Ahora quiero hablar de cómo lo hacemos, y qué principios guían nuestras decisiones – cuando estamos frente a todas estas opciones, ¿cómo sabemos que la elección es la correcta para nuestro proyecto? Durante los años en Yahoo! hemos asentado una serie de principios básicos y me gustaría hablar de cuatro actuales.

Primero es la disponibilidad – esta es la piedra angular de la construcción de un sitio web. Si el sitio no está disponible para las personas, se acabó, no tendríamos ni que molestarnos. Por tanto, nuestro trabajo es asegurar que todo lo que hacemos está ahí, corriendo, a disposición de todos. Esto tiene que ser así independientemente de dónde estén los usuarios en el mundo, o las circunstancias especiales que puedan tener – todo tiene que estar disponible y accesible. He utilizado la palabra disponibilidad a propósito – se oye mucho hablar de la accesibilidad pero la disponibilidad se aplica a todo el mundo y es un término general que abarca también la accesibilidad. Y así me gusta pensar que los sitios están disponibles para todos, independientemente de lo que ello supone.

Un segundo principio es el sentido de la apertura. La web se basa en tecnología abierta y plataformas abiertas. Muchos aficionados y desarrolladores web han considerado el código y la ingeniería inversa como cosas que pasan; la apertura es una parte fundamental de la web, una parte fundamental que la mantiene saludable y viva. Por eso hay principios filosóficos para la apertura, pero también es una técnica de supervivencia para entender el trabajo que hacemos. Es importante que nosotros, como industria y como disciplina, sigamos compartiendo lo que estamos aprendiendo, y continuemos abogando por una mejor tecnología, mejores prácticas, la mejora de las políticas – todas estas cosas juntas ayudan a asegurar que tenemos una Internet sana, que beneficia a todo el mundo. La apertura, en mi opinión, es la base para todo esto.

El tercer pilar es la riqueza. Ha habido un gran avance en el desarrollo de DHTML y de Ajax durante los últimos cinco años, y es lo que siempre estamos intentando. Es nuestro trabajo como diseñadores de software, diseñadores de interfaz y desarrolladores web, para hacer herramientas que son útiles para los usuarios – y la riqueza les proporciona servicios más ricos con características más ricas. Por lo que queremos cumplir este objetivo sin olvidar nunca el primer principio que es el de la disponibilidad. Hay que conseguir un equilibrio entre la riqueza y la disponibilidad. Si elevas el listón demasiado alto, puede suponer la exclusión de gente. Y con el fin de construir con esta riqueza, lo hacemos en capas de modo que empezamos con un núcleo sólido y capas cada vez más ricas y después de que esto es accesible para los usuarios, no importa desde dónde accedan y cómo lo hagan.

Otra cosa a tener en cuenta acerca de la riqueza es que, como desarrollador web, probablemente, no seamos un usuario medio. Aquí, en Yahoo!, estamos en lo alto de la ola al tener una conexión a Internet tremendamente rápida – todo se carga rápidamente y muchos de nosotros trabajamos con hardware nuevo y con un montón de memoria – y en estas condiciones hacemos ricos desarrollos en JavaScript y escribimos un montón de software que se ejecuta en el navegador, y, aun así, trabajamos muy bien. Pero tenemos que recordar que existen personas que tienen equipos diferentes, diversos anchos de banda, y así sucesivamente. Por tanto, todo esto son razones para construir en capas y con precaución.

Y, por último, el cuarto principio es la estabilidad. Queremos construir sitios que sean estables, así que intentamos que las cosas corran en todo momento, en términos de disponibilidad – pero también desde una perspectiva de futuro. La web es joven. No sabemos que nos encontraremos al doblar la esquina. Desconocemos qué cosas se inventarán y qué tecnologías vendrá. Por eso es importante invertir en estabilidad, en una infraestructura fuerte y en un código estable para poder desarrollar una plataforma potente de cara al futuro. Por tanto, centrándonos en la estabilidad, inviertes en futuro y, de nuevo, te preparas para ese futuro – cualquiera que sea. A todas estas cosas tienes que empezar hoy. No puedes estar listo mañana si empiezas mañana – necesitas poner en prácticas todas estas cosas.

Así que estos son los cuatro principios básicos que nos guían y sé que son ideas nobles pero al tratar de encontrar el camino correcto a través de toda esta tecnología, estos principios nos conducen en la dirección correcta. Para continuar, son tres las técnicas que sustentan estos principios…

Charla de Nate Koechley, desarrollador front de Yahoo! – segunda entrega -

30 de marzo, 2009 - por | | Análisis, Frontend

El 18 de marzo se publicó en YUI Theater la charla de Nate Koechley, primer ingeniero front de yahoo! Grosshat ha pensado que sería interesante traducir al español algunas partes con mucha sustancia de la transcripción de la charla, ya que resultan muy esclarecedoras sobre el desconocido papel que desempeña el desarrollador front en las empresas que se dedican a la web (frontend engineer en USA).

Nuestra traducción de la segunda parte de la charla

Una cuestión básica: ¿qué es exactamente un desarrollador front? Hay varias formas de definirlo y más adelante veremos qué hace. Una forma simple de definir lo qué hacemos es diciendo que somos aquel

Charla de Nate Koechley, desarrollador front de Yahoo! – primera entrega -

24 de marzo, 2009 - por | | Análisis, Frontend

El 18 de marzo se publicó en YUI Theater la charla de Nate Koechley, primer ingeniero front de yahoo! Grosshat ha pensado que sería interesante traducir al español algunas partes con mucha sustancia de la transcripción de la charla, ya que resultan muy esclarecedoras sobre el desconocido papel que desempeña el desarrollador front en las empresas que se dedican a la web (frontend engineer en USA).

Nuestra traducción de la primera parte de la charla

Hola. Me llamo Nate Koechley — soy ingeniero front de yahoo! Vamos a hablar sobre los profesionales del desarrollo de la interfaz. Es una disciplina un poco oscura, actualmente en desarrollo – incluso, en algunos sitios, no se conoce lo que hacen estos profesionales y la importancia del trabajo que desempeñan. Así que vamos a intentar aclarar algunas cuestiones y explicar lo qué hacen exactamente y cómo lo hacen.

El objetivo de esta charla es reiterar los valores fundamentales del desarrollo front, abogar por la disciplina y, así, ayudar a promover una web saludable. Vamos a dividir la charla en cuatro secciones. Primero, vamos a hablar un poco desde la perspectiva histórica — qué hemos sido y dónde nos encontramos ahora. Segundo, vamos a hablar sobre las creencias y fundamentos del desarrollo front. Después, vamos a adentrarnos con más detalle en las áreas de conocimiento de nuestro trabajo. Y, finalmente, voy a intentar hablar del por qué de esta materia.

Vamos pues, en primer lugar, con la perspectiva histórica. Creo que esta es la página principal de yahoo de 1994. Veréis que se trata de cuando Yahoo no tenía signo de exclamación. Y aquí debajo, sólo por curiosidad: 31.000 links en la base de datos… Pero, en cualquier caso, Internet ha recorrido un largo camino desde entonces. Una cosa a destacar en esta página, para la gente que está interesada en los estándares web, en el marcado semántico y cosas por el estilo, esta página es muy limpia desde dicha perspectiva. La cabecera, una serie de links, la lista de enlaces y categorías. Empezamos fuerte, pero ha pasado mucho tiempo desde entonces.

Esta es Yahoo! un par de años después, en 1996. Las primeras imágenes en la parte de arriba y, justo debajo, un enlace a la versión de sólo texto de Yahoo! nos indican que, desde el principio, Yahoo! ha empatizado con el usuario y con sus diferentes necesidades, y que ha procurado mantener un sitio accesible.

Poco tiempo después — en 1997. Un poco más de fidelidad en la página. Algunas imágenes más y mucho más contenido. Se comienza a ver tablas para desarrollar los primeros diseños de columnas múltiples — pero por lo general, muy parecido a como era dos años antes. Y esa tendencia continúa. En 2000, más contenido, más efectos visuales — resaltando bordes, usando colores en áreas diferentes. Pero aun así, fundamentalemente, la misma página que antes. Esa tendencia continúa — es 2001.

Y es al llegar a 2003 cuando comenzamos a ver algunas diferencias claras — mucho más control sobre el diseño visual, mayor control sobre la renderización de las listas, cabeceras y fondos de imagen — muchas más cosas dentro de una página. Y aquí tenemos el Yahoo! actual. La página de ahora, de principios de 2009. Una página compleja y sofisticada, con muchas oportunidades de interacción y personalización.

Así que si saltamos hacia la mitad de estos 14 años de historia, en 2001, podemos reflexionar sobre lo que Yahoo! era entonces. Yahoo! tenía siete años de historia, era una de los sitios web más grandes del mundo con 3000 personas empleadas — 0 de las cuales eran desarrolladores front. Así que construímos una gran sitio, con muchos servicios, visitada por gente de todo el mundo cada día, sin la ayuda de ingeniería front.

Comencemos desde este punto de inflexión y miremos hacia delante. En 2001, se contrató a los primeros desarrolladores front — gente especializada en gestión de navegadores, en construcción de interfaces de interacción con el usuario. Hoy en día hay, aproximadamente, 700 personas trabajando en Yahoo! como ingenieros front a tiempo completo, repartidas por nuestras oficinas a lo largo de todo el mundo.

En 2001, el sitio estaba construido a base de tablas, etiquetas de texto y experiencia muy estática. Hoy en día usamos marcado semántico y estándares para el diseño; el sitio es muy dinámico, muchas de las áreas están pensadas para su personalización — pero sigue siendo tan rápido como siempre. Hemos encontrado técnicas para poner más cosas en el sitio, dar al usuario mayor control y mantener la velocidad por la que se nos reconoce.

En 2001, el sitio web estaba disponible y accesible para todo el mundo — todo el marcado se pensó para que las personas pudieran interactuar con el contenido. Y hemos mantenido esta línea aunque se haya aumentado la sofisticación del sitio. En 2001 era un sitio muy básico y predecible — las pruebas eran un poco más fáciles porque había menos desarrollos y la experiencia era bastante estable y coherente en todo el mundo. En 2009, el sitio es muy, muy visual, muy adaptable y tan fiable como siempre.

Los usuarios evolucionan junto con la tecnología, y en 2001 había pocas expectativas sobre cómo un sitio web debería comportarse y cómo debía ser contruido. Las expectativas del usuario eran pocas. Hoy en día los usuarios se han sofisticado, tienen expectativas de cómo los sitios deben comportarse y qué servicios les deben ofrecer. Y esta interacción, la experiencia de usuario, puede ser muy compleja.

Por último, en 2001 la intersección entre el diseño y el desarrollo no se conocían — diferentes equipos trabajaban de formas diferentes, y la vinculación entre la gente de desarrollo front y la gente de desarrollo back se establecía al final en un proceso vago e indefinido. Y creo que estamos asistiendo al nacimiento de la ingeniería front como la intersección de ambas cosas.

Desde una perspectiva histórica diferente, Irene era la responsable del Departamento de Diseño y Experiencia del Usuario de Yahoo! así que ella fue la responsable de la contratación de los primeros desarrolladores front. Ella lo hizo para que les ayudasen a ofrecer un desarrollo más rico y adaptado a las nuevas demandas de los usuarios. Realmente, necesitaban crear un cuerpo de especialistas que llevasen a cabo este trabajo. La segunda motivación fue la de construir una disciplina definitoria para el trabajo que estaban desarrollando. En vez de limitarse a esperar que sucediera con el tiempo, queríamos tener un proceso riguroso y sacar el mayor partido a la tecnología, así tendríamos más flexibilidad y seríamos más eficientes en el camino.

No estoy seguro de cuántos recordaréis este libro — se llamaba “Creating Killer Web Sites” de David Siegel. Era muy conocido como libro que enseña a la gente a diseñar y crear sitios mediante el diseño de tablas que entonces estaba de moda. En el prefacio del libro, el autor escribía que “los maquetadores de la web veían las diferencias entre navegadores como algo beneficioso y creían que los usuarios elegirían cómo sus navegadores mostraban la página…” Y él tenía un problema con esto así que escribió que “quería más control sobre la página”, de forma que “tiró su libro de HTML a la basura para empezar desde cero”. Y esto está bien pero los navegadores van evolucionando, junto a la industria — no sabíamos cómo hacer todas las cosas que queríamos hacer y encontrar, así, formas de trabajar que estuvieran al orden del día.

Así que la web todavía se está recuperando de las decisiones erróneas y de los pilares defectuosos de la tecnología. Creo que, realmente, el desarrollador front es el radiólogo de la web — el que puede ver la enfermedad, comprender lo que está mal y encontrar un camino para hacer la web mejor.

Bases para el desarrollo web

2 de diciembre, 2008 - por | | Análisis

Cualquier persona que ha participado de alguna forma en un proyecto web, conoce la enorme incertidumbre con la que se trabaja, a causa de las numerosas opciones que se barajan. Tomar una decisión sobre cualquier aspecto conlleva la necesidad -o la sensación de tenerla- de informarse y evaluar las distintas alternativas, a menudo sólo apoyándose en una metodología cualitativa difícil de formular conscientemente.

En todo ésto hay una parte, para mí, asumible de forma natural, que tiene que ver básicamente con el esfuerzo constante por innovar. Las tecnologías nacen para tener versiones, mejoras e incluso ser sustituidas por otras, con lo que los cambios -estructurales o por meras modas- son algo inevitable. Algunas personas piensan, además, que es positivo; y, por supuesto, hay otras que opinan justo lo contrario. La incertidumbre a la que me refería se mueve básicamente en esta parte.

Ahora bien, hay todo otro conjunto de cosas que, en mi opinión, son de naturaleza arquitectónica, y que por eso mismo no deberían verse comprometidas por las otras. Desgraciadamente, muchas veces son las partes más descuidadas de los proyectos, y los problemas que traen consigo suelen convertirse en críticos.

La primera cosa que suele descuidarse es el marcado HTML. Este descuido tiene consecuencias a todos los niveles, puesto que la web se apoya, intrínsecamente, en las estructuras de los documentos. Existe todavía una actitud bastante generalizada que concede poca importancia a este aspecto, produciendo una base de conocimiento muy pobre y poco rigurosa. Recientemente, Opera hacía públicos algunos datos recogidos a través de su herramienta MAMA, que cifraban en tan sólo un 4,13% los documentos existentes en la red validados correctamente. En este tipo de datos lo interesante no está tanto en las cifras, cuanto en la actitud que éstas reflejan.

El descuido en el marcado produce una reacción en cadena de descuidos que, en conjunto, afectan sustancialmente al documento.

Por un lado, existe un riesgo mayor de que estructura y presentación no se comporten como partes estancas, con lo que se incrementa la probabilidad de restringir y/o dificultar el acceso al documento (documentos más pesados, documentos no válidos para algunos dispositivos, etc.), así como de ofrecer un contenido menos significativo.

Por otro lado, aumenta la dificultad de incorporar comportamientos relacionados con el navegador, puesto que éstos se benefician de una estructura bien organizada y limpia de estilos. Ésto, a su vez, incrementa la posibilidad de restringir el acceso a causa de problemas con los dispositivos.

Asimismo, al disponer de un contenido menos significativo, disminuirá la capacidad de acceder a éste mediante búsquedas de patrones y/o semánticas. Lo que repercutirá, nuevamente, en restricción de acceso.

Más importante aún que todo ésto es que este tipo de actitud va en aumento según se desarrolla un proyecto, de forma que las pocas consideraciones que se tenían en el momento 0, han disminuido en el momento 5, y empiezan a considerarse como un problema en el momento 10. A partir de ahí se habrá invertido lo que debería ser el orden natural del proyecto, de forma que la web habrá pasado a considerarse un corsé demasiado pobre que necesariamente hay que forzar.

En ese punto penetrarán todos esos aspectos de la primera parte (tecnologías cambiantes, modas, etc.) desbordando sus límites naturales. En la historia de la web -que escribimos cada día- hay ejemplos de todo ésto -que todos vivimos diariamente- y se puede decir que prácticamente nadie está a salvo, y que es un ejercicio diario hacer el esfuerzo por mantener cada cosa en su sitio.

Merece la pena, puesto que ayuda a gestionar la incertidumbre que se mencionaba al principio, poniéndole límites, y evita la generación gratuita y progresiva de problemas y restricciones a todos los niveles.