Feedback y UnifOrm!daD (Virus y diseño de interfaces - 3ra parte)

En el post anterior escribí acerca de los archivos de sistema y el problema de visibilidad. Así que continuando con los problemas planteados en Virus y diseño de interfaces, ahora le toca el turno al AutoRun. Creo que hay dos problemas con él:

El primero es un problema de feedback: cuando inserto un CD con autorun no tengo un feedback sobre el hecho que se esta por ejecutar un programa de forma automática y poder así evitar que eso suceda. Puedo evitar la ejecución apretando SHIFT, pero eso no es algo obvio para cualquier usuario. (aunque en Vista y el SHIFT funciona distinto - ver el comentario UPDATE más adelante).

Volviendo al problema planteado en el primer post: si al insertar el pendrive Windows me avisa que esta por ejecutar un programa, al menos sabría lo que esta pasando.

Pero... ¿Por qué Windows me indica con una ventana si inserto un CD con fotos o música, pero no me dice nada si inserto un CD con un instalador que se va a ejecutar? ¿No son acaso tareas con ciertas similitudes: en ambos casos estoy insertando un CD que quiero usar?

Esta cuestión de uniformidad es para mi el segundo problema.

Diferencias en el código que se reflejan en la UI

Aunque la tarea de usar un CD con fotos o uno con un instalador tengan muchas similitudes (al menos para mi son similares), son presentadas de forma distinta al usuario por una razón no tan obvia: a nivel API son cosas distintas.

En Windows XP se introdujo un API llamada AutoPlay cuyo objetivo más general es permitir la "auto ejecución" según el tipo de dispositivo (ver Using Hardware Autoplay). Creo que el AutoRun se pudo haber implementado sobre el API de AutoPlay, creando un handler para CDs con autorun.inf, pero por una cuestión "histórica" se mantuvieron como cosas separadas. (y aún hoy sigue generando confusión a los usuarios)

UPDATE: Estuve utilizando Windows Vista y si bien el SHIFT funciona distinto, el comportamiento por default para el autorun es mostrar una ventana como la del autoplay. Eso es de mi punto de vista un cambio positivo.

Conclusiones

A nivel programación hay algo interesante que surge de los últimos dos posts: El diseño del sistema a nivel programa se termina reflejando a nivel de UI.

Creo que ambos problemas de interfaz vienen de niveles más bajos:

• Los archivos con atributos de sistema y ocultos son un "hack" que viene desde DOS por la ausencia de un mecanismo mejor para crear constraints de autorización.
• La inconsistencia en la interfaz entre AutoRun y AutoPlay vienen de APIs distintos que no fueron "refactorizadas".

A nivel interfaz, la conclusión la voy a transcribir del libro "The Design Of Everyday Things" de Don Norman:

Design should:

• Make it easy to determine what actions are possible at any moment (make use of constraints)
• Make things visible, including the conceptual model of the system, the alternative actions, and the results of actions.
• Make it easy to evaluate the current state of the system.
• Follow natural mappings between intentions and the required actions; between actions and the resulting effect; and between the information that is visible and the interpretation of the system state.

In other words, make sure that (1) the user can figure out what to do, and (2) the user can tell what is going on.

Visibilidad y restricciones (Virus y diseño de interfaces - 2da parte)

En el post anterior mencione que "ocultar los archivos" era para mi un error de diseño. Voy a aclarar eso un poco más.

Ocultar la complejidad del sistema esta bien, por ejemplo: Ejecuto múltiples programas y no me interesa como funciona internamente el sistema operativo (SO) para permitirme hacer eso.

La misma idea aplica a los archivos:

Al usuario promedio no le interesa si el SO tiene que guardar cierta información en el disco para su funcionamiento interno. De hecho, esta bien que el sistema no me permita borrar fácilmente esa información (y evitarme así "hacer cagadas").

¿Entonces cual es el problema?

El problema es que no hay una relación entre el modelo conceptual expuesto al usuario y el modelo del sistema.

Voy a explicar esta frase con un ejemplo, supongamos una carpeta con un archivo:

Ahora marcamos"archivo.txt" como oculto y de sistema:

Pero en el Explorer no hay ningún indicador de que la carpeta contiene un archivo oculto:

A ver... y con la linea de comandos?

Tampoco. Y en las propiedades de la carpeta?

Ahora si. Y si lo abro con el Notepad? (no voy a poner la pantalla de eso, pero si hacen la prueba van a ver que pueden abrir y modificar el archivo normalmente).

El modelo del sistema es el siguiente:

No hay ninguna restricción especial sobre los archivos marcados como ocultos y de sistema.

Son los programas quienes tienen que interpretar estos atributos según sea necesario.

Por ejemplo quienes le dan un tratamiento especial a estos archivos son las herramientas de consola del sistema operativo y el Explorer, principalmente para evitar que usuarios inexpertos borren estos archivos accidentalmente.

Sin embargo la gran mayoría de los programas simplemente ignora estos atributos y no hay ninguna restricción de permiso sobre los mismos.

Pero el modelo expuesto al usuario es:

En el explorer y en la consola ejecutando "dir" veo todos los archivos que hay en mi maquina. Si la carpeta o el pendrive no tienen archivos entonces están vacíos.

Mas allá de la no visibilidad de los archivos, esperaría también que un archivo de sistema no pueda ser modificado directamente por cualquier herramienta.

Solución 1: Visibilidad

La solución más sencilla es aportar visibilidad al usuario. No es necesario mostrar los archivos para eso, simplemente indicar que hay archivos ocultos:

Y si queremos llevar la visibilidad un paso mas, es decir que no existan archivos ocultos, todavía tenemos el problema de evitar que el usuario "meta la pata"...

Solución 2: Visibilidad + Undo

Un buen diseño tiene que permitir que el usuario se equivoque (este articulo de la gente de Humanized explica eso con algunos ejemplos).

Si el usuario borra/modifica un archivo de sistema debería poder volver atrás fácilmente.

Lamentablemente en un SO esa vuelta atrás no es sencilla: y si borro un archivo que hace que el sistema no arranque más? Ok, no hay forma de hacer un undo sencillo para todos los casos, lo que nos lleva a otra solución...

Solución 3: Visibilidad + Restricciones

Otra forma de resolver el problema es simplemente haciendo que el usuario no tenga permiso para modificar archivos de sistema.

Si el usuario quiere borrar/modificar un archivo de sistema tiene que cambiar a un usuario con más permisos y por lo tanto tiene un indicativo muy fuerte por parte del sistema de: "mas vale que sepas lo que estas haciendo".

En el caso particular de Windows esto no siempre es posible: en el sistema de archivos FAT32 el único "permiso" es el de marcar un archivo como solo lectura.

Lo que nos lleva a otro tipo de restricción...

Solución 4: Visibilidad + Standards (o mejor dicho Restricciones "culturales")

Para darle al usuario la información de: "no deberías tocar esto al menos que sepas lo que estas haciendo", también se puede usar una "restricción" cultural. Es decir estandarizar donde estan los archivos de sistema.

Por ejemplo a nadie se le ocurre borrar la carpeta C:\WINDOWS o C:\Archivos de Programas.

Pero Windows no sigue siempre estos "standards", por ejemplo hay archivos de sistema en el directorio raíz y que salvo por los atributos de oculto y de sistema no se diferencian del resto.

El atributo de sistema es una restricción "cultural", sin embargo tiene algunos problemas de visibilidad:

• Si un archivo es marcado como de sistema, se muestra de la misma forma en el Explorer.
• No hay forma de diferenciar un archivo oculto de sistema de uno que solo tiene el atributo de oculto.

Solución 5: La combinación de las anteriores

Salvo por la solución de facilitar el Undo, Unix hace una combinación de las soluciones anteriores:

• Los archivos de sistema solo pueden ser modificados por un usuario con permiso de root
• "Culturalmente" los archivos que son de usuarios están en el directorio "/home". El resto de las carpetas tiene un significado especial.

En Unix también hay configuraciones que se guardan en archivos "ocultos". Pero acá el "modelo conceptual del sistema" es presentado de una forma más directa al usuario: se sigue la convención que los archivos que empiezan con punto no se muestran por default en las listas de archivos. Sin embargo ninguna herramienta trata a estos archivos de forma especial (como sucede con los archivos de sistema y las herramientas de la linea de comandos en Windows).

Conclusiones

• El modelo expuesto al usuario debe ser coherente con el modelo del sistema
• No es necesario exponer toda la complejidad al usuario mientras el usuario pueda construirse fácilmente una idea de lo que esta pasando.

Algunas herramientas que uno tiene para lograr eso: visibilidad, restricciones y "standards".

Virus y diseño de interfaces (1era parte)

"Che sabes que la compu me anda raro, que puede ser?"

Como "compunerd" que soy es típico que me hagan estas consultas. En general la gente piensa que como uno estudia computación conoce absolutamente todo, desde hardware hasta las configuraciones mas rebuscadas de windows. Estas ultimas semanas me toco revisar la PC de mi novia y de unos amigos. Ambas maquinas tenían problemas parecidos. En una había un programa llamado Disk Knight que se copia por medio de los pendrives (no es un virus maligno, pero es igual de molesto). Y en la otra un virus cuyo nombre no me acuerdo. Una característica de estos virus es que no son rebuscados programas en assembler con código para mutar y ocultarse en archivos exe. Si no que son programas simples (es decir pueden ser creados por cualquier persona con un minimo de conocimiento de programación) que aprovechan algunos errores de diseño de Windows. Lo que me interesaría escribir en esta serie de posts es acerca de esos errores de diseño: cuales son y que se puede aprender de ellos. Los problemas Ambos virus utilizaron las siguientes características de Windows:

• Archivos ocultos del sistema
• Autorun
• La entrada "Run" de la registry (para ejecutarse al inicio)

Archivos ocultos y de sistema Windows tiene flags para marcar a un archivo como oculto y de sistema, y evitar así que un usuario común y corriente lo borre accidentalmente. Estimo que el 90% de los usuarios -yo me incluyo en ese numero- tiene activada la opción de ocultar archivos de sistema. ¿Por que? Simplemente por que la mayoría de los archivos de sistema (thumbnails y otras hiervas) molestan cuando uno quiere manejar los archivos en la PC. (si selecciono fotos para copiar no quiero estar copiando siempre el Thumbs.db). Usando estos atributos un virus puede copiarse a un directorio/pendrive sin ser visto y sin usar ninguna técnica complicada de stealth (que por lo general es dectectada por un anti-virus). Desafíos:

• Evitar que el usuario cometa un error que rompa el sistema
• Ocultar ciertos niveles de complejidad más bajos del sistema

Autorun El autorun parece buena idea para las PC de hogar: si quiero jugar un juego solo pongo el CD como si fuese una consola y listo. Pero prácticamente todos los juegos de PC que requieren instalación. Así que el autorun se limita a ejecutar el setup, por lo que pierde un poco la gracia de la idea original. Además requiere de cierta "fe" por parte del usuario: si tengo activado autorun e inserto un CD tengo que saber de antemano que programa estoy queriendo ejecutar. Otro problema es que Windows permite que cualquier unidad de disco tenga autorun! (Prueben de poner un autorun.inf en el C: y vean como se comporta ahora el icono de Mi Pc). Desafíos:

• Detectar según el contexto cual es la intención del usuario. (quizás quiero ver los archivos en el CD, no instalar la aplicación)
• Como hacer que el usuario tenga el control sin hacer más complejo el uso del sistema.

La entrada "Run" de la registry El problema de la entrada "Run" en la registry es que uno nunca termina sabiendo que es todo lo que se ejecuta al iniciar Windows. Muchas aplicaciones colocan iconos en el system tray, otras como el Office o el Acrobat tienen "caches" para hacer que el programa se levante más rapido, otras programas para detectar nuevas versiones y otras para cosas que en realidad deberían ser servicios del sistema. Desafíos:

• Intention revealing: como hacer que el usuario sepa que es necesario o no para que el sistema funcione bien.

En el próximo post me voy a dedicar a analizar el problema de los "Archivos ocultos" es decir como:

• Evitar que el usuario cometa un error que rompa el sistema
• Ocultar ciertos niveles de complejidad más bajos del sistema

Dibujando el logo para el 1er. Congreso Argentino de Smalltalk

Hace unos días Hernán me pidió si podía hacer un logo para el congreso Argentino de Smalltalk que él esta organizando junto con Leandro Caniglia. Hoy acabo de terminar la primer versión del logo (no sé si será la versión final, todo depende de los comentarios de Hernán y Leandro). El dibujo no es nada original: es prácticamente una copia de la portada original de la Byte. El problema es que crear ilustraciones de este tipo que sean originales no es un trabajo menor: requiere de muchas pruebas con diferentes ideas, es decir requiere de un tiempo que no tengo :( Les comparto la primer versión junto con algunos tips para los que quieren aprender Illustrator: Tips para aprender Illustrator:

• Es bueno aprenderse las combinaciones de tecla para cada una de las herramientas. La mayoría de las herramientas de la paleta se pueden seleccionar con una sola tecla, por ejemplo A - point selection, V - direct selection, P - path, etc. La ventaja: uno puede tener una mano en el teclado y la otra en lapiz/mouse. La diferencia entre laburar así y estar seleccionando las opciones de la paleta es enorme.
• Teclas importantes: BARRA ESPACIADORA no importa que herramienta se este usando la barra muestra la mano y permite mover el canvas (esto es así en todas las aplicaciones de Adobe), Z - Zoom (yo uso mucho el zoom cuando estoy trabajando).
• Aprender a utilizar: Live Paint, Clipping Masks y las herramientas para combinar figuras del path finder... ahorran mucho tiempo.
• Me costo mucho darme cuenta como hacer un gradient transparente (odio la herramienta de gradient de Illustrator, es muy incomoda!), hasta que encontré esta pagina.
• Uno puede aprender Illustrator de forma intuitiva... sin embargo es bueno ver algunos tutorials en la web, la UI de Illustrator tiene algunas cosas que no están a primera vista por ejemplo:
• En la mayoría de los lugares donde se puede ingresar valores tipo 1px uno puede hacer cuentas en diferentes unidades: 1px+5pt.
• La mayoría de las herramientas se comportan diferente cuando uno presiona Alt, Ctrl ó Shift (o la combinación de estas). Asi que vale la pena hacer la prueba
• Sitios con tutorials:
• PixelPerfect: Es un programa de TV vía web. La mayoría de los episodios son sobre Photoshop, pero hay algunos de Illustrator (muy recomendable)
• Illustrator Techniques: tiene algunos tutorials on-line.

El Smalltalk que no miramos

Usualmente los dialectos recomendados para empezar con Smalltalk son: Visual Works y Squeak, sin embargo rara vez alguien recomienda mirar GNU Smalltalk. ¿Por qué? Simplemente por que a primera vista GNU Smalltalk (gst) luce muy GNU y poco Smalltalk, es decir no hay un entorno grafico por default, si no herramietas de linea de comandos. Y por esa razón nunca tuve interés en mirarlo. Hace unos días anunciaron la puesta on-line de su nuevo sitio web (antes tenían una pagina muy escueta que tampoco motivaba demasiado). Mirando el sitio hubo un par de cosas que llamaron la atención e hicieron que me dieran ganas de ver este proyecto:

• Soporte para embeber St en otras aplicaciones: esto es realmente importante por que fue lo que llevo a que lenguajes como Python o Lua se hagan conocidos (bueno Lua no es tan conocido...)
• Soporte para continuations (lo que para envidia de algunos significa que en teoría es posible portar Seaside a este dialecto de St)
• GUI toolkit con soporte para GTK: no me gusta GTK, pero que hayan logrado tener eso es importante, especialmente por que Squeak no tiene soporte para UIs nativas. (salvo por algún que otro proyecto que nunca se llegó a terminar).
• Namespaces: mientras que en las listas de Squeak siguen discutiendo (1, 2, 3 y quizás más veces) como hacer la implementación perfecta de namespaces, gst ya los tiene (aunque no sean "perfectos"). En mi opinión esto aunque parezca una boludez es importante para poder compartir módulos y usar diferentes frameworks...
• Ejecución de St desde la linea de comandos: es también otra cosa que parece boba y que en VisualWorks y Squeak se puede hacer con paquetes adicionales. Las diferencia: no hay que configurar imágenes especiales para eso y como gst es un paquete instalable en la mayoría de los linux basados en Debian, lo convierte en una buena alternativa como lenguaje de shell scripting.

Es por eso que mientras escribo esto estoy bajando Xubuntu para usarlo con VMWare y probar gst (desinstale la partición de Linux que tenia por que la mayoría de las veces uso la PC con programas que solo funcionan en windows). Creo que hay un paquete de gst para Cygwin... pero no me gusta Cygwin (para mi usar directamente un unix es mucho mejor que lidiar con el engendro mutante de cygwin). En fin en cuanto tenga tiempo de probar gst voy a actualizar el blog con algunos comentarios.