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:
¿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:
É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!
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?
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:
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:
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.
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.
É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:
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:
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.
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.
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.
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).
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.
En el caso de que optes por ofrecer a tu cliente con un único boceto, ten en cuenta lo siguiente:
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:
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! :)
Screenshot de premassagar
Aunque parezca extraño, una de las cosas que más me ha costado diseñar en este sitio personal han sido los comentarios. Muchas son las preguntas que debes hacerte antes de ponerte manos a la obra.
Lo bueno de un sistema de gestión de contenidos como WordPress es que te facilita muchísimo esta labor. Ya sabes que la mayoría de las plantillas (templates) que están a tu disposición cuentan con la integración de comentarios con avatares (leídos desde Gravatar) o el cebreado de color para los mismos (comentarios par, comentarios impar y comentarios del autor). Solventados estos problemas las principales cuestiones que has de plantearte a la hora de diseñar tus comentarios son:
Aunque por defecto los avatares se presentan en la mayoría de los sitios con unas medidas “estándar” (unos 48×48 pixel), nunca descartes la posibilidad de presentarlos a un tamaño mayor o, incluso, no presentarlos. Por ejemplo:
En resumen, los comentarios de tu sitio contienen tres partes:
No necesariamente los metadatos tienen que presentarse junto al nombre del autor. Recuerda que tu intención es maquetar con la ayuda de tu hoja de estilos una presentación mejorada y usable de los comentarios. Concibe los datos a presentar como las capas que dispones para crear en tu modelo y juega un poco con ellas. Te propongo algunos ejemplos de wireframes para comentarios:
Seguro que con un poco de imaginación puedes sacar decenas de modelos.
Una vez decidas el boceto (wireframe) de tus comentarios, te será mucho más fácil diseñarlos y posteriormente maquetarlos. Para la labor de diseño debes empaparte de los blogs que más te gustan para anotar acabados y tener en cuenta varios factores además de todo lo señalado: