Entradas en la categoría “Frontend”

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.

Probar, probar, probar

6 de noviembre, 2008 - por | | Desarrollo, Frontend

En el desarrollo web una de las áreas posiblemente más descuidada es la de probarlo todo con diferentes navegadores. Descuidar cualquier cosa que tenga que ver con el elemento más crucial de todos (el navegador) es un problema bastante gordo. Aunque no hay una solución perfecta, sí existen formas de corregir parcialmente el problema.

Lo primero, antes de nada, es familiarizarse mucho con los navegadores; convivir con ellos; hacerse cargo de su diversidad; entender los distintos motores de renderización (“layout engines”) y cómo se apoyan los navegadores en ellos; comprender la forma en que se produce esa renderización… Todo esto siempre es mejor hacerlo, aunque sea un poquito, que no hacerlo. El resultado, además de los conocimientos concretos, es una actitud desde la que es más fácil resolver problemas y crear cosas, y desde la cual la diversidad dejará de ser percibida como un obstáculo para ser explotada como un beneficio.

Podemos empezar por echarle un ojo al listado que de navegadores que ofrece Wikipedia.

Una vez que ya estamos con esa “mochila”, podemos afinar un poco, distinguiendo las cosas que pueden variar de unos a otros navegadores: marcado, hojas de estilos, nivel del DOM, soporte de imágenes, etc.

Con todo eso, es razonable crear una plataforma mínima de pruebas. La complejidad y coste de la plataforma de pruebas estará en función de nuestras necesidades. En la red hay algunas cosas interesantes.

Por ejemplo, si queremos hacer alguna prueba puntual, y no necesitamos resultados inmediatos, browsershots.org está bastante bien. Es abierto, gratuito y fácil de utilizar, e íntegramente web. Utiliza una nube de ordenadores voluntarios a los que envía las peticiones, y que escupen capturas de pantalla que luego puedes visitar directamente en la web. No es muy rápido, y la captura es plana. En esta misma línea, hay soluciones comerciales como browsercam.com, y litmusapp.com, que funcionan bastante bien, y son más rápidas que la primera. El principal problema que le encuentro a todas ellas es que necesitan trabajar con urls públicas, lo que en entornos de desarrollo no es habitual.

Si, por el contrario, necesitamos realizar periódicamente pruebas y no sólo disponer de una captura de pantalla, sino poder analizar/modificar directamente el código, lo mejor es montarse un entorno de pruebas instalando diferentes sistemas operativos (so), diferentes navegadores y distintas versiones de cada uno de éstos. Esta gama puede variar; si se trata de algo que ya está en marcha y tiene unas estadísticas de uso muy concretas (por ejemplo, Windows XP con IE6 y Windows Vista con IE7), podemos concentrarnos en ese grueso; si se trata de algo nuevo (un portal, una aplicación, etc.), entonces dependería de la orientación que se le quisisera dar (¿pcs? ¿dispositivos móviles?…). En cualquier caso, es bueno habituarse a mirar las estadísticas de uso globales (por ejemplo, el XiTi Monitor), y de ahí extraer una idea sobre lo que se necesita.

La forma de montar un banco de pruebas de este tipo pasará casi siempre por tirar de máquinas virtuales, para correr los diferentes sistemas operativos, e intentar instalar el número máximo de versiones de un mismo navegador en una misma máquina virtual, de forma que minimicemos las complicaciones y la pesadez de tener levantadas varias.

Un tercer elemento importante es el de los dispositivos. Es bueno, para simplificar, considerar los monitores como un dispositivo más, como podría serlo un móvil, una pda o un tablet. Lo más importante es tener en cuenta la resolución de pantalla y la profundidad de color (bits por píxel). En ésto tambien es bueno habituarse a consultar las estadísticas sobre uso de dispositivos, que suelen incluir su resolución de pantalla y su profundidad de color. Como en el caso de los navegadores, hay diversidad; y como entonces, no debemos interpretarla como un obstáculo sino como un beneficio, adaptándonos a ella. Quizás la prueba más importante sea la de comprobar que la paleta cromática que estamos utilizando se ajusta igual de bien a profundidades de 24, 16 y 8. Y es ahí donde el uso los llamados “colores seguros para la web” así como de los “browser-safe colors” (Lynda Weinman) adquiere toda su importancia.

Como hay un montón de chicha en todos estos temas, voy a intentar ir escribiendo entradas para ir complementando esta información.