Lucas Mourelle

200 años de literatura argentina

Lucas Mourelle — Thu, 26 Aug 2010 17:55:36 +0000

No es que esté conforme con el resultado pero, a pedido del público, aquí va la mentada infografía acerca de los últimos 200 años de literatura argentina.

Aquí un encuadre con nuestros amigos favoritos.

El partido original se sostenía en la idea de diferentes niveles de información funcionando como capas superpuestas, codificadas en diferentes colores para facilitar la legibilidad (simple, pero efectivo). Negro para los autores nacionales; verde para los extranjeros (pero con gran influencia a nivel nacional); rojo para las obras, libros y revistas de peso en el ámbito literario; azul para los eventos históricos.

La pieza mide 150 x 70 cm.

To be or not to be HTML5

Lucas Mourelle — Tue, 03 Aug 2010 14:50:38 +0000

Hace varios días que tengo este post en mente (To be or not to be HTML5), y no he encontrado el tiempo para desarrollarlo y publicarlo.

Hoy comienzo mi día de trabajo y leo un tweet de Jeffrey Zeldman, que nos lleva a un comentario donde aclara ciertas cuestiones relacionadas con la confusión general que está experimentando el común de la gente, acerca de lo que efectivamente es HTML5. Ahora bien, cuando el querido Zeldman escribe algo similar a aquello que viene rondando nuestros pensamientos, uno se siente bien: debemos ir por buen camino. Así es que decidí apurarme y publicar aunque sea algunos pensamientos fragmentados, desprolijos, y sacarlos afuera de una vez.

¿Qué es HTML5 y qué no?

Primero lo primero: las tecnologías y estándares web son muchos y muy abarcativos, pero hay tres que son fundamentales y juegan un rol protagonista en la mayoría de los sitios web:

HTML (sea cual fuere la versión)
CSS (sea cual fuere el módulo)
JavaScript (lo dicho)

Ahora bien, estas tecnologías cumplen tres funciones muy diferentes que se complementan mutuamente, a saber:

HTML (contenido estructurado semánticamente)
CSS (presentación; los diseñadores podemos llamarlo “diseño”)
JavaScript (comportamiento)

Cualquiera que se dedique al desarrollo web de calidad tiene este concepto tatuado en el cerebro o se dedica a alguna otra cosa (fuegos de artificio… digo, manejo de Fireworks).

El punto es que en las últimas semanas, una monstruosa cantidad de posts, comentarios, tweets y charlas de café abordan la temática HTML5, citando ejemplos que, o bien no son HTML5, o bien lo son, pero cuyas características principales no tienen que ver en absoluto con el uso (o no) del futuro estándar HTML5. Incluso Apple ha decidido sumarse a la confusión de una forma espantosa: creando una web donde todos los ejemplos utilizan HTML5 (es cierto), pero muchas de las características que se muestran como sus bondades dependen —en realidad— de las bondades de CSS3, o JavaScript, y podrían realizarse sin problemas utilizando las tradicionales versiones HTML 4 ó XHTML 1.

Haremos a continuación un par de listas que reflejan algunos ejemplos (sólo algunos) de lo que es, y no es HTML5. Adelantamos, de todas maneras, que cuando una gracia relacionada con el diseño de una página web —como la posibilidad de rotar el ángulo del texto, o de generar cajas con puntas redondeadas—, está publicada como una bondad de HTML5, habrá que al menos sospechar (sabemos que el HTML no debe encargarse del diseño/presentación del contenido, sino de marcar correctamente el contenido en sí mismo; es la tecnología CSS la que se ocupa de la presentación de los elementos que el HTML describe).

To be HTML5

Nuevas etiquetas que ayudan a marcar mejor el contenido a nivel semántico:
,
,
,
,
, , etc.
La posibilidad de incluir video y audio sin la utilización de tecnologías externas y plugins adicionales: y .
La posibilidad de generar experiencias altamente interactivas, dibujando sobre cierta área con JavaScript, sin la utilización de tecnologías externas y plugins adicionales:
Un doctype human-friendly (finalmente), que no comunica la versión del HTML:
La posibilidad de utilizar la sintaxis del viejo HTML o la de XHTML (que sigue la sintaxis del metalenguaje XML).

Not to be HTML5

Texto rotado, puntas redondeadas, sombras estilo drop-shadow, imágenes y colores en transparencia, y todo tipo de situaciones que dependen del área de presentación/diseño de una página web, y que es responsabilidad exclusiva de la tecnología CSS. Por lo general, debemos estas nuevas posibilidades a CSS3.
Animaciones de objetos que aparecen, desaparecen, se mueven, agrandan, colapsan y cambian su forma. Cuestiones que evidentemente tienen que ver con el comportamiento de un site, y que suelen programarse en JavaScript.
Geolocation: muchos suelen decir que se trata de parte del futuro estándar HTML5, pero no.
Posibilidad de visualizar el website en celulares y equipos móviles como el iPhone, iPad y similares: este asunto es escabroso, pero tampoco es exclusivo de HTML5. El debate Flash vs HTML5 ha generado la equívoca sensación de que para que un celular pueda interpretar correctamente una página web, ésta debe estar codificada en HTML5, cuando lo que en realidad ocurre es que simplemente se debe evitar la utilización de la tecnología Flash.
La tecnología que hace volar al DeLorean en Back To The Future II.

Pero…

Como comenta el estimadísimo Jeffrey Zeldman, el hecho de que aquellos no-geeks (a veces gerentes de empresas, y quienes deciden cuándo/cuánto invertir en tecnología web) estén entusiasmados con el concepto HTML5, es genial y beneficia a la Web en general. Cuando estas personas se refieren a HTML5, en realidad se están refiriendo a un conjunto de tecnologías nuevas que incluyen HTML5, CSS3, manejo de JavaScript avanzado y algunas otras más crípticas como Microformats, Geolocation, Microdata, etc.

Es nuestro deber, como profesionales con conocimiento técnico, al menos tener la delicadeza de nombrar este conjunto de tecnologías por lo que son, o como bien recomienda Mr. Zeldman, titularlas: “HTML5 and related technologies” (HTML5 y tecnologías relacionadas). De esta manera, /1. mantenemos el halo marketinero del asunto y /2. evitamos malentendidos.

There, I said it. Pensamientos fragmentados y desprolijos afuera.

Excelente video explicativo

Lucas Mourelle — Wed, 16 Jun 2010 01:26:41 +0000

Es genial cuando se logra explicar un asunto complejo de forma simple. Aquí una explicación acerca del funcionamiento del buscador de Google.

HTML5, Flash, y otras armas de destrucción masiva

Lucas Mourelle — Fri, 11 Jun 2010 14:53:17 +0000

En los últimos meses se ha hablado, escrito y discutido muchísimo acerca de cuestiones relacionadas con el universo del desarrollo web, el desarrollo de aplicaciones para smartphones y depravaciones similares, cuestiones político-filosóficas acerca del futuro de la web y del modelo de negocio de las empresas más pesadas dedicadas al software. Todo en la misma bolsa.

¿Un post más acerca de todo esto? En serio… ¿otro más? Sip. Un poco porque contar me ayuda a ordenar las ideas y otro porque probablemente le sirva a alguna que otra persona interesada, que todavía no hubiera llegado a entender de qué se trata todo esto, por qué tanto revuelo y cómo se relacionan estos asuntos entre sí.

First thing first

A continuación, una breve reseña descriptiva de algunas cuestiones:

Hace algunos años (en el 2000 aproximadamente) la W3C intuyó que el futuro de la web no podría montarse sobre nuevas versiones del viejo y peludo HTML —ya muy vapuleado—. Decidieron lanzar al ruedo una nueva recomendación, que sentaba las bases de una línea de pensamiento renovada, un HTML más ordenado, limpio y estructurado, uno basado en el estándar XML: así nació el XHTML. Hoy, diez años más tarde, nos encontramos ante una situación similar: con una W3C que decide —en vez de continuar la lógica del XHTML y generar una versión 2.0— volver a la ruta del HTML y se encuentra as we speak desarrollando el mentado HTML5 (cambio de rumbo que se vio influenciado por el trabajo realizado por el WHATWG). Casi una marcha atrás, pero no.
Apple, empresa que diseña y fabrica la línea de smartphones más popular del mercado, se niega a permitir la ejecución de Flash en sus artefactos. Adobe pone el grito en el cielo al tiempo que algunos usuarios. Steve Jobs, CEO de Apple, publica una carta en abril de este año, en donde explica el por qué de su decisión. Adobe responde con una campaña publicitaria titulada “We love Apple”.
Apple apoya el formato HTML5 y se instala en el mercado que la Plataforma Flash está en decadencia, con la nueva versión de HTML como su verdugo y sucesor. Nace la rivalidad HTML5 vs. Flash.
Tooodo el mundo enloquece con las vistosas nuevas posibilidades de lo que dan en llamar HTML5 (aunque en muchos casos se trata de posibilidades absolutamente factibles aún sin la utilización del dichoso HTML5). Hay la sensación de que algo groso, muy groso, está ocurriendo en el universo del desarrollo web.

¿Qué demonios está ocurriendo?

Trataremos de ordenar un poco el panorama, ahora sí, olvidando la poca objetividad que pude esbozar en los párrafos anteriores. Todas estas cuestiones se relacionan íntimamente. Veremos…

¡Que vivan los estándares!

Durante un largo tiempo, desarrolladores web y otros evangelizadores han invertido una enorme cantidad de energía en la utilización de estándares. —Me incluyo en la humilde y pequeñísima porción que me toca: comencé a utilizar estándares XHTML y CSS allá por el 2003 en trabajos para clientes, todo se veía para el traste en Internet Explorer y los clientes me querían hacer asesinar.— Esto se hizo con muchísimo esfuerzo, contra la corriente y contra muchos intereses económicos opuestos. Ha sido una tarea hercúlea que dio sus frutos: hoy podemos decir que los estándares gozan de buena salud, buena publicidad y buen funcionamiento en casi todos los navegadores web.

¿Qué significa esto? Significa, entre otras cosas, que un sitio web desarrollado acorde a estándares tiene una alta probabilidad de funcionar correctamente en una gran cantidad de navegadores web. Significa, también, que personas no videntes, con visión reducida o problemas motrices severos, pueden navegar sin mayores inconvenientes gracias a una web más accesible. Esto último es muy importante: es equivalente a rampas y ascensores en edificios públicos.

En el pasado, algunas empresas (principalmente Microsoft) vieron esta democratización en cuanto a la libre elección de navegadores web como una amenaza contra la preponderancia del Internet Explorer, e hicieron todo lo posible por retrasar el avance en relación a los estándares web. Las consecuencias de esta estrategia han sido tan fuertes que aún hoy lo sufrimos a diario, tanto navegantes como desarrolladores.

¿Qué ha cambiado?

Los intereses económicos han cambiado. Por estos días, Apple —cuyo capital ha superado al de Microsoft muy recientemente—, basa la porción de su negocio con mayor crecimiento en sus plataformas mobile, esto es: iPhone, iPod touch y iPad. Estos artefactos son computadoras —mi Motorola W375 también, aunque sea menos evidente— pero, a diferencia de sus hermanas de escritorio, tienen menos velocidad de procesamiento, sus componentes son muy pequeños, se encuentran empaquetados de la manera más comprimida posible, y deben economizar la potencia de procesamiento al máximo para evitar el sobrecalentamiento y utilizar el menor consumo de batería posible.

Apple necesita del HTML5, y no es una cuestión de filantropía. Lo necesita porque puede brindarle contenido textual, imagen, animación, video, audio e interactividad utilizando pocos recursos. Los desarrolladores web nos encontramos ante una situación muy extraña: de repente el gran capital está a favor de los estándares web. ¿Algo andará mal? Not quite.

What’s up Flash?

El asunto Flash está sobredimensionado, salvo que se lo mire desde el interior mismo de los cuarteles de Adobe. La remota posibilidad de la desaparición de Flash, debe preocupar a nadie salvo a sus mismísimos fabricantes. En lo personal, le tengo muchísimo cariño a la Plataforma Flash, me ha dado de comer durante años, ha significado el 70% de mi trabajo de programación diario, pero debo admitir que la Web será un lugar tanto más feliz cuanto menos preponderancia posea Flash.

Las dos virtudes más importantes de la Plataforma Flash son:

Un altísimo grado de interactividad, incluyendo texto, imagen, animación, audio y video.
Fidelidad absoluta entre diferentes plataformas. Un contenido Flash se verá exactamente igual en Mac OS, Windows, y en algunos casos Linux, incluso cuando vistos en diferentes navegadores como Internet Explorer, Firefox, Safari, etc.

Por otro lado, los grandes problemas del Flash son:

Una performance paupérrima. Basta con mover un objeto más o menos grande (una foto que ocupe toda la pantalla, digamos) para que algunas notebooks levanten su temperatura en segundos.
Una cantidad incontrolable y muchas veces indocumentada de bugs. Aún en la última versión de su lenguaje de programación, ActionScript 3.0, programar en la IDE de Flash suele ser un safari infernal a lo desconocido.

¿Comienzan a vislumbrar el asunto? Flash tenía sentido en una realidad donde la fidelidad de un mismo contenido entre navegadores era muy pobre (una misma página web se veía y funcionaba de formas diferentes según desde qué navegador se ejecutara), y donde alcanzar un alto nivel de interactividad que incluyera audio, video y animación era imposible en el marco de los formatos estándares propuestos por la W3C.

Ahora bien, hemos sido testigos de la carrera de Intel y AMD por generar procesadores cada vez más rápidos y poderosos, pero esos tiempos se han acabado. El mayor interés actual es lograr un alto poder de procesamiento, en poco espacio, con poco consumo de energía y poca necesidad de ventilación. El gran capital necesita procesadores que puedan hacer funcionar sus nuevos gadgets para la burguesía tecnológica y software altamente optimizado que acompañe dicho ahorro de energía.

Como dijimos, Flash sufre de una performance paupérrima, un pésimo uso de la energía y está lleno de bugs. Que se cuelgue una aplicación en una computadora de escritorio es una cosa (force quit o ctrl+alt+delete y chau), que se cuelgue una aplicación en un teléfono móvil implica que la batería se consuma en unos pocos minutos: un día entero de incomunicación.

Contenido semántico

En los últimos años se habló mucho acerca de la web semántica. El asunto merece un post al margen, pero haré un breve reconto de por qué es importante en medio de todo este asunto.

La web abriga una cantidad demencial, inimaginable, incuantificable, infernalmente gigante de contenidos. Esto dificulta un tanto su accesibilidad. Cómo encontrar el contenido necesario entre semejante cantidad de datos es uno de los grandes temas en el campo de preocupaciones de científicos, ingenieros especializados y desarrolladores web. La respuesta es simple: hay que ordenar el contenido de alguna forma, hay que darle estructura.

El asunto es que la mayoría de las veces, quienes buscan entre el contenido son robots. Google puede mostrar una lista de resultados más o menos útiles en nuestras búsquedas, porque periódicamente envía una tropa de robots a darse una vuelta por la web, y a anotar lo recolectado en bases de datos. Cuanto mejor entienda la información este robot, más efectiva será la lista de resultados que ofrezca el motor de búsqueda.

La estructuración de ciertos tipos de datos en formas estándar, permite que estos robots puedan comprender la naturaleza de la información y sus relaciones. Por ejemplo, en los sitios web que están bien desarrollados y acorde a estándares, el robot de Google entiende qué partes de cierta página son más importantes, cuáles textos son títulos, a qué párrafos corresponden, de qué tratan las imágenes, etc.

Hoy en día, existen propuestas estándares para codificar muchos tipos de datos, por ejemplo un evento. Esto implica que es hipotéticamente viable, con la ayuda de Google y un smartphone con GPS, pararse en cualquier esquina de Buenos Aires y buscar eventos que ocurran de aquí a 4 horas, en un radio de 20 cuadras. Esto se hace posible únicamente en el marco de una web semántica, que sigue ciertos estándares.

¿Por qué nos interesa todo esto? Porque la información que se encuentra en un archivo HTML o XHTML (es decir, en una página web), es información que se encuentra accesible a robots, y que puede estructurarse semánticamente sin problemas. El Flash no lo permite, y es probable que no lo permita nunca, salvo que cambien cuestiones de la naturaleza de fondo de la tecnología.

¿Desaparecerá el Flash?

No creo. Pienso que se va a enfocar fuertemente al desarrollo de aplicaciones multiplataforma, lo que hoy en día Adobe llama Air, o tecnologías similares. Sin dudas la utilización de Flash en web está decreciendo, esto es un hecho. Apple ha ayudado mucho a acelerar el proceso. Vale la pena aclarar, sin embargo, que todavía no ha salido al mercado una versión del Flash Player que funcione en dispositivos móviles —con o sin manzana— por lo que está por verse si efectivamente Flash estará disponible en celulares y tabletas interactivas. Hoy en día hay un beta del Flash Player corriendo en un beta de la próxima versión de Android, el sistema operativo mobile de Google.

En ciertos casos clave, cuando se necesite un altísimo nivel de interactividad con una curva de aprendizaje más o menos sencilla, la tecnología de Adobe seguirá siendo una buena opción. Mientras tanto, sólo queda observar atentamente cómo se desarrollan los hechos, e ir practicando muuucho JavaScript ;-)

Herb Lubalin… groso

Lucas Mourelle — Tue, 09 Mar 2010 00:18:34 +0000

Pocos diseñadores manejaron con la maestría de Herb Lubalin los vericuetos tipográficos. Sí, ya sé ya sé… hoy en día tenemos las locuras de Marian Bantjes, pero convengamos que el amigo Herb jugó de forma exquisita con las formas tipográficas, evocando significados increíbles hace tantísimos años, y sin Illustrator.

Muchos son los que critican la tipografía ITC Avant Garde (diseñada por Lubalin), por extremadamente geométrica —en contraposición a otras tipografías similares en cuanto a la inspiración geométrica, pero con menor sumisión a la geometría y un mayor respeto por los necesarios ajustes ópticos, como es el caso en la familia Futura (de Paul Renner)—. Lo que muchos desconocen, es que la tipografía nació únicamente como solución para la realización del logo de la revista homónima. Lubalin había realizado ese logo, diseñando únicamente los caracteres que necesitaba para la tapa de la revista, y con ligaduras especialmente pensadas para escribir esas palabras salvando los problemas de espaciado entre los pares de signos. Con posterioridad el diseñador creó toda la familia, agregándole ligaduras para poder realizar juegos similares a los que había planteado en la marca de la publicación. Por desgracia, la comunidad de diseñadores malinterpretó, en general, las intenciones de dicha tipografía, que fue utilizada para texto, abusando de sus ligaduras u omitiéndolas por completo.

Una familia tipográfica no es buena o mala en sí. No podemos analizar la calidad de una familia tipográfica de forma aislada, sin tener en cuenta los usos: una obviedad que vale la pena recordar es que las tipografías se diseñan para ser usadas. Hay fuentes que escriben bien en determinados contextos y utilizadas de determinada forma, y otras que funcionan mejor en otras situaciones y modos de uso. Analizar la calidad de una familia tipográfica siempre implica escribir, y al escribir se toman decisiones de diseño indefectiblemente: un cuerpo, un interletrado, un interlineado, una paleta cromática, incluso el idioma cambia radicalmente la forma de escribir de una familia tipográfica.

El valor de una fuente, cuando fuera de un texto, es un valor meramente formal. Ahí donde los signos y caracteres dicen, escriben, es cuando surge el valor tipográfico.

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

Lucas Mourelle — Wed, 24 Feb 2010 14:38:45 +0000

(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 se debe a una cuestión de principios, casi 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, una persona, realizar un proceso intelectual interno, 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 absolutamente objetivo 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 para el 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, o 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

Lucas Mourelle — Mon, 22 Feb 2010 13:35:16 +0000

El otro día me junté a comer locro con un viejo amigo mío —uno que en algún momento supo jugar al poliladron en los pasillos de nuestra escuela primaria, y que el presente lo encuentra abogado— y 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 (como si tal cosa fuese posible), y comencé diciendo que “el diseño no es una cuestión estética”.

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

Cuando tuve tiempo para analizar el asunto entendí que al decir aquello, lo hice desde el lugar de 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 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, todo pasa a depender de la dimensión funcional del objeto: 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, en lindo brete me metí. 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

Lucas Mourelle — Sat, 13 Feb 2010 01:32:58 +0000

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…

Lucas Mourelle — Mon, 08 Feb 2010 04:32:10 +0000

…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

Lucas Mourelle — Fri, 05 Feb 2010 14:25:17 +0000

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.