Latest Posts

El diseño es, también, una cuestión estética

(Este post podría ser una continuación de “El diseño no es una cuestión estética“.)

Los no-diseñadores están habituados a percibir el diseño como algo artístico. Los diseñadores estamos acostumbrados a escuchar —y a creer, porque en definitiva se trata de una cuestión de fe— que “el diseño no es arte”. En cierto momento de la vida de algunos diseñadores el intríngulis entre lo que es diseño, arte, o ambos vuelve a aparecer; a veces con una tendencia hacia un lado, otras hacia el otro, otras en la forma de una inquietud constante que no se termina de definir. Yo creo que la no-definición de esa incógnita es saludable, siempre y cuando se aleje de la visión superficial que juzga artística la actividad de diseño.

La seguridad de los diseñadores modernos —aunque a veces roce la testarudez— es envidiable. Tener fe en que la dimensión funcional del diseño es la que rige (y debe regir) el proceso proyectual es un lujo que otorga una determinación y una firmeza de pulso digna de admiración. Pone al diseñador en un lugar heroico, muy de corte romántico: nos convierte (diseñadores) en algo así como desinteresados y temerarios salvadores de la humanidad toda. Very nice.

Sin embargo, como dije en mi post anterior, al pensar el diseño en el terreno de lo útil únicamente algo hace ruido. ¿Puede, un sujeto, realizar un proceso intelectual, de significación, de formalización, de invención, y hacerlo de manera tal de obstaculizar por completo la aparición de situaciones inconscientes que impregnarán la obra en forma de sublimación? ¿Puede, el objeto proyectado por un sujeto, permanecer virgen de forma tal que la relación entre forma, función, contexto cultural y entorno objetual definan el objeto en su totalidad sin la contaminación subjetiva del autor/diseñador? Y por otro lado, ¿puede un usuario ejecutar acciones con dicho objeto únicamente en términos de utilidad, dejando de lado la proyección que él mismo realiza sobre el objeto, en función de su duración (en palabras de Bergson), su goce y sus expectativas personales? Yo creo que no.

Pensemos en diseño industrial (haré una simplificación, lo sé, pero una simplificación que me será útil momentáneamente): ¿Cuántos modelos de sillas son suficientes para cubrir las necesidades de la totalidad de la población en términos funcionales? ¿Cuántos diseños de pavas para hervir el agua del mate? Hablemos ahora en términos de diseño gráfico: ¿Cuántas familias tipográficas alcanzan para cubrir las necesidades funcionales que un texto requiera? Massimo Vignelli dirá, en el film documental Helvetica, que una docena de tipografías es ya suficiente.

Las sillas, los edificios, las grandes obras arquitectónicas y las pequeñas, las familias tipográficas, la vestimenta: no están allí únicamente para cumplir la función de albergar, comunicar o abrigar; están allí también como vehículo de valores, como material significante que participa activamente del flujo de mensajes que da forma a nuestra sociedad y a nuestra cultura. Son objetos que, en tanto operan con un valor estético meditado, dejan ver algo de la esencia misma del hombre —en términos kantianos—, permiten intuir lo que de otro modo sería imposible ver o conocer. Un transatlántico a punto de zarpar nos dice mucho, nos enriquece, nos ilumina quizás más que la vista de una obra pictórica renacentista; nos eleva y nos abruma con su inmensidad; no se trata de un mero transporte de personas. La forma del objeto-transatlántico tiene un potencial significante enorme que da cuenta de la inmensidad a la que arroja al hombre.

Admitir que el diseño —o las piezas de diseño— pueden analizarse a nivel estético, es muy parecido a decir que diseño es arte, pero allí está la complejidad de todo el asunto. ¿Qué significa que el diseño es arte? Aguí algunas posibilidades de significado:

  • Diseño y arte son la misma cosa.
  • El arte es una categoría más amplia, que incluye el diseño.
  • El diseño es una categoría más amplia, que incluye el arte.

Es complejo, porque ninguna es satisfactoria. La misma definición de arte ha sido materia de preocupación de pensadores, filósofos y estetas durante siglos. Lo mismo ocurre con la definición de diseño, pero con menos historia por el momento. Pensar que la una es sub-categoría de la otra es también extraño. Los límites del campo del arte y del diseño son difusos y es ahí, en la zona de límite, que suceden los fenómenos interesantes y surgen las dudas más complicadas de solucionar.

Cuando digo que el diseño es, también, una cuestión estética, lo hago pensando en lo estético en toda su profundidad, y no en el sentido artístico superficial que comenté al principio de este texto. Lo estético, la belleza —y también la fealdad— nos conecta con el más allá de la existencia humana. Eso.

El diseño no es una cuestión estética

El otro día me junté a comer locro con un viejo amigo mío —alguien que supo jugar al poliladron en los pasillos de nuestra escuela primaria y que el presente lo encuentra abogado—, no sé cómo terminamos hablando de diseño. Noté en aquel momento que debía hacer una brevísima introducción explicándole qué es “diseño”, para mí (como si tal cosa fuese posible), y comencé diciendo —El diseño no es una cuestión estética—.

Continué contándole por qué diseño es función, materiales, técnica y varios etcéteras que ahora no vienen al caso. Sí me importa esto: a la mañana siguiente me desperté un tanto inquieto pensando no sólo por qué demonios había dicho aquello, sino además cómo fue que eso había aparecido con tanta naturalidad en mi discurso, como un terrible lapsus favorecido por el vino que acompañaba el riquísimo locro picante de El Sanjuanino.

Cuando tuve tiempo para analizar el asunto entendí que hablé desde el lugar del diseñador moderno (utilizo aquí la palabra “moderno” no como sinónimo de novedoso, nuevo, etc., sino refiriéndome a la ideología o movimiento específico dentro de la historia del diseño). A nivel formal, el diseño moderno basó su revolución en la búsqueda de la pureza en las formas y la no arbitrariedad: la forma debía seguir la función. En este sentido, el diseñador industrial Dieter Rams escribió una serie de máximas para el buen diseño que listo a continuación:

  • Gutes Design ist innovativ.
  • Gutes Design macht ein Produkt verständlich.
  • Gutes Design ist ästhetisch.
  • Gutes Design macht ein Produkt brauchbar.
  • Gutes Design ist unaufdringlich.
  • Gutes Design ist ehrlich.
  • Gutes Design ist langlebig.
  • Gutes Design ist konsequent bis ins letzte Detail.
  • Gutes Design ist umweltfreundlich.
  • Gutes Design ist sowenig Design wie möglich.
  • El buen diseño es innovador.
  • El buen diseño hace útil al producto.
  • El buen diseño es estético.
  • El buen diseño hace comprensible al producto.
  • El buen diseño es honesto.
  • El buen diseño es no-intrusivo.
  • El buen diseño es duradero.
  • El buen diseño se prolonga hasta el último detalle.
  • El buen diseño está comprometido con el medio ambiente.
  • Buen diseño significa tan poco diseño como sea posible.

Sipt, uno de los ítems de la lista dice que el buen diseño es estético. Pero vale la pena aclarar que lo dice en tanto que:

La calidad estética de un producto es parte integral de su utilidad ya que los productos que utilizamos diariamente afectan a nuestra persona y nuestro bienestar; pero sólo los objetos bien ejecutados pueden ser hermosos. (fuente)

Es decir que el diseño moderno le daba importancia a la cuestión estética sólo en tanto y en cuanto consideraba al bienestar del usuario como una de las funciones del objeto, y lo estético como medio para satisfacer esa necesidad.

Cuando desaparece el valor estético en sí mismo, y se pierde la posibilidad de la arbitrariedad en la forma (un imposible), todo pasa a depender de la dimensión funcional del objeto: esto es, incluyendo su forma.

Dándole aún más vueltas al asunto, comprendí que cuando dije —El diseño no es una cuestión estética—, lo que estaba significando, en definitiva, era que el diseño no es arte. Claro, lindo brete. Si la Estética es la raíz filosófica encargada de pensar el terreno de lo bello y lo feo, pues entonces es la encargada de pensar el arte; si el diseño no es de interés estético —es decir, si no se relaciona con lo bello y lo feo—, es de interés utilitario: su importancia radica en lo útil o inútil de su producción.

Sin embargo, al pensar al diseño como en el terreno de lo útil únicamente algo hace ruido… verdad? Sí, sé que al decir esto sufriré el ataque de una horda de zombies modernos, pero creo que prefiero correr el riesgo. Después de todo, el diseño es, también, una cuestión estética.

Carga de archivos en AS3

Antes y después

El lengueja de programación de la Plataforma Flash ha pasado por 3 versiones: ActionScript 1, ActionScript, 2 y ActionScript 3. Como sabemos, varias cuestiones han cambiado en el paso de AS2 a AS3. La carga de archivos externos es una de ellas. Si bien la traducción literal es más o menos sencilla, vale la pena repasarla.

Lo que en AS2 solíamos hacer así:

loadMovie("archivo_secundario.swf", this);

En AS3 se debe hacer así (el ejemplo citado a continuación está copiado de la documentación de Adobe, y luego ligeramente modificado):

import flash.display.*;
import flash.net.URLRequest;
var cargador:Loader = new Loader();
var urlReq:URLRequest = new URLRequest("archivo_secundario.swf");
cargador.load(urlReq);
this.addChild(cargador);

Más allá de lo que se puede ver a golpe de vista, hay un par de cuestiones interesantes que trataré de sacar a la luz en este post.

El ejemplo de Adobe:

Antes de crear nuestro propio ejemplo —seguramente más complejo— repasaremos lo que hicieron los muchachos de Adobe. El ejemplo original se incluye en la documentación de la clase Loader (encargada de la carga de archivos externos en AS3).

Se importan las clases necesarias para la realización de la carga de un archivo externo. Nosotros lo haremos de forma detallada cuando nos toque crear nuestro propio ejemplo. Adobe ha sido un poco vago al importar todas las clases del paquete flash.display sin mayores precisiones (como podrán ver ustedes mismos, ésta no es una práctica muy amigable ya que el paquete flash.display contiene numerosas clases que no están siendo utilizadas por el resto del código).

// importar las clases necesarias:
import flash.display.*;
import flash.net.URLRequest;

Se crea una instancia de la clase Loader, que hará las veces de cargador. Este tipo de objeto (que hereda de la clase DisplayObjectContainer) tiene la funcionalidad necesaria para realizar la carga.

// crear el cargador:
var cargador:Loader = new Loader();

Se prepara una instancia de URLRequest, el tipo de objeto que espera recibir el método load de la clase Loader.

// preparar la URL request:
var urlReq:URLRequest = new URLRequest("archivo_secundario.swf");

Efectivamente se da la orden de carga por medio de la función load, incluyendo como parámetro a aquel objeto de tipo URLRequest que creamos anteriormente.

// se da la orden de carga:
cargador.load(urlReq);

Hasta aquí, la carga del archivo externo ya se puso en marcha, pero aún queda agregarlo a la escena. La siguiente línea de código agrega al cargador (de tipo Loader) a la escena, como child del root. Siendo que los objetos de clase Loader heredan de DisplayObjectContainer, tienen la posibilidad de agregarse a la Display List, al igual que un MovieClip o un Sprite.

// poner el cargador en escena:
this.addChild(cargador);

Recordemos el código completo, comentado:

// importar las clases necesarias:
import flash.display.*;
import flash.net.URLRequest;
// crear el cargador:
var cargador:Loader = new Loader();
// preparar la URL request:
var urlReq:URLRequest = new URLRequest("archivo_secundario.swf");
// dar la orden de carga:
cargador.load(urlReq);
// poner el cargador en escena:
this.addChild(cargador);

A primera vista, parece mucho más complejo que la escueta versión en AS2 (y lo es), pero en programación menos no siempre es más. El cambio a AS3 nos facilita la resolución de errores y la generación de diferentes funcionalidades. El código nuevo ganó en complejidad, pero también en coherencia, orientación a objetos, facilidad en la solución de errores y funcionalidad.

Veremos un poco más a fondo el asunto en la siguiente página…

An apple a day…

…keeps doctor away.

Cortito y al pie. La semana pasada llevé mi antigua MacBook a reparar a Alfauno (servicio técnico autorizado de Apple): tenía algunas rajaduras en la carcasa y hacía tiempo que se había vencido la garantía de 1 año.

Al día siguiente me llamaron para avisarme que la computadora ya estaba lista para retirar, cambiada toda la pieza rajada, el teclado, el pad, y el botón del pad. El arreglo fue por cuenta de Apple, por lo que me salió $0 (ni siquiera tuve que abonar la mano de obra). Fui a buscar la compu el viernes, y estaba impecable.

Ayer, a dos días del arreglo, recibo mail oficial de Apple, solicitándome que responda una encuesta de satisfacción acerca del servicio prestado por el proveedor de servicios autorizado.

Estimado cliente de Apple:

Apple quisiera conocer tu opinión respecto de la reciente reparación de tu MACBOOK en un Proveedor de Servicios Autorizado Apple.

No voy  a negar que dicho mail me sorprendió absoluta y gratamente. Al final de la encuesta, podemos elegir enviar las respuestas únicamente a Apple, o también al proveedor de servicios que realizó la reparación. Nice.

Anécdotas adicionales:

  • Conozco gente que ha comprado notebooks de otras marcas en Europa, y tras un desperfecto no le quedó otra que enviar por correo la computadora para hacer valer la garantía en el lugar de origen. El soporte de Apple es global y no requiere la muestra de ningún comprobante, garantía impresa, o factura de compra (el producto de Apple en cuestión es lo único necesario).
  • Conozco casos de iMacs de 4 años de antigüedad a las que les falló el monitor y también fueron reparados sin cargo (si sos uno de ellos, no dudes en acercar tu compu a un proveedor de servicios autorizado, aún con la garantía vencida).

Nada más… quería, simplemente, hacer público mi agradecimiento.

Thanks Steve!

La travesía de la forma

Recomiendo un libro que creo indispensable para diseñadores, o interesados en la historia del diseño gráfico en la Argentina: La travesía de la forma, de Verónica Devalle.

El libro es genial y absolutamente inspirador en cuanto a labor investigativa. A lo largo del desarrollo del texto se hace un análisis exhaustivo de los orígenes del término diseño gráfico y de sus prácticas.

Sobre Verónica Devalle:

Licenciada en Sociología, doctora en Artes por la Universidad de Buenos Aires y magíster en Sociología de la Cultura y Análisis Cultural por la Universidad de San Martín. Se desempeña como profesora adjunta de Comunicación I y profesora titular de Diseño y Estudios Culturales, ambas de la carrera de Diseño Gráfico de la Facultad de Arquitectura, Diseño y Urbanismo (FADU/UBA). En la misma institución es coordinadora y profesora de la Maestría en Diseño Comunicacional (DICOM). Es investigadora del Conicet y directora de proyectos UBACyT, en el marco de la FADU. Sus temas articulan la reflexión sobre el arte, el diseño y la cultura visual contemporánea.

Explorer go home

Quienes trabajamos en el desarrollo de sitios web sabemos que el Internet Explorer, de Microsoft, es de lo peor. Lo sabemos, no por nuestro fanatismo geek, los numerosos artículos que versan sobre sus vulnerabilidades en materia de seguridad, o por boca de terceros, sino porque sufrimos diariamente sus caprichos y su incorrecta interpretación de código HTML y CSS.

Cuando terminamos de escribir el código y los estilos de un sitio, cuidando que todo esté acorde a los estándares dictados por la W3C, y pasamos a testearlo en diferentes navegadores, vemos que la mayoría muestra las páginas de la forma esperada… la mayoría, salvo el Internet Explorer. De ahí que estamos obligados a introducir hacks —en muchos casos incluso código no estándar— para reparar el problema. Este fenómeno suma horas, complicaciones inesperadas, incertidumbre y stress a nuestra tarea de desarrollo.

Una posible solución a largo plazo, es procurar que los usuarios elijan otros navegadores y dejen de utilizar IE (algo que está ocurriendo: las estadísticas de los últimos años muestran cómo viene perdiendo terreno el que alguna vez fue el navegador más utilizado).

Educar al soberano:

Dejar de incluir hacks en los sitios que desarrollamos sería una buena táctica; algo así como una guerrilla de insurrectos desarrolladores web —aunque convengamos que sería complicado explicarle a nuestro cliente que ve su sitio destartalado porque está utilizando Internet Explorer, que es el peor navegador, y entonces debiera cambiarlo y utilizar Firefox, o Chrome o Safari, lo mismo que los demás visitantes del sitio—. Eso es imposible. El cliente quiere que su sitio se vea perfecto en todos los principales navegadores, especialmente en el bendito Explorer.

Estos pocos días que transcurrieron desde que puse en marcha mi blog personal me han enseñado mucho. Ayer, por ejemplo, pensé que tener un sitio web personal implica hacer lo que se me de la gana. Decidí que no agregaría hacks para solucionar los errores de interpretación de IE, y que aportaría mi granito de arena para explicarle a los navegantes usuarios de Explorer que les convenía utilizar otros navegadores. Decidí incluir un cartel —visible únicamente para usuarios de IE— que los alerte e invite a probar otras alternativas.

Hay muchas maneras de presentar contenido únicamente a Internet Explorer. Voy a explicar a continuación cómo está resuelto en el caso de este sitio web en particular.

A modo de receta de cocina, diré que haremos uso de:

  • los comentarios condicionales de IE.
  • un poco de javascript no intrusivo.
  • css a gusto para condimentar.

Comentarios condicionales:

Quizás porque la gente de Mircosoft sabe que su navegador deja mucho que desear, inventaron una forma fácil para que los desarrolladores podamos escribir código que sólo el IE pueda ver; lo hicieron en la forma de comentarios de HTML, pero con una estructura estándar que el IE leerá.

Haciendo uso de esta posibilidad, podemos agregar un archivo JavaScript externo, que sólo IE verá. Escribiendo el siguiente código dentro de la etiqueta head:

<!--[if IE]>
    <script type="text/javascript" src="ruta_al_archivo_javascript.js"></script>
<![endif]-->

Los demás navegadores verán eso como parte de un comentario de HTML, y no cargarán el JS externo.

Un poco de JS no intrusivo:

A continuación, utilicé un poco de JavaScript para escribir contenido en el HTML. ¿No podría haber escrito el código HTML directamente dentro de la etiqueta body, utilizando los comentarios condicionales propios de IE? Sí, lo podría haber hecho, pero preferí utilizar JS porque no quería ensuciar el código HTML (ni siquiera con un “comentario”) con todo este asunto. Cada cual podrá sopesar qué le conviene, según el caso.

El código JS será algo así:

// definir la funcion escribirCartelIE:
function escribirCartelIE() {
    // chequea que funcione el control del DOM desde JS:
    if (!document.getElementsByTagName){
        return;
    }
    // crear una referencia al body:
    var body_element = document.body;
    // modificar el contenido del body, agregándole un poco de HTML al principio:
    body_element.innerHTML = '<div id="cartel_ie"><p>Ups! Est&amp;aacute;s utilizando Internet Explorer.</p><p>El <strong>Microsoft Internet Explorer</strong> es un navegador web inseguro, inc&amp;oacute;modo y cuya habilidad para mostrar correctamente las p&amp;aacute;ginas web deja mucho que desear. Por fortuna, no es el &amp;uacute;nico navegador que existe en el mercado. Te recomiendo que pruebes alguno de los siguientes navegadores:</p><ul><li><a href="http://www.mozilla.com">Mozilla Firefox</a></li><li><a href="http://www.google.com/chrome">Google Chrome</a></li><li><a href="http://www.apple.com/safari/">Apple Safari</a></li><li><a href="http://www.opera.com">Opera</a></li></ul></div>' + body_element.innerHTML;
}
// hacer todo cuando se cargue el HTML:
window.onload = escribirCartelIE;

Desde ya, el mensaje puede ser otro. Estoy seguro de que tendrán más imaginación que yo a la hora de redactar el texto.

Fíjense que no incluí código JS en el html. Recuerden que es siempre conveniente mantener separado el contenido (HTML), de la presentación (CSS) y del comportamiento (JS).

CSS a gusto:

Cuando el IE termine de cargar la página, ejecutará la función escribirCartelIE, que modificará el contenido del HTML. A partir de ese momento, el HTML literalmente tendrá nuevos elementos: un div con id cartel_ie y su contenido.

Las órdenes de cómo deben presentarse estos elementos, pueden estar junto con los demás selectores, en el archivo CSS que se esté usando. Esto no afecta al resto del contenido del CSS. Los navegadores que no tengan ese elemento en el HTML, no aplicarán esas órdenes del CSS.

Aquí, a modo de ejemplo, el código CSS que se está utilizando en este sitio:

/* css para IE */
#cartel_ie {
    width: 428px;
    padding: 10px;
    border: 1px dotted #F0F;
    font: 13px/1.5em Georgia, "Times New Roman", Times, serif;
    margin: 10px auto 5px 249px;
}
#cartel_ie .titulo {
    font: 16px "Courier New", Courier, mono;
    color: #F0F;
}

¡Los invito a hacer una movida similar en sus sitios web personales! Un pequeño banner no basta.