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.
Muy copado el artículo Diegote.
ResponderBorrarQue tal Diego, me parece muy buena idea esta serie de artículos.
ResponderBorrarAl respecto del artículo en cuestión mi opinión sobre esto es que el hecho de que el sistema necesite crear archivos para usos internos debería ser transparente al usuario. y me pregunto: porque un usuario debería querer hacer algo con un archivo del sistema? en la situación ideal me parece que el usuario no debería siquiera ver las carpetas de Windows, Archivos de Programa, etc.
Quizás ni siquiera necesitarían saber que existen los archivos :)
Saludos
Gabriel
Gabriel, gracias por el comentario!
ResponderBorrarY muy buena tu pregunta... me obligo a re veer lo que escribí. :)
Coincido con vos en que lo ideal es que las complejidades técnicas no interfieran con la tarea que tiene que hacer el usuario. (es decir por que tengo que preocuparme de los archivos!)
Y aunque suene contradictorio con lo que escribí, también creo que el usuario no debería hacer nada con un archivo de sistema.
No es que los archivos de sistema estén mal, para mi la falla es esta:
Aunque la UI oculte muchas complejidades el SO, debería permitirle al usuario evaluar cual es el efecto de sus acciones.
El caso que origino los posts es el siguiente:
El usuario inserta un pendrive y se instala un programa no deseado. (el proximo post le toca al autorun :) ). Pero cuando se fija en el contenido del pendrive, no hay nada! 0 files.
Como se ejecuto eso? Como sé si fue el pendrive u otra cosa? Seguro fue algún mail que abrí por que el pendrive esta vacío.
Si oculto totalmente a existencia de los archivos de sistema al usuario, entonces tengo que hacer que el sistema se comporte de forma tal la existencia o no de los mismos no me afecte (por ejemplo si borro el Thumbs.db todo sigue funcionando igual). Si la existencia de los mismos me afecta de alguna forma, lo mejor es dar un indicativo de que están (aunque no los pueda tocar).
Un caso de algo similar que me viene a la cabeza es el iPod:
Los temas son guardados en una base de datos, que es manejada por iTunes y no se puede tocar.
Pero aun así cuando se ve la barra de espacio libre en el disco, iTunes muestra en color naranja el espacio ocupado por los archivos de sistema... por que?
Por que si me compre un aparato que en la caja decía 1GB y veo solo 970MB, mi primer pregunta va a ser donde fueron a parar los 30MB que faltan.
Otro argumento en contra de lo que escribí es: bueno tanto lio entonces usa el Total Commander y problema resuelto.
Eso es cierto, pero volviendo a lo que origino el post, creo que con un indicativo visual algunos virus simples que se aprovechan de los archivos ocultos y el autorun serian menos probables, por que el usuario común quizás se daría cuenta más rápido de donde esta el problema.
Saludos, y de nuevo gracias por el comentario, je! esta bueno saber que hay alguien leyendo del otro lado :)
Diego.-