Entradas con la etiqueta “web”

Efecto bokeh para home y landing pages

10 de marzo, 2010 - por | | Diseño, Tips

Poco a poco el efecto bokeh se ha ido convirtiendo en uno de los recursos más frecuentes para conseguir gráficos atractivos. Con frecuencia, se utiliza sobre imágenes de fondo posicionadas en la cabecera o en el body de las home y de las landing pages, es decir, de aquellos espacios que esperan no sólo el mayor número de visitas sino también rebajar el porcentaje de rebotes.

Con ocasión de un proyecto reciente que hemos estado preparando para la gente de noalamonotonia.com, hemos tenido la oportunidad de probar distintas técnicas sobre distintas suites gráficas para conseguir ese efecto. Hemos visto también que la comunidad ha generado un montón de buenos tutoriales, ejemplos y patrones de texturas listos para usar. Así que hemos seleccionado varios de los recursos que más nos han gustado. A ver qué te parecen.

FOSDEM 2010: más open source, más diversión :)

21 de febrero, 2010 - por | | Open Source

En 2009 Grosshat estuvo en el FOSDEM y lo disfrutó mucho. Como comentamos entonces, Fin de semana en el FOSDEM, el ambiente de esta reunión europea de desarrolladores y simpatizantes del open source es realmente positivo y divertido, y su visita siempre te reporta un montón de información y te da un poco el tono de por dónde están yendo las cosas en líneas generales.

En 2009 nos parecía que lo más preponderante había sido todo el tema de dispositivos embebidos, para los cuales distintas distribuciones populares y otras tantas menos conocidas tenían ya preparados un montón de recursos tanto en forma de software como de hardware. Por su parte, en 2010 hemos vuelto con una impresión bastante fuerte de que las alternativas a los motores SQL son ya una realidad, y que los temas de escalabilidad en la web ya están convirtiéndose en un tema frecuente a raíz de la aparición y consolidación de portales (ala Facebook) que han llevado las cifras de visitas y uso a cotas difícilmente pensables hace unos años.

El reparto de charlas ha reflejado muy bien el peso de esos 2 temas principales; por un lado, dentro de los llamados “Main Tracks” se creo uno dedicado completamente a la escalabilidad; por otro lado, en las “Developer Rooms” se organizaron más de una docena de charlas sobre el tema NoSQL. Al mismo tiempo, hubo bastantes referencias cruzadas entre ambos espacios, lo que reforzó aún más la intuición de que algunos de sus problemas tienen al menos un origen común. Ésto se vio perfectamente en la magnífica charla que dio la gente de Facebook, donde los temas de escalabilidad y las soluciones NoSQL fueron las alusiones más habituales.

Un año más ha sido una experiencia genial y una oportunidad perfecta para conocer Bruselas y disfrutar de la ciudad, con todos los encantos que tiene, incluidad la cerveza. ;)

Si no has podido ir, pero piensas que podrías animarte a ir el próximo año, échale un vistazo a los siguientes enlaces, donde recopilamos fotos, videos y presentaciones de todo el fin de semana.

Mi maquinita tatuada con Facebook

máquina de iñigo con la pegatina de facebook

Colecciones de fotos

Colecciones de vídeos

Presentaciones

  • en slideshare se han reunido muchas de las charlas

Plugins para GIMP

20 de febrero, 2010 - por | | Diseño, Tips

En Grosshat utilizamos GIMP para las tareas habituales de manejo de gráficos. En proyectos con clientes muchas veces se nos cae, bien porque no es el programa habitual en esos otros entornos, bien porque no incorpora las capacidades vectoriales que otros programas combinan con las netamente gráficas. En este sentido, Fireworks de Adobe sigue siendo una especie de navaja suiza realmente productiva.

Bueno, el caso es que si como nosotros eres de los que tiran de GIMP de forma habitual, manejar plugins se convierte con el tiempo en algo inevitable; de hecho, el programa está pensado como un core alrededor del cual la comunidad genera utilidades en forma de plugin. Así que profundiza, una vez más, en la exitosa forma de funcionar de la tradición open source: módulos sencillos que se interconectan fácilmente a partir de una base común.

Algunos plugins que seguro te van a ayudar un montón:

  • Image subdivide te permite dividir un gráfico en n filas y n columnas, y salvar cada celda de la matriz
  • Liquid Rescale trae a GIMP el escalado típico de Photoshop que posibilita redimensionar un gráfico de forma no uniforme pero sin distorsión
  • Save for Web es imprescindible si quieres manejar unos pesos razonables en gráficos para la web
  • Pencil drawing from Photo te proporciona un hermoso efecto de lápiz sobre un gráfico, muy bueno para diseño de sitios livianos y muy lineales
  • Layer Effects te suministra operaciones típicas de shadow, glow, bevel, overlay, etc.
  • Quick sketch ofrece un precioso efecto de esbozo sobre el gráfico que le proporciones; combina muy bien con el de Pencil que comentábamos más arriba

La instalación de algún script puede en ocasiones resultar un poco pesada, pero en general es algo sencillo y rápido. Y con la ventaja de cuentas con el código fuente y puedes modificar cosas triviales o profundas a tu gusto.

Más allá de estos plugins que destacamos aquí, apúntate como sitio de referencia el GIMP Plugin Registry.

Herramientas para la calidad front

20 de agosto, 2009 - por | | Calidad, Frontend

Cuando se dispone de cierta cantidad de código funcionando y estable, es conveniente empezar a pensar en términos de calidad. Del lado front la cosa no es distinta, y existen varias herramientas plenamente funcionales que nos pueden hacer la vida más fácil, al menos para empezar a poner las bases.

Para que todo nos resulte más manejable, es conveniente separar 3 partes del área front:

  • el marcado (html/derivados y css)
  • la interacción (javascript)
  • la disponibilidad (pesos, cabeceras, peticiones)

Para la primera parte existen algunos principios generales que permiten definir una orientación general de cara a la calidad, así como varias herramientas que ayudan a concretar esos principios. De éstas sin duda la que ha llegado a hacerse más popular ha sido la que tiene que ver con la validación del marcado html/xhtml, que se refleja en los conocidos iconos del W3C indicando si el documento ha pasado cierta validación.

Para la segunda parte se han ido asentando, con el tiempo, varias directrices generales, así como diferentes herramientas a nivel de análisis sintáctico, debugging y testing. La popularización de librerías marco, asociadas a plugins para funcionalidades concretas, ha introducido mayores niveles de calidad como punto de partida, pero también ha conducido el desarrollo a un entorno más complejo y, por lo tanto, potencialmente más difícil de mantener.

Por último, de cara a la disponibilidad el creciente uso intensivo de interacción ha llevado progresivamente a una mayor conciencia sobre la importancia de establecer rangos de pesos, tiempos de expiración para las cabeceras, y máximos de peticiones asumibles. Y estas ideas cuentan ya con algunas herramientas que permiten analizarlas y cuantificarlas, haciendo que la optimización sea un objetivo pragmático.

Voy a intentar recorrer esas 3 partes en diferentes entradas con la intención de:

  1. llamar la atención sobre los procesos de calidad en el área front;
  2. ayudar a que se entienda un poco mejor la interrelación entre las 3 partes mencionadas;
  3. recopilar ideas comunes y herramientas frecuentes del trabajo diario;
  4. poner mi granito de arena para que se entienda qué consigue cada proceso de calidad, de forma que no se mezclen ni se asocie burdamente calidad con eliminación completa de problemas.

Charla de Nate Koechley, desarrollador front de Yahoo! – séptima entrega -

20 de julio, 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 séptima parte de la charla

Ahora vamos a echarle un vistazo a la perspectiva histórica hablando sobre algunas de las creencias y principios. Me gustarÍa profundizar en algunas de las principales partes de la tecnología que tienen que tener en cuenta un ingeniero del interfaz.

Lo primero es el contenido de la capa: la capa HTML. Debe ser lo primero en el día a día de trabajo – queremos conseguir unas base sólida, antes de comenzar con otras partes tecnológicas. Antes de ponerte a escribir HTML tienes que definir en qué tipo de HTML vas a escribir mediante el doctype. ¿Qué es el doctype? El doctype es lo primero que aparece en un documento HTML. El elemento contiene una indicación sobre la definición del tipo de documento – lo cual sirve de indicación definitoria para el lector de la hoja, es decir, es una explicación de la tecnología que estás utilizando. En la práctica esto es importante porque da lugar a que los navegadores se comporten de modos diferentes. A principios de esta década, dado que los más modernos navegadores se estaban desarrollando, existía la preocupación de que si no se fijaban las singularidades de los viejos tiempos, los sitios que no se actualizasen podrían tener dificultades de renderización en los nuevos navegadores. Por lo que se quería ofrecer una forma de apoyar la idea de la compatibilidad con versiones anteriores, de sitios estrafalarios, a pesar de que los desarrolladores estaban empezando a crear más estándares basados en los sitios. Así que los vendedores de los navegadores eligieron el doctype como la forma de que los autores del documento – desarrolladores, fronted – optaran por alguno de los formatos existentes. En Yahoo!, utilizamos el HTML Estricto 4.01 DTD dentro de nuestro doctype, y esto, junto con varios otros doctypes, le dice al navegador el estándar que seguimos.

Una cosa más sobre el modo de los estándares vs al modo de las peculiaridades. Los navegadores realizan un gran trabajo como adivinos – somos capaces de lanzarles código propenso a errores pero los navegadores están diseñados para ser resistentes así que arreglan muchos de los fallos o hacen su mejor aproximación. Ellos hacen un buen trabajo de adivinación pero hacen un mejor trabajo si no tienen que adivinar en nuestro nombre. Así que como ingenieros fronted, nosostros debemos definir exactamente el lenguaje en el que escribimos – en este caso el HTML Estricto 4.01 – y eso nos asegurará obtener la mejor visualización posible.

La segunda cosa que me gustaría comentar sobre el marcado: ¿cuál es la presentación por defecto de los elementos HTML? ¿Cómo se pinta un elemento strong? ¿Y un H1? ¿Y una lista? Y son preguntas con trampa porque el marcado no tiene una presentación visual inherente – no hay nada en el HTML en sí mismo que diga que un elemento H1 tiene que ser grande y destacado y con mucho margen alrededor de él. Eso, en realidad, lo define la css dentro del navegador. Y así, darnos cuenta de que el marcado no tiene una visualización inherente nos libera para usarlo tal y como fue diseñado. El trabajo del marcado mejora el contenido de la página y se envuelve de aquellos elementos que le dan al contenido más significado. Podemos coger una cadena de texto y decir: esta es la cabecera. Podemos coger una serie de frases y decir: esto es una lista. Marcas lo que tienes y lo enriqueces con más significado.

Pero como ya he mencionado, los diferentes navegadores llaman al fichero interno CSS que nos proporciona la presentación de los elementos HTML, incluso de aquellos elementos que no forman parte del HTML en sí mismo. Esta es la razón por la que hemos creado, como parte de la librería YUI de Yahoo!, un fichero que se llama “CSS Reset”. Este fichero normaliza la presentación de los elementos HTML en diferentes navegadores. Si tienes un fichero CSS Reset, ya sea el de YUI o el que hayas desarrollado tú mismo, las páginas se van a ver iguales – hemos hecho que el navegador quiera usar nuestra preesentación inicial – reduciendo así el campo de juego. Así que en este caso ùedes cer que en la primera línea hay una cabecera h3 y, después, un h4, h5 y h6. Aquí obtenemos una lista y aquí otra. Y podríamos esperar que la lista se comportara con puntos o números – nosotros los hemos suprimido, así que sólo tratamos con HTML sin pensar en cómo podría verse en la página. Esto nos libera, realmente, y nos hace ocuparnos de qué elemento utilizar preocupándonos, únicamente, de su significado.

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

26 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 sexta parte de la charla

Así que estas son las tres técnicas básicas que nos ayudan a alcanzar o mantener nuestra mirada hacia las cuatro prioridades que se establecieron al principio. Hay un montón de opciones que deben tenerse en cuenta. Y queremos mostrar todas las opciones que apoyan nuestros principios – pero hay algunas otras cosas a tener en cuenta en función de la elección tecnológica del día a día de trabajo.

En primer lugar, siempre queremos hacer lo correcto. Y lo correcto significa seguir los estándares siempre que sea posible. Si existe un estándar, nuestro trabajo es seguirlo – si funciona, en nuestro caso. En algunos casos, todavía no existe un estándar o está surgiendo, y en esos casos está bien seguir las convenciones. Por lo tanto, si no podemos seguir el estándar – si no hay estándar definido – entonces, echaremos un vistazo a los estándares que están surgiendo o al convenio común que sigue la industria y tratar de hacerlo. Y sólo cuando esas cosas fallan – sólo cuando no podemos seguir un estándar y no puedes apoyarte en un estándar nuevo – entonces, vuelves a la mesa de dibujo y diseñas una técnica nueva para ese caso en particular. Como ingenieros, y diseñadores, existe siempre la tentación de reinventar algo nuevo y más ingenioso – pero para la salud de la Internet, y para la estabilidad de tu proyecto, es aconsejable seguir los estándares y los que van surgiendo siempre que sea posible. Si lo estás haciendo de cualquier forma – si vas por el camino menos visitado – entonces recuerda el principio de apertura y documenta lo que estás haciendo, y exponlo a discusión como posible estándar futuro.

Además de querer hacer lo correcto, siempre queremos ser considerados. Queremos ser considerado con nuestros compañeros desarrolladores, y con nuestros usuarios. Esto significa hacer la cosa lo más simple posible – no recibes puntos de bonificación por encontrar la forma más compleja que hacer algo. Hay por lo general la belleza en la simplicidad. La segunda forma de ser considerado es el ser flexibles. Tenemos diferentes propiedades en Yahoo!, así que cuando somos flexibles en el trabajo que hacemos, beneficia a otras personas de la empresa y del sector. Así que no se trata sólo de pensar en la valoración de los widgets para un sitio web de fotografía, también se trata de imaginar cómo se puede utilizar en un sitio web de cine, o en un blog, o en cualquier otro sitio. Así las cosas que flexibilizamos a través del contexto también se flexibilizan a través de la tecnología – las cosas que vas a trabajar para tu página se abren para todo el mundo. Y, al final, será considerado por estar abierto. Coger lo que hemos aprendido, documentarlo, y subir la API y los procesos que, por definición, están abiertos.

Lo último a tener en cuenta es el cómo tomar decisiones, es mantener el sentido de la empatía. Trabajamos al servicio de nuestros usuarios, y es nuestro trabajo ofrecer una experiencia de usuario fantástica – pero no es nuestro único objetivo. También tenemos que recordar que nuestro trabajo influye en los desarrolladores del sector y de nuestra empresa, y también lo hacen las máquinas que posibilitan estos sitios web. Determinados patrones de JavaScript son más comprensibles que otros, y así si es el mismo para el usuario y para el equipo de desarrolladores, debes elegir el que va a estar más optimizado para las máquinas. Pero recuerda siempre – a pesar de que hemos descrito los tres tipos de público, los usuarios son nuestra principal preocupación. Está bien entre nosotros sufrir un poco si es para dar al usuario una mejor experiencia, que es para lo que estamos aquí.