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.