Si buscáis texturas con una buena resolución, en sxc.hu podemos encontrar muchas muy interesantes. En designmag han hecho una recopilación de 60 de ellas.

Via webdesignledger encontramos una muy buena recopilación de packs de texturas de todo tipo, aunque lo que más abunda son de texturas tipo papel, siempre útiles.    

Como muchos otros diseñadores web, yo me esfuerzo en codificar páginas web hermosas pero flexibles que se vean virtualmente idénticas en cada navegador web. Desafortunadamente, diseñar boletines de email te envía de vuelta diez años atrás. Etiquetas depreciadas, tablas, estilos inline, ¡oh, cielos! En este artículo, voy a listar seis métodos que mejorarán inmediatamente tus layouts de email.

Boletines de Email.

Como nuevo contratado en el servicio de marketing por email de AWeber, mi asignación fue crear un par de docenas de nuevas plantillas para los boletines de email en HTML de nuestros clientes. Para el diseñador web que gusta del código limpio, un email en HTML es un recuerdo de un pasado afligido. Después de semanas de trabajo e incontables dolores de cabeza, entregué el material. También aprendí mucho acerca de diseñar para email.

Para ayudarte a evitar muchos de los dolores de cabeza que tuve durante la fase de prueba, aquí hay algunas cosas que puedes hacer para crear emails en HTML que se vean geniales.

¡Crea Múltiples Cuentas de Email Para Probar!

Si sólo vas a tomar un consejo de este artículo, por favor que sea éste. Como diseñadores, pasamos mucho tiempo creando la experiencia de usuario perfecta en la web y probando esa experiencia en múltiples plataformas. Sin embargo, cuando se trata de email, demasiados de nosotros fallamos en entregar la misma atención al detalle.

Parecido a hacer pruebas para la web, crear un layout de email que se vea igual en cada cliente de email puede ser una pesadilla absoluta.
Para asegurarse de que tus suscriptores recibirán tu mensaje en la forma en que se propuso – ¡prueba en todo lo que puedas!

Leer más…

¿Has tenido alguna vez ese sentimiento terrible cuando te das cuenta – sólo un fragmento de segundo demasiado tarde – de que no deberías haber cliqueado “OK” en el diálogo “¿Está seguro de que desea terminar?”?

¿Sí? Bueno, estás en buena compañía – todo el mundo ha tenido una experiencia similar así que no hay necesidad de sentirse avergonzado por ello. No es tu culpa: es culpa de tu software.

¿Por qué? Porque el software debería “saber” que formamos hábitos. El software debería saber que después de hacer clic en “OK” incontables veces en respuesta a una pregunta, probablemente también haremos clic en “OK” esta vez, incluso si no queríamos hacerlo. El software debería saber que no tendremos la oportunidad de pensar antes de desechar nuestro trabajo en forma accidental.

¿Por qué debería saber estas cosas? Porque los diseñadores de software deberían saber que formamos hábitos, querámoslo o no.

La formación de hábitos es realmente algo bueno: nos ahorra el problema de tener que pensar cuando nos enfrentamos a banalidades de interfaz y disminuye la probabilidad de que nuestro tren de pensamiento se descarrile. En el caso del diálogo “¿Está seguro de que desea terminar?”, nuestras manos han memorizado cerrar-y-hacer-clic como un gesto continuo individual. Eso es bueno, porque la mayoría de las veces no queremos pensar en la pregunta – sólo queremos hacer lo correcto. Desafortunadamente, nuestros hábitos a veces nos hacen hacer lo incorrecto: ni siquiera tenemos tiempo de darnos cuenta de nuestro error hasta después de haberlo cometido.

Así que, como diseñadores somos llevados a un principio general de interfaz: Si una interfaz va a ser humana, debe respetar la habituación.

Soluciones posibles

¿Qué tal si se hace la advertencia más difícil de ignorar? Una advertencia sutil no será tomada en cuenta, así que usaremos todas las trabas: haremos pestañear la pantalla y que suene un fuerte sonido estridente para asegurarnos de que el usuario está prestando atención. Y aunque lo intentemos, eso todavía no funcionará. A medida que la advertencia esté más en nuestras narices, más rápido querremos alejarnos de ella (al hacer clic en “OK”) y más errores cometeremos. La cosa es, no importa qué tan en nuestras narices nos presente el computador la advertencia, aún cometeremos el mismo error – hacer clic en “OK” cuando no queríamos. Pero sigue sin ser nuestra culpa: mientras sea posible habituarse a ignorar el mensaje, nos habituaremos, y entonces cometeremos errores.

Leer más…

Si tratas con FLASH seguro que alguna vez te has topado con esta “característica”. Si no usas archivos externos no hay ningún problema, pero si haces uso de archivos de configuración externos en formato txt, carga de imágenes externas, te habrás dado cuenta de que no importa donde hayas puesto tu SWF en el arbol de directorios, la ruta relativa a esos archivos externos siempre se hace desde el HTML donde se carga.

Por ejemplo tienes un SFW visor.swf y una imagen arbol.jpg que están dentro de la carpeta MULTIMEDIA colgando de la raiz que es donde está tu index.html.

Al editar el flash lo lígico es que pongas que la ruta de la imagen sea “arbol.jpg“, ya que está en la misma carpeta que la imagen, y si abrimos el SWF a pelo comprobarás que la carga correctamente. El problema viene cuando cargamos el SWF en el index.html, cosa bastante normal. El flash por defecto tomará la ruta actual de carga, no donde se encuentra el archivo SWF realmente, con lo que buscará en este caso en el raiz el archivo arbol.jpg y no lo encontrará.

Una solución es que si sabemos que el flash se va a cargar en el index.html que está en raiz, cambiar la ruta de carga del flash a “multimedia/arbol.jpg” y funcionará. Para sitios sencillos esto funciona bien, pero ¿que pasa cuando queremos cargar ese flash en otro HTML que no está en raiz?, no funcionará, y por lo tanto no podemos usar el mismo SWF para 2 lugares (o 3, 7, 200) siendo que el visor es el mismo. También surgen problemas cuando usamos gestores de contenido con URL dinamicas, tipo permalinks, etc, donde una dirección como www.nerv.es/blog/titulo-del-articulo dará error al cargar el visor ya que el flash se cree que está en una estructura de directorios “/blog/titulo-del-articulo” que no existe físicamente.

La mejor solución es usar un atributo que no es muy conocido llamado base.

Si en el código de carga del flash usamos:

<param name=”base” value=”.”>

para <object> y para <embed>:

base=”.”

No importa desde donde se cargue el archivo SWF que la ruta base para él será donde esté ubicado realmente dentro del arbol de directorios. Con esto conseguimos que funciones siempre sin importar desde donde ser carge. ( dentro del mismo dominio al menos )

Trabajar con CSS puede parecer una batalla constante. Los navegadores siempre están cambiando la manera en que leen el código (*cof* Internet Explorer *cof*), y parece que hay un montón de pequeñas “pillerías” en CSS. Aunque es un lenguaje increíblemente poderoso, puede ser utilizado de forma incorrecta con facilidad, lo cual condenará tu desarrollo a una vida de imperfecciones.

1) Ignorar la Compatibilidad con el Navegador

Este es, probablemente, el problema número uno en desarrollo web, ya que debes tener layouts que se vean siempre igual, sin importar qué navegador esté utilizando el visitante al navegar el sitio. Este hecho a veces puede parecer la maldición de tu existencia: hay diferencias fundamentales en la manera en que Internet Explorer renderea una página, comparado con Firefox. Aunque ya no es tan grave como solía ser, todavía existe una gran diferencia entre navegadores.

Es fácil para los desarrolladores web diseñar la página en su navegador favorito y no preocuparse acerca de cómo se ve en otros navegadores de uso frecuente, ya que probablemente no se verán las diferencias. (Y soy un gran culpable de esto. ¡A veces diseño el sitio en Firefox y me olvido de revisarlo en IE hasta después de haberlo terminado!). Aunque hay algunos métodos ya probados para ayudar a salvaguardar tus diseños para el rendereo de diferentes navegadores, la mejor manera de asegurarse de que todo se ve constante es simplemente utilizar Browsershots. Browsershots entrega una instantánea acertada de cómo se ve tu sitio en diferentes plataformas y navegadores, permitiéndote estar seguro de que nada se ve distorsionado en un navegador.

2) No tomar en cuenta las resoluciones de navegador más pequeñas

Mientras que varios de nosotros, los diseñadores web, tenemos monitores de computador grandes (y estamos bastante orgullosos de ello), una gran parte de los visitantes de tu sitio puede que no. Puedes utilizar tus programas de análisis para ver las resoluciones de navegación de tus visitantes y qué tan amplio es su rango (Google Analytics hace esto de maravilla). Sin embargo, hay un mundo de diferencia en la manera en que un diseño se ve en una resolución de 1024×768 en oposición a una resolución de 800×600. Puede convertir un hermoso diseño en algo casi inútil.

Leer más…