google analytics

31.7.08

Cómo presupuestar Diseño

Dentro de lo que fué el III Encuentro Latinoamericano de Diseño en Palermo, una de las charlas más interesantes y convocantes a las que pude asistir, fue la que brindó Jorge Piazza (Redargenta) sobre uno de los "tabúes" de nuestra profesión... Cómo presupuestar Diseño.

Para quien quiera escucharla, puede bajarla hahiendo clic acá.

Link actualizado el 01/08/08 (avisen cuando no funciona el link asi vuelvo a subir el archivo)

29.7.08

New Pack Disc



Si los videos les parecieron interesantes y tienen ganas de construir este novedoso pack para cds, no tienen más que bajarse e imprimir las siguientes imágenes..

22.7.08

Picasso: sintesis de un toro

Pablo Picasso creó “Bull” alrededor de la Navidad de 1945. “Bull” es una conjunto de once litografías que se han convertido en una clase primordial de cómo desarrollar ilustraciones de lo académico a lo abstracto. En esta serie de imágenes, tirada todo de una sola piedra, él diseca visualmente la imagen de un toro para descubrir su presencia esencial con un análisis progresivo de su forma. Cada placa es una etapa sucesiva de una investigación para encontrar el “esencia absoluta” de la bestia.












Extraido de Art Appreciation

11.7.08

Diferencias entre Diseño Gráfico y Diseño Web

¿En qué se diferencian el diseño gráfico y el diseño web?
Aparentemente las bases del diseño aplicables pueden ser las mismas (o parecidas) pero si que existen diferencias y hablar de este tema puede llevarnos muchas horas…

Primero debemos entender una cuestión fundamental… El diseño gráfico se trabaja en altas resoluciones (archivos) y se procura mantener la mejor calidad en las imágenes y originales porque la idea es imprimirlo (ya sea offset o digital), mientras que en el diseño web ahorrar recursos del servidor y para ahorrarnos espacio…

Actualmente ambos estilos de diseños son flexibles…, hace unos años el diseño web era rígido, sistemático y casi inamovible. Pero con la creación de nuevas tecnologías y lenguajes de programación, el dinamismo de las páginas webs es impresionante, es por esto que ambos métodos de maquetación de proyectos son flexibles y sus limitantes son nada más el freno de nuestra propia imaginación…

Algunas características interesantes que diferencian al diseño web del diseño gráfico:

1. Cuando diseñamos para imprimir, tomamos valores específicos, tanto de color, tipografía resultado va a ser (casi siempre) exactamente igual o muy parecido al original que hemos diseñado y guardado…
1.1. Si estamos diseñando una web, debemos considerar factores externos de los cuales no tenemos ningún control. Por ejemplo podemos destacar el tamaño del ancho que le demos al diseño (no todos los usuarios tienen un monitor de 21 pulgadas como el tuyo)…
1.2. Otro factor es el optimizar la página para los diferentes tipos de navegadores (el peor dolor de cabeza del diseñador web: como hacer funcionar una web en Internet Explorer y en Firefox sin que alguno muestre errores)…
1.3. En diseño de páginas web, debemos optimizar las imágenes y animaciones que subamos (esto es bajar la resolución lo más posible sin perder la calidad -lo cual es imposible-) para que sea fácil cargar la entrada a nuestro sitio web.

2. Cuando creamos un diseño gráfico publicitario (de cualquier tipo) debemos procurar revisar la ortografía para no enviar a imprimir con errores de este tipo…
2.1. Mientras diseñamos una Web, debemos revisar adecuadamente la ortografía de los escritos, para no tener errores ortográficos, además, debemos procurar colocar palabras clave (keywords), etiquetas adecuadas (tags), no abusar del uso de negritas ( / ) y procurar revisar los enlaces que agreguemos…
2.2. El trabajo del diseñador web no se limita a eso, ya que se debe procurar organizar todo el contenido (SEO) para que los buscadores posicionen la Web, además de hacer entendible y fácil de usar la interfaz (Flash Apesta… Los sitios creados enteramente en Flash son un bodrio total… Sugerencia: “Usar Flash lo menos posible“)…
2.3. Al diseñar una Web, debemos ser escrupulosos a la hora de experimentar con tipografías extrañas, y tratar de utilizar tipografías de uso común… Lo que se ve genial en tu ordenador puede verse horroroso en el ordenador de otro…
2.4. El nombre que le asignes a los archivos (todos) tiene una importancia esencial para el posicionamiento…

Finalmente algo en que el diseño web vence al diseño gráfico:

Diseño Gráfico:
* Si diseñamos algo con errores (cualesquiera) y enviamos a imprimir, el coste la producción se duplica porque hay que reimprimir una vez corregido el original…
Diseño Web:
* Si cometemos algún error en el diseño de una web (siempre y cuando sea estático y no dinámico) es muy fácil dar con el error y corregirlo… Claro, siempre y cuando no sea un error que comprometa a tu cliente de algún modo y dicho error haya sido visto por millones de personas, porque en ese caso, tu carrera como diseñador web, habrá terminado (al menos como uno de confianza)…

Este tema da para bastante más, pero por la falta de tiempo que impera por las obligaciones, creo que lo dejaré así por el momento, si tienes alguna duda o consulta, ya sabes, envíame un correo electrónico…


Visto en portafolio en mano.


1.7.08

10 errores principales en el diseño de aplicaciones

Por Jacob Nilsen.

Es difícil hacer una lista de errores tan general, ya que los peores problemas son específicos de cada ámbito; no
obstante, suelen caer en alguna de estas tres categorías:

* la aplicación resuelve un problema equivocado;

* la aplicación tiene funcionalidades inadecuadas para el problema correcto;
* la aplicación tiene funcionalidades adecuadas para el problema correcto, pero son demasiado complicadas para que el usuario las entienda

El único consejo general es basar el diseño, no en las intuiciones o suposiciones del desarrollador, sino en la investigación usando estudios de comportamientos y tareas, prototipado en papel, diseño iterativo y testeo con usuarios, etc. Las especificaciones de requerimientos están siempre equivocadas o son incompletas; por eso hay que basarse en lo que los usuarios hacen, más que en lo que dicen.

Estos son (para Nielsen) 10 errores de usabilidad frecuentes y especialmente escandalo
sos en una amplia variedad de aplicaciones.

1. Controles GUI no estándar


Los controles GUI básicos, como enlaces, botones, casillas de verificación, barras de scroll, etc., son las unidades léxicas que forman el vocabulario para el diseño de diálogos; cambiar su apariencia o comportamiento es como introducir en una conversación palabras de un idioma extranjero desconocido.


Sin embargo, muchos diseños continúan violando ese principio, siendo las barras de scroll la víctimas más habituales. Si los mejores expertos en diseño de interacción han refinado esos controles durante casi 30 años, es poco
probable que un diseñador invente un botón mejor en un fin de semana. Y aunque lo hiciera, los usuarios están mucho más habituados a los controles estándar.
Barras de scroll no estándar: una mala idea

1.a. Parecer un control GUI sin serlo


Un elemento que parezca un control pero no lo sea puede ser un problema todavía peor, ya que pueden dar la impresión de que "algo no funciona". Puede ser, por ejemplo, un texto que parezca un enlace (por su color o por estar subrayado); o un elemento que parece un botón pero no lo es, como en este caso, donde los títulos 'NEW CUSTOMER' y 'EXISTING CUSTOMER' parecen botones, pero no tienen ninguna acción asociada:

Ejemplo de elementos que parecen botones, pero no lo son

2. Inconsistencia

Una aplicación que utiliza diferentes palabras o comandos para la misma acción, o que usa la misma palabra para diferentes conceptos en diferentes momentos provoca confusión; lo mismo ocurre cuando los mismos elementos aparecen en diferentes puntos de la pantalla. Lo diferente es difícil.


Vemos en este ejemplo la selección de las fechas de ida y vuelta de un viaje, pudiendo elegir la fecha entre dos meses consecutivos. Un usuario que quisiera viajar del 10 de marzo al 15 de marzo podría, equivocadamente, hacer esta selección:

Selección de fechas de viaje, en dos meses consecutivos

El error es debido a que la selección de la fecha de vuelta no muestra el mismo funcionamiento que la de ida: el mes de marzo se ha movido a la parte izquierda del calendario. Podría parecer un comportamiento útil, ya que permite que se pueda seleccionar la fecha de regreso en marzo o en abril (en febrero ya no tiene sentido una vez seleccionada la fecha inicial en marzo); pero la diferencia entre ambos calendarios puede motivar el error del usuario que entiende que ambos calendarios tienen el mismo contenido. Es más; aunque el usuario no llegue a equivocarse, pierde más tiempo entendiendo el contenido del calendario del que se pueda ahorrar por mostrar directamente el siguiente mes.

3. No mostrar claramente su funcionamiento ("no perceived affordance")


"Affordance" significa lo que se puede hacer con un objeto: por ejemplo, una casilla de verificación se puede activar o desactivar; un "slider" puede moverse arriba o abajo; "perceived affordances" son funcionamientos que se entienden simplemente viendo el objeto, antes de utilizarlo. Es importante que los diseños posean esa característica, ya que los usuarios (con la posible excepción de los niños) normalmente no tienen tiempo ni les gusta tener que jugar una partida de buscaminas, probando diferentes acciones para ver cómo funciona cada elemento.

Los diseños arrastrar-y-soltar ("drag-and-drop") son especialmente problemáticos, ya que es difícil mostrar cuándo un elemento puede ser arrastrado, o dónde puede ser soltado, o qué pasará en tales casos. En general, los siguientes síntomas revelan un problema de falta de "perceived affordance":

* Los usuarios se preguntan "¿qué hago ahora?".

* Los usuarios no utilizan una funcionalidad que les habría ayudado.
* Hay una parrafada de texto que intenta solucionar los dos problemas anteriores.

3.a. Zonas de click diminutas

Un problema asociado al anterior es el de las zonas de click tan pequeñas que los usuarios fallan y hacen click fuera de ella. Aunque inicialmente hayan comprendido su funcionamiento, el no obtener una acción por haber fallado en su objetivo puede hacerles creer que no se trata de una zona activable. El problema es especialmente importante en los usuarios de edad avanzada y aquellos con discapacidades motoras.

4. Sin retroalimentación ("feedback")


Uno de los principios de diseño más básicos en un diálogo es proporcionar retroalimentación para evitar que el usuario tenga que adivinar (y se equivoque) en cuanto a lo que está pasando. Para ello el sistema debe:

* Mostrar al usuario el estado actual del sistema.
* Informar sobre qué comandos han sido interpretados.

* Decirle al usuario qué está pasando.

En la siguiente captura de pantalla de ejemplo, el usuario puede elegir entre dos modelos de rueda; pero la rueda seleccionada se muestra con un tono gris, lo que confunde al usuario ya que es un color que se utiliza por convención para opciones que no están disponibles. El usuario no está correctamente informado de cuál es el estado del sistema ni qué opciones tiene disponibles.

Captura de pantalla del área 'build-your-own-car' en el sitio web de VolksWagen, mostrando el paso de selección de ruedas.

4.a. "He salido a comer" sin un indicador de progreso


Una variante de la falta de retroalimentación es no avisar al usuario cuando una determinada acción va a llevar un tiempo especialmente largo. Los usuarios pueden pensar que la aplicación se ha "colgado", o empezar a hacer clicks y lanzar nuevas acciones. Si no se pueden respetar los tiempos de respuesta límites , es necesario mantener informado al usuario:

* Si la acción dura más de 1 segundo, mostrar el cursor "ocupado" (reloj de arena).

* Si la acción dura más de 10 segundos, mostrar una barra de progreso indicando, si es posible calcularlo, el porcentaje realizado.

5. Malos mensajes de error


Los mensajes de error son un tipo especial de retroalimentación que indican al usuario que algo ha ido mal. A pesar de tener directrices sobre mensajes de error desde hace casi 30 años, todavía muchas aplicaciones las violan.

La violación más habitual es cuando el mensaje de error simplemente indica que algo ha ido mal, sin explicar por qué y cómo el usuario puede solucionarlo. Esos momentos pueden aprovecharse para enseñar al usuario el funcionamiento del sistema, ya que estará más dispuesto de lo habitual para solucionar el problema.


En la web, existe un segundo problema con los mensajes de error: en muchas ocasiones los usuarios los pasan por alto ya que están rodeados por grandes cantidades de información. Se puede aliviar haciendo páginas más simples, pero aun así los mensajes de error tienen que ser más prominentes en interfaces web.
Página 404 (not found) del sitio Dilbert.com

6. Pedir la misma información varias veces

Los usuarios no deberían verse obligados a introducir la misma información más de una vez. Después de todo, los ordenadores son especialmente buenos recordando datos. El único motivo de que los usuarios tengan que hacerlo es que los programadores no se han tomado la molestia de transferir la información de una parte de la aplicación a otra.

7. Sin valores por defecto


Los valores por defecto ayudan a los usuarios de muchos modos. Por ejemplo, pueden:

* hacer más rápida la interacción, ya que los usuarios no tienen que introducir un valor si el que está por defecto es aceptable;
* enseñando, mediante un ejemplo, el tipo de respuesta que es apropiada para la pregunta; y

* dirigiendo a los usuarios novatos hacia un resultado común o seguro, dejándoles aceptar el valor por defecto si no saben qué otro elegir.

En este ejemplo, la aplicación permite configurar una camisa al gusto del usuario, con multitud de opciones pero dejando seleccionada por defecto la más común en cada caso (en concreto, la selección del cuello tiene 15 posibilidades diferentes).


Caputra de pantalla parcial la aplicación de configuración de camisa en www.listerouge-paris.com

8. Usuarios "lanzados" contra la aplicación

Muchas aplicaciones web son aplicaciones efímeras con las que los usuarios se encuentran como resultado secundario de su navegación, de cuyo funcionamiento no tienen un modelo conceptual. En otro tipo de aplicaciones esto menos problemático: las aplicaciones tradicionales son más o menos conocidas (muchos usuarios saben cómo funciona un editor de textos o una presentación), y para las aplicaciones críticas para su trabajo se supone que el usuario tendrá el tiempo, la motivación o la formación necesarias para aprender a manejarlas.

Pero en las aplicaciones basadas en web (incluso las que pertenecen a una intranet), muchas veces los usuarios se ven "lanzados" contra la aplicación sin tener idea de qué va a ocurrir. Desgraciadamente, la mayoría de usuarios no leerán un largo texto con instrucciones, por lo que necesitarán una lista corta o una imagen que les permita tener, en un vistazo, una idea general del funcionamiento de la aplicación.


En el siguiente ejemplo, la aplicación no consigue ese objetivo ya que mezcla dos metáforas: el configurador de producto y el detalle de un producto prediseñado en un sitio de comercio electrónico. El usuario no consigue tener por tanto una idea clara del objetivo de la aplicación.

Captura de pantalla de la aplicación de configuración de camisas en Hamilton

9. No indicar cómo se usará la información

En general, obligar a los usuarios a seguir un proceso sin mostrar claramente el resultado es un problema importante; pero el peor caso es cuando se pide a los usuarios que introduzcan información sin indicarles para qué se va a utilizar.

Un ejemplo clásico es el campo "alias" en un proceso de registro de un foro; muchos usuarios no se dan cuenta de que ese alias será utilizado para identificarlos en el foro para siempre, así que a menudo introducen algo inapropiado.

Otro ejemplo es el de sitios de comercio electrónico que piden el código postal del usuario antes de poder ver páginas de productos; muchos usuarios abandonan el sitio preocupados por su privacidad. Esto se evita con un diseño en el que se explica a los usuarios que el código postal es necesario para calcular los gastos de envío en caso de productos pesados.

10. Funcionalidades centradas en el sistema

Demasiadas aplicaciones muestran su "ropa sucia", ofreciendo funcionalidades que reflejan su punto de vista interno de los datos, en vez de la visión que tienen los usuarios del problema.

Por ejemplo, un usuario puede querer recolocar los fondos de su plan de pensiones (actuales y futuros), moviéndolos de un tipo de inversión a otro (bonos a acciones, por ejemplo). Pero en la práctica, puede ocurrir que la aplicación únicamente cambie el destino de sus aportaciones futuras, mientras que las anteriores quedarán donde estaban.

¿Por qué este funcionamiento incorrecto? Porque desde el punto de vista del gestor del plan, las aportaciones anteriores y las futuras se tratan de modo diferente: recolocar nuevas aportaciones implica invertirlas en un mercado u otro, mientras que recolocar los fondos anteriores puede que implique vender las inversiones anteriores para adquirir otras diferentes.

Pero los usuarios probablemente no hacen esa distinción entre aportaciones nuevas y viejas; para ellos sus ahorros forman una misma unidad, y como tal quieren operar con ellos. Probablemente sería más adecuado ofrecer una funcionalidad destacada para recolocar la totalidad de los fondos, y ofrecer una funcionalidad más avanzada (mediante revelación progresiva ) para los usuarios expertos que quieran hacer una distinción más detallada entre ambos tipos de aportaciones.

Error extra: botones de reset en formularios web

Este error se refiere a formularios web: es casi siempre una equivocación tener un botón de Reset en un formulario web.

El botón Reset borra toda la información insertada por el usuario y deja el formulario en su estado inicial. Sólo sería útil para usuarios que introducen datos de modo repetido con el mismo formulario pero con datos totalmente diferentes cada vez, que es una situación que no se da prácticamente nunca.

Poner tan fácil que los usuarios puedan perder su trabajo con un simple click viola uno de los principios de usabilidad más básicos, que es respetar y proteger el trabajo del usuario casi a cualquier coste; por eso se utilizan diálogos de confirmación para las acciones más destructivas.