Bruce Tognazzini
Addison Wesley, 1996
331 páginas

El libro está construido sobre la base de las colaboraciones de Bruce Tognazzini para la revista de desarrolladores de Apple. En las columnas respondía a las preguntas que le planteaban los que creaban software para la empresa de la manzana. El libro responde a cuestiones que son comunes a todos los interfaces. Todas las columnas acaban con un principio. Por ejemplo, use objetos nuevos con nuevas apariencias si quiere mostrar una nueva funcionalidad.

Trata sobre los problemas comunes que siente un humano frente a un ordenador. Por ejemplo, divide lo que es pensamiento y lo que es intuición.

Son temas variados, no es sólo para especialistas en test. No habla de webs, pero puede ser una buena base. No presenta principios en el aire sino respuestas concretas a preguntas concretas.

Tog on Interfaces proporciona muchísimos consejos muy prácticos.
Es un libro sobre Interfaces de software con mucha sabiduría extraída de Apple. Pero yo creo que todos tenemos mucho que aprender de Apple.

Partes Principales

-Primeras letras -El Proceso del Diseño -Las teorías de Goldilocks -El Interface natural: principios de diseño -Más correos electrónicos -Superando las barreras para el éxito

, , , , , ,

Andy Beaumont, Dave Gibbons, Jody Kerr, Jon Stephens
Glasshaus, 2002
227 páginas

Este libro está escrito por varios autores. Cabe preguntarse si es también para lectores distintos. Es decir, tiene tres capítulos para arquitectos de la información y cuatro capítulos para programadores. En el país de los hombres orquesta puede ser útil que uno sepa hacer de todo. Si se piensa que una web es un trabajo de equipo, hay libros
para arquitectos de la información que hablan de menús y libros para programadores. También están en inglés como este.

No dice nada sobre arquitectura de la información que no digan Peter Morvile, Christina Wodtke o Jakob Nielsen.

Cuando se habla de los usuarios, no se usan estadísticas o estudios. Tiene la ventaja de que no aburre con datos. En el mundo de la usabilidad, hay cosas discutibles como que los links tienen que ir
subrayados. Los autores ignoran estudios sobre las ventajas de la navegación a la derecha.

Hay cuatro capítulos en el libro que tratan sobre código. No todos sobre el mismo: hay capitulos sobre programación en Flash y sobre programación en JavaScript. Se quedan un poco antiguos. El libro es anterior a Mozila y AJAX. Aunque Mozila pueda parecerse a Netscape.  No se habla de Safari. Los trucos son interesantes.

Es difícil leer un libro de código. Está pensado para leer junto a un ordenador y tecleando. No se me ocurre nada más incómodo que eso.

Capítulos principales

Reglas para un buen diseño de menús – Arquitectura de la Información para menús Menús en Java Script básicos – Menús con lenguaje de script avanzados y DHTML Menús en Flash – Menús dinámicos del lado del servidor

, , , , ,

Ellen Isaacs y Alan Walendowski
(Cómo pueden colaborar los diseñadores y los ingenieros para construir tecnología
colaborativa)
336 páginas

El título es muy prometedor; las primeras 93 páginas son realmente esclarecedoras; el resto del libro es bastante ramplón.

La primera parte de la obra se dedica a dar ejemplos sobre la dificultad de uso o problemas de usabilidad en distintos tipos de software. Hay consejos interesantes en estos capítulos. Se traen a colación ejemplos ricos y variados. Es una novedad y parece atractivo el hecho de que esté escrito por una diseñadora de interfaces y un desarrollador de software.

La segunda parte de Designing from both sides of the screen (yo no he encontrado una versión en castellano) es la narración del desarrollo concreto de una aplicación específica. En ese sentido, el libro no es muy distinto de un archivo de Microsoft Project. Puede ser enriquecedor para jefes de proyecto y apasionados. En mi opinión, las conclusiones de ese trabajo son demasiado específicas como para aplicarlas a otros proyectos. En otros ambientes, las condiciones pueden ser muy diferentes.

Hay que leer la narración en orden porque los primeros capítulos explican conceptos que luego no se vuelven a definir. Es terminología propia de la obra.

, ,