Archive for category Usabilidad
Educación gratuita en línea
Posted by Leonel in Educación, Interfaz de Usuario, Internet, Sociedad, Usabilidad on 28 May 2012
El profesor Scott Klemmer anuncia el curso gratuito en línea sobre Interacción Humano-Computador.
La educación superior gratuita en línea está cobrando auge en todo el mundo. También la educación técnica gratuita. Una parte de la explicación de este fenómeno la da Ruti Polachek en su excelente artículo “¿Está Bajo el Índice de Empleo? ¿Y qué tal si le Enseñamos Ciencias de Computación a las Masas?” (“Employment Down? Why Not Teach Computer Science to the Masses?”). Su lógica es sencilla: “En la raíz de todo está la educación. Si se le enseña a programar a un millón de personas el desempleo se reducirá” y aún más: “No hay que enseñarle a un millón de personas a programar, mejor aún es enseñarle a programar a un millón de profesores – y podríamos estar levantando una generación entera de avances tecnológicos”. Hace sentido.
En el caso del curso de HCI (Human Computer Interaction) en el que me matriculé, el soporte tecnológico viene provisto por Coursera, una empresa que está promoviendo cursos en línea para diversas universidades, incluyendo Princeton, Stanford, California, Berkeley, Michigan-Ann Arbor y Pensilvania. Pero no es la única, está también Udacity, que recientemente hizo historia al ofrecer un curso en línea de introducción a la inteligencia artificial en el que se inscribieron más de 160,000 participantes. MITx empezó ofreciendo los cursos del MIT y recientemente se le unió Harvard en la iniciativa edX. Carnegie Mellon tomó la delantera hace algunos años con OLI.
Y la lista continúa con emprendimientos fuera del ámbito universitario como la muy exitosa Khan Academy y otras. (Lamento no tener a mano más enlaces de iniciativas similares en Español y en Latinoamérica, pero investigaré para incluirlas).
Bueno, de momento solo me queda desear encontrarme con alguno de los amables lectores de este blog como compañero de clase en las aulas virtuales. Pero si deciden no matricularse, trataré de ir contando algo de la experiencia en mi blog personal en Tumblr.
El departamento de Ingeniería Simple
Posted by Leonel in Ingeniería, Interfaz de Usuario, Sociedad, Temas generales, Trabajo en equipo, Usabilidad, Video on 14 August 2010
Descubrí el sitio de TED (www.ted.com) y su excelente contenido de videos hasta hace poco, unos meses apenas. Se trata de una impresionante colección de charlas cortas, de menos de 18 minutos la mayoría, sobre temas variados, planteados de forma accesible y dictadas por personas exitosas de todos los ámbitos: deportivo, científico, social, empresarial, académico, cultural, industrial, educativo, etc.
Las charlas están organizadas por categorías lo cual facilita localizar los temas que a uno le puedan interesar. La categoría de ingeniería cuenta con 21 charlas al momento de escribir esta entrada, entre ellas una particularmente divertida y llena de sentido común, con una llamada a la acción, de Rory Sutherland: “Sweat the small stuff” título que hace referencia al dicho común norteamericano “don’t sweat the small stuff” (“no sudes por las cosas pequeñas”) para decir que no hay que preocuparse demasiado por las cosas pequeñas, lo que Sutherland rebate diciendo que precisamente hay que tratar de encontrar esas cosas pequeñas que tienen un gran impacto, a las que nadie le pone atención bajo el supuesto equivocado de que para que se obtengan beneficios grandes se debe gastar una cantidad enorme de dinero.
Los cuadrantes propuestos por Rory Sutherland, el de abajo a la derecha todavía no tiene nombre
En una gráfica donde el eje “x” representa el efecto de las cosas y el “y” el costo de ellas, Sutherland explica los cuatro cuadrantes resultantes. Arriba a la derecha están las cosas con grandes efectos y que cuestan mucho dinero, a las que llama “estrategia” y que son las que se supone que hacen los directivos y gerentes que ganan más dinero y tienen más presupuesto.
A la izquierda arriba están las cosas de poco impacto pero que cuestan mucho dinero, que arrancan risas de la concurrencia cuando Sutherland las llama “consultoría”. Lo “trivial” cae en el cuadrante de abajo a la izquierda pues no cuesta nada pero no tiene ningún efecto.
Abajo a la derecha están las cosas con muchísimo impacto pero sin costo, de las que usualmente nadie se ocupa porque erróneamente se piensa que hay que ocuparse de situaciones que requieran soluciones acorde al salario percibido y presupuesto disponible, de forma que si solucionar un problema no consume una cantidad significativa del presupuesto asignado entonces eso es un signo de que a eso no hay que ponerle atención.
Cosas como poner más sillas en los centros de atención al público, actualizar las noticias en el sitio Web de la organización, poner un rótulo adecuado que oriente a quienes visitan por primera vez una oficina, establecer un mecanismo sencillo, claro y conocido para obtener un nuevo bolígrafo, etc., etc.
Este cuadrante es tan poco atendido que Sutherland indica que no existe una palabra adecuada para referirse a él en inglés. Entre los comentarios de la charla se sugiere que “elegancia” podría ser lo más indicado o “simplicidad”. Las empresas deberían tener a alguien con mucho poder pero bajo presupuesto encargado de atender esas cuestiones, alguien a quien Sutherland llama el “director jefe de detalle”.
Una de las razones por las que me encanta esta charla es porque creo que el nombre correcto del cuadrante podría ser “ingeniería simple” y el encargado empresarial de este aspecto debería ser el “gerente de ingeniería simple”, aunque claro, lo del nombre es lo de menos, lo importante sería atender la idea.
La charla dura solo 12 minutos y 37 segundos, tiene subtítulos en español y en otros idiomas incluyendo inglés y definitivamente vale la pena verla.
Rory Sutherland: Sweat the small stuff. La charla dura 12 minutos y 37 segundo y vale la pena verla.
¿Qué son y para qué sirven las aplicaciones portables?
Posted by Leonel in Internet, Programación, Temas generales, Usabilidad on 5 February 2010
Por Juan Manuel
3 Instancias de IE de diferente versión corriendo al mismo tiempo gracias a que están disponibles como aplicaciones portables
Por aplicación portable o portátil en informática definimos a aquel programa o conjunto de programas que pueden ejecutarse en una computadora sin necesidad de realizar instalación alguna de sus componentes en el sistema de directorios del sistema operativo instalado.
Típicamente al instalar alguna aplicación por ejemplo Microsoft Office, debemos realizar una serie de pasos para tener el conjunto de programas que lo componen funcionando, como son:
1.- Tener a la mano el paquete o asistente de instalación del sistema de programas que componen Microsoft Office.
2.- Iniciar el instalador, ingresar la clave de instalación, seleccionar los programas que queremos instalar y ingresar la ruta donde queremos instalar el paquete de programas.
3.- Esperar a que el asistente copie todos los archivos necesarios al disco duro de la computadora y registre los programas en las entradas de menús del sistema, asocie los programas con determinados tipos de archivos, etc., para que sean completamente funcionales.
Durante el proceso de copiado de los archivos al disco de la máquina el asistente los acomodará en diferentes partes del mismo, por ejemplo archivos de programa, system32, etc., resultando muy complicado determinar cuales archivos han sido copiados a tal o cual localización pues generalmente estos antes de ser copiados se encuentran en archivos comprimidos y tal vez encriptados si se trata de una aplicación de tipo comercial. Además resulta difícil exportar esa aplicación ya instalada a otra computadora pues no se conoce con precisión que archivos en el disco duro la componen ni donde se encuentran ubicados, peor aún podría haber dependencias al registro de Microsoft Windows que si no se encuentran presentes al momento de mover todo el conjunto de programas a un nuevo destino no funcionarían correctamente.
Entonces para que una aplicación pueda ser designada “portable” debe evitar que todo el conjunto de programas/archivos que la componen sean distribuidos en el conjunto de directorios del sistema operativo en curso y de ser posible no requerir la existencia de determinados registros en las bases de datos del mismo y tampoco depender de la existencia de ciertos programas, archivos u otra información previamente instalada en la computadora destino para poder funcionar correctamente.
Lamentablemente esto no siempre se cumple pues muchos de los programas denominados “portables” están programados en Java o VB.Net los cuales requieren que se encuentre previamente instalada la máquina virtual que los hace funcionar, pero minimizando este problema nos encontramos con verdaderos programas que son capaces de funcionar en cualquier computadora (por ahora solo probado con Microsoft Windows instalado) únicamente copiando a una carpeta en el disco duro los archivos que componen la aplicación, pero realmente no es necesario pues la mayoría de ellos puede funcionar desde una memoria o pendrive usb, lo cual los hace útiles para casos necesarios como por ejemplo rescate del sistema o ejecutar sistemas operativos alternos al actual sin tener que instalar absolutamente nada en el disco duro de la computadora.
Ahora veamos el proceso de instalación de la versión portable de OpenOffice a nuestro sistema operativo en curso, aclarando que la aplicación OpenOffice requiere un proceso de instalación similar a la de Microsoft Office pero con algunos ajustes es posible generar una versión que no requiere de instalación en el disco duro, pudiendo ejecutarse sin problemas desde un pendrive.
1.- Tener a la mano el paquete o asistente de instalación del sistema de programas que componen OpenOffice.
2.- Iniciar el instalador, ingresar la ruta donde queremos instalar el paquete de programas y esperar a que el asistente copie todos los archivos necesarios al disco duro de la computadora, con la ventaja que una vez copiados todos ellos podemos simplemente copiar la carpeta donde fueron instalados a otra ubicación (carpeta, o incluso otra computadora) y nuestra aplicación con todos los programas que la componen es funcional al 100%, es decir no se requiere hacer uso del asistente de instalación de nuevo.
Por supuesto no todo podría ser ventajas en las aplicaciones portables, estas tienen ventajas y desventajas que se resumen en esta lista:
| Ventajas: | Desventajas: |
|---|---|
| 1.- Poder migrar fácilmente la instalación de una aplicación portable a otra computadora manteniendo la configuración previa. | 1.- Algunos programas requieren Java o .Net Framework instalado previamente para funcionar. |
| 2.- Si es necesario formatear y reinstalar el sistema operativo no es necesario reinstalar nuevamente los programas, basta con copiarlos nuevamente al disco duro de la computadora para tenerlos funcionando tal cual estaban antes del formateo. | 2.- La mayor parte de ellos no son auto actualizables, teniendo que esperar a que se libere la siguiente versión portable y teniendo que bajar el asistente nuevamente para reemplazar la instalación anterior. |
| 3.- No utilizan el registro de Microsoft Windows. | |
| 4.- Poder utilizar al mismo tiempo varias versiones del mismo programa sin conflictos por la instalación (véase la imagen de éste post, la cual muestra a los navegadores IE 5.5, 6 y 7 ejecutándose al mismo tiempo sin conflictos debido a la instalación). |
¿Son legales?
Si, pero dependen de la versión del programa original, si el programa es freeware no hay ningún problema en crear una versión portable, podemos decir lo mismo de programas con licencias libres como GPL, BSD, etc., pues la misma licencia permite la distribución gratuita como comercial de los mismos. Sin embargo, existen diversos programas que en la red se distribuyen como “portables” teniendo como sinónimo “gratis”, cuando en realidad son de carácter comercial y se le han hecho modificaciones para ejecutarlos sin necesidad de instalación y clave de activación, por lo cual si los usamos estamos incurriendo en el delito de piratería; por lo que es recomendable mirar previamente la licencia del programa original antes de buscar su versión portátil.
¿Dónde conseguirlos?
En la red abundan los sitios de descargas de programas portables sin costo alguno, una buena opción son los siguientes enlaces:
http://portableapps.com/apps
http://appsportables.blogspot.com/
http://www.pendriveapps.com/
¿Cómo crear aplicaciones portables?
Existen en la red varios programas para transformar cualquier aplicación común (instalable) en portable, pues estos analizan el programa y miran todas las dependencias y automáticamente hacen los cambios necesarios para crear un ejecutable que pueda ser exportado sin problemas a otra computadora, a través de éste link http://www.taringa.net/posts/ebooks-tutoriales/1990237/Crear-Programa-Portable-%28Portatil%29.html podemos darnos una idea del uso de un software llamado Thinstall que nos será de ayuda para crear nuestras propias versiones portables.
En resumen:
Las aplicaciones portables son aquellas que no requieren de una instalación en disco duro para funcionar, lo cual las hace candidatas a llevar a todas partes en un pendrive usb y trabajar con ellas con las configuraciones que se hagan a las mismas. También presentan la enorme ventaja de que al no requerir instalación pueden servir para reinstalar con rapidez los programas de uso común en la computadora cuando se reinstala el sistema operativo. Sin embargo no todas las aplicaciones portables existentes en la red son 100% legales pues muchas de ellas en realidad son comerciales y al crear una versión portátil se está violando los derechos de la misma con lo cual nos podemos hacer acreedores a sanciones administrativas. Valen la pena utilizarlas.
Fuentes de consulta para más información
Aplicación portátil
http://es.wikipedia.org/wiki/Aplicaci%C3%B3n_port%C3%A1til
Crear programa portátil
http://www.taringa.net/posts/ebooks-tutoriales/1990237/Crear-Programa-Portable-%28Portatil%29.html
¿Programas portables?
http://es.answers.yahoo.com/question/index?qid=20090315075526AALroU7
Ventajas o beneficios de los programas portables
http://darkub.wordpress.com/2008/05/08/ventajas-o-beneficios-de-los-programas-portables/
Los mejores ingenieros
Posted by Leonel in Diseño, Ingeniería, Trabajo en equipo, Usabilidad on 8 September 2009
Todo proyecto de ingeniería debe tener un diseño
Sería un tanto pretencioso decir que hay ciertas características bien identificadas que definen a los mejores ingenieros, sobre todo porque cuando se presentan circunstancias especiales – como catástrofes, emergencias o problemas muy difíciles – los factores de peso pueden ser múltiples. Sin embargo, como se verá más adelante, existen cuatro virtudes que marcan una diferencia tan palpable que no es posible ignorarlas y en particular hacerlo en la formación de los futuros ingenieros trae consecuencias negativas.
La fórmula para “formar” a los mejores ingenieros del mundo parece sencilla: matemáticas, física, química, todas de buen nivel, cursos exigentes en el área técnica y profesional de la rama y un complemento que cubra las principales habilidades de gerencia y administración que tan necesarias resultan para el trabajo en el mundo empresarial actual.
Pero esa fórmula tiene un fallo: no ayuda por sí misma a obtener ciertas habilidades para las que la clave no es el contenido formativo, sino la práctica constante, el enfoque de los ejercicios, las situaciones a las que como parte de cada curso se expone a los alumnos, etc.
Sin más, esas cuatro virtudes o habilidades especiales tan deseables en un ingeniero son: el trabajo en equipo, cuidado por la seguridad, respeto por el usuario y pasión por el diseño. Ninguna puede considerarse más prioritaria que otra, puesto que usualmente son inherentes y concomitantes a cualquier proyecto.
El trabajo en equipo ni siquiera es una opción en ingeniería
Trabajar en equipo en ingeniería ni siquiera es una opción, pero que siempre se tenga que hacer no significa que siempre se haga bien. Hay mejores formas de trabajar en equipo y hay vicios que se le oponen directamente, como el protagonismo individualista, la inconsistencia en la planificación o en la definición de objetivos, las fallas en la comunicación, etc.
Muchos ingenieros deben aprender a trabajar en equipo en su vida profesional – por no haberlo aprendido en sus años de formación en la escuela de ingeniería – y mejorar cada vez más en ese aspecto a costa de perder eficiencia si no lo hacen.
Pero esa no es una opción en materia de seguridad donde las omisiones y negligencias pueden resultar en graves pérdidas económicas o humanas.
El mejor ingeniero en seguridad es el que la tiene presente a partir del mismísimo inicio de cada ciclo de ingeniería, desde el planteamiento de un proyecto, pasando por sus etapas de análisis y diseño, el respeto por las normas establecidas de seguridad y el recurso a principios más generales cuando las buenas prácticas no están bien identificadas, es lo que garantiza una solución segura para los usuarios finales.
En último caso, los riesgos no cubiertos, por cualquier razón, deben quedar claramente consignados en la documentación del proyecto.
Por tanto, la seguridad en ingeniería debe ser también un hábito del ingeniero. Ahora bien, la adquisición de un hábito puede hacerse en los años de formación, en ambientes donde los riesgos se controlan mejor, o puede hacerse en el ejercicio profesional con lo que el costo del aprendizaje corre por cuenta de los usuarios finales. Obviamente es mejor crear el hábito en los años de formación.
Pero esto no se logra si la seguridad se confina en la formación a uno o varios cursos independientes del resto – que usualmente se colocan al final de la carrera – como si la falta del hábito de la seguridad pudiera subsanarse con puros conocimientos teóricos. Es mejor que en cada proyecto, sin importar el curso o el contexto en el que se ejecuta, se exija al estudiante que cuide los aspectos de seguridad. Esta sí es una forma efectiva de crear el hábito. Requiere creatividad de parte de los catedráticos y evaluadores identificar los requisitos de seguridad en todo proyecto. Para encontrar indicios, se puede hacer la pregunta ¿qué tendría que tener este proyecto para no comprometer la seguridad de sus usuarios si fuera implementado en el mundo real?
Los productos de ingeniería tienen usuarios que merecen respeto
De la misma forma se puede promover el respeto por el usuario final. En buena parte de los cursos de ingeniería se pierde el interés por la usabilidad de los productos finales, probablemente porque se enfatiza la calidad técnica de la solución, es decir sus mecanismos internos de funcionamiento, su eficiencia en el proceso, el costo mínimo, etc. No es difícil olvidar que alguien será el usuario final de la solución y que la eficiencia técnica no sirve de mucho si el artefacto es imposible de usar, sin mencionar que el costo de soporte de un mecanismo complicado para el usuario se eleva hasta anular cualquier ahorro en su fabricación.
En relación al diseño pareciera una redundancia recalcar lo importante que es. Todo proyecto de ingeniería debería empezar su etapa de construcción con un diseño bien estructurado. El hecho de que no suceda así es indicativo de que algo falta para hablar de verdadera ingeniería.
Nuevamente el énfasis se traslada demasiado rápido al reto técnico de la construcción, con todas sus variables, materiales, tecnología y trabajo práctico y se obvia o disculpa el paso y la evaluación de un buen diseño, hasta convertirse en algo habitual, es decir, un vicio, el vicio de no diseñar.
Más que inculcar el hábito lo que la escuela de ingeniería debería lograr es despertar en el futuro profesional una pasión tal por el diseño que nunca pueda plantearse ni remotamente empezar una etapa de construcción sin un diseño bien definido.
Usabilidad de los Rótulos en las Carreteras
Posted by Leonel in Ingeniería, Usabilidad on 13 April 2009
Este rótulo está cerca de Cocales en Suchitepéquez. Nombres largos como Santiago Atitlán se comprimen, lo que dificulta aún más su lectura.
Y una vez más pude comprobar el lamentable estado de esas carreteras.
Pero que arreglen las carreteras es menos complicado que cambiar una práctica incorrecta y hasta perjudicial, porque está casi tan arraigada en la ingeniería de las carreteras como la procesión en el alma del devoto cargador: escribir los rótulos en mayúscula.
Desde los primeros textos que leí sobre factores humanos (ver por ejemplo El Factor Humano, 14 MB) aprendí que la clave está en conocer las capacidades humanas y adaptar los productos de ingeniería para que el usuario no se vea limitado o constreñido por el artefacto, ya que uno de los fines de la ingeniería debe ser solucionar los problemas prácticos de la vida y por lo tanto hacerla más sencilla, no más complicada.
Y por como funciona la visión humana se conoce, desde hace bastante tiempo, que lo que está escrito combinando correctamente las mayúsculas y las minúsculas, siguiendo las reglas de ortografía, que por algo existen, es mucho más fácil de leer que si se usa exclusivamente mayúsculas.
Algunos ejemplos de rótulos en un formato muy parecido al que se usa en las carreteras en Guatemala. A la derecha se ven los contornos de las letras, que es en lo que se enfoca el sentido de la vista para leerlos. Se nota la dificultad para leer las palabras que se deriva de la similitud en las formas y contornos.
Pero esto no se termina de entender o de conocer y los rótulos en las carreteras siguen en mayúscula. Los problemas que se derivan de esta práctica son varios:
- Reducción de la visibilidad del mensaje ya que hay que acercarse más para leer en mayúscula que en texto combinado.
- Pérdida de tiempo, valiosos segundos que al ir conduciendo en carretera pueden ser cruciales, porque leer en mayúsculas es más lento.
- Confusiones por letreros mal entendidos (se toma un camino equivocado).
- Reducción de la velocidad del tráfico para poder leer los letreros.
- Distracción de la atención del conductor que intenta leer el rótulo.
La razón de que sea más fácil leer textos que combinan correctamente mayúsculas y minúsculas que los que están solamente en mayúscula yace en la forma en que preparamos y procesamos la información visual con el sentido de la vista.
Los mismos rótulos de arriba solo que en minúsculas. En los contornos a la derecha es mucho más sencillo identificar diferencias puntuales entre una y otra palabra, la forma de cada palabra ayuda a leerla completa más rápido.
Disponemos de células sensitivas especializadas en colores, los conos, y otras especializadas en intensidad de luz, formas y movimientos, los bastones. En la lectura usualmente atendemos poco al color, ya que se usa uno sólo por lo general, y mucho a la forma y al contorno. Es un hecho conocido que no leemos interpretando letra por letra sino palabras completas, que reconocemos por su figura. Al escribir todo en mayúsculas se pierde esa valiosa información de figura y se mete todo en un extraño rectángulo que requiere interpretar letra-por-letra.
En resumen, además de arreglar las carreteras hay que hacerlas más usables, con adecuada señalización y rótulos escritos adecuadamente. Hacer caminos bien asfaltados o de trazo perfecto puede ser una buena obra técnica, pero no es suficiente para hacerla usable. Para esto se requiere tomar en cuenta los factores humanos.
Jef Raskin y las Leyes del Diseño de Interfaces
Posted by Leonel in Diseño, Ingeniería, Interfaz de Usuario, Programación, Usabilidad on 8 April 2009
El libro de Jef Raskin se llama en español Diseño de Sistemas Interactivos: la Importancia de Nuestra Relación con las Computadoras
La semana pasada terminé de leer “Diseño de Sistemas Interactivos” del difunto Jef Raskin (1943 – 2005). Este libro es una traducción de “The Humane Interface: New Directions for Designing Interactive Systems”, y confieso que nuevamente me sucedió lo mismo que con el libro “Presos de la Tecnología” (traducción de “The Inmates are Running the Asylum” de Alan Cooper), es decir, me enteré de las excelentes referencias del escrito hasta que revisé su nombre en inglés. Es asombroso lo mucho que puede cambiar el nombre de un libro cuando lo traducen al español.
Curiosamente ambos libros los compré en rebaja por menos de Q30.00 en la librería del IGA. Tengo que ir más seguido a comprar allí.
Volviendo al libro, me llamó la atención la analogía que Raskin hace entre las leyes de la robótica, postuladas por Isaac Asimov, y las que él considera que deberían ser las leyes del diseño de interfaces:
Primera: Una computadora no debe causar daño al trabajo del usuario, o, por su inacción, permitir que el trabajo del usuario reciba algún daño.
Segunda: Una computadora no debe hacer al usuario perder tiempo u obligarlo a trabajar más de lo que es estrictamente necesario.
Y no hay tercera, al parecer no hace falta más, con solo estas dos podríamos encontrar miles de ejemplos de interfaces fuera de la ley.
El libro también da muchísimos principios de diseño, algunos muy generales, como “los usuarios establecen el ritmo de una interacción”, y otros muy prácticos como “si un control debe operarse siempre, (o nunca) no lo proporcione”.
Esta es la portada de la versión en inglés que dice algo totalmente diferente a lo que dice en español, el contenido del libro se mantiene, la portada ¡nada que ver!
Siempre a la caza de nuevos retos de investigación y siguiendo en la línea de mi proyecto científico para el 2009, encontrar la descripción de ZoomWorld que Raskin hace en el capítulo 6, me hizo proponerme hacer una estructuración en metodología DEIU de ese interfaz de usuario.
Indagando un poco más encontré que ZoomWorld es solo una parte del proyecto Archy, también iniciado por Raskin, que a su vez es un ejemplo entre varias interfaces basadas en el paradigma de ampliación o Zooming Interface Paradigm – ZIP.
El primer esfuerzo por construir un ZIP fue el realizado por Ken Perlin, Jim Hollan y Ben Bederson y se llama Pad++, además es el que está mejor documentado y el que se ha mantenido activo por más tiempo.
El mejor conocido, sin duda, es Google Maps y Google Earth, aunque se puede argumentar que no se trata estrictamente de un ZIP sino de una aplicación de técnicas de ZIP para un interfaz de aplicación. Eso es discutible.
De vuelta de nuevo al libro, Raskin presenta un interesante discusión sobre lo que él dice debería ser un Interfaz Humano, como un paso adelante a lo que se podría llamar simplemente interfaz humano-computador. “Una interfaz es humana si responde a las necesidades humanas y es considerada con las limitaciones humanas” en contraposición las interfaces han sido diseñadas tradicionalmente con el enfoque de atender primero las necesidades de las máquinas o los requerimientos de información de los sistemas o el modelo mental del programador. Hay que mejorar la enseñanza de los factores humanos y su aplicación en el diseño en las escuelas de ingeniería de software.
En el libro se tocan otros temas interesantes también, como el de la cognética – la ergonomía de las facultades cognoscitivas – o el de la definición de interfaz de usuario que me interesa particularmente y sobre el que espero escribir en otro artículo.
En resumen, se trata de un libro muy bueno, un auténtico clásico de la literatura de HCI y de usabilidad de sistemas interactivos. Me encantó especialmente un párrafo casi al final del libro, en el capítulo siete, donde se tocan temas diversos, hablando sobre las sofisticadas interfaces de los ambientes de programación modernos y su diferencia con las sencillas herramientas de programación antiguas:
Algo francamente maravilloso se ha perdido: en particular la retroalimentación inmediata que necesitan los humanos a fin de iterar con rapidez su camino hacia un programa efectivo. No soy tan ingenuo para pensar que podemos mantener la sencillez original por completo y alcanzar el nivel de complejidad de los programas que ahora se demanda, pero estoy seguro de que podemos hacerlo mucho mejor que lo que tenemos.
El ciclo de ingeniería
Posted by Leonel in Diseño, Ingeniería, Usabilidad on 22 March 2009
Las cuatro actividades principales del ciclo de ingeniería: analizar, diseñar, construir, evaluar.
En este artículo, “Usability Engineering Turns 10”, publicado en la revista especializada Interactions de la ACM, Butler explica en qué consiste la ingeniería de la usabilidad y por qué puede considerarse una rama de la ingeniería con todo derecho.
Su argumento básico es que sigue el ciclo de ingeniería. Hasta ese momento la usabilidad era para mi algo así como la aplicación de la teoría conocida sobre factores humanos, computadoras y usuarios para construir sistemas que fueran fáciles de usar y de entender, eficientes y satisfactorios. Pero no la entendía como una ingeniería.
Tampoco estoy seguro de que yo entendiera bien cuál es la esencia de la ingeniería, y eso a pesar de que para ese entonces llevaba ya más de 3 años de haberme graduado y más de 10 de haber cerrado ingeniería y estaba estudiando la maestría.
El ciclo de ingeniería consiste en una serie de actividades que se realizan iterativamente en cada proyecto. En mayor o menor medida el ingeniero las planifica y ejecuta una o varias veces si es necesario, de acuerdo a la naturaleza del proyecto.
Para algunos proyectos de ingeniería el ciclo se ejecuta una sola vez, pero en otros, especialmente en los de ingeniería de sistemas, el ciclo puede recorrerse varias veces hasta alcanzar la solución. Se construyen múltiples prototipos que pueden desecharse hasta llegar a la versión final.
En el diseño se plantea la solución a implementar. A pesar de que la solución puede ser de común aplicación en la industria o para el tipo de problema que se intenta resolver, la adaptación que se requiere para las circunstancias concretas puede implicar una innovación considerable. Si la solución es novedosa entonces resulta innovadora por sí misma. Así que todo diseño de ingeniería siempre implica innovación.
Luego inicia la construcción. Tanto el diseño como la construcción son etapas bien específicas para cada rama de la ingeniería, no se ejecutan igual si se trata de un proyecto de ingeniería química o de ingeniería mecánica y definitivamente no con las mismas perspectivas. Se puede decir que la construcción es la parte administrativa de un proyecto de ingeniería, ya que implica planeación, organización, dirección y control, que son las cuatro funciones administrativas comúnmente aceptadas. Dependiendo del proyecto la construcción puede resultar la etapa más larga.
En la evaluación se hace un examen de cómo se llevó a cabo el proyecto, si se resolvió el problema que se había planteado y si se hizo de una forma efectiva y eficiente. Puesto que no es conveniente dejar esta etapa exclusivamente para el final, ya que ayuda a identificar errores y efectos negativos que es importante resolver tan pronto como sea posible, es común que las evaluaciones se hagan con cada etapa parcial del proceso de construcción.
El ciclo se cierra cuando del resultado de la evaluación se desprenden nuevos problemas que requieren nuevamente de análisis, diseño, construcción y evaluación.
Algunos autores definen un ciclo de ingeniería con más actividades principales de las que se plantearon aquí. A mi me parece que estas cuatro especifican muy bien lo esencial de cualquier ciclo de ingeniería y que de hecho identifican lo que podríamos llamar el método de ingeniería, pero eso será tema de otro artículo.
Encabezado del artículo de Butler, publicado en 1996 en la revista Interactions de la ACM.
Ya es tiempo de dejar el diskette
Posted by Leonel in Interfaz de Usuario, Usabilidad on 12 March 2009
El floppy de 3 1/2
Hace unos días, caminando por los pasillos entre cubículos de las oficinas donde trabajo, me di cuenta que en el escritorio de alguien habían unos diskettes (disquettes o floppies) y me pregunté inconcientemente que para qué querría alguien usar esos discos hoy en día.
Lo más extraño fue que al poco tiempo me di cuenta de que casi todos seguimos usando esos artefactos arcaicos, no en su forma física, sino como un pequeño dibujito, muy bien conocido, al que llamamos “ícono de guardar”.
Este bien podría ser uno de esos casos en los que algo se sigue usando no porque sea bueno sino porque la fuerza de la costumbre es tal que nos obliga a continuarla y a no considerar siquiera la posibilidad del cambio.
Office 2007 con diskette
Revisé cuidadosamente y aún las aplicaciones más recientes que tengo disponibles siguen usando ese ícono: Microsoft Office 2007, Adobe Reader 8.0, y otros. Nadie se atreve a cambiarlo porque los resultados para la usabilidad del producto podrían ser negativos.
Cuando los disquettes pasaron de ser de 8 pulgadas a 5 ¼ no hubo problema porque prácticamente nadie usaba GUIs – Graphical User Interface – y por tanto no habían íconos. El primer GUI de gran difusión fue el de la Mac, lanzada al mercado en 1984, hace 25 años, y cuando le siguió Windows de Microsoft, la transición del disco de 5 ¼ a disco de 3 ½ no fue problema, básicamente se cambió de color al ícono, de negro a azul o gris, sin que se avizorara inconveniente alguno para los usuarios finales.
Pero con la introducción masiva de las memorias USB la transición no fue tan simple. Hubo un tiempo, entre 1995 y el 2000, en que no estaba claro cuál sería el sucesor del diskette o siquiera si habría sucesor.
Para guardar un PDF en IE se hace clic en un diskette
Los discos compactos o CD-ROM, no fueron aceptados masivamente por lo complicado de su selección a la hora de comprarlos – había que elegir entre varias opciones y uno nunca estaba seguro de cual comprar, si la R o la RW o cualquier otra – y al momento de querer guardar en ellos había que recurrir a un programa especial que se tomaba su tiempo hasta para agregar un solo archivo.
Así que nunca vimos un ícono de guardar con forma de CD-ROM y si lo vimos no nos acordamos.
Las memorias USB solucionaron el problema de la facilidad de uso, eran fácilmente aceptadas por los sistemas operativos más modernos – salvo Windows 98 que requería instalar los drivers – y se integraban transparentemente al sistema de archivos.
Omnipresente diskette
Pero no hemos visto íconos con forma de memoria USB por un problema básico: ¿Qué forma tiene una memoria USB?
El ícono de guardar se debe asociar fácilmente con el dispositivo en que se guarda, para que el usuario intuya la operación que se realiza al presionarlo. Pero si la imagen no es identificable entonces se compromete la intuitividad. ¿Resultado? Nadie se atreve a poner un ícono de guardar con forma de memoria USB.
Lo mismo pasa con los discos duros. Como usualmente no se ven, tampoco se conoce qué forma tienen.
El floppy sigue saludable
Para mí, la solución sería no tener ícono de guardar, de hecho no tener siquiera el concepto de archivo. Los archivos son un concepto arcaico relacionado con cómo se guarda la información en la computadora y yo no soy el primero que opina que los usuarios finales no deberían tener que preocuparse por cómo guarda la computadora la información. Jeff Raskin ya lo decía y otros también.
Pero como nadie se atreve a cambiar algo a lo que se supone que todos ya estamos acostumbrados, seguimos teniendo diskettes, lo mismo que teclados QWERTY cuando desde hace mucho tiempo se sabe que el DVORAK sería mucho mejor, seguimos con teclas que ya no se usan como “Scroll Lock”, “Pause/Break”, “SysRq” y la mayoría de las “Fx” (F1 a F12).
Bueno, para ser honesto tengo que reconocer que Microsoft implementó un cambio radical en su interfaz de Office 2007 y lo hizo sin mirar atrás, o sea, sin incluir una opción para regresar al interfaz anterior. El diskette demostró su fortaleza y su ícono aparece con todo su esplendor. Si esto es bueno o malo no lo sabría decir.
Intentar hacer un ícono de guardar que se pueda asociar con memorias USB no es la mejor opción, pero como parece que tendremos ese ícono presente en nuestras computadoras por largo rato, ¿qué tal si ideamos uno mejor?
Comentarios recientes