Archivo de la etiqueta: diseño web

La pesada carga del pixel

Splash de Photoshop CC

Últimamente los proyectos en los que estoy metido tienen mucha carga de tareas diseño. Normalmente balanceo en mi labor profesional las tareas de diseño visual y maquetación web, pero en esta última temporada el diseño visual ha cobrado mucho más peso. Puramente circunstancial. Ambas tareas me apasionan por igual.

El que está acostumbrado a trabajar con él, sabe perfectamente que Photoshop con el paso del tiempo se ha convertido en un mastodóntico centro de operaciones del pixel. Si bien es cierto que caminando en paralelo al hardware, yo personalmente noto que los problemas de rendimiento que tengo hoy no me los encontraba con Photoshop 7, por poner un ejemplo “lejano” (ver historial de lanzamientos).

Esto tiene una explicación muy sencilla. Con la llegada su versión Cloud (Photoshop CC), el software ahora incluye por defecto módulos que antes eran propios de la versión “Extended” del mismo. Es decir, el Photoshop “normal” ahora es el “Photoshop Extendido”. Módulos como el de 3D, Camera Raw, integración con Adobe Bridge… están ahora por defecto, haciéndolo más pesado.

Y la verdad, es frustrante tener que esperar segundos o incluso minutos, cuando las pantallas que se producen no tienen un peso realmente exagerado. Y no es por hardware, pues al tiempo de escribir este post trabajo con un Mac Book Pro que no tiene más de 6 meses. Tened presente que mi labor es el diseño web. No hablamos de diseñar grandes lienzos a 300ppp. Hablamos de pantallas, de entre 420-1600px de ancho a 72ppp. La altura puede variar, pero rara vez una pantalla normal sobrepasa los 10.000px de alto, a menos que sea una pantalla que recopila el diseño de componentes, tal y como se presentan hoy en día los conocidos diseños de elementos de interacción.

La solución podría ser que el señor Thomas Knoll y los chorrocientos nombres que vemos durante un segundo cada día, tomen en cuenta las peticiones de usuarios como nosotros, y provean en Creative Cloud de versiones modularizadas para descargar sólo lo que uno necesita. Algo así como la versión creada por usuarios, “Photoshop Lite“, pero con la seguridad y garantía de la firma de Adobe. Es el siguiente paso obligatorio para el servicio que ofrecen. Entre tanto hay que conformarse con los consejos oficiales de Adobe para la optimización del mastodóntico centro de operaciones de pixel.

Landing page para Clinker

El equipo de klicap ha confiado en mi persona para solventar una serie de necesidades de diseño en sus principales productos. Hemos arracando con Clinker. Más adelante detallaré en qué consiste cada proyecto y cómo hemos resuelto cada necesidad. De momento os dejo la landing page diseñada para Clinker:

Tu marcado HTML comienza en Photoshop

¿Debe tener nociones de marcado HTML el diseñador visual, diseñador de interfaz, diseñado gráfico —llámalo como más cómodo te resulte—? A pesar de la aparente segmentación de perfiles profesionales, un debate recurrente suele ser esa cuestión. Sí, todavía, al día de hoy. Independientemente de si respondemos afirmativa o negativamente a esta cuestión, es innegable que ello condicionará la eficiencia de los archivos gráficos.

Personalmente me identifico con la vieja escuela. Ésa del “yo me lo guiso, yo me lo como“. Ésa en la que no existía ni la mitad de perfiles intermedios actuales y acometía en la producción del sitio desde los primeros bocetos —prototipos, ahora— hasta, incluso, algunas líneas de php (por gusto, porque no nos quedaba otra, etc). Esto, independientemente de la profundidad de los conocimientos o habilidades, da al diseñador / desarrollador una visión general de todo el proceso de front-end. Y se debería reflejar claramente en la estructura interna de un archivo psd.

Conste que no estoy en contra de la segmentación. Todo lo contrario: enriquece y mejora los métodos de producción de cada una de las tareas específicas porque ahonda en ellas. Sin embargo, no podemos llevar dicha segmentación a un extremo de aislamiento donde la cadena de producción se rompe en el momento en que hay un punto de inflexión importante. Esto ocurre en el paso de transformar un diseño visual en marcado HTML.

Por lo tanto, si el diseñador visual tiene esas nociones de marcado, puede y debe reflejar una posible estructura de carpetas que coincida con el código final. Con ello conseguimos varios objetivos de una sola vez:

  • Facilita la edición. Coincida o no con la estructura de HTML final, una organización por carpetas siempre facilita la edición, sobre todo si es un archivo que puede retomar otro profesional. Más aún: si es un archivo que deberemos entregar al cliente, una organización previa nos ahorrará algo de tiempo en la entrega y nos evitará pasar algo de vergüenza en una revisión del mismo.
  • Facilita la labor de maquetación. Sobre todo si lo maquetará otro profesional. Piensa en el tiempo que le ahorrarás a la otra persona buscando las diferentes capas ¡nómbralas semánticamente! que tendrá que exportar. Si el diseñador visual y el maquetador web hablan el mismo idioma a través de este punto de encuentro, todo se agiliza.

Ésta es mi experiencia y la imagen al principio del post un claro ejemplo (real) de una estructura de un archivo psd con el que estoy trabajando. ¿Creéis que el método el mejorable? ¿Conocéis otra forma más ágil de comunicación entre el diseñador visual y el maquetador? ¿Cuántos de vosotros ejecutáis ambas tareas por igual? Y aunque tengáis complejo de “Juan Palomo” ¿ponéis en práctica estos métodos con vosotros mismos? ¡Espero vuestros comentarios!

The Photoshop Etiquette Manifiesto For Web Designers

Existe un prejuicio respecto a la labor de diseño visual de una interfaz. A priori, los escrupulosos análisis del diseño de interacción; la labor de marcado semántico; o incluso el desarrollo que hace funcional un sitio, parecen tareas más metódicas y sesudas que el simple hecho de “pintar una interfaz. Nada más lejos de la realidad.

En favor de fomentar una buenas prácticas en la producción de diseño visual con Photoshop, el diseñado de interfaz Dan Rose, ha creado “The Photoshop Etiquette Manifiesto For Web Designers“. 40 puntos magistrales a tener en cuenta que abordan todos los aspectos más importantes en el diseño visual con Photoshop. Digno de leer, guardar en marcadores y, si fuera necesario, imprimir.

¿Cumples todos los requisitos? ¿Hay alguna buena práctica de las que señala Dan Rose que no conocías? ¿Echas en falta alguna?

Por qué sí puedes usar Garamond en la web

Garamond

David Kadavy escribió hace unos días un interesante artículo donde explicaba las complicaciones de usar una tipografía tan conocida como Garamond en nuestro diseños web. Extrapolando el mensaje de su artículo, se reformula la pregunta: ¿es recomendable usar tipografías con serifa en la Web?

El motivo que me anima a escribir este artículo es intentar completar el artículo de Kadavy con algunos detalles sobre metodología de trabajo. Si bien es cierto que existen una serie de normas que todos debemos acatar independientemente del medio, un diseñador web no debería trabajar la tipografía tal y como lo hace un diseñador gráfico.

Cuando un diseñador gráfico elabora un diseño para la imprenta se enfrenta a una serie de problemas que están íntimamente relacionados con la labor física y mecánica de la imprenta. Sin embargo, un diseñador web no debería entender la tipografía como algo estático, fijo, ni siquiera físico. Un diseñador web debe considerar la tipografía como un elemento dinámico en cuerpo y forma que depende del dispositivo del usuario. Esta es la diferencia, por lo tanto, entre un diseñador gráfico y un diseñador web que trabajan con la tipografía:

  • El diseñador gráfico entenderá la elección tipográfica como un ideal inamovible y procurará que ésta llegue al usuario, intentando solventar todos los inconvenientes técnicos sin dejar de vigilar la legibilidad de la misma.
  • El diseñador web debería entender la elección tipográfica como un conjunto de posibilidades condicionado por el dispositivo con el que navega el usuario.

Por ello, la cuestión de la tipografía en la web no se ha de reducir a serifa sí, serifa no. La cuestión es tomar como epicentro del diseño al mismo usuario, que condicionará el resultado gráfico final:

  1. Las tipografías deberán tener tamaño porcentuales en relación al tamaño de la pantalla y así mismas (%, em, small, medium, large, etc)
  2. Podemos forzar la elección de un juego tipográfico (Google Font Directory, @font-face), pero ser flexibles con los cambios en nuestro diseño, según el dispositivo de navegación, nos asegurará una audencia mayor
  3. La elección no se ha de limitar a un único juego tipográfico. Podemos agrupar posibilidades dependiendo de las tipografías con las que cuente el usuario en su dispositivo
  4. Las hojas de estilos deberán detectar el dispositivo y ofrecer una alternativas tipográfica en relación al medio utilizado.

En relación a este último punto, podemos ayudar a usuarios cuyo dispositivo tenga una pantalla de menor tamaño (dispositivo móvil, principalmente) —donde leer un texto con serifa es, obviamente, una dificultad—. Para ello debemos detectar los medios a través de los que accede un usuario a nuestro sitio:

 

Y en la Hoja de Estilos de dicho medio ofrecer las alternativas tipográficas (u otros valores relacionados con el diseño):

p {font-family: sans-serif;}

Además de todo esto, actualmente el diseñador web cuenta con el apoyo de un gran soporte de la regla @font-face, así como una colección de navegadores para distintos dispositivos que apuestan por un suavizado (antialiasing) a la hora de renderizar CSS.

Por lo tanto, un diseñador gráfico y un diseñador web comparten la raiz de los problemas tipográficos, pero no la metodología de trabajo, ni mucho menos las soluciones, por las condiciones de cada medio.

El futuro de la tipografía en la web

Google Font Directory

Conforme se van asentando las bases de un nuevo modelo de producción de sitios y aplicaciones con la llegada de HTML5, nacen nuevas necesidades a las que grandes empresas como Google, como no, ya tenían previsto dar soporte o van solventando sobre la marcha.

Nuevos recursos, nuevas necesidades

Éste es el caso de nuevas propiedades de las hojas de estilos en cascada de tercer nivel, que desde hace ya aproximadamente un par de años vienen proponiendo soluciones desde el código CSS para problemáticas estrictamente visuales que se han ido asentando en la nueva cultura visual de la web participativa (bordes redondeados, sombras en los elementos, un mayor catálogo tipográfico, etc).

En concreto y actualmente, la regla @font-face —a través de la que el diseñador web puede proponer una mayor riqueza tipográfica para la web— tiene un soporte mayoritario por los actuales navegadores. Pero no todo es jauja. De esta ventaja nacen los siguientes problemas que se han de solventar:

  • Cargar un archivo de fuente aumenta notablemente la tasa de transferencia de un sitio ya que cada visita suma al servidor las peticiones del archivo. Teniendo en cuenta las actuales velocidades de conexión, en principio esto afectaría sólo a sitios con un contrato modesto en su servicio de hospedaje.
  • Al igual que otro tipo de material, los catálogos tipográficos cuentan con licencias y derechos de autor que no siempre promueven la filosofía del Creative Commons

De dónde venimos, a dónde vamos

Teniendo en cuenta estos factores y que anteriormente la regla @font-face tenía un soporte minoritario, dos grandes alternativas han sido hasta ahora sIFR o Cufón. Su continuidad es incierta, pero podríamos teorizar con su paulatino desuso por los siguientes motivos:

  • sIFR depende de Flash —y Flash tiene un futuro incierto—. Además el juego completo de sIFR (archivos css, javascript, actionscript y objetos flash) es tanto o más pesado que embeber el archivo de fuente original.
  • Cufón es menos pesado que sIFR, pero su implementación sigue siendo más tediosa que usar la regla @font-face.

Font Directory: las soluciones de Google y las posibles soluciones de otros

Así pues, es en este justo momento en que @font-face tiene mayor soporte por todos los navegadores y sitios de referencia implementan su aparición (p. ej: Smashing Magazine, algunas plantillas en Tumblr), cuando Google sorprende —no nos extraña, coincidiendo con su evento Google I/O 2010— con Google Font Directory: un catálogo tipográfico libre que podemos utilizar aplicando la regla @font-face sin necesidad de realizar las peticiones del archivo fuente a nuestro propio servidor. Solventando de esta manera las dos limitaciones que señalábamos anteriormente.

Dando un pequeño salto en el futuro y conociendo el rechazo que provoca el esfuerzo de omnipresencia que hace Google por acompañarnos en todas nuestras tareas como diseñadores y desarrolladores —y aún peor: en nuestro momentos de ocio en la red—, no sería de extrañar que algún aventurado emprendedor abra una cuña de mercado dando alternativas a este servicio.

Imaginad una empresa mediadora entre los derechos de autor de los catálogos tipográficos que ofrece servicios premium de gestión de fuentes (un buen catálogo y hospedaje) a desarrolladores; una especie de YouTube de las tipografías. Esta es la primera idea, si hay algún emprendedor en la sala seguro que se le ocurre alguna más.

Conclusiones

En cualquier caso queda patente que la llegada de HTML5 y el soporte total de CSS3 ofrecerán las ventajas que ya hemos releído en infinidad de sitios, abrirán la puerta a nuevos modelos de negocio —o el fomento de algunos ya existentes— y sobre todo enriquecerán el diseño de la red.

Cantidad de bocetos para un diseño web

Charlando con Juanj0 vía Twitter, hemos intercambiado una breve experiencia común entre todos los diseñadores web: qué cantidad de bocetos presentar a un cliente para el diseño de una web y cómo guiarlo en las elecciones. El tema es complejo, asi que comparto con vosotros una serie de ideas basadas en mi experiencia.

Tu método de trabajo

Lo primero que debes valorar es el método de trabajo propio. Si estás dentro de un equipo de trabajo y se te exije presentar más de un boceto, irremediablemente no tienes escapatoria y tendrás que pensar en varias versiones. Si por contra eres profesional autónomo ó tienes las riendas de la dirección de arte y puedes elegir el número de bocetos a entregar, tendrás la opción de presentar un único boceto (siempre supeditado a otras variables en la labor).

El cliente

Variables como por ejemplo el tipo de cliente. Quizás tu cliente esté muy perdido a nivel gráfico de sus necesidades (a priori te contrata por eso). Es indiscutible que el que más sabe de su negocio es el cliente, pero no todos los cientes tienen claro los conceptos gráficos que deben servir como caballo de batalla para la presentación de su negocio/producto en la red.

Como véis tenemos una serie de posibles combinaciones que, además, pueden alterarse según tu metodología de trabajo o los conocimientos y/o requerimentos (caprichos también, todo hay que decirlo) de tu cliente. A continuación una guía rápida de premisas a tener en cuenta en ambos casos.

Cuando vayas a presentar un único boceto

En el caso de que optes por ofrecer a tu cliente con un único boceto, ten en cuenta lo siguiente:

  • Pide referencias a tu cliente.
    Por ejemplo: su identidad corporativa (siempre), sitios webs que le gusten, que visite con asiduidad, los sitios webs de la competencia, etc.
  • Tómate mucho más tiempo en analizar el sector para el que diseñas.
    Tienes sólo una tirada para dar en la diana. Aunque a posteriori cuentes con corrrecciones, prevee y minimízalas analizando fríamente la disposición, forma, contenido y trabajos tipográficos de otras webs del sector de tu cliente y sus competidores.
  • Respeta y adapta la identidad corporativa de tu cliente.
    Tienes razón, quizás ese logo de tu cliente no encaje bien del todo en la cabecera de tu fantástico sitio 2.0. No te agobies. Intenta respetarlo y cuenta con las opciones del manual de identidad corporativa (negativos, calados, etc). Si aún así, al poner ese logotipo en la cabecera de tu boceto no puedes conciliar el sueño por las noches, plantea humildemente el rediseño de la identidad ofreciéndole un análisis riguroso de por qué no funciona (no vale simplemente “que no te guste”, ya que desconoces quién/cómo/cuándo/por cuánto otro compañero ha realizado ése trabajo). Esto supone mayor costo al cliente, quizás no previsto, asi que mentalizate para una negativa y tener que lidiar (como comentaba antes) con dicha identidad.
  • No diseñes sólo para ti.
    Quizás si te piden un único o boceto es porque el cliente confía en tu estilo. Sin embargo esto no es excusa para que diseñes sólo para satisfacer tu portafolio. No tomes tu único boceto como “una web de diseño”: céntrate para el sector que estás diseñando y adapta todos tus conocimientos.
  • Sé flexible con las correcciones.
    Insisto: aunque la entrega de un único boceto significa que el cliente confia en tu criterio, no descartes correcciones a posteriori, porque siempre las hay por pequeñas que sean.
  • Defiénde tu boceto.
    Que tengas como respuesta correcciones no significa que tengas que acatarlas todas. Actúa profesionalmente y argumenta el boceto y guía a tu cliente. Quizás muchos de los cambios que te piden son inviables y tu cliente no sepa que a posteriori en una labor de maquetación puedan suponer algún problema de visualización (diseño en layouts fluidos, contenido administrable, etc). Prevee estos problemas desde el boceto.

Cuando vayas a presentar varios bocetos

La mayoría de las premisas anteriormente citadas son necesarias en la entrega de uno o varios bocetos. Cuando entregues varios bocetos, debes tener en cuenta lo siguiente:

  • Tu tercer punto de vista.
    Si trabajas con 2 bocetos te costará menos. En el caso de que sean 3 puede ser más dificil, ya que has hecho las que quizás consideres “versiones antagónicas”. Intenta escapar de ti mismo, analiza otros estilos con los que te sientas cómodos y que aún no has probado por dinámica de trabajo (y solucionen la gráfica del cliente, por supuesto) y hallarás ese tercer punto de vista.
  • No flaquees en ninguna versión.
    Si haces 3 bocetos —uno muy elaborado, tu “preferido”; y otros dos más “flojos”— pensando que escogerán el que a ti te gusta porque se ve “claramente” que es el mejor, quizás el tiro te salga por la culata. Es posible que tu cliente escoja lo que más le gusta de cada uno, así que si no quieres acabar maquetando una web que “odias” cuando tú mismo la has diseñado, no flaquees en ninguna versión.
  • Prevee la mezcla.
    Lo idea es que se escoja una única solución, pero como comentaba más arriba la mezcla nunca está descartada. Prevéela y trabaja en Photoshop organizando todas tu capas por grupos de carpetas (nombrarlas, agrupalas unas dentro de otras) con la idea de que puedas posteriormente unir todo a golpe de click en un solo archivo .psd.
  • Una versión no es un cambio de color.
    Dependiendo siempre de lo estipulado con tu cliente, procura que una versión no signifique un cambio en la gama cromática. ¿Estás seguro que sólo hay un layout posible? ¿El menu principal realmente debe estar ahí? ¿Seguro que ése es el único juego tipográfico para titular, para textos, etc? ¿Ése tamaño de las imágenes es el correcto? En cada nueva versión vuelve a replantear los conceptos.
  • Una corrección no es versión.
    Sé profesional y no sumes a la cuenta de tu cliente las correcciones como nuevas versiones. A su vez, defiende tus argumentos indicándo al cliente que un rediseño total de una versión elegida no es una corrección, sino un nuevo boceto.

Como véis, lamentablemente no hay una regla mágica que especifique el numero de bocetos a entregar. Lo que si espero es que esta pequeña guía os sirva en el futuro. Suerte ¡y a diseñar! :)