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

5 de junio, 2009 - por

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.

Tema: Análisis, Frontend

Etiquetas: , , , , , , , , .


Otras entradas que pueden interesarte