Archive for category Programación
Jef Raskin y las Leyes del Diseño de Interfaces
Posted by Leonel in Diseño, Ingeniería, Interfaz de Usuario, Programación, Usabilidad on 8 April 2009
El libro de Jef Raskin se llama en español Diseño de Sistemas Interactivos: la Importancia de Nuestra Relación con las Computadoras
La semana pasada terminé de leer “Diseño de Sistemas Interactivos” del difunto Jef Raskin (1943 – 2005). Este libro es una traducción de “The Humane Interface: New Directions for Designing Interactive Systems”, y confieso que nuevamente me sucedió lo mismo que con el libro “Presos de la Tecnología” (traducción de “The Inmates are Running the Asylum” de Alan Cooper), es decir, me enteré de las excelentes referencias del escrito hasta que revisé su nombre en inglés. Es asombroso lo mucho que puede cambiar el nombre de un libro cuando lo traducen al español.
Curiosamente ambos libros los compré en rebaja por menos de Q30.00 en la librería del IGA. Tengo que ir más seguido a comprar allí.
Volviendo al libro, me llamó la atención la analogía que Raskin hace entre las leyes de la robótica, postuladas por Isaac Asimov, y las que él considera que deberían ser las leyes del diseño de interfaces:
Primera: Una computadora no debe causar daño al trabajo del usuario, o, por su inacción, permitir que el trabajo del usuario reciba algún daño.
Segunda: Una computadora no debe hacer al usuario perder tiempo u obligarlo a trabajar más de lo que es estrictamente necesario.
Y no hay tercera, al parecer no hace falta más, con solo estas dos podríamos encontrar miles de ejemplos de interfaces fuera de la ley.
El libro también da muchísimos principios de diseño, algunos muy generales, como “los usuarios establecen el ritmo de una interacción”, y otros muy prácticos como “si un control debe operarse siempre, (o nunca) no lo proporcione”.
Esta es la portada de la versión en inglés que dice algo totalmente diferente a lo que dice en español, el contenido del libro se mantiene, la portada ¡nada que ver!
Siempre a la caza de nuevos retos de investigación y siguiendo en la línea de mi proyecto científico para el 2009, encontrar la descripción de ZoomWorld que Raskin hace en el capítulo 6, me hizo proponerme hacer una estructuración en metodología DEIU de ese interfaz de usuario.
Indagando un poco más encontré que ZoomWorld es solo una parte del proyecto Archy, también iniciado por Raskin, que a su vez es un ejemplo entre varias interfaces basadas en el paradigma de ampliación o Zooming Interface Paradigm – ZIP.
El primer esfuerzo por construir un ZIP fue el realizado por Ken Perlin, Jim Hollan y Ben Bederson y se llama Pad++, además es el que está mejor documentado y el que se ha mantenido activo por más tiempo.
El mejor conocido, sin duda, es Google Maps y Google Earth, aunque se puede argumentar que no se trata estrictamente de un ZIP sino de una aplicación de técnicas de ZIP para un interfaz de aplicación. Eso es discutible.
De vuelta de nuevo al libro, Raskin presenta un interesante discusión sobre lo que él dice debería ser un Interfaz Humano, como un paso adelante a lo que se podría llamar simplemente interfaz humano-computador. “Una interfaz es humana si responde a las necesidades humanas y es considerada con las limitaciones humanas” en contraposición las interfaces han sido diseñadas tradicionalmente con el enfoque de atender primero las necesidades de las máquinas o los requerimientos de información de los sistemas o el modelo mental del programador. Hay que mejorar la enseñanza de los factores humanos y su aplicación en el diseño en las escuelas de ingeniería de software.
En el libro se tocan otros temas interesantes también, como el de la cognética – la ergonomía de las facultades cognoscitivas – o el de la definición de interfaz de usuario que me interesa particularmente y sobre el que espero escribir en otro artículo.
En resumen, se trata de un libro muy bueno, un auténtico clásico de la literatura de HCI y de usabilidad de sistemas interactivos. Me encantó especialmente un párrafo casi al final del libro, en el capítulo siete, donde se tocan temas diversos, hablando sobre las sofisticadas interfaces de los ambientes de programación modernos y su diferencia con las sencillas herramientas de programación antiguas:
Algo francamente maravilloso se ha perdido: en particular la retroalimentación inmediata que necesitan los humanos a fin de iterar con rapidez su camino hacia un programa efectivo. No soy tan ingenuo para pensar que podemos mantener la sencillez original por completo y alcanzar el nivel de complejidad de los programas que ahora se demanda, pero estoy seguro de que podemos hacerlo mucho mejor que lo que tenemos.
¿Por qué son tan aburridos los libros de programación?
Posted by Leonel in Ingeniería, Programación on 18 March 2009
El ciclo de programación son los pasos que se ejecutan iterativamente al programar.
Pero cuando se intenta hacer lo mismo con un libro de programación el resultado es muy diferente.
No creo que mi percepción que se deba a que la programación es una de mis grandes pasiones, ni tampoco a que en general se le considera un tópico “complicado”. Lo que creo es que los libros de programación están en general muy mal hechos.
Para empezar la programación es algo eminentemente práctico y por lo tanto no se aprende leyendo teoría sino programando. Usualmente se enseña algo de teoría, pero la relación es más o menos de 20% de teoría contra 80% de práctica. Siguiendo esta fórmula muchos libros de programación parecen una mezcla de 20% de libro de matemáticas y 80% de libro de instrucciones para armar muebles “hágalo Usted mismo”.
En el diseño se visualiza la estrategia a seguir para resolver el problema, usualmente con un algoritmo.
Como consecuencia cualquier libro de programación que uno tome del anaquel de una biblioteca probablemente está desactualizado en el lenguaje que utiliza aunque sus conceptos teóricos sigan vigentes la mayoría.
Tomar un libro de programación y pretender leerlo nada más significa que uno tendrá que negarse a poner en práctica inmediatamente los conceptos que están expuestos en él, lo cual no es sencillo porque los ejemplos abundan y no son como los de un libro de física, con el que basta tomar papel y lápiz para “practicar”, lo lógico con la programación es ir a la computadora y programar.
En la codificación se lleva el diseño a código en el lenguaje que se esté utilizando.
Por supuesto, para eso es más útil una referencia del lenguaje, con lo cual el libro de programación pierde buena parte de su razón de ser.
Hay que repensar la forma en que se estructuran los libros y los cursos de programación. Para empezar hay que abandonar completamente la idea de que se utilice exclusivamente un lenguaje concreto como herramienta de apoyo. Algunos lenguajes son mejores que otros para mostrar técnicas como recursión, estructuras de control, manejo de errores, tipos de datos, algoritmos básicos, manejo de números, construcción de interfaces de usuario, etc.
Las pruebas implican ejecutar el programa en variedad de escenarios.
Para evitar el problema de que el lector quiera probar cómo funciona el ejemplo hay que cambiar el enfoque y convertirlos en retos del tipo ¿qué hace este código? ¿Qué error tiene? ¿Dónde podría mejorarse? ¿Es eficiente al aumentar la cantidad de entradas? Este tipo de razonamiento inducido es más beneficioso que simplemente copiar el texto en la computadora y ejecutarlo.
Luego hay que centrarse en las competencias básicas de un programador: recorrer el ciclo de programación, diseñar un programa antes de codificarlo, utilizar patrones, leer y entender código que no ha sido escrito por él en un lenguaje que no es el que domina, encontrar errores y depurarlos, etc.
Por supuesto el enfoque no es el mismo si se trata de libros dirigidos a estudiantes de primaria, secundaria o universitarios; si la carrera está relacionada con Ciencias de la Computación o si la programación se toma como una materia auxiliar. Pero definitivamente creo que se puede hacer algo mejor que revisar tediosamente todas las posibles estructuras y comandos de un lenguaje particular, que es lo que hacen buena parte de los libros que conozco.
Corregir cada problema o mal funcionamiento encontrado y volver a empezar el ciclo.
Siempre he dicho que para cualquier ingeniero la habilidad de programar es tan básica como resolver ecuaciones o hacer un diagrama de fuerzas. La diferencia con los ingenieros de sistemas no es más que el enfoque y probablemente la intensidad. Así que tenemos una gran necesidad de buenos libros de programación, bien orientados y que puedan ser leídos con gusto aún 10 años después de haberse utilizado en un curso.
Algún día espero poder escribir un libro así.
Comentarios recientes