Recently in Usabilidad Category

Si tu único aporte a esta vida ha sido escribir un documento, entonces tu aporte en esta vida es casi cero, si tu aporte fue criticar un documento, tu aporte tiende a cero por la izquierda.

Para escribir documentos solo hay que seguir un algoritmo, y lo entretenido de los algoritmos es inventarlos, descubrirlos e implementarlos, por algo dejamos su ejecución a los autómatas, porque ejecutarlos es aburrido.

Es mejor escribir una historia, una épica si quieres lograr cambios efectivos.

Los humanos somos adictos a las historias, nos fascinan, nos seducen y nos motivan.

Vean la propuesta de Joel Spolsky sobre cómo escribir una especificación funcional. Los casos de uso deben ser contados como historias.

Contar historias es difícil, porque es un arte superior, pero es más efectivo que escribir un documento que sólo termina acumulando polvo.

Por eso que hay que leer historias, como la de Gilgamesh, para aprender como se cuentan las historias. Hay que leer toda clase de historias, no sólo las que te gustan, hay que leer de todo, porque te enriqueces. 

Lo mejor, es que no hay un algoritmo para escribir historias, Joseph Campbell en toda su obra, apenas esbozó algunas heurísticas, que han sido aplicadas por grandes contadores de historias. Pero lo único que realmente funciona es escuchar o leer historias, y contarlas con pasión.

Los relatos son mejores que los informes de un comité y logran más cambios, porque las historias  nos llegan más. Como dice JC Baroux:

Gilgamesh el mayor rey de la Tierra, dos terceras partes dios y una humano, descubre que también va a morir, a pesar de todos sus esfuerzos y de todo su poder, y eso lo hace humano.

Para mí, eso es lo más interesante de este relato. Más de cuatro mil años después, la historia nos llega. Es una historia profundamente humana, con preocupaciones que resuenan del mismo modo hoy.

Somos tan humanos como ellos lo fueron, y eso es reconfortante en alguna parte. No sé qué parte, pero alguna parte...

Hace mil años atrás vi una demo de realidad aumentada, en que una joven interactuaba con un perro en una pantalla. De hecho, tengo un libro de 1990 que se llama Artificial Reality II, escrito por Myron W. Krueger, quién acuñó el término para denominar a la experiencia inmersiva en un ambiente interactivo (para diferenciarlo de la realidad virtual).

En ese libro se ven y explican como funcionan cosas como estas:

Bueno, eso ya está a un paso de dejar de ser investigación para poder instalarse en el living de nuestras casas, gracias al proyecto Natal de Microsoft.

Seguro ya han visto este video, y si no, los invito a verlo:

Antes de seguir, debo decir que para mi, las interfaces REST, o las API en el contexto de la Web 2.0, es decir, las APIque permiten hacer Mashups, por ejemplo, no son estrictamente una API, pero esta distinción es más bien semántica.

Pero, eso no importa mucho. Lo que sigue sirve para las APIs más tradicionales, y también para las APIs púbicas en el contexto de aplicaciones en la nube.

La GUI es para el usuario, la API es para el programador.

Tal como nos preocupamos de la interfaz de usuario, cuando diseñamos una aplicación, de modo que esta sea "usable", del mismo modo, si queremos que este sistema pueda expandir su funcionalidad, por parte de terceros, o si queremos que estos tengan acceso a sus servicios, entonces debemos proveer de una Interfaz para los programadores, también.

Si usted se dedica a ese esotérico arte del feng shui de la arquitectura de información, creo que va a entender la importancia del punto anterior. Una buena interfaz de usuario, es aquella que le facilita la interacción con el sistema al usuario. Del mismo modo, una buena API, es aquella que le facilita la labor al programador.

Entonces cuando diseñamos una API tenemos que ponernos desde la perspectiva del programador. De la persona que quiere usar nuestra API para extender las funcionalidades de nuestra aplicación, o quiere aprovechar los servicios de nuestra aplicación, pero para integrarlos en su propia aplicación o servicio.

¿Cuáles son los principios de diseño de una buena API?

La referencia, obligada en estos tiempos, es esta presentación de Joshua Bloch,  ingeniero d

e Google, quien nos presenta muy buenos principios de diseño de interfaces de programación.

Lo que sigue es más o menos un resumen de su charla, con algo de mi cosecha.

¿Estás seguro que quieres diseñar una API?

Antes de empezar, hay que tener en cuenta que es muy importante diseñar bien nuestras APIs, por lo siguiente:

• Las APIs terminan siendo uno de los activos más importantes para la compañía.
•  Los clientes invertirán fuertemente ya sea comprando tu API, escribiendo código para esta y aprendiéndo a usarla.
• Con el tiempo, el costo de dejar de usar una API se puede volver prohibitivo.
• Las APIs exitosas capturan clientes
• Una mala API resulta en una sobrecarga del área de soporte externo
• Las APIs públicas son para siempre, así que tienes sólo una oportunidad de hacerlas bien.
• Las APIs terminan convirtiéndose en uno de los grandes pasivos de la compañía.

• Debe ser fácil de aprender
• Debe ser fácil de usar, incluso sin documentación
• Debe ser dificil usarla mal
• El código que la use debe ser fácil de leer y mantener
• Debe ser suficientemente poderosa para satisfacer los requerimientos
• Fácil de extender
• Apropiada para la audiencia

El proceso de diseñar una API

¿Cómo procedemos a diseñar una API?

Primero, como siempre, hay que capturar los requerimientos, siempre con un alto grado de excepticismo ;). Recuerda, que siempre pueden haber mejores soluciones. Acá es importante elaborar buenos casos de uso.

Segundo, escribir una especificación, ojalá muy breve, una página es lo ideal. Es bueno mostrar esta especificación al máximo posible de personas. Mantener una especificación corta permite modificarla fácilmente, tras el feedback de las personas que revisan tu especificación. Es importante ir ganando confianza con la especificación, y en este punto es bueno escribir algo de código, que use la API, desarrollar casos de prueba, es importante ser lo más ágil en este punto.

Tercero, hay que tener las expectativas claras. No se puede agradar a todo el mundo, y por lo mismo, tienes que aceptar que es muy probable que tu API termine desagradando a todo el mundo igualmente. Es seguro que vas a cometer errores, sólo los años terminarán borrando estos errores, así que debes pensar que tu API evolucionará.

Principios generales de una buena API

1. Una API debería hacer una cosa, y hacerla bien. La funcionalidad de una API debe ser fácil de explicar.
2. Una API debe ser lo más pequeña posible, pero no demasiado
3. La implementación no debería impactar a una API. Los detalles de implementación confunden al usuario de una API, y por supuesto impiden la libertad de cambiar la implementación. Hay que tener cuidado de sobre especificar el comportamiento de los métodos de una API. Todo parámetro que se fije para sintonizar el desempeño de una API  es sospechoso.
4.  Minimizar la accesibilidad de todo, que es otra forma de plantear el viejo principio de ocultamiento de la información. Recuerden a Parnas, alta cohesión, pero bajo acoplamiento.
5. Los nombres importan, la API es un pequeño lenguaje. Los nombres deben ser, en gran medida, auto explicativos. Es importante ser coherente, las mismas palabras deben ser usadas en toda la API.
6. La documentación es importante. Como dice Parnas, la reutilización requiere de un buen diseño una buena documentación.
7. Considere las consecuencias en el desempeño de las decisiones de diseño de una API. Un buen diseño, normalmente coincide con un buen desempeño.
8. Las APIs deben coexistir pacificamente con la plataforma. Es bueno obedecer las convenciones de nombres de la plataforma. También es recomendable imitar las convenciones de los lenguajes en que implementamos la API (con la excepción de PHP, por supuesto).

Otros aspectos a considerar:

• No violar el principio del mínimo estupor. El usuario de una API no debe quedar sorprendido por el comportamiento de esta.
• Falla rápido. Ya hemos hablado de esto, las malas noticias es mejor decirlas pronto, es decir, hay que reportar los errores tan pronto ocurran.
• Cuidado con sobrecargar. Hay que tener cuidado cuando sobrecargamos el nombre de un método, sobretodo, hay que evitar las ambiguedades.
• Si no eres programador, pide ayuda a un programador para diseñar una API pública. Recuerda que las APIs son interfaces para ellos, y no se diseñan igual que las interfaces de usuario.
• El diseño de API no debe ser un trabajo de una sóla persona, aunque escribir las especificaciones, y las ideas pueden ser de una persona, es bueno que te asesores por terceros, y que pruebes con una amplia base de usuarios.

Los chistes gráficos son cortesía de Geek and Poke.

Los lectores habituales de este blog saben que no me gustan los captcha, pero la verdad es que me tienen aburrido los comentarios spam, se pierde bastante tiempo administrándolos, y me tiene cansado el tema.

Así que vamos a habilitar captchas, y vamos a usar el default de Movable TYpe, y espero que no les aparezca uno tan aberrante como este.

Incidentalmente, sin querer habilité el captcha hace unos meses atrás y creo que funcionó, aunque sospecho que demasiado bien, porque los comentarios llegaron casi a 0 :(

La verdad es que creo que hay otras opciones mejores, pero no tengo mucho tiempo por ahora para implementarlas, así que espero me disculpen, y si alguien sabe de una alternativa que funcione con movable type 4, que me deje una nota (si el captcha se los permite).

A mi me parece divertido que la gente reclame contra microsoft desde un PC con Windows XP, si linux les resuelve todos los problemas, ¿por qué no lo instalan?

Hay mucho de pose con respecto al tema del software libre, y también mucha ignorancia cuando se habla de tecnología.

Un ejemplo reciente de estos argumentos llenos de ignorancia es aquel que propone LaTeX como alternativa al formatoOOXML.

Bien, como fan de Knuth, y también de Leslie Lamport (sobretodo por su trabajo en computación distribuida), me siento con un cierto deber de explicar uno poco de que se trata esto de LaTeX, y por qué no es una alternativa a OOXML, y de paso ver si se aprovechamos de aportar algo de "cultura" al debate.

Primero, LaTeX es un conjunto de macros, y scripts que simplifican la composición de textos usando un sistema más general llamado TeX, inventado por nuestro querido Donald Knuth.

TeX corresponde a las letras griegas Tau, epsilon y Chi, y corresponde a la raiz griega TeX, como en la palabra griega tekné, que es la raiz de la palabra tecnología.

Así que esto de TeX es más que un sistema de composición tipográfica, es una manifestación de la filosofía de Knuth, con respecto a la relación entre arte y tecnología.

Sucede que a fines de los 70, Donald Knuth estaba revisando el segundo volumen de su obra magna, The Art Of Computer Programming (coloquialmente conocidoc como TAOCP). Insatisfecho con el resultado de las pruebas tipográficas, Knuth, una persona con un profundo sentido estético meditó y llegó a la conclusión de que el art de la tipografía digital consiste en ordenar 1's y 0's (tinta y no tinta) en un patrón apropiado. Así que se dijo, "Como científico en computación realmente puedo identificar 0's y 1's, así que algo puedo hacer al respecto".

Knuth emprendió un trabajo que tomó unos diez años, en que recibió la ayuda de expertos en tipografía, como Hermann Zapf, el famoso diseñador tipográfico.

El resultado de esos años es el sistema conocido como TeX.

La intención de TeX "es permitir la creación de libros hermosos, especialemente libros que contienen mucha matemática" (de la introducción al Tex Book).

Una de las características interesantes de TeX es que su código fuente no sólo es libre, sino que está hermosamente escrito, puesto que fue escrito usando Web y Tangle, un lenguaje que permite componer código que es agradable de leer, usando una técnica conocida como Literate Programming.

Aparte de TeX, Knuth escribió MetaFONT, un sistema que permite especificar y crear fuentes en formato Bitmap.

Knuth presentó los fundamentos de su trabajo a la AMS (American Math Society)

• Este software debía ser usado directamente por los autores (y sus secretarias) que realmente son los que saben de qué están escribiendo.
• Venía de uan fuente academica, y por lo tanto estaría disponible libremente, sin necesidad de pago monetario alguno (en ese tiempo no se preocuparon mucho sobre el tema del soporte).
• El sistema terminaría estando disponible en cualquier sistema operativo y sería diseñado de modo que los archivosde entrada serían portable.
• Además el sistema no sería WYSIWYG.

De hecho, ese es uno de los problemas que aún persisten con los sistemas WYSIWYG. Por ejemplo, pueden introducir una fórmula matemática en un documento word y ocurre que la mísma fórmula matemática se puede ver mal en otra parte del documento. Para que vamos a hablar de lo que pasa con Word en Windows, versus la versión en un Mac.

Knuth en este proceso de creación concibe una de las mejores abstracciones que hay en un sistema computacional, se trata de los conceptos de Glue y Boxes, elementos centrales de la composición en TeX. Para programar eficientemente en TeX hay que dominar estos dos conceptos, que juntos permiten resolver muchos (si no todos) los problemas tipográficos que se presentan en la publicación profesional.

El trabajo de Knuth en TeX no sólo fue revolucionario, sino que probablemente estableció el mejor sistema de composición de textos que se haya logrado.

A principios de los 80, Leslie Lamport, tenía ambiciones similares a las de Knuth, escribir una mega obra, the Great American Concurrency Book, y como Lamport era usuario de TeX decidió escribir un conjunto de macros para poder escribir su libro.

Así nació LaTeX, un "sistema de preparación de documentos", como lo llamó su autor. El prefijo La es simplemente las inicial de su autor, LaTeX es literlamente el TeX de Lamport.

Por años usé LaTeX en mi trabajo, y me divertí programando mis propias macros alternativas a las escritas por Lamport. Y seguiría usándolo si tuviera que escribir documentos con frecuencia, pero en realidad este sistema es ideal para publicaciones científicas, de hecho muchos journals exigen que los trabajos que se envían deben ir en LaTeX.

Pero en la práctica usar Word basta para escribir cartas, o informes. Pero en el mundo académico es ampliamente usado, probablemente porque tienen mucho más tiempo libre ;)

Como sea, la idea de LaTeX es despreocuparse de cómo va a lucir un documento para enfocarnos más en el contenido. El formato lo pone LaTeX, a través de una serie de plantillas pre definidas.

Por ejemplo, si quiero escribir un artículo debo escribir lo siguiente:

\documentclass[12pt]{article}
\usepackage{lingmacros}
\usepackage{tree-dvips}
\begin{document}
Este es un documento
\end{document}

El formato de como se va a ver este documento no es importante para el usuario de LaTeX. Lo que garantiza el sistema es que va a salir siempre igual. Si uno no contaba con un buen monitor podía gastar bastante papel realizando pruebas (algo que tampoco parece preocuparle mucho a los univesitarios).

Aunque con TeX se puede formatear cualquier cosa, hacerlo es un trabajo arduo, al final estás "programando tu texto". Está muy bien en ciertos ambientes, como el académico, pero no es práctico para las empresas o el servicio público.

Sí, existen herramientas que permiten trabajar en forma visual con TeX o LaTex, pero no son muy flexibles y sus resultados tampoco son tran satisfactorios.

Pero hay que enteder que TeX permite componer la tipografía de un documento, está pensado para eso. No esta pensado para interoperar en ambientes de negocios.

Pongámoslo de esta manera, tu puedes crear un documento en TeX y el output, el resultado de aplicar TeX (o LaTeX) sobre tu documento es otro documento en otro formato, que puede ser Postscript, PDF, HTML, Word, u otro. ¡De hecho, se puede generar archivos ODF con LaTeX!

LaTeX es el lenguaje donde describes lo que quieres escribir, te preocupas más del contenido (si te preocupa la tipografía "bajas" a TeX).

ODF por otro lado es un formato que no sólo contiene el texto, sino que integra con multiples fuentes, agrega anexos binarios, como imágenes, sonido, y permite interoperar con otros sistemas.

ODF formatea el texto, al igual que LaTeX, pero es la capacidad de interoperar con otros sistemas lo que lo hace diferente, y le da su potencia (y utilidad).

Por ejemplo, uno puede insertar un fragmento de una planilla de cálculo dentro de una presentación, o una diapositiva dentro de un documento de texto, e incluso colocar un vínculo a una película, y todo eso interactúa en forma dinámica. Puedes presionar un botón y gatillar que el resultado de una fórmula en una planilla de cálculo cambie el texto completo de una carta.

Otro tema que para lo cual TeX tampoco fue pensado es la firma electrónica, de hecho, ¿puede alguien decirme qué es lo correcto: aplicar la firma electrónica al output final de un documento LaTeX o a la fuente? Este problema es bastante interesante en si mismo y daría para armar todo un estándar o un comite para evaluarlo.

Ese tipo de interoperabilidad es la que solucionan formatos propietarios como los de Microsoft Office, o formatos abiertos, como ODF.

LaTeX está pensado para preparar documentos, TeX está pensado para componer documentos con una bella tipografía.

ODF es algo distinto, es un formato para transportar información, integrar multiples sistemas y tecnologías multimediales, y facilitar la ofimática.

Además al ser ODF un documento XML uno puede realizar infinitas transformaciones adicionales, lo que permite automatizar miles de procesos.

No, LaTeX (y TeX) siendo sistemas extraordinariamente valiosos no son adecuados para las necesidades de la ofimática, y para el manejo documental. Así que es mejor no confundirse en estos temas.

Una última cosa, si necesitas ayuda con LaTeX, o con alguna macro para TeX o MetaFONT, bueno, no me preguntes, ya no me acuerdo.

"Internet fue construida sin una manera de saber quien y a que te estas conectando. Estos límita lo que podemos hacer y nos expone a peligros crecientes. Si no hacemos nada enfrentaremos rápidamente una proliferación de episodios de robo y fraudes que acumulativamente erosionarán la confianza pública en Internet."

Como emprendedor centrado en el desarrollo de tecnologías de identidad el trabajo de Kim Cameron es importante para mí, pero creo que lo es para todos los que estamos preocupados de la privacidad, el uso y el abuso de la información personal, tanto en las transacciones comerciales, como en otros ámbitos tan diversos, como la libertad de expresión, y la protección de la privacidad.

Por ejemplo, debido a ciertos casos particulares se está discutiendo en la blogosfera sobre el anonimato de los comentarios. El tema es complejo, y como apunta Carlos, finalmente es decisión de cada cual. Pero hay espacios en que el anonimato no es deseable, puesto que queremos protegernos malos o desagradables "elementos". Siguiendo la analogía de considerar al blog como un símil de nuestra casa, entonces si llega un visitante me gustaría de quien se trata, porque si comete un acto vandálico, me gustaría poder denunciarle, y eventualmente, si comete un delito, puedo denunciarlo.

Sin embargo, también queremos un grado de privacidad, muchos de mis comentaristas dejan su email cuando hacen comentarios, porque confían en que no haré mal uso de esta información.

Investigando Las Leyes de la Identidad

"Tu identidad es tu posesión más valiosa. ¡Protéjela! Y si algo sale mal, entonces usa tus superpoderes".

En este blog emprenderemos una exploración a leyes de la identidad, y traduciremos el trabajo seminal de Cameron, que es probablemente uno de los más importantes que se han publicado en el último tiempo.