Embed Size (px)
Citation preview
INSTITUTO POLITECNICO NACIONAL
UNIDAD PROFESIONAL INTERDISCIPLINARIA DE
INGENIERÍA Y CIENCIAS SOCIALES
Y ADMINISTRATIVAS.
Sección de Estudios de Posgrado e Investigación.
Un análisis de usabilidad del escritorio
de Ubuntu y algunas mejoras.
TESIS
QUE PARA OBTENER EL GRADO DE
MAESTRO EN CIENCIAS EN INFORMÁTICA.
PRESENTA
Ing. Edgar Daniel Sánchez Muñoz.
Director de la tesis:
Dr. Mauricio J. Procel Moreno.
MÉXICO D.F. 14 DE SEPTIEMBRE DE 2012
Índice General
Índice de figuras ............................................................................................................ v
Resumen ..................................................................................................................... vii
Abstract ......................................................................................................................viii
Introducción .................................................................................................................. 1
Capítulo 1 Interfaz de usuario .................................................................................... 3
1.1 Tipos de interfaz de usuario ............................................................................................. 3
1.2 Evolución de la interfaz gráfica de usuario ........................................................................ 7
1.3 Usabilidad ..................................................................................................................... 16
1.3.1 Importancia de la usabilidad ........................................................................................................... 17
1.3.2 Atributos de la usabilidad ............................................................................................................... 18
1.4 La ingeniería de la usabilidad ......................................................................................... 19
1.4.1 El modelo del proceso .................................................................................................................... 20
1.4.2 Fases del modelo de proceso de la ingeniería de la usabilidad ...................................................... 20
1.4.2.1 Prototipado ............................................................................................................................. 20
1.4.2.2 Evaluación ............................................................................................................................... 23
1.4.2.2.1 Métodos de indagación ................................................................................................... 24
1.4.2.2.2 Métodos de Test .............................................................................................................. 27
1.4.2.3 Ingeniería de software ............................................................................................................ 30
1.4.2.3.1 Análisis de requisitos ....................................................................................................... 30
1.4.2.3.2 Diseño .............................................................................................................................. 36
1.5 Modelo de proceso de reingeniería de software ............................................................. 46
1.5.1 Análisis de inventarios .................................................................................................................... 47
1.5.2 Reestructuración de documentos................................................................................................... 47
1.5.3 Ingeniería inversa............................................................................................................................ 47
1.5.3.1 Ingeniería inversa para comprender datos ............................................................................. 48
1.5.3.2 Ingeniería inversa para comprender el procesamiento .......................................................... 48
1.5.3.3 Ingeniería inversa de interfaces de usuario ............................................................................ 49
1.5.4 Reestructuración............................................................................................................................. 49
1.5.4.1 Restructuración de código....................................................................................................... 50
1.5.4.2 Restructuración de datos ........................................................................................................ 50
1.5.5 Ingeniería directa ............................................................................................................................ 50
1.5.5.1 Ingeniería directa de interfaces de usuario ............................................................................. 52
Capítulo 2 Distribución Ubuntu y el proyecto GNOME .............................................. 53
2.1 Antecedentes GNU/Linux .............................................................................................. 53
2.1.1 El proyecto GNU ............................................................................................................................. 53
2.1.2 El kernel Linux ................................................................................................................................. 56
2.1.3 Distribución GNU/Linux .................................................................................................................. 58
2.2 GNU/Linux en el mercado actual .................................................................................... 59
2.3 Ubuntu y su filosofía...................................................................................................... 63
2.3.1 Mark Shuttleworth y “The Warthogs” ............................................................................................ 63
2.3.2 “La humanidad hacia los demás” .................................................................................................... 64
2.3.3 Objetivos de Ubuntu ....................................................................................................................... 64
2.3.3.1 Objetivos tecnológicos ............................................................................................................ 64
2.3.3.2 Objetivos filosóficos ................................................................................................................ 65
2.3.3.3 Objetivos de conducta y el código de conducta ...................................................................... 65
2.3.3.4 “Bug #1” .................................................................................................................................. 66
2.4 El proyecto GNOME ....................................................................................................... 67
2.5 Editor de configuraciones gconf ..................................................................................... 68
2.5.1 Repositorio de gconf ....................................................................................................................... 69
2.5.1.1 Fuentes de configuración de gconf ......................................................................................... 70
2.5.1.2 Esquemas de gconf .................................................................................................................. 71
2.5.1.3 Archivos de definición de esquemas de gconf ........................................................................ 72
2.5.2 Demonio de gconf ........................................................................................................................... 73
2.5.3 Herramientas para la línea de comandos y su editor gráfico ......................................................... 73
Capítulo 3 Análisis y diseño de la propuesta de Mejora. ........................................... 76
3.1 Análisis de inventarios ................................................................................................... 76
3.2 Análisis de requisitos ..................................................................................................... 80
3.2.1 Análisis etnográfico ......................................................................................................................... 80
3.2.2 Análisis de implicados ..................................................................................................................... 81
3.2.3 Clasificar a los usuarios ................................................................................................................... 81
3.2.4 Identificación de objetos ................................................................................................................ 82
3.2.5 Características de la plataforma de ejecución ................................................................................ 82
3.2.6 Objetivos de usabilidad................................................................................................................... 82
3.2.7 Requisitos funcionales y no funcionales ......................................................................................... 84
3.3 Diseño .......................................................................................................................... 85
3.3.1 Análisis de tareas y modelo conceptual ......................................................................................... 85
3.3.1.1 Análisis de tareas y modelo conceptual del Reloj ................................................................... 85
3.3.1.2 Análisis de tareas y modelo conceptual del Panel .................................................................. 89
3.3.1.3 Análisis de tareas y modelo conceptual de la barra de menú ................................................. 95
3.3.1.4 Análisis de tareas y modelo conceptual de los iconos especiales en el Escritorio .................. 97
3.3.1.5 Análisis de tareas y modelo conceptual de la barra de título. .............................................. 102
3.3.1.6 Análisis de tareas y modelo conceptual del Menú principal ................................................ 110
3.3.2 Estilo ............................................................................................................................................. 112
Capítulo 4 Construcción de la solución ................................................................... 113
4.1 Modificaciones al Reloj ................................................................................................ 113
4.1.1 Ingeniería inversa.......................................................................................................................... 113
4.1.1.1 Ingeniería inversa para comprender datos ........................................................................... 113
4.1.1.2 Ingeniería inversa para comprender el procesamiento y de interfaz de usuario ................. 114
4.1.2 Ingeniería directa .......................................................................................................................... 114
4.2 Modificaciones al Panel ............................................................................................... 118
4.2.1 Ingeniería inversa.......................................................................................................................... 118
4.2.1.1 Ingeniería inversa para comprender datos ........................................................................... 119
4.2.1.2 Ingeniería inversa para comprender el procesamiento y de interfaz de usuario ................. 119
4.2.2 Ingeniería directa. ......................................................................................................................... 120
4.3 Modificaciones a la Barra de Menú .............................................................................. 128
4.3.1 Ingeniería inversa.......................................................................................................................... 128
4.3.1.1 Ingeniería inversa para comprender datos ........................................................................... 128
4.3.1.2 Ingeniería inversa para comprender el procesamiento y de interfaz de usuario ................. 128
4.3.2 Ingeniería directa. ......................................................................................................................... 129
4.4 Modificaciones al Escritorio ......................................................................................... 135
4.4.1 Ingeniería inversa.......................................................................................................................... 135
4.4.1.1 Ingeniería inversa para comprender datos ........................................................................... 135
4.4.1.2 Ingeniería inversa para comprender el procesamiento y de interfaz de usuario ................. 136
4.4.2 Ingeniería directa .......................................................................................................................... 136
4.5 Modificaciones a la Barra de Título .............................................................................. 141
4.5.1 Ingeniería inversa.......................................................................................................................... 141
4.5.1.1 Ingeniería inversa para comprender datos ........................................................................... 141
4.5.1.2 Ingeniería inversa para comprender el procesamiento y de interfaz de usuario ................. 142
4.5.2 Ingeniería directa .......................................................................................................................... 142
4.6 Modificaciones al Menú Principal ................................................................................ 164
4.6.1 Ingeniería inversa.......................................................................................................................... 164
4.6.1.1 Ingeniería inversa para comprender datos ........................................................................... 164
4.6.1.2 Ingeniería inversa para comprender el procesamiento y de interfaz de usuario ................. 164
4.6.2 Ingeniería directa. ......................................................................................................................... 165
Evaluación ................................................................................................................. 171
Tasa de tareas completadas satisfactoriamente ................................................................................... 171
Valoración de tareas .............................................................................................................................. 171
Tiempo en tareas ................................................................................................................................... 172
Valoración del sistema ........................................................................................................................... 172
Conclusión ................................................................................................................. 173
Anexo 1 ..................................................................................................................... 175
Reporte de la Primer Fase de Pruebas de Usabilidad ............................................................................ 180
Reporte de la Segunda Fase de Pruebas de Usabilidad ......................................................................... 186
Ejemplo de las pruebas de usabilidad ................................................................................................... 192
Bibliografía ............................................................................................................... 197
v
Índice de figuras
Ilustración 1.1 Interfaz de lenguaje natural. __________________________________________________________________________ 3
Ilustración 1.2 Interfaces de pregunta respuesta. _____________________________________________________________________ 4
Ilustración 1.3 Interfaces de menús. ________________________________________________________________________________ 5
Ilustración 1.4 Interfaz de llenado de formas. ________________________________________________________________________ 5
Ilustración 1.5 Interfaz de línea de comandos. ________________________________________________________________________ 6
Ilustración 1.6 Interfaz gráfica de usuario del escritorio de la distribución Ubuntu. ___________________________________________ 7
Ilustración 1.7 La estación de trabajo on-line system mostrando monitor CRT, mouse, teclado y botones de control. ________________ 9
Ilustración 1.8 La computadora Xerox Alto desarrollada por Xerox en 1973. _______________________________________________ 10
Ilustración 1.9 Una versión mejorada de la computadora Xerox Alto corriendo el entorno Smalltalk. ___________________________ 10
Ilustración 1.10 La computadora Star mostrando símbolos para notaciones científicas. ______________________________________ 11
Ilustración 1.11 La computadora Lisa de Apple. ______________________________________________________________________ 12
Ilustración 1.12 La computadora Macintosh de Apple. ________________________________________________________________ 13
Ilustración 1.13 Microsoft Windows 1.0 mostrando el menú de cada aplicación en su propia ventana. __________________________ 13
Ilustración 1.14 Amiga Workbench desarrollada por Commodore International. ____________________________________________ 14
Ilustración 1.15 Interfaz Arthur, donde se muestra el dock para poner aplicaciones más usadas. _______________________________ 14
Ilustración 1.16 La interfaz gráfica del sistema operativo NeXTStep mostrando la “X” para cerrar una aplicación. _________________ 15
Ilustración 1.17 La interfaz gráfica Windows 95. _____________________________________________________________________ 15
Ilustración 1.18 La interfaz gráfica Aqua mostrando el efecto Expose. ____________________________________________________ 16
Ilustración 1.19 Modelo del proceso de la Ingeniería de la usabilidad_____________________________________________________ 20
Ilustración 1.20 Pequeña diferencia entre la Ingeniería del software y la Ingeniería de la usabilidad. ___________________________ 31
Ilustración 1.21 Representación gráfica del análisis de una tarea con el método HTA. _______________________________________ 39
Ilustración 1.22 Diagrama de transición de estados para realizar un Check-in y Check-out de una habitación de hotel. ____________ 42
Ilustración 1.23 Diagrama de estados UML que demuestra los estados en que se encuentra un usuario de una biblioteca. __________ 43
Ilustración 1.24 Diagrama de actividad UML que demuestra la lógica para beber café. ______________________________________ 43
Ilustración 1.25 Modelo del proceso de la reingeniería de software.______________________________________________________ 46
Ilustración 1.26 Proceso de la ingeniería inversa. _____________________________________________________________________ 48
Ilustración 2.1 Sistemas operativos usados por supercomputadoras en Noviembre de 2011. __________________________________ 61
Ilustración 2.2 Tendencia del uso de GNU/Linux en supercomputadoras. __________________________________________________ 61
Ilustración 2.3 Porcentaje del uso de GNU/Linux en computadoras personales. _____________________________________________ 62
Ilustración 2.4 Puntos de popularidad por clic al día para cada distribución. _______________________________________________ 63
Ilustración 2.5 Interfaz de gconf-editor. ____________________________________________________________________________ 74
Ilustración 3.1 Interfaz de Ubuntu 10.04 usando GNOME 2.30 como escritorio. ____________________________________________ 77
Ilustración 3.2 Diagrama HTA que muestra la actividad de personalizar el reloj de GNOME 2.30. ______________________________ 86
Ilustración 3.3 Interfaz de las preferencias del reloj, mostrando la inclusión de la pestaña de Formato. _________________________ 87
Ilustración 3.4 Contenido de la pestaña Formato. ____________________________________________________________________ 87
Ilustración 3.5 Interfaz desplegada para establecer una tipografía. ______________________________________________________ 88
Ilustración 3.6 Interfaz desplegada para establecer un color. ___________________________________________________________ 88
Ilustración 3.7 Diagrama de actividades UML para establecer el formato del reloj. __________________________________________ 89
Ilustración 3.8 Diagrama HTA que muestra la actividad de establecer las preferencias generales del panel. ______________________ 90
Ilustración 3.9 Diagrama HTA que muestra la actividad de establecer preferencias de fondo del panel. _________________________ 90
Ilustración 3.10 Interfaz con elementos nuevos para realizar la modificacion al panel. _______________________________________ 91
Ilustración 3.11 Modificación a la pestaña de Fondo. _________________________________________________________________ 92
Ilustración 3.12 Diagrama de actividades UML para establecer las preferencias generales del panel. ___________________________ 93
Ilustración 3.13 Diagrama de actividades UML para establecer el formato de fondo del panel. ________________________________ 94
Ilustración 3.14 Diagrama HTA que muestra la actividad de establecer icono personalizado en la barra de menú. _________________ 95
Ilustración 3.15 Interfaz para realizar el cambio de icono de la barra de menú. _____________________________________________ 95
Ilustración 3.16 Interfaz para seleccionar un nuevo icono. _____________________________________________________________ 96
Ilustración 3.17 Diagrama de actividades UML que muestra la actividad de establecer un icono personalizado en la barra de menú. __ 97
Ilustración 3.18 Diagrama HTA que muestra la actividad de Activar/Desactivar iconos especiales en el escritorio. _________________ 98
Ilustración 3.19 Interfaz de las preferencias del reloj, mostrando la inclusión de la pestaña de Formato. ________________________ 99
Ilustración 3.20 Contenido de la pestaña Escritorio. __________________________________________________________________ 99
Ilustración 3.21 Diagrama de actividades UML para activar el icono de "Equipo" en el escritorio. _____________________________ 100
Ilustración 3.22 Diagrama de actividades UML para activar el icono de "Carpeta Personal" en el escritorio. _____________________ 101
vi
Ilustración 3.23 Diagrama de actividades UML para activar el icono de "Servidores de Red" en el escritorio. ____________________ 101
Ilustración 3.24 Diagrama de actividades UML para activar el icono de "Papelera" en el escritorio. ___________________________ 101
Ilustración 3.25 Diagrama de actividades UML para activar los iconos de los volúmenes montados en el escritorio. ______________ 101
Ilustración 3.26 Diagrama de actividades UML para seleccionar el número de lineas de texto debajo de los iconos. ______________ 102
Ilustración 3.27 Diagrama HTA que muestra la actividad de establecer la decoracion de las ventanas. _________________________ 103
Ilustración 3.28 Diagrama HTA que muestra la actividad de Establecer las acciones de la barra de título._______________________ 104
Ilustración 3.29 Diagrama HTA que muestra la actividad de establecer la disposicion de los botones de la barra de título. _________ 104
Ilustración 3.30 Interfaz de las preferencias de la apariencia, mostrando la inclusión de la pestaña de Ventana. _________________ 105
Ilustración 3.31 Contenido de la pestaña Ventana. __________________________________________________________________ 105
Ilustración 3.32 Diagrama de actividades UML para activar Metacitycomo gestor de ventanas. ______________________________ 107
Ilustración 3.33 Diagrama de actividades UML para activar la transparencia de la ventana activa. ____________________________ 107
Ilustración 3.34 Diagrama de actividades UML para seleccionar el nivel de opacidad de la ventana activa. _____________________ 107
Ilustración 3.35 Diagrama de actividades UML para activar la transparencia de la ventana inactiva. __________________________ 107
Ilustración 3.36 Diagrama de actividades UML para seleccionar el nivel de opacidad de la ventana inactiva. ____________________ 108
Ilustración 3.37 Diagrama de actividades UML para seleccionar la accion de la rueda central en la barra de título. _______________ 108
Ilustración 3.38 Diagrama de actividades UML para seleccionar la acción al doble clic en la barra de título. _____________________ 108
Ilustración 3.39 Diagrama de actividades UML para seleccionar la acción del botón central en la barra de título. ________________ 108
Ilustración 3.40 Diagrama de actividades UML para seleccionar la acción del botón derecho en la barra de título. _______________ 109
Ilustración 3.41 Diagrama de actividades UML para establecer la disposición de los botones en la barra de título. _______________ 109
Ilustración 3.42 Diagrama HTA que muestra la actividad de establecer un icono personalizado en el menú principal. _____________ 110
Ilustración 3.43 Interfaz diseñada para seleccionar el uso de un icono personalizado para el menú principal. ____________________ 110
Ilustración 3.44 Interfaz para seleccionar un nuevo icono. ____________________________________________________________ 111
Ilustración 3.45 Diagrama de actividades UML que muestra la actividad de establecer un icono personalizado en el menú principal._ 112
vii
Resumen
El uso de las computadoras ha ido cambiando a lo largo del tiempo. En un inicio solo gente
especializada tenía la oportunidad de manipular algún sistema de computo y solo gracias a las
mejoras en las tecnologías, los usuarios se hicieron más diversos, a tal grado de que en la
actualidad el escenario más habitual es que una persona acceda a la información publicada en
internet, instale aplicaciones y personalice su entorno de trabajo sin muchas complicaciones. Esto
da lugar a usuarios finales menos técnicos, quienes no tienen interés en conocer cómo funciona su
sistema, solo les interesa usarlo. Debido a esto surge la necesidad de comparar y evaluar los
sistemas con respecto a su usabilidad.
Por otro lado, gracias a la consolidación del proyecto GNU y a la liberación del núcleo libre Linux,
se abrió la posibilidad de tener sistemas libres que compitan con los sistemas operativos
propietarios dando paso al surgimiento de distintas distribuciones GNU/Linux con propósitos
específicos como lo es Ubuntu, cuyos objetivos son la facilidad de uso y mejorar la experiencia de
usuario, teniendo como fin el ser la distribución y sistema operativo más usado a nivel mundial.
Con estas dos ideas en mente, el presente trabajo de investigación analizó el escritorio de la
distribución Ubuntu con el fin de encontrar y dar solución a problemas en la usabilidad de sus
interfaces gráficas para la configuración del entorno de trabajo del usuario final y así, con la
realización de las mejoras, la distribución se acerque a su objetivo primordial.
viii
Abstract
Throughout the time, computer’s use has been changing. At the beginning only people who were
specialized had the opportunity to manipulate a computer system and just because of Technology
developments, users became more diverse to the extent that nowadays the most common
scenario is people accessing to published information in internet, installing applications and
customizing their work environment without many complications. This result in less technical end
users, who have no interest in knowing how their systems work, they are only interested in using
them. Because of this, there is a need to compare and evaluate systems with respect to its
usability.
On the other hand, as a result of the GNU project and the Linux kernel release, a possibility of a
competition between free systems and proprietary operating systems was opened, giving rise to
various GNU/Linux distributions for specific purposes, such as Ubuntu, whose goals are ease of use
and improve the user experience, having as ultimate objective being the most used distribution
and operating system in the entire world.
In view of the above, this research analyzed the Ubuntu desktop to find and solve problems in the
usability of graphical interfaces for configuring the user's working environment and with such
improvements, the distribution approaches to its primary purpose.
1
Introducción
GNU/Linux es un sistema operativo libre, todo su código fuente puede ser utilizado, modificado y
redistribuido libremente por cualquiera bajo los términos de la GPL y otra serie de licencias libres.
Existen versiones de GNU/Linux a las que se les adicionan diversos programas de aplicación de
propósitos específicos o generales, a estas versiones se las denomina distribuciones.
Al ser libre, este sistema operativo puede instalarse en tantas computadoras como sea necesario
sin necesidad de contar con licencias y sin infringir ninguna ley de derechos, su desarrollo y
adaptabilidad no está ligado a un solo proveedor, ya que cualquiera puede ver el código y
modificarlo según sus necesidades y no se depende de una empresa específica para el
mantenimiento del sistema.
Al ser de código abierto con GNU/Linux los usuarios pueden saber exactamente qué hacen los
programas que componen el SO y, en caso de detectar alguna vulnerabilidad o irregularidad,
pueden corregirla al instante sin tener que esperar un parche o actualización. Cualquiera puede
editar el código fuente de Linux y los programas que lo componen, eliminar la brecha de seguridad
y compartirla con el resto de los usuarios. Más usuarios con acceso al código fuente permiten la
detección y solución más rápida de los problemas. En otras palabras, hay menos agujeros de
seguridad y los parches se lanzan más rápidamente que en otros sistemas propietarios.
Este sistema operativo es ampliamente utilizado en la industria, debido a su gran adaptabilidad, a
la comunidad de programadores que dan ayuda para mejorar el proyecto, por su bajo costo y por
su alto nivel de seguridad.
Sin embargo estadísticas del sitio de Internet w3counter.com demuestran al mes de Noviembre
del 2011 que el sistema más usado en el mundo de las computadoras personales es Windows 7
con 36.63% le sigue Windows XP con 32.97% , después Windows Vista con 9.17% , Mac OS X
8.65%, Apple iOS con 3.78% y en el sexto lugar esta Linux con 1.58%.
Las principales razones del porque este sistema que ofrece buenas prestaciones no es utilizado en
ambientes de escritorios personales son las siguientes:
En la mayoría de los países, los consumidores, al comprar una computadora personal no tienen la
oportunidad de elegir el sistema operativo instalado en su nuevo equipo, esto es debido a que los
grandes proveedores de tecnologías de información han realizado contratos con los proveedores
de sistemas operativos propietarios, los cuales ofrecen a los primeros, licencias baratas, que
carecen de manuales y soporte físico, con lo cual, los proveedores de tecnología ofrecen sus
maquinas nuevas con sistemas privativos instalados, produciendo un monopolio y dañando al
comprador ya que el costo de dicha licencia es transferida al consumidor final y este se ve limitado
a lo que el proveedor ofrece.
Otra de las razones por la que GNU/Linux no es usado es que la gente que ha oído de este sistema
operativo y de su buen desempeño, cree que es difícil de usar, lo cual pudo resultar verdadero en
2
sus inicios, pero actualmente, las distribuciones ofrecen un conjunto de aplicaciones que ayudan,
por ejemplo, a la instalación de programas; la mayoría de las distribuciones tienen implementados
gestores de paquetes que permiten instalar casi todo el software disponible con un simple coman-
do, y todo esto de manera segura, rápida y automática, además de ofrecer la posibilidad de
realizar esta misma tarea, usando interfaces gráficas muy intuitivas.
Por último, en donde Linux no es tan intuitivo de usar, es en la personalización del sistema, ya que
aún se necesitan la configuración de ciertas opciones mediante la edición de archivos destinados a
tal fin y esto para un usuario normal no es tan común de realizar.
Como se vio, actualmente existe una cantidad enorme de usuarios de sistemas propietarios, que
están acostumbrados a la disposición gráfica de las opciones para la configuración del sistema, por
lo que un usuario común (que no dispone de conocimientos en informática ni tiempo para buscar
soluciones en la comunidad) que pretenda probar el funcionamiento de una distribución de
GNU/Linux con el escritorio GNOME estándar, enfrentará la dificultad de no encontrar las
opciones de configuración de la manera a la que ya está acostumbrado y que ha usado por
bastante tiempo en el sistema propietario, lo cual podría provocar que dicho usuario abandone el
uso de la distribución y pierda el interés en probar una herramienta funcional y de bajo costo.
Por lo anterior, el objetivo del presente trabajo de investigación es diseñar, implementar y probar
un conjunto de modificaciones a las aplicaciones del escritorio GNOME, utilizado en el sistema
operativo GNU/Linux con la distribución Ubuntu; de manera que alcance niveles de facilidad en la
configuración de elementos equivalentes a las que ejercen los escritorios de sistemas comerciales.
La tesis se encuentra estructurada en cuatro capítulos a saber:
En el capítulo 1, se hablará acerca de los tipos de interfaces de usuario, la relación entre éstas y el
concepto de usabilidad; se expondrá un modelo para evaluar la usabilidad y por último se tocará el
modelo de la reingeniería del software.
El capítulo 2, menciona la historia de Linux, su evolución y uso en la industria a nivel global, se
hablará acerca de la distribución Ubuntu, en la cual está enfocada la presente investigación y en su
escritorio por defecto que es GNOME, además de su editor de configuración llamado gconf.
En el capítulo 3, se realizarán las actividades de análisis y diseño pertenecientes a cada modelo
expuesto en capítulos anteriores, con la finalidad de detectar y corregir errores en la usabilidad de
la configuración de elementos del escritorio GNOME.
Por último, en el capítulo 4, se presenta el desarrollo y la implementación de las modificaciones a
los elementos del escritorio GNOME siguiendo las actividades de ingenieria inversa e ingenieria
directa, que dicta el modelo de la reingeniería de software.
3
Capítulo 1 Interfaz de usuario Para dar inicio a este proyecto de investigación en esta sección se comentará acerca de los tipos
de interfaz de usuario, se hablará sobre la evolución de las interfaces con el paso del tiempo, se
expondrá un modelo para asegurar la usabilidad y por último se explicará un modelo para realizar
reingenieria de software.
1.1 Tipos de interfaz de usuario
Las interfaces de usuario se componen de dos partes esenciales: el lenguaje de presentación, que
es el flujo de información de la computadora al usuario, y el lenguaje de acción; que consiste en
como el usuario da órdenes a la computadora. Ambos cubren el término interfaz de usuario. A
continuación se hablará acerca de los tipos de interfaces.
Interfaz de lenguaje natural.
Permiten a los usuarios interactuar con el sistema en el lenguaje natural, sin embargo, el lenguaje
natural es ambiguo, lo cual produce problemas de programación complejos, estos problemas de
implementación y demanda de recursos, han mantenido a las interfaces de éste tipo al margen;
pero hay un gran interés en poder hacerlos factibles, así que se puede asegurar que será un área
de investigación que seguirá creciendo.
Ilustración 1.1 Interfaz de lenguaje natural, donde un usuario comanda tres órdenes y el sistema las
ejecuta.
4
Interfaz de pregunta respuesta.
En esta interfaz se muestra una pregunta al usuario en la pantalla, el usuario teclea una respuesta
y la computadora actúa de acuerdo a la información introducida, pasando de una pregunta a la
otra de una manera pre programada.
En este tipo de interfaz, se encuentran catalogados los cuadros de diálogo, en donde
generalmente uno de los botones de selección se encuentra resaltado indicando la respuesta más
probable, ya que una mayor amplitud para la respuesta de los usuarios, se traduce directamente
en un incremento de la complejidad del programa. Es recomendable introducir avisos para que el
usuario recuerde las respuestas aceptables, ya que si se gasta esfuerzo en buscar que respuestas
son las correctas, el usuario podrá quedar insatisfecho y no querer usar el programa.
Ilustración 1.2 Interfaces de pregunta respuesta. En la izquierda el sistema pide parámetros y en la
derecha se muestra un cuadro de diálogo de Microsoft Word 2007.
Interfaz de menús.
Esta interfaz proporciona al usuario una lista en pantalla de las selecciones disponibles, para
responder, el usuario está limitado a las opciones desplegadas. El usuario no debe conocer el
sistema, solo debe saber que acción quiere que el sistema realice. Los menús pueden ser anidados
dentro de otros, lo que permite que la pantalla se vea más limpia, que el usuario solo vea
información de su interés y que se desplace con una mayor velocidad entre las opciones.
5
Ilustración 1.3 Interfaces de menús. En la izquierda un menú que usa números para seleccionar una acción
y en la derecha un menú desplegado del escritorio de la distribución Ubuntu.
Interfaz de llenado de formas.
La interfaz consiste de formas en pantalla que despliegan campos que contienen parámetros para
ser llenados por el usuario. Las formas son puestas en pantalla, muestran que información debe
ser dada y en donde, los campos en blanco son resaltados, el cursor se mueve por mouse o con
teclas del teclado y la entrada de datos puede ser alfanuméricamente restringida. La ventaja
principal es que la versión impresa de la forma llena proporciona muy buena documentación.
Ilustración 1.4 Interfaz de llenado de formas.
6
Interfaz de lenguaje de comandos.
Permite al usuario controlar la aplicación con una serie de comandos y frases. El lenguaje de
comandos no tiene ningún significado para el usuario, este lenguaje permite que el usuario
controle el diálogo, manejando a la computadora como una herramienta, lo que proporciona al
usuario mayor flexibilidad y control. Cuando el usuario teclea una orden, el lenguaje de comandos
realiza la acción inmediatamente y una vez concluida la tarea, el usuario puede continuar dando
órdenes a la computadora.
La principal desventaja del lenguaje de comandos es que el usuario debe recordar la sintaxis de las
órdenes, sin embargo esta sintaxis puede ser rápidamente memorizada con el paso del tiempo y el
uso.
Ilustración 1.5 Interfaz de línea de comandos. Mostrando la sentencia para crear una tabla con la sintaxis
de mysql.
Interfaz gráfica de usuario (GUI).
Esta interfaz utiliza imágenes y objetos gráficos para representar la información y acciones
disponibles en el sistema. La clave de la GUI es la retroalimentación sobre el logro de la tarea que
se esté realizando.
En la creación de interfaces gráficas de usuario debe ser inventado un modelo adecuado de la
realidad o un modelo aceptable de la representación a lo cual se le llama metáfora, por ejemplo, si
existiera alguna aplicación para controlar el tráfico aéreo, se deberá representar las funciones del
programa con iconos relacionados con el tráfico aéreo y no con iconos que representen por
ejemplo una central camionera.
Generalmente la interfaz gráfica de usuario crea ventanas que aparecen en el dispositivo de
visualización del usuario. Las ventanas están compuestas de widgets (controles), los cuales
interactúan con el usuario por medio del mouse, el teclado u otra forma de entrada.
7
Ilustración 1.6 Interfaz gráfica de usuario del escritorio de la distribución Ubuntu.
En esta investigación nos enfocaremos en el estudio de la interfaz gráfica de usuario, siendo la más
usada en computadoras personales la metáfora del escritorio, la cual crea los recursos necesarios
para dar la impresión que en nuestro sistema operativo trabajamos en un escritorio de la vida real.
1.2 Evolución de la interfaz gráfica de usuario
Las interfaces gráficas de usuario no han sido siempre como las conocemos, han ido
evolucionando. Todo comenzó con una idea que se adelantó a su tiempo, después hubó esfuerzos
para que esa idea se hiciera realidad, fue así que el concepto fue pasando de compañía a
compañía, cada una de las cuales aportaban algo innovador y enriquecían el diseño, hasta llegar a
aquello con lo que actualmente estamos familiarizados. A continuación se presentarán algunos
puntos importantes en el avance de la interfaz gráfica de usuario.
A finales de la segunda guerra mundial un científico estadounidense de nombre Vannevar Bush
publicó un artículo (BUSH, 1945) en 1945 con el título “As We May Think” (Como podríamos
pensar), en el cual sugiere unas cuantas ideas y pensamientos acerca de la evolución de algunos
dispositivos de su época, estas ideas eran el retrato de lo que él creía que podía ser posible en un
futuro teniendo en cuenta el desarrollo de ciertos instrumentos. Este artículo se considera como la
idea principal para el nacimiento de la World Wide Web, pero además de esto, Vannevar Bush
retrató en palabras un instrumento que es muy parecido a lo que ahora conocemos como interfaz
gráfica de usuario.
En su artículo menciona un artefacto llamado memex, al cual definió de la siguiente manera: “Un
memex es un aparato en el que una persona almacena todos sus libros, archivos y
comunicaciones, y que está mecanizado de modo que puede consultarse con una gran velocidad y
flexibilidad. En realidad, constituye un suplemento ampliado e íntimo de su memoria.” El artículo
proponía que el memex era un artefacto que podía acceder a recursos almacenados en microfilms
8
no solo por índices, sino también por medio de referencias, como actualmente lo hacemos con los
links en el hipertexto.
Lo interesante del articulo es la manera en que describe al memex: “El memex consiste en un
escritorio que, si bien puede ser manejado a distancia, constituye primordialmente el lugar de
trabajo de la persona que accede a él. En su plano superior hay varias pantallas translúcidas
inclinadas “visores” sobre las cuales se puede proyectar el material para ser consultado. También
dispone de un teclado y de un conjunto de botones y palancas. Por lo demás, su aspecto se
asemeja al de cualquier otra mesa de despacho.” Como se puede apreciar, el pensamiento de este
personaje describió un entorno de trabajo en el que se podía consultar de una manera organizada
la información. Cabe señalar que la tecnología de ese momento no permitió la creación de algo
tan sofisticado.
Tiempo después, un ingeniero eléctrico que había sido operador de radar durante la guerra
llamado Douglas Englebart leyó el artículo de Vannevar Bush y pudo imaginarse el sistema de
visualización del memex a través de tubos de rayos catódicos. Englebart terminó su doctorado en
1955 y consiguió trabajar en el instituto de investigación de Standford, para 1959 ya había sido
reconocido por su trabajo y logró que la Fuerza Aérea de EE.UU. financiara sus investigaciones, es
así que en 1962 publicó un trabajo de investigación llamado “AUGMENTING HUMAN INTELLECT: A
Conceptual Framework” (Aumentando el intelecto humano: un marco conceptual), en donde
sostenía que las computadoras “incrementaban la capacidad de un hombre para solucionar una
situación problemática compleja, para obtener la comprensión adecuada para satisfacer sus
necesidades particulares, y para obtener soluciones a los problemas.” En el artículo que publicó se
puede observar que lo que lo impulsó fue la definición del memex con lo que dedujo que las
computadoras podrían ser una herramienta para desarrollar el potencial intelectual de los seres
humanos (Engelbart, 1962).
Englebart y su equipo trabajaron durante años y en 1968 presentó el NLS (oN Line System), la
primera aplicación práctica de un sistema hipertextual, destinado a gestionar la información del
centro en donde trabajaba y permitir el trabajo conjunto de personas en línea. El NLS contenía
procesadores de textos, editores de esquemas, un sistema de correo electrónico, teleconferencia,
un entorno visual mediante un sistema de ventanas y por primera vez se concibió el mouse. En
este punto, las ventanas del sistema no eran como las que se conocen actualmente, debido a
limitaciones en el hardware se mostraban las ventanas pero sin ningún área de división ni barras
de titulo. Con la aparición del mouse, se introdujo el puntero, el cual en vez de estar en diagonal
como lo está actualmente, apuntaba hacia arriba.
9
Ilustración 1.7 La estación de trabajo on-line system mostrando monitor CRT, mouse, teclado y botones de control. Fuente: http://sloan.stanford.edu/mousesite/Archive/AugmentingHumanIntellect62/Display1967.html
En 1978 el laboratorio en donde Englebart trabajaba cerró por falta de fondos, el sistema se
vendió y la mayor parte del equipo de desarrolladores fueron contratados por Xerox.
En ese entonces Xerox abrió un nuevo centro de investigación llamado Xerox PARC (Palo Alto
Research Center, Centro de investigación de Palo Alto), en donde acogió a los antiguos
desarrolladores del NLS, dándoles total libertad de trabajar en sus ideas. Fue en este centro en
donde se inventó la impresora laser y con ella la necesidad de una computadora que pudiera
preparar adecuadamente las páginas a ser impresas lo que llevó al desarrollo de la computadora
Xerox Alto en 1973, la cual tenía una pantalla del tamaño de una página con la resolución de 606 x
808, cada pixel se podía activar y desactivar de forma independiente, además contenía una versión
modificada del mouse diseñado por Engelbart, fue entonces que apareció el cursor como lo
conocemos con forma de flecha blanca y este cambiaba cuando realizaba otras tareas.
El software que se desarrolló para esta máquina no era muy gráfico, utilizaba líneas y texto. Se
incluía un editor de texto llamado Bravo, el cual podía representar como es que se vería el texto
impreso, se podía cambiar de formato a los textos y la impresión salía tal y como se veía en
pantalla; nació el termino WYSIWYG “what you see is what you get” (lo que ves es lo que
obtienes), también se incluía un editor de gráficos de mapa de bits. La interfaz de estos programas
no era uniforme, cada uno tenía su propio diseño, fue en este punto que los desarrolladores
vieron la necesidad de crear una interfaz consistente.
10
Ilustración 1.8 La computadora Xerox Alto desarrollada por Xerox en 1973.
Fuente: http://toastytech.com/guis/altosystem.jpg
Alan Kay, quien era un ingeniero electrónico y trabajaba en el PARC, desarrolló en los setenta el
que se considera el primer lenguaje orientado a objetos SmallTalk.
SmallTalk además de ser un lenguaje, es un entorno de programación, en donde conviven objetos.
Las ventanas en este entorno contenían un borde que las delimitaba, tenían un color distinto al
fondo y una barra de título para diferenciarlas, además, podían ser movidas por toda la pantalla,
una ventana podía sobreponerse a otra y la ventana del fondo podía traerse a la vista con un clic.
Los iconos, los menús, las barras de desplazamiento, los botones de radio y las cajas de diálogo
también fueron inventados aquí.
La combinación de SmallTalk y la Xerox Alto dio cabida a la primer computadora con interfaz
gráfica, conexión ethernet y puntero, sin embargo nunca salió al mercado ya que solo fue ocupada
en la investigación.
Ilustración 1.9 Una versión mejorada de la computadora Xerox Alto corriendo el entorno Smalltalk.
Fuente: http://toastytech.com/guis/altost2.jpg
11
En 1977 Xerox crea el SDD “System Development Departament” (Departamento de Desarrollo de
Sistemas) con sede en El Segundo, California, donde se tenía como objetivo el desarrollar un
equipo con las características del Xerox Alto, pero que fuera fácil de usar en oficinas. Los
desarrolladores del proyecto tuvieron muchas reuniones en donde definían estándares a usar en
su sistema, fue así que se creó el “Red Book”, en donde todo se encontraba detallado y cualquier
cambio era sujeto a aprobación y una vez más el WYSIWYG tuvo una gran importancia.
Es así que en 1981 Xerox lanza la computadora Xerox Star, en la cual todo era un objeto y con solo
oprimir un botón del mouse, se podía cambiar la propiedad del objeto seleccionado, la interfaz de
usuario se estandarizó, apareció el foco entre ventanas, los iconos seleccionados cambiaban de
color y se introdujo la metáfora del escritorio, los iconos y ventanas se podían acomodar tal cual la
pantalla fuera un escritorio de la vida diaria, los archivos podían ser guardados dentro de otras
estructuras llamadas carpetas como se hace en la actualidad y el mouse pasó de tener tres
botones a solo dos para simplificar su uso. El único inconveniente de esta computadora fue su
precio ya que utilizaba hardware de gran capacidad para la época y es por eso que no fue un éxito
comercial.
Ilustración 1.10 La computadora Star mostrando símbolos para notaciones científicas. Fuente: http://toastytech.com/guis/starapp5.jpg
Entre el proceso de diseño de una y otra computadora de Xerox, Steve Jobs, quien era un nuevo
empresario en el ramo de la computación, en Diciembre de 1979 logró tener acceso al PARC de
Xerox, en donde pudo observar el funcionamiento y diseño de la interfaz gráfica y el mouse de la
Alto y la Star, fue entonces que la compañía creada por Jobs, Apple, empezó a incorporar estas
ideas a un proyecto de computadora que ya había estado desarrollando.
Es así que en Enero de 1983 Apple lanzó la computadora Lisa, la cual era un terminal que incluía
dos unidades de diskette un disco duro de 5 megabytes y un megabyte de memoria RAM, lo cual
hacia de esta computadora un dispositivo caro. Lo interesante de este equipo fue la adopción de la
interfaz gráfica de usuario a la cual se le añadieron nuevos componentes como son las casillas de
12
verificación, la barra de menú característica de todas las Mac actuales, el concepto de atajos de
teclado para los comandos más comunes, también por primera vez apareció el concepto de
papelera, en donde se arrastraban los archivos para su eliminación y se añadió el tono gris a los
menús que no se encontraban disponibles en ese momento. El mouse también sufrió una
modificación, en la que solo incluía un botón, y surgió la idea del doble clic para iniciar las
aplicaciones.
Otros de los aportes de Lisa para las interfaces gráficas fueron que todos los archivos del sistema
podían ser representados por iconos, además el sistema de archivos podía ser accedido mediante
una estructura de directorios jerárquicos, donde cada directorio se abría en una ventana nueva, se
creó la idea de “arrastrar y soltar” para manipular archivos y el concepto de que al dar doble clic
en un archivo, se lanzara automáticamente la aplicación para su visualización o edición.
Ilustración 1.11 La computadora Lisa de Apple mostrando LisaDraw, LisaWrite y su habilidad para compartir información a través del Clipboard. Fuente: http://toastytech.com/guis/lisadrawwrite.png
En 1984 Apple lanzó una nueva computadora llamada Macintosh, la cual era un diseño
independiente de Lisa pero tenía todas las características de la interfaz de usuario de esta última.
Lo sobresaliente de Macintosh fue su precio, ya que por tener menor capacidad que la
computadora Lisa, era más barata y por lo tanto mejor vendida.
13
Ilustración 1.12 La computadora Macintosh de Apple mostrando la habilidad de cerrar todas las ventanas de su navegador de archivos “Finder”. Fuente: http://toastytech.com/guis/moremac.html
Durante los ochentas varias compañías ofrecieron productos con interfaces gráficas, la mayoría
para el IBM PC y sus clones, aquí solo se mostrarán las que implementaron algo nuevo al diseño de
Apple.
En 1985 Microsoft libera Windows 1.0 el cual era una interfaz gráfica para MS-DOS, abarcaba
todas las peculiaridades de las interfaces expuestas hasta ahora, el único cambio es que las
ventanas de las aplicaciones contenían una barra de menú individual en vez de la barra superior
de Macintosh.
Ilustración 1.13 Microsoft Windows 1.0 mostrando el menú de cada aplicación en su propia ventana. Fuente: http://toastytech.com/guis/win101tile2.gif
En ese mismo año Commodore International lanzó la computadora Amiga con una interfaz gráfica
de usuario llamada Workbench, ya que simulaba un espacio de trabajo virtual. Esta interfaz se
14
caracterizaba por sus colores de alto contraste azul, naranja, blanco y negro, y el aporte más
distintivo a las interfaces gráficas es que como la Macintosh contenía una sola barra de menú en la
parte superior, pero esta normalmente se encontraba oculta y solo se activaba cuando se
presionaba el botón derecho del mouse.
Ilustración 1.14 Amiga Workbench desarrollada por Commodore International. Fuente: http://toastytech.com/guis/wb_10.gif
En 1987 Acorn Computers pone a la venta las computadoras Acorn A305 y A310, estas
computadoras fueron las primeras en ocupar un procesador de 32 bits. Su interfaz gráfica llamada
Arthur implementa por primera vez el concepto de dock, la cual era una barra donde se podían
poner iconos de aplicaciones más utilizadas.
Ilustración 1.15 Interfaz Arthur, donde se muestra el dock para poner aplicaciones más usadas. Fuente: http://toastytech.com/guis/bigarthur.gif
15
Más tarde, la empresa Next Computer desarrolló en 1989 una interfaz gráfica para sus
computadoras Next. Esta interfaz fue la primera en utilizar el símbolo “X” para cerrar una
aplicación, además de introducir los efectos de tercera dimensión a todos los componentes de la
interfaz.
Ilustración 1.16 La interfaz gráfica del sistema operativo NeXTStep mostrando la “X” para cerrar una aplicación. Fuente: http://toastytech.com/guis/opensteptextedit.png
En 1995 Windows lanzó su nuevo sistema operativo llamado Windows 95 en el que introdujo el
concepto del Botón Inicio, al cual al darle clic mostraba todas las aplicaciones instaladas en la
computadora. Otra idea nueva fue la barra de tareas, en donde se mostraban todas las
aplicaciones que se encontraban corriendo y se podía cambiar de una a otra con solo seleccionarla
con el mouse.
Ilustración 1.17 La interfaz gráfica Windows 95 mostrando el botón de inicio desplegado y la ventana del panel de control abierta con su respectivo ícono en la barra de tareas. Fuente: http://toastytech.com/guis/win95cpl.png
Pasados tres años, en 1998 el sistema operativo BeOS aportó una idea más; todas las ventanas
abiertas de una misma aplicación podían ser representadas en un único botón en la barra de
16
tareas y al ser seleccionado se desplegaría un menú con el nombre de cada ventana, a esto se le
llamó “Taskbar Grouping”.
En el 2000 Apple desarrolló una interfaz nueva, a la que llamó Aqua, esta interfaz introdujo
animaciones a los componentes de la interfaz y desarrolló una manera de hacer que todas las
ventanas de las aplicaciones activas se redimensionaran y se mostraran en pantalla a lo que se le
dio el nombre de “Expose”.
Ilustración 1.18 La interfaz gráfica Aqua mostrando el efecto Expose. Fuente: http://www9.pcmag.com/media/images/211911-apple-os-x-10-6-snow-leopard-expose-from-dock.jpg
A partir de entonces las interfaces gráficas para escritorios de computadora solo han sufrido
cambios con respecto a efectos gráficos.
Este resumen de la evolución de las interfaces se logró consultando: (Reimer, 2006), (Clavel, 2009)
y (Lagoa Caridad & Montero Manso) los tres en web.
A lo largo de la evolución de las interfaces gráficas se han estandarizado sus diseños mediante
guías prácticas, principios y teorías dando paso al concepto de usabilidad que será un tema en
discusión en la siguiente sección:
1.3 Usabilidad
En este apartado se dará una introducción al concepto de usabilidad, comenzando con su
definición, importancia, sus atributos; para después en la siguiente sección se pueda estudiar el
proceso de la ingeniería de la usabilidad. Lo expuesto en esta sección y hasta el final del capítulo
está basado principalmente en: (i Saltiveri, Lorés Vidal, & Cañas Delgado, 2005) y (Sidar, 2011)
La organización internacional para la estandarización (International Standarisation Organization,
ISO) propone dos definiciones para el término de usabilidad.
17
La ISO 9241-11 (Guidance on Usability-1998) proporciona la definición de usabilidad para
estándares ergonómicos:
“La medida en la que un producto puede ser usado por determinados usuarios para conseguir
objetivos específicos con efectividad, eficiencia y satisfacción en un contexto de uso especificado.”
En donde:
La efectividad es la precisión y plenitud con la que los usuarios alcanzan los objetivos. Aquí
se asocia la facilidad de aprendizaje, la tasa de errores del sistema y la facilidad del sistema
para ser recordado.
Por eficiencia se entienden a los recursos empleados en relación con la precisión y
plenitud con las que los usuarios alcanzan los objetivos.
Por satisfacción se entiende a la ausencia de incomodidad y la actitud positiva en el uso
del producto, es por tanto un factor altamente subjetivo.
Y la segunda definición está dada en la ISO/IEC 9126 (Software product evaluation-Quality
characteristics and guidelines for their use-1991), que es desarrollada como un estándar de la
ingeniería de software y dice que la Usabilidad es “La capacidad que tiene un producto software
para ser atractivo, entendido, aprendido, usado por el usuario, usado bajo unas condiciones
especificas.” Con lo cual se puede apreciar que un producto de software no dispone de usabilidad
intrínseca, sino que tiene la capacidad de ser usado en un contexto particular.
1.3.1 Importancia de la usabilidad
En la década de los sesenta se pudo comprender que un aspecto importante de la ingeniería del
software era el diseño de la interfaz de usuario, se desarrollaba software para ser usado
interactivamente con lo cual se fue prestando más atención al usuario final. Con el tiempo, la
tecnología fue mejorando y con la aparición de las computadoras personales se hizo común que
los usuarios finales instalaran y personalizaran su propio software.
Actualmente, el escenario habitual del uso del software, es que una persona acceda desde su
computadora a información publicada en la web o bien que utilice algún paquete de software
instalado por ella misma.
Esta realidad nos lleva a encontrar usuarios finales cada vez más diversos y menos técnicos, a los
cuales no les importa el funcionamiento interno del software, lo que ellos quieren es utilizarlo.
La usabilidad hace referencia a la rapidez y facilidad con la que las personas llevan a cabo sus
tareas mediante el uso del producto con el que están trabajando, esta idea descansa en cuatro
puntos:
18
1. Una aproximación al usuario: usabilidad significa centrarse en los usuarios. Para
desarrollar un producto usable se tiene que conocer, entender y trabajar con las personas
que representan a los usuarios actuales o potenciales del producto.
2. Un amplio conocimiento del contexto de uso: las personas utilizan los productos para
incrementar su propia productividad. Así pues, un producto se considera fácil de aprender
y de usar en términos del tiempo que toma el usuario para llevar a cabo su objetivo, el
número de pasos que debe realizar para esto y el éxito que tiene para predecir la acción
apropiada para llevar a cabo. Para desarrollar productos usables, hay que entender los
objetivos del usuario, es necesario conocer los trabajos y tareas del usuario que el
producto automatiza o modifica.
3. El producto debe satisfacer las necesidades del usuario y adaptarse a sus modelos
mentales: los usuarios son gente muy diversa y ocupada, que intenta llevar a cabo una
tarea. Se va a relacionar usabilidad con productividad y calidad. El hardware y software
son las herramientas que ayudan a la gente ocupada a realizar su trabajo y a disfrutar de
su ocio.
4. Son los usuarios, y no los diseñadores o los desarrolladores, los que determinan cuando un
producto es fácil de usar.
La interfaz de usuario es la puerta del usuario a la funcionalidad del sistema y, por tanto, el hecho
de que las interfaces estén mal diseñadas es un factor que frena el uso de las funcionalidades, es
así que es muy importante diseñar interfaces de usuario usables.
1.3.2 Atributos de la usabilidad
1. Facilidad de aprendizaje.
a) Minimizar el tiempo necesario que se requiere desde el no conocimiento de una aplicación a su uso productivo.
b) Reducir el tiempo necesario para ayudar en las sesiones de aprendizaje.
Para que el sistema sea fácil de aprender, tiene que ser:
a) Sintetizable. El usuario debe poder evaluar el efecto de operaciones anteriores en el estado actual, es decir, cuando una operación cambia algún aspecto del estado anterior, que el cambio sea captado por el usuario. Es importante que la interfaz refleje posteriormente estos cambios.
b) Familiar. Los nuevos usuarios de un sistema tienen una amplia experiencia interactiva con otros sistemas.
2. Consistencia. Se dice que un sistema es consistente si todos sus mecanismos se usan de la
misma manera, sea cual sea el momento y la manera en la que se haga.
19
3. Flexibilidad. Se refiere a las múltiples formas en las que el usuario y el sistema intercambian
información.
Los parámetros que miden la flexibilidad son:
Control de usuario. Permite a los usuarios conducir la interacción y no estar forzados a trabajar para la aplicación.
Migración de tareas. Tanto el usuario como el sistema deben poder pasar de una tarea a la otra o promocionarla, de manera que pueda ser completamente interna o compartida entre los dos.
Capacidad de sustitución. Permite que valores equivalentes puedan ser sustituidos unos por otros.
Adaptabilidad. Se trata de la adecuación de la interfaz del sistema al usuario.
4. Robustez. Proporciona a la interacción todas las características que permiten a los usuarios
cumplir siempre sus objetivos, sea cual sea el camino que hayan tomado.
5. Recuperabilidad. Es la habilidad que permite al usuario del sistema corregir una acción una
vez este ha cometido un error.
6. Tiempo de respuesta. El tiempo que necesita el sistema para expresar los cambios de estado
al usuario. Es importante que los tiempos sean soportables para el usuario.
7. Adaptación de las tareas. Ya que el propósito de un sistema interactivo es permitir a sus
usuarios realizar varias tareas en el dominio especifico de la aplicación, nos podemos
preguntar si el sistema soporta todas las tareas necesarias (completitud de las tareas) y si lo
hace tal y como el usuario espera (adecuación de las tareas). Los dos criterios deben seguirse
para adaptar las tareas del sistema las necesidades del usuario.
8. Disminución de la carga cognitiva. Los usuarios confían más en lo que reconocen que en lo
que recuerdan; la interfaz proporcionará los mecanismos que permiten reconocer las acciones
y no tener que recordar su realización.
1.4 La ingeniería de la usabilidad
En esta sección se explicará un modelo de diseño de interfaces que hace uso de la ingeniería de la
usabilidad.
Se usa el término de ingeniería de la usabilidad, para referirse a las técnicas y conceptos para
planificar, conseguir y verificar objetivos de la usabilidad del sistema. La idea principal es que los
objetivos “medibles” de usabilidad se deben definir pronto en el desarrollo del software y,
después, se tienen que evaluar repetidamente durante el desarrollo para asegurar que se han
conseguido.
20
1.4.1 El modelo del proceso
El estándar ISO 13407 proporciona un marco de trabajo para aplicar el diseño centrado en el
usuario, el proceso que a continuación se detalla, se basa en este marco de calidad.
Ilustración 1.19 Modelo del proceso de la Ingeniería de la usabilidad Fuente: http://www.grihohcitools.udl.cat/mpiua/modelo.htm
Una de las metas importantes de este modelo es el “casar” el modelo de desarrollo de la
ingeniería del software, con los principios de la ingeniería de la usabilidad, para proporcionar una
metodología capaz de guiar el desarrollo durante el proceso de implementación de un sistema
interactivo.
Como se puede ver, el modelo se apoya en la ingeniería del software (columna izquierda),
presenta al prototipado (columna central), como un conjunto de técnicas que permitirán la
próxima fase de evaluación y por último la evaluación (columna derecha), que engloba y
categoriza los métodos de evaluación que hay. Todo este proceso se realiza con el usuario en el
centro del desarrollo y de una manera iterativa.
1.4.2 Fases del modelo de proceso de la ingeniería de la usabilidad
Como ya se ha dicho el modelo del proceso se apoya en la ingeniería del software e incluye
técnicas de prototipado y evaluación, las cuales pueden ser usadas desde el inicio del proyecto, es
por esto que serán las primeras en explicarse.
1.4.2.1 Prototipado
Los prototipos son documentos, diseños o sistemas que simulan partes del sistema final que
debemos implementar. En una interfaz de usuario se realizan prototipos con la finalidad de
21
explorar los aspectos interactivos del sistema, incluyendo su usabilidad y funcionalidad (Rosson &
Carroll, 2002).
El prototipado engloba todas las herramientas que permiten realizar a los diseñadores de sistemas
estas simulaciones.
Las técnicas de prototipado se catalogan en dos categorías: baja fidelidad y alta fidelidad.
1. Los prototipos de baja fidelidad implementan aspectos generales del sistema sin entrar en
detalles. Se caracterizan por ser económicos, rápidos de construir, fáciles de arreglar y por
no precisar de técnicos expertos.
2. Los prototipos de alta fidelidad presentan aspectos más precisos, por ejemplo, pueden
detallar el proceso de alguna tarea concreta. Se caracterizan por el uso de herramientas
especializadas de prototipado, por requerir de expertos que conozcan las herramientas,
por ser más caros y por requerir de más tiempo en realizar el prototipo y en hacer
cambios.
El prototipado comprende dos procesos diferenciados:
1. La presentación, comprende la disposición de los elementos de la interfaz (gráficos y texto
en la pantalla, botones en un mando a distancia, la voz, el sonido y el tacto en una interfaz
multimodal).
2. La interacción, hace referencia al procesamiento y a su rendimiento.
Las técnicas que se pueden utilizar son:
a) Bocetos. Son representaciones de primeras ideas, se usan en etapas tempranas del diseño
incluso antes de determinar el análisis de requisitos. La clave está en la velocidad de
producción, ya que se realizan entre quince o veinte segundos.
b) Storyboard. Consiste en una serie de dibujos que representan como se usará un sistema
durante la consecución de una tarea. Muestran la evolución de la situación del usuario
mientras interactúa con el sistema. Su uso es indicado cuando el nuevo sistema cambiará
la forma de trabajar de las personas afectadas. No servirá para comprobar la
interactividad del sistema, pero será útil para asegurar que el diseñador ha asimilado el
problema y para discutir detalles con usuarios e implicados.
c) Prototipos de papel. Se basa en la utilización de lápiz, papel y tijeras, lo cual permite una
gran velocidad y flexibilidad al hacer los prototipos y es muy económica. Debe capturar la
funcionalidad del sistema, comunicar la información y sus interacciones. Consiste en
dibujar en un papel las interfaces que se van a valorar y probar. Los diferentes estados de
la interfaz se dibujan en hojas separadas y mediante un proceso de ordenación, el usuario
interactúa con el material simulando el funcionamiento el sistema.
22
d) Maquetas digitales. Son representaciones que llenan el espacio que hay entre el prototipo
de papel y la versión definitiva de la interfaz. Para su realización es necesario herramientas
sofisticadas, como editores gráficos, que necesitan de mayor tiempo de desarrollo y mejor
preparación de las personas que las realizan, pero el mayor nivel de detalle permite que el
prototipo se visualice de una manera muy aproximada a la versión final del diseño de la
interfaz.
e) Storyboards navegacionales. Consiste en representar en un espacio bidireccional todos
los estados de las interfaces de la parte del sistema que se examinará y todas las
posibilidades en un ámbito interactivo desde cada uno de estos estados para visualizar las
posibles acciones que el usuario puede realizar mientras interactúa con la interfaz.
Permite comprender el flujo del trabajo de los usuarios y como la interfaz le dará apoyo
paso a paso. Se pueden implementar con secuencias de prototipos en papel o con
maquetas digitales.
f) Videos. Permiten desarrollar un escenario, en el que gracias a la producción pueden
parecer reales funcionalidades y sistemas que solo son ideas, están en fase inicial o son
imposibles de realizar. Estos prototipos ofrecen una manera económica de visualizar
partes de los futuros sistemas, pero suelen fallar cuando intentan comunicar el sentido
global de una nueva experiencia del usuario, ya sea porque el hardware aún no existe o
porque sea difícil crear un prototipo fluido e interactivo de un sistema grande.
g) Escenarios. Consisten en describir las actividades que se realizan durante algún proceso.
Reflejan las historias sobre personas y sus actividades destacando: lo que las personas
quieren hacer con el sistema, que procedimientos son usados y cuáles no, cuales se
realizan satisfactoriamente y que interpretaciones hacen de lo que sucede. No se
ahondará mucho sobre los escenarios, basta con decir que los más usados son: el de
lenguaje natural, Storyboards, escenarios en video y diagramas de caso de uso de UML.
h) Prototipos de software. Son implementaciones realizadas con técnicas de programación
del sistema propuesto en las que se reproduce la interfaz simulando o implementando
parte de las funcionalidades para probar aspectos del sistema final. Se implementan
después de varias interacciones prototipado-evaluacion y cuando se tiene la intención de
ver cómo responde el sistema. El propósito del prototipo es probar los aspectos
relacionados con la interacción del usuario con el sistema, no su funcionalidad.
23
A continuación se presenta una tabla que resume lo que se quiere analizar con cada técnica de
prototipado.
Boceto Primeras ideas.
Storyboard
Reflejo del contexto.
Descripción del contexto de interacción.
Identificación y ubicación de los actores y objetos que intervienen en la interacción.
Prototipo en papel
Simplicidad, minimalismo.
Visibilidad de las funciones.
Metodología de interacción.
Capacidad de ser sintetizado.
Maquetas Reflejo de su utilización.
Reflejo de las características físicas.
Maquetas digitales
Visibilidad de las funciones.
Metodología de interacción.
Disposición de los elementos interactivos de la interfaz.
Storyboard navegacional
Representación de la interacción de la interfaz
Visibilidad de la navegación.
Representación de los estados del sistema.
Videos
Representación de casos o situaciones interactivas.
Entender el contexto y el porqué de la tarea.
Visibilidad de los actores y de los objetos que intervienen en la interacción.
Escenificación de posibilidades futuras o de acceso difícil.
Escenarios
Representación de casos o situaciones interactivas.
Entender el contexto y el porqué de la tarea.
Visibilidad de los actores y de los objetos que intervienen en la interacción.
Prototipo en software horizontal
Navegabilidad.
Seguimiento de las tareas.
Globalidad del proceso interactivo.
Prototipo en software vertical
Exploración de las funcionalidades concretas.
Medidas de rendimiento.
Una vez realizados los prototipos se deberá asegurar que los diseños se adaptan a las necesidades,
requisitos y expectativas de los usuarios, dando paso al papel de la evaluación.
1.4.2.2 Evaluación
Se entiende el término evaluación como la actividad necesaria de comprobación que comprende
un conjunto de metodologías y técnicas que analizan la usabilidad de un sistema interactivo en
diferentes etapas del ciclo de vida del software.
24
La evaluación tiene definidos tres objetivos principales (Dix et al, 2003):
1. Comprobar la extensión de la funcionalidad del sistema. 2. Comprobar el efecto de la interfaz de usuario. 3. Identificar cualquier problema específico con el sistema.
El primer punto consiste en que el sistema debe permitir al usuario realizar las tareas de manera
fácil, por lo cual se deberán incluir medidas del rendimiento del usuario con el sistema. El segundo
punto trata de comprobar el impacto que el diseño tiene sobre el usuario, considerando aspectos
como lo fácil de aprender, de manejar o identificar áreas del diseño que puedan requerir una
sobrecarga de información que el usuario debe recordar. Por último, el objetivo de la evaluación
es identificar problemas específicos de diseño, por ejemplo, aspectos que mientras el usuario está
en su tarea, causen resultados inesperados.
Existen diversas maneras de clasificar los métodos de evaluación, en este trabajo hablaremos de la
clasificación por tipo de técnica de comprobación utilizada, en la cual se distinguen tres categorías:
a) Métodos de inspección. Son un conjunto de métodos basados en evaluadores que
examinan aspectos relacionados con la usabilidad de la interfaz. Los inspectores de la
usabilidad pueden ser especialistas en usabilidad, consultores de desarrollo de software
con experiencia en guías de estilo de interfaces u otros tipos de profesionales.
b) Métodos de indagación. Estos métodos se realizan hablando con los usuarios, observando
como usan el sistema y obteniendo respuestas a preguntas verbales o por escrito acerca
de sus gustos, quejas, necesidades, etc.
c) Métodos de test. En estos métodos, usuarios representativos trabajan en tareas utilizando
el sistema (o el prototipo) y los evaluadores utilizan los resultados para ver como la
interfaz da apoyo a los usuarios con sus tareas.
Los métodos de inspección quedan fuera del estudio de este trabajo de investigación, por lo que
solo ahondaremos en los métodos de indagación y en los métodos de test.
1.4.2.2.1 Métodos de indagación
En los métodos de evaluación realizados por indagación se habla con los usuarios y se les observa
detenidamente usando el sistema en trabajo real y se realizan preguntas en forma oral o escrita.
Existen diversos métodos de indagación, los que se expondrán son: la observación de campo, las
entrevistas, y los cuestionarios.
1. Observación de campo.
Para hacer una observación de campo (Nielsen, 1993), el trabajo a realizar consiste en visitar el
lugar de trabajo donde se están realizando las actividades que nos interesan y donde habrá
usuarios representativos.
25
El objetivo de este método es observar a los usuarios para ver como realizan sus tareas y qué
modelo mental tienen de estas, la observación debe ser complementada con preguntas o
entrevistas.
La fase más apropiada para realizar este método es en el análisis de requisitos, que es cuando nos
interesa conocer el entorno de trabajo, los objetos, las personas, las tareas, etc.
Procedimiento.
Las visitas deben ser planeadas con anticipación para evitar la improvisación.
1. Se elige una variedad de usuarios representativos del producto. 2. Se elabora una lista con las preguntas que deseamos nos contesten y de los datos que
queremos recoger. 3. Se debe utilizar el sitio de observación y el tiempo con eficacia y recoger tantos datos
como sea posible en los puntos de observación. 4. El análisis de datos se puede hacer una vez concluida la observación y las entrevistas a los
usuarios. 2. Entrevistas.
Este método resulta ser una manera directa de recoger información acerca de la experiencia del
usuario. Las entrevistas pueden ser abiertas o cerradas, en las primeras el entrevistador sigue un
guion preestablecido, mientras que en las abiertas, se da la posibilidad de que los entrevistados se
expresen con más libertad.
Sirven particularmente para extraer información sobre las preferencias del usuario, impresiones y
actitudes, además de que pueden servir para encontrar problemas no previstos en el diseño.
Para que la técnica tenga un buen efecto, debe ser planeada con antelación, con un conjunto de
preguntas básicas y agregando nuevas preguntas dependiendo del entrevistado.
3. Cuestionarios.
Este método es menos flexible que la entrevista, pero puede llegar a un grupo más numeroso y se
puede analizar mejor, además se puede utilizar muchas veces en el proceso de diseño.
El cuestionario se basa en recolectar información a partir de respuestas contestadas por los
usuarios.
Las siguientes son tipos de preguntas que se pueden incluir en un cuestionario:
1. Pregunta de carácter general. Ayudan a establecer el perfil de usuario, por ejemplo edad, sexo, ocupación, lugar de residencia, etc.
2. Pregunta abierta. Ayudan a recoger información subjetiva, pueden dar sugerencias y
encontrar errores no previstos.
26
3. Preguntas de tipo escalar. Permite preguntar al usuario sobre un punto específico en una escala numérica.
Ejemplo de pregunta de tipo escalar.
¿Es comprensible el diseño de los iconos?__________Poco |1|2|3|4|5| Mucho
4. Pregunta de opción múltiple. Es una pregunta en donde se ofrecen una serie de opciones y se pide responder con una opción o varias. Es útil para recoger experiencia previa del usuario.
Ejemplo de pregunta de opción múltiple. ¿Qué tipo de software has utilizado?
Tratamiento de texto.
Hoja de cálculo.
Bases de datos.
Contabilidad.
5. Pregunta ordenada. Se presentan una serie de opciones a ordenar. Ejemplo de pregunta ordenada. Ordena la utilidad de cómo se ejecuta una acción: 1 la más útil; 2 la siguiente; etc.; 0 si no se utiliza.
Por iconos.
Selección de menú.
Doble clic. Partes de un cuestionario.
Cuando el realizar un cuestionario está vinculado a la ejecución de varias tareas que el evaluador
ha creído conveniente realizar para medir aspectos interactivos del sistema se recomienda dividir
el cuestionario en tres partes:
1. Pretarea: las preguntas de esta sección suelen ser generales sobre ciertas habilidades del usuario (perfil del usuario).
2. Posttarea: esta sección se repetirá tantas veces como tareas tenga que resolver el usuario.
Ejemplo de posttarea.
Después de la realización de un juego de un sitio web orientado a un público muy joven, se pregunta lo siguiente:
27
1. ¿Has tardado mucho en poder empezar a jugar? Si No
2. ¿Te ha gustado el juego? Si No
3. ¿Has leído las instrucciones? Si No
4. Si las has leído, ¿las has encontrado comprensibles? Si No
5. ¿Tenias claro el objetivo que tenias que conseguir? Si No
3. Posttest: sirve para recoger aspectos generales acerca de la percepción general del usuario tras la consecución de las diferentes tareas planteadas.
Ejemplo de posttest.
Tras la realización de todas las tareas planteadas por el evaluador del sitio web orientado a un público joven, se pide a cada usuario que conteste a estas preguntas:
1. El trabajo con este sitio web te ha resultado…
Muy fácil Fácil Normal Difícil Muy difícil
2. Con las opciones del menú, saber lo que me puedo encontrar ha sido…
Muy fácil Fácil Normal Difícil Muy difícil
3. ¿Identificas los juegos con los que puedes jugar a tu edad? Si No
4. ¿Recomendarías el sitio a un amigo? Si No
1.4.2.2.2 Métodos de Test
En este tipo de métodos, usuarios representativos trabajan en tareas utilizando el sistema o un
prototipo y los evaluadores utilizan los resultados para evaluar como la interfaz soporta a los
usuarios con sus tareas.
Las técnicas que se explicarán a continuación serán: medida de las prestaciones, pensar en voz
alta, la interacción constructiva, el test retrospectivo y el método del conductor.
1. Medida de las prestaciones.
Se basa en la toma de medidas acerca del rendimiento u otro aspecto subjetivo que afecte a la
usabilidad del sistema, para lo cual será necesario tener el sistema ya implementado o algún
prototipo que permita evaluar estos aspectos.
Se deben tener en cuenta:
El objetivo primordial es mejorar la usabilidad del producto y no comprobar su funcionalidad.
Se analizará tanto la manera en la que los usuarios utilizan el producto como el tiempo en que tardan en realizar una tarea.
28
Para la realización del test es muy importante la selección de tareas que realizará el usuario, las
cuales deberán ser:
Tareas que demuestren potenciales problemas de usabilidad, cuantos más problemas se encuentren, mejor.
Tareas sugeridas por el desarrollador, basándose en partes de la interfaz que le resultaron difíciles de desarrollar.
Tareas habituales que realizarán los usuarios, para optimizar la usabilidad de los aspectos más cotidianos.
Lo que se puede medir es:
a) Medidas de rendimiento. Explican acciones y comportamientos. Son medidas cuantitativas y pueden contar personas, errores cometidos, veces que se repite algún error, etc.
Ejemplos de medidas de rendimiento.
Tiempo Para completar una tarea. Consumido en menús de navegación. Consumido en ayuda en línea. Para buscar información en un manual. Invertido para recuperarse de errores.
Número De opciones de menú erróneas. De opciones incorrectas en cajas de diálogo. De selección de iconos incorrectos. De teclas de función mal seleccionadas. De llamadas a la ayuda. De pantallas de ayuda en línea. De veces que se consulta el manual.
Observaciones De frustración. De confusión. De satisfacción.
b) Medidas subjetivas. Son las percepciones de las personas, opiniones y juicios. Pueden ser
cuantitativas o cualitativas. Ejemplos de medidas subjetivas.
Reflexiones sobre la: Facilidad de uso del producto. Facilidad de aprender el producto. Facilidad de hacer una determinada tarea. Facilidad de instalar el producto.
29
Facilidad de encontrar información en el manual. Facilidad de comprender la información. Utilidad de los ejemplos de ayuda.
Preferencias o razones de la preferencia: De una versión previa. Sobre un producto de la competencia. De la manera en la que están haciendo las tareas ahora.
Predicciones de comportamiento: ¿Comprará el producto?
Comentarios espontáneos: Estoy totalmente perdido. Ha sido fácil. No comprendo el mensaje. 2. Pensar en voz alta.
En este método se pide a los usuarios que expresen en voz alta sus pensamientos, sentimientos y
opiniones mientras interactúan con el sistema.
Procedimiento.
Se les da a los usuarios el prototipo que hay que probar y un conjunto de tareas que realizar,
después se les pide que realicen las actividades y que expliquen en voz alta que es lo que piensan
al respecto mientras trabajan con la interfaz, que describan que es lo que está pasando, porque
escogen una u otra opción y que es lo que intentan realizar, mientras más impresiones den los
usuarios será mejor para la prueba.
El beneficio principal de esta prueba es una mejor comprensión del modelo mental del usuario y la
interacción con el producto, sin embargo también nos permite conocer la terminología que el
usuario utiliza para las funciones que debería ir incorporada en el diseño.
Sus ventajas son:
Es muy fácil de aplicar.
Proporciona ideas útiles acerca del diseño de la interfaz.
Puede ser utilizado para observar como el sistema se utiliza actualmente.
Puede ser realizado en todas las fases del ciclo de vida y con cualquier prototipo.
Es un método muy económico. Sus desventajas son:
La información propuesta es subjetiva y selectiva.
Describir lo que uno hace con frecuencia cambia la forma de hacerlo, por lo que es posible obtener vistas parciales.
30
3. Interacción constructiva.
Se deriva del método anterior, pero en vez de tener a un solo usuario, se tienen a dos que realizan
la prueba conjuntamente, con esto el test es más natural ya que las personas al resolver un
problema en equipo tienden a verbalizar, lo cual resultará en una mayor cantidad de comentarios.
Sus desventajas son que se requiere del doble de usuarios y estos pueden tener distintas
estrategias de aprendizaje.
4. Test retrospectivo.
Consiste en realizar una grabación en video mientras se realiza algún test visto anteriormente y al
finalizar la prueba se le muestra el video al usuario para que realice comentarios, que usualmente
son más extensos que los realizados mientras se llevaba a cabo el test. Existe la posibilidad de que
el evaluador pare el video y pregunte al usuario con más detalle sin interferir en la prueba que ya
ha sido completada.
El único aspecto negativo es que la prueba se llevará el doble de tiempo en cada usuario.
5. Método del conductor.
En este método existe una interacción explicita entre el usuario y el evaluador, este ultimo
conduce al usuario mientras usa el sistema, durante la prueba el usuario puede preguntar acerca
de la interfaz y el evaluador responderá.
El método se centra en el usuario inexperto y tiene como propósito descubrir las necesidades de
información de los usuarios para proporcionar entrenamiento, documentación y un posible
rediseño de la interfaz para evitar preguntas.
1.4.2.3 Ingeniería de software
Lo que a continuación se detallará serán los puntos clave en donde la ingeniería de la usabilidad se
destaca para crear interfaces mas usables dentro del proceso de la ingeniería del software, por lo
tanto se ahondará en la fase de análisis de requisitos y en la fase del diseño, dejando para su
estudio fuera de este trabajo de investigación la fases de implementación y lanzamiento, ya que
las actividades de esta fase pertenecen mayoritariamente a la ingeniería del software.
1.4.2.3.1 Análisis de requisitos
Según la ingeniería del software, el análisis de requisitos es la fase donde se establecen los
servicios que el sistema debe proporcionar y las restricciones bajo las cuales debe operar. Se
determinan los requisitos que establecen que debe hacer el sistema y como tiene que hacerlo, los
requisitos se dividen en:
a) Funcionales, describen una funcionalidad o servicio del sistema.
b) No funcionales, suelen ser restricciones al sistema o definen el proceso de desarrollo.
31
Ingeniería del software
Especificación del diseño
Diseño de datos Diseño arquitectónico Diseño de módulos Diseño de interfaces
Ingeniería de la usabilidad
Especificación del diseño
Diseño de interfaces Diseño de datos Diseño arquitectónico Diseño de módulos
En el modelo de la usabilidad, se incluye lo anterior y se añade una serie de actividades que
garantizarán el desarrollo de un producto con un más alto grado de usabilidad, las actividades son:
Hacer análisis etnográfico.
Analizar a los stakeholders.
Desarrollar el perfil de usuario.
Desarrollar el perfil de entorno.
Realizar el análisis contextual de tareas.
Identificar y describir los actores, los roles y la organización.
Identificar, describir y relacionar totalmente las listas de tareas.
Identificar y relacionar todos los objetos que intervienen en la interacción.
Describir y determinar las características de la plataforma de ejecución.
Determinar los objetivos de usabilidad que la aplicación deba conseguir. Además de estas actividades, en las cuales ahondaremos más tarde, el modelo propuesto aplica la
gestión de configuración de software mediante un cambio decisivo para conseguir un producto
centrado en el usuario: en la ingeniería del software, el diseño de la interfaz gráfica se realiza
después del diseño de datos, del diseño arquitectónico y del diseño de módulos, en este modelo,
el diseño de interfaces pasa a primer término y el resto es condicionado por la interfaz.
Ilustración 1.20 Pequeña diferencia entre la Ingeniería del software y la Ingeniería de la usabilidad. Fuente: (i Saltiveri, Lorés Vidal, & Cañas Delgado, 2005).
Este cambio, aunque parece insignificante, es muy importante, ya que con mucha frecuencia se
producen cambios en, por ejemplo, la estructura de la base de datos que viene impuesta por un
requisito de la interfaz, si no se elimina el problema en este punto el código presentara
inconsistencias.
La fase de análisis de requisitos de este modelo se interesa por los aspectos de los elementos
relacionados con la interacción persona computador en la que el usuario es el centro del diseño.
En esta fase se estudia el dominio del problema, se interactúa con clientes y usuarios para obtener
información de sus necesidades.
Las actividades que la fase contempla para una buena recopilación de requisitos son:
32
Análisis etnográfico.
La etnografía es un término que deriva de la antropología y se traduce etimológicamente como el
estudio de las etnias y significa el análisis del modo de vida de una raza o grupo de individuos,
mediante la observación y descripción de lo que la gente hace, como se comportan y cómo
interactúan entre sí, para describir sus creencias, valores, motivaciones, perspectivas y como
estos pueden variar en diferentes momentos y circunstancias.
Para realizar esta actividad es necesario adentrarse en el grupo que se quiere estudiar para
aprender su lenguaje, costumbres y puntos de vista.
A continuación se enlistarán las líneas básicas de la etnografía aplicadas al desarrollo de sistemas
interactivos (Kotonya & Sommerville, 1997).
Asumir que las personas realizan correctamente su trabajo y que con mucha frecuencia intentan hacerlo de manera que difiera de la estándar.
Disponer y pasar tiempo suficiente en conocer a las personas e intentar establecer una buena relación con ellas.
Guardar notas detalladas de todas las actividades de su trabajo. Analizarlas y sacar conclusiones con ellos mismos.
Combinar la observación con entrevistas abiertas.
Organizar sesiones regulares de resumen en las que el etnógrafo habla con los usuarios fuera del proceso.
Combinar la etnografía con otras técnicas de adquisición. Si aplicamos la etnografía, se nos facilitarán otras fases del análisis de requisitos, ya que seremos
capaces de:
1. Describir el contexto, el puesto de trabajo y como realizan las personas sus tareas. 2. Detallar y relacionar los objetos que estas personas utilizan. 3. Aumentar información de las tareas. 4. Aumentar cualitativamente y cuantitativamente las conclusiones de una observación de
campo. El principal problema de esta técnica es que si se realiza adecuadamente, el proceso es muy lento,
además de que el etnógrafo es una persona extraña al ambiente y su presencia no se asimila de
forma inmediata.
Análisis de implicados (stakeholders).
Los implicados son personas u organizaciones que serán afectadas por el sistema y que tienen
influencia directa o indirecta en los requisitos del sistema (Kotonya & Sommerville, 1997).
Los implicados se clasifican en cuatro categorías:
Los responsables del diseño y desarrollo.
Los que tienen un interés financiero o económico (responsables de la venta o compra).
33
Los responsables de su implantación y mantenimiento.
Los que tienen interés sobre su uso (los usuarios). En todos los proyectos existen unos implicados muy elementales, cuya identificación resulta ser
muy fácil, pero se debe realizar un esfuerzo para encontrar aquellos que no son tan elementales.
Una vez identificados los implicados se procederá a realizar una reunión llamada reunión de
implicados.
Propuesta de cómo realizar una reunión de implicados.
1. Planificar una reunión de un solo día e invitar a los implicados que tienen conocimiento sobre las intenciones de los usuarios y de su uso, incluyendo:
a) Responsables del negocio. b) Responsables del proyecto. c) Usuarios representativos. d) Responsables de marketing. e) Desarrolladores. f) Responsables de la formación. g) Responsables del mantenimiento.
2. El miembro del equipo de desarrollo encargado de esta reunión prepara una lista con todas las
cuestiones que deben ser tratadas durante la reunión. 3. Las principales recomendaciones para preparar esta reunión son:
a) Antes de la reunión.
Identificar puntos clave que necesitamos explorar.
Proporcionar la agencia y la lista con los puntos que se deben tratar a todos los participantes.
b) Durante la reunión.
Una vez discutidos los puntos clave, deberemos obtener un consenso en aquellos puntos en los que haya habido incertidumbre o disconformidad.
Si se ha echado en falta información, deberá acordarse como se obtendrá.
Realizar una discusión sobre temas menores.
c) Después de la reunión.
Obtener toda la información faltante.
Si la información no es fácil de obtener, realizar un estudio de campo para observar a los usuarios en su ambiente de trabajo.
Proporcionar a los participantes un resumen de la reunión.
34
Clasificar a los usuarios.
Para poder simplificar la interacción del usuario con el sistema, debemos conocer bien a los
usuarios y sus características, es por esto que se clasificarán en términos de dos características
complementarias:
a) El perfil de usuario, que consiste en agrupar a los usuarios según sus capacidades y habilidades, dando lugar a grupos con características semejantes.
b) El rol, que se orienta a las funcionalidades del sistema. Perfil de usuario.
Consiste en descubrir a los usuarios primarios (los que harán uso del sistema frecuentemente) y
los secundarios (quienes lo usarán ocasionalmente), para clasificarlos y describir sus características
más relevantes como el grado de conocimientos, experiencia profesional, nivel de estudios,
entorno social, etc. Estas características servirán para poder tomar decisiones a la hora de diseñar
la interfaz de usuario.
El perfil de los usuarios se puede obtener por diversos métodos, pero los más efectivos son los
cuestionarios y las entrevistas. Una vez analizados, los resultados permiten identificar patrones de
usuarios (características y necesidades semejantes) y reflejarlos en el sistema final.
Roles.
Los roles determinan clases de usuarios que tienen asignados algunos subconjuntos determinados
de tareas, ya sea por elección propia o como resultado de la organización en la que los usuarios se
encuentran.
Más de un usuario puede estar involucrado en un mismo rol y un mismo usuario puede ejercer
más de un rol al mismo tiempo, los roles pueden negociarse entre los actores y ser aceptados o
rechazados.
Existe el concepto de organización, que hace referencia a la relación entre actores y roles en un
contexto determinado, que describe la estructura jerárquica y de delegación de responsabilidades
entre roles, así como el papel de los actores en los distintos roles.
Relación entre los perfiles de usuario y los roles.
La relación entre las dos clasificaciones es que uno o más perfiles de usuario pueden estar
asociados a uno o más de un rol y al revés, por lo tanto la correcta clasificación de los perfiles y la
determinación de los roles asociados están estrechamente vinculadas a las tareas que el sistema
debe ser capaz de ejecutar. Si se resuelve la identificación correcta, la disposición de las
funcionalidades se adaptará bien a los modelos mentales de los perfiles de usuario y se favorecerá
a la usabilidad del sistema.
35
Análisis contextual de tareas.
Este análisis intenta realizar un estudio de las tareas de los usuarios, de cómo las llevan a cabo, de
que patrones de trabajo utilizan, en qué contexto se desarrollan y se trata de entender y
especificar los objetivos de los usuarios.
No se trata de hacer el análisis de las tareas, si no de determinar, a partir del análisis etnográfico
previo, todas las tareas que el sistema es capaz de llevar a cabo relacionadas con el contexto
especifico en que se desarrollan, entendiendo como sistema el conjunto de personas, objetos,
métodos y herramientas que intervienen efectivamente.
La contextualización de las tareas compromete la estructura organizativa en la que se encuentran
los actores con lo cual cohesionan las tareas que el sistema debe llevar a cabo y el contexto en que
se ejecutan.
Otro aspecto a tener en cuenta es el entorno, ya que influye en el trabajo de los actores y
condiciona la manera de llevarlo a cabo, este aspecto influye en el diseño del sistema, ya que
aunque el resultado final de una tarea sea el mismo, los pasos para conseguirla pueden ser
distintos.
Identificar objetos.
Se considera objeto o artefacto a cualquier cosa que intervenga directa o indirectamente en el
proceso de interacción entre la persona y el sistema interactivo, por innecesaria que parezca.
Se debe hacer la observación que el concepto de objeto difiere mucho del utilizado en la
ingeniería del software.
Los objetos pueden ser cosas físicas (una pluma, una tarjeta de crédito, una puerta de entrada,
etc.) o conceptuales (mensajes, textos, gestos, contraseñas, firmas, etc.).
El buscar objetos permite descubrir aspectos de la interacción que aun siendo vitales para el
sistema podrían pasar por alto y emerger en un momento inoportuno en el desarrollo. El
contenido y el significado de los objetos o su disposición en el entorno codifican sus estados y
disparan acciones subyacentes a esta codificación: un papel en un sitio determinado de la mesa
puede significar “archívame”, mientras que en otro lugar –por ejemplo en una bandeja junto con
otros documentos- puede significar “en curso” o incluso en la misma bandeja con un post it que
sale, puede significar “para ser revisado” (Dix et al, 2003). Estas actividades podrían no estar
recogidas en el protocolo oficial del funcionamiento del sistema pero modifican su estado de una
manera tan natural que podrían tener implicaciones en el diseño.
36
Describir las características de la plataforma de ejecución.
En función de la plataforma tecnológica escogida, se deberá estudiar y documentar el conjunto de
posibilidades que esa plataforma nos ofrece, así como las restricciones tecnológicas que nos
impone, esto nos definirá un conjunto de opciones posibles para tener en cuenta a la hora de
diseñar la interfaz de usuario.
Determinar los objetivos de usabilidad.
No hay aplicación que no se realice sin tener un objetivo concreto, ya que el desarrollo de una
aplicación por una empresa, persona o grupo, es consecuencia de haber marcado unos objetivos a
cumplir y por tanto se ve necesaria la implementación de la aplicación como herramienta para
conseguirlos.
Es así que al recoger los objetivos, será necesario identificar los objetivos funcionales, los no
funcionales y aquellos objetivos de usabilidad, una vez definidos estos últimos, será necesario
contrastarlos con los objetivos funcionales para descartar que entren en conflicto y si es así
negociar para adoptar una buena solución realizando un análisis de pros y contras en una reunión
de implicados en la situación.
Solo para recordar, se dirá que la usabilidad es vista generalmente para asegurar que los
productos interactivos sean fáciles de aprender, efectivos y agradables para los usuarios.
Siendo un poco más claros se enunciarán los objetivos básicos de la usabilidad vistos con
anterioridad.
Facilidad de aprendizaje.
Consistencia.
Flexibilidad.
Robustez.
Recuperabilidad.
Tiempo de respuesta.
Adecuación a las tareas.
Disminución de la carga cognitiva.
1.4.2.3.2 Diseño
La principal función de esta fase es el modelado del sistema a partir de los requisitos establecidos
en la etapa anterior. Al usuario no le interesa la estructura de la aplicación, sino como usarla, así
que se deberá empezar con una idea clara de cómo se quiere la interfaz de usuario y como serán
las interacciones con éste, para después desarrollar las especificaciones funcionales que sirvan de
guía en el diseño posterior.
Las actividades relacionadas con esta etapa del modelo de proceso son:
a) El análisis de tareas. b) El modelo conceptual.
37
c) La definición del estilo de acuerdo con lo siguiente:
Los estándares generales.
La definición de las metáforas que se tienen que utilizar.
La definición de los colores que determinaran la interfaz.
Los estándares (generales y particulares).
d) La realización de un diseño detallado. El éxito del producto dependerá de dos factores muy importantes:
1) Que el usuario se sienta cómodo con el sistema en el sentido de no tener errores, que le sea
fácil de usar, que recuerde en donde se encuentran las opciones y sus funcionalidades, etc.
2) Que los responsables obtengan los resultados esperados.
El primer concepto está relacionado con la usabilidad, mientras el segundo con la funcionalidad.
Con la aplicación del modelo se garantiza que los dos aspectos se vean satisfechos ya que el diseño
se ha hecho pensando en los usuarios y para los usuarios y como todo producto de software
desarrollado por los métodos clásicos, la evaluación funcional es lo primero que se prima y no se
da por válido hasta que se cumplen las especificaciones.
A continuación se detallarán las actividades relacionadas con esta etapa:
a) Análisis de tareas.
Gracias a la fase de análisis de requisitos, se obtienen los requisitos funcionales que el sistema
debe satisfacer y una serie de tareas contextualizadas que los usuarios realizan. Ambos grupos
influyen en la materialización de las tareas y deberán traducirse en líneas de código para que el
sistema las realice.
Entonces, el análisis de tareas supone un paso intermedio entre la descripción de las tareas
obtenidas y su codificación, estando orientado a describir las interacciones usuario-sistema de
manera sistemática y eficiente.
Realizar esta actividad antes de la codificación ayuda a dar inicio a un nuevo ciclo de análisis de
requisitos, ya que a menudo afloran detalles que no quedaron perfectamente especificados.
El análisis de tareas según (Dix et al, 2003) es: “el proceso de analizar la manera en la que las
personas realizan sus trabajos: las cosas que hacen, las cosas sobre las cuales actúan y las cosas
que necesitan conocer”.
Al analizar las tareas hay dos fases bien diferenciadas:
1. Obtención de la información necesaria para comprender las actividades que hace el usuario (fase de análisis).
38
2. Representación de la información sobre un modelo adecuado (fase de modelado). La utilidad de esta tarea es:
Ayuda a comprender el dominio de la aplicación (identificar las actividades más importantes y sus relaciones).
Fija, organiza y describe los datos recogidos anteriormente.
Facilita las discusiones interdisciplinarias.
Ayuda a un diseño de la aplicación de forma consistente con el actual modelo conceptual, manteniendo las características más importantes del funcionamiento lógico.
Ayuda al análisis y evaluación de la usabilidad (se puede predecir el rendimiento humano e identificar problemas de uso).
Existen diferentes métodos que permiten llevar a cabo el análisis de tareas y se agrupan en tres
categorías según sus características:
1. Métodos cognitivos.
Identifican secuencias de comportamiento correctas.
Representan el tipo de conocimiento que debe tener el usuario acerca del uso del sistema.
Generan una especificación del usuario a partir de la descripción de tareas.
Los métodos más destacados del grupo son: análisis jerárquico de tareas (HTA), goals-operations-methods-selection (GOMS) y user action notation (UAN).
2. Métodos predictivos.
Evalúan el rendimiento humano.
Describen secuencias de comportamiento.
Hacen un análisis centrado en rutinas de comportamiento.
Los métodos más destacados del grupo son: keystroke level mode (KLM) y task action gramar (TAG).
3. Métodos descriptivos.
Permiten obtener una descripción más o menos completa del sistema a partir de la información de las tareas.
El método más destacado del grupo es: concur task trees (CTT). A continuación se explicarán dos de los métodos cognitivos más usados.
Análisis jerárquico de tareas (HTA).
La técnica de análisis jerárquico de tareas (hierarchical task analisys), HTA, es una de las más
antiguas, pero también una de las más usadas.
En HTA se realiza una descripción de tareas en términos de operaciones y planes:
Las operaciones (descomposición en subtareas), actividades que realizan las personas para alcanzar un objetivo.
Los planes, descripción de las condiciones que se tienen que dar cuando se hace cada una de las actividades.
39
Las operaciones se descomponen de manera jerárquica y se asigna un plan a cada una de las
tareas que aparecen. La representación puede ser gráfica, en árbol descendente o en texto.
El análisis se realiza en tres etapas:
1. Etapa inicial: definir la tarea principal, que puede ser dividida entre cuatro u ocho subtareas. 2. Etapa intermedia: decidir el nivel de detalle que se requiere y el punto donde finalizar la
composición. 3. Etapa final: evaluar y revisar el trabajo para comprobar su consistencia.
Ilustración 1.21 Representación gráfica del análisis de una tarea específica realizada con la finalidad de rediseñar el espacio interactivo de una recepción de un hotel. Fuente: (i Saltiveri, Lorés Vidal, & Cañas Delgado, 2005).
Método GOMS (Goals – Operations – Methods – Selection).
Este método comprende una familia de lenguajes basados en la visión del usuario como un
sistema procesador de información (modelo de procesador humano). Está basado en el
mecanismo de razonamiento humano para la resolución de problemas y formaliza aquellas
actividades (físicas y mentales) que intervienen en la tarea.
La metodología para este método es la siguiente:
Para cada tarea se describe
1. El objetivo (goal) que se debe satisfacer.
Las metas que se propone el usuario (lo que desea obtener).
Los objetivos pueden servir como un punto de referencia en caso de un error.
Un objetivo contiene información de la intención del usuario.
Para esto debe hacer una serie de operaciones básicas.
40
2. El conjunto de operaciones (operations) que el sistema pone a disposición del usuario para la interacción.
Las operaciones son unidades elementales de percepción, motoras o actos cognitivos cuya ejecución es necesaria para cambiar algún aspecto del modelo mental del usuario, o bien para modificar el entorno.
Estas acciones pueden afectar al sistema (pulsar una tecla) o solo afectar al estado mental del usuario (leer un cuadro de diálogo).
Hay un grado de flexibilidad en la granularidad de las operaciones (amplitud de cada operación).
3. Los métodos disponibles (methods) para llevar a cabo estas operaciones.
Posibilidades para descomponer las tareas en subtareas. Por ejemplo en un gestor de ventanas se puede cerrar la ventana mediante ratón en un menú o teclado. Cada una de estas posibilidades será un método.
4. Un conjunto de reglas de selección (selection) para determinar la alternativa más conveniente
en cada caso (descritas mediante estructuras de control if-then).
Cuando hay más de una alternativa, podemos indicar una serie de condiciones y reglas para tomar la mejor alternativa (método).
Cada tarea se podría descomponer en otra tarea primitiva formando un árbol jerárquico.
Ejemplo de una tarea con la notación GOMS en la cual se tiene la descripción de la tarea de mover una pieza en un juego de ajedrez.
GOAL: MOVER-PIEZA GOAL: DETERMINAR-TURNO [select GOAL: CONOCER-ULTIMO-MOVIMIENTO
MOVER-A-LA-HISTORIA-DE-MOVIMIENTOS DETERMINAR-ULTIMO-MOVIMIENTO COMPROBAR-SI-NO-ERES-TU
GOAL: CONOCER-MOVIMIENTO-SIGUIENTE MOVERSE-EN-EL-TABLERO IDENTIFICAR-POSICION-DEL-RELOJ COMPROBAR-SI-RELOJ-EN-TU-POSICION]
GOAL: ESCOGER-MEJOR-ESTRATEGIA GOAL: REALIZAR-MOVIMIENTO GOAL: SELECCIONAR-PIEZA-ADECUADA [select GOAL: IDENTIFICAR-PIEZA
SELECCIONAR-TECLADO ESCRIBIR-IDENTIFICACION-PIEZA CONFIRMAR
GOAL: TOMAR-PIEZA MOVER-CURSOR-A-PIEZA PULSAR-BOTON-RATON]
GOAL: ELEGIR-DESTINO [select GOAL: IDENTIFICAR-DESTINO
MOVER-CURSOR-ARRASTRANDO-PIEZA ESCRIBIR-IDENTIFICACION-POSICION
41
CONFIRMAR GOAL: DEJAR-IR-PIEZA
MOVER-CURSOR-ARRASTRANDO-PIEZA DEJAR-IR-BOTON-RATON]
GOAL: CONFIRMAR-MOVIMIENTO [select GOAL: tecla-confirmacion
PULSAR-ENTER GOAL: PARAR-RELOJ
MOVER-CURSOR -RELOJ PULSAR-BOTON-RATON]
Selection Rule for GOAL: DETERMINAR-TURNO Si es una visualización gráfica, usar el método CONOCER-MOVIMIENTO-SIGUIENTE De otro modo, usar el CONOCER-ULTIMO-MOVIMIENTO Selection Rule for GOAL: SELECCIONAR-PIEZA-APROPIADA Si no tiene ratón usar el método IDENTIFICAR-PIEZA De otro modo usar el método TOMAR-PIEZA Selection Rule for GOAL: ELEGIR-DESTINO Si no tiene ratón usar el método IDENTIFICAR-DESTINO De otro modo usar el método DEJAR-IR-PIEZA Selection Rule for GOAL: CONFIRMAR-MOVIMIENTO Si no tiene ratón usar el método TECLA-CONFIRMACION De otro modo usar el método PARAR-RELOJ
b) Modelos de diálogo como parte del modelo conceptual.
Para desarrollar un modelo conceptual se tiene que pre visualizar el producto basándose en las
necesidades del usuario y otros requisitos identificados.
Se pueden distinguir dos tipos de modelos conceptuales:
Modelos conceptuales basados en las actividades que interactúan con sistemas. Los usuarios se pueden ver en tareas (instruyendo, conversando, manipulando, explorando y hojeando), que no son excluyentes entre sí.
Modelos basados en objetos (como una herramienta, un libro, un vehículo, etc.) utilizados en un determinado contexto.
Esta actividad se materializa con los modelos de diálogo, los cuales plasman la estructura del
diálogo y describen la comunicación con cada participante.
La descripción de los modelos de diálogo se pueden hacer mediante:
Gramáticas. Descripción del diálogo como reglas de producción.
Diagramas de transición de estado.
Redes de Petri. Formalismo, connotación gráfica de actividades concurrentes.
42
Diagramas de transición de estados.
Estos diagramas expresan los posibles estados del sistema (nodos), así como las transiciones
(enlaces) entre los mismos. Se podría incluso identificar el actor que ha provocado la acción. Las
acciones del usuario serán aquellas transiciones realizadas directamente por la participación del
usuario.
Ilustración 1.22 Diagrama de transición de estados para realizar un Check-in y Check-out de una habitación de hotel. Fuente: (i Saltiveri, Lorés Vidal, & Cañas Delgado, 2005).
Diagrama de estados y de actividad UML.
Se dispone de dos diagramas de UML que proporcionan herramientas útiles para matizar el
modelo conceptual del sistema:
1. El diagrama de estados UML. Representan los estados por los que pasa un objeto a lo largo de su vida y que modelan el comportamiento de partes del sistema. Este comportamiento es modelado en términos del estado en el cual se encuentra el objeto, que acciones se ejecutan en cada estado y cuál es el estado al que transita después de un determinado evento.
43
Ilustración 1.23 Diagrama de estados UML que demuestra los estados en que se encuentra un usuario de una biblioteca. Fuente: (i Saltiveri, Lorés Vidal, & Cañas Delgado, 2005).
2. Diagrama de actividad UML. Especifica el comportamiento de los objetos de una clase, la
lógica de una operación, una parte o toda la descripción de un caso de uso y la descripción del flujo de trabajo.
Ilustración 1.24 Diagrama de actividad UML que demuestra la lógica para beber café. Fuente: (i Saltiveri, Lorés Vidal, & Cañas Delgado, 2005).
Según el detalle requerido se hará uso de uno u otro diagrama, incluso de los dos.
44
c) Estilo. Estrategias de diseño de la información.
Esta actividad consiste en definir un estilo que garantice la coherencia general de toda la
aplicación, englobando las facetas de la interfaz, la funcionalidad del sistema y la interactividad
con la que este ofrece dicha funcionalidad al usuario mediante la interfaz.
Una vez definido el estilo se recomienda se documente para que sirva de guía de estilo para toda
la aplicación.
Estándares generales.
El desarrollo de estándares permite que el desarrollo del sistema sea más fácil y seguro,
establecen algunos requisitos mínimos de fabricación y elimina inconsistencias y variaciones
innecesarias en las interfaces, además de que garantizan una terminología e identidad comunes,
facilitan el mantenimiento y reducen el proceso de formación.
Seguir estándares generales en el diseño de cualquier sistema y proteger la uniformidad y la línea
de productos desarrollados mejora la eficiencia del usuario. Los estándares aseguran la coherencia
y consistencia a lo largo del diseño de la interfaz y del sistema entero.
Metáforas.
Se basan en modelos conceptuales que combinan objetos y conocimientos familiares con nuevos
conceptos. Papeles, carpetas, archivadores, buzones de correo y papeleras son representados en
forma de iconos en pantalla, los cuales poseen su propia funcionalidad y propiedades.
Las metáforas son muy importantes para que los usuarios hagan un buen uso del sistema, si esta
se ha hecho con acierto, el usuario intuirá su funcionalidad, no necesitará ayuda adicional y
recordará su uso con facilidad.
Colores.
Es muy importante establecer colores apropiados dependiendo del contexto y de los usuarios a los
que va dirigida la interfaz.
Una buena selección de colores ayudara a disponer de una interfaz agradable, además de que las
funciones críticas serán mucho más accesibles dependiendo de los colores utilizados.
El estilo de colores complementa a las metáforas y les da incluso significados diferentes
dependiendo del color utilizado.
Principios de Gestalt.
Estos principios describen las propiedades de configuración de la información visual, constituyen
uno de los fundamentos de la psicología perceptual y tienen muchas aplicaciones en el diseño de
interfaces que expresan o transmiten información.
45
Y los principios son los siguientes:
1. Proximidad. Elementos visuales con propiedades comunes o cercanas se interpretan como agrupados.
2. Similitud. Objetos que comparten características visuales (forma, color, etc.) se interpretan como grupo.
3. Cierre. Existe la tendencia de percibir elementos discontinuos como completos, ya que las formas cerradas y acabadas son más estables visualmente y nuestra mente los completa, buscando la mejor organización posible.
4. Simetría. Existe la tendencia de ver elementos simétricos como partes de una misma figura. 5. Área. Hay la tendencia a agrupar elementos de manera que se cree la figura más pequeña
posible Estos principios no indican cómo deben presentarse las unidades de información coexistentes en
una interfaz, si no que hacen referencia a las consecuencias perceptuales acerca de su forma,
composición y posición.
Organización de los elementos de la interfaz.
La interfaz organiza la información en estructuras de varios niveles perceptuales. Los elementos
básicos –pixeles, contornos y caracteres- se agrupan en estructuras como párrafos, iconos, listas
de archivos, barras de menú, etc.
Se pueden organizar los elementos de la interfaz siguiendo unas reglas de diseño efectivas como
son:
El balanceado. Busca el equilibrio entre los ejes vertical y horizontal.
La simetría duplica la imagen visual a lo largo de un eje de simetría.
La regularidad. Elementos ubicados regularmente entre filas y columnas.
El alineamiento. Elementos alineados entre sí transmiten una percepción más ordenada de la interfaz.
El enrejillado. Es una técnica que facilita los cuatro puntos anteriores. d) Diseño detallado.
Es la fase, la cual es el resultado de la evolución lógica de las fases anteriores cuando se han
prototipado y evaluado como mínimo una vez.
Se realiza un diseño de la interfaz que recoge todos los detalles de tareas anteriores y con el
mayor detalle posible, hasta disponer de una versión que dispone de todos los mismos detalles
que la versión de software definitiva.
Este modelo será uno de dos que se utilizarán para desarrollar este trabajo de investigación.
46
1.5 Modelo de proceso de reingeniería de software
Lo expuesto en puntos anteriores, consiste en un modelo para asegurar la ingeniería de la
usabilidad que ayuda a crear software altamente usable, pero el propósito de este trabajo no se
centra en crear una aplicación nueva, sino en modificar interfaces para que todas las
funcionalidades del escritorio GNOME se encuentren disponibles de manera gráfica a los usuarios
poco especializados, es por eso que hablaremos acerca de la reingeniería del software.
El proceso de la reingeniería lleva tiempo, consume dinero y absorbe recursos. Es un proceso de
reconstrucción y tiene los siguientes principios:
Antes de empezar la reconstrucción es razonable inspeccionar el producto. Determinar si
es necesaria la reconstrucción requiere que se elabore una lista de criterios de modo que
la inspección resulte sistemática.
Antes de eliminar y reconstruir todo el producto se debe tener la certeza que la estructura
es débil, si la estructura es solida, tal vez sea mejor solo una modificación.
Antes de empezar la reconstrucción se debe entender cómo se construyó el producto
original.
Si se comienza a reconstruir solo se utilizarán las técnicas más modernas para asegurar un
mantenimiento menos costoso.
Si se decide reconstruir se utilizaran prácticas que ofrezcan alta calidad.
La implementación de estos principios requiere aplicar un modelo cíclico de reingeniería del
software que define seis actividades:
Ilustración 1.25 Modelo del proceso de la reingeniería de software. Fuente: (S. Pressman, 2002)
Es un proceso cíclico, puede acabar después de cualquier actividad y no necesariamente tiene que
ser lineal.
47
1.5.1 Análisis de inventarios
Consiste en revisar qué aplicaciones de software se tienen en la organización. El inventario podría
ser una hoja de cálculo que contenga información que proporcione una descripción detallada
(tamaño, edad, importancia para el negocio), de las aplicaciones activas. Al ordenar esta
información, de acuerdo con la importancia para el negocio, antigüedad, facilidad actual del
mantenimiento, etc. aparecen los candidatos para la reingeniería.
1.5.2 Reestructuración de documentos
La poca documentación es un distintivo de los sistemas heredados. Se puede hacer lo siguiente:
Crear documentación consume mucho tiempo. Si el sistema funciona vivirá con lo que se
tenga. Si un programa no sufre cambios, probablemente esté llegando al final de su vida
útil, no es necesario documentarlo.
La documentación debe actualizarse pero se tienen recursos limitados. Se debe utilizar un
enfoque de “documentar cuando se toque”. Se documentan porciones del sistema que
están experimentando cambios. Con el tiempo saldrá documentación útil y relevante.
El sistema es crucial para el negocio y debe volver a documentarse por completo. Es
necesario recortar la documentación a un mínimo esencial.
1.5.3 Ingeniería inversa
Proceso de analizar un programa con la finalidad de crear una representación con un mayor grado
de abstracción que el código fuente, es un proceso de recuperación de diseño. Se obtiene
información del diseño de datos, arquitectónico y de procedimientos a partir de un programa
existente.
El proceso de ingeniería inversa se presenta en la ilustración 1.26, antes de que comiencen las
actividades de la ingeniería inversa, el código fuente sucio “no estructurado” se reestructura, lo
cual facilita la lectura del código fuente y ofrece la base para las siguientes actividades en el
proceso.
La actividad extracción de abstracciones es el núcleo de la ingeniería inversa. El ingeniero debe
evaluar el sistema antiguo y a partir del código fuente comprender como funciona, qué interfaz de
usuario aplica, y qué estructuras de datos o bases de datos utiliza.
48
Extracción de
abstracciones
Refinamiento y
simplificacion
Restructuración
del código
Código fuente sucio
Código fuente limpio
Especificación inicial
Especificación final
Base de datos
Interfaz
Procesamiento
Ilustración 1.26 Proceso de la ingeniería inversa. Fuente: (S. Pressman, 2002)
1.5.3.1 Ingeniería inversa para comprender datos
Esta actividad ocurre en distintos grados de abstracción y suele ser la primera tarea de
reingeniería. A nivel de programa, las estructuras de datos internos del programa deben
someterse a reingeniería inversa como parte de un esfuerzo global de reingeniería. En el nivel de
sistema, las estructuras globales de datos, por ejemplo archivos, bases datos, con frecuencia se
someten a reingeniería para ajustarlos con los nuevos paradigmas de gestión de base de datos o
reemplazar la base de datos actual. Como este trabajo no contempla bases de datos, no se
ahondará en este aspecto, para su estudio se pide al lector que consulte la siguiente fuente: (S.
Pressman, 2002).
Estructuras de datos internos. Se enfoca en la definición de clases objeto, se logra
examinando el código del programa para agrupar las variables de programa relacionadas.
La organización del código identifica tipos abstractos de datos.
1.5.3.2 Ingeniería inversa para comprender el procesamiento
Esta actividad comienza comprendiendo para luego extraer abstracciones de procedimientos
representadas por el código fuente. Para comprender las abstracciones de procedimientos el
49
código se analiza en grados variables de abstracción: sistema, programa, componentes, patrón y
planteamiento.
La funcionalidad global del sistema de aplicación se debe comprender antes de que ocurra un
trabajo de ingeniería inversa más detallado. Cada uno de los programas que conforman el sistema
de aplicación representa una abstracción funcional en un mayor grado de detalle. Cada
componente realiza una subfunción y representa una abstracción de procedimiento definida. Para
cada componente se desarrolla una narrativa de procesamiento.
Cuando se considera el código dentro de un componente, el ingeniero debe buscar secciones de
código que representen patrones de procedimiento genéricos. En un componente una sección del
código prepara los datos para el procesamiento, una sección distinta realiza el procesamiento y
otra sección prepara los resultados del procesamiento para exportarlos desde el componente.
Dentro de cada una de las secciones se pueden encontrar algunos patrones, por ejemplo la
validación de los datos y la verificación de enlaces con frecuencia ocurre dentro de la sección de
código que prepara los datos para el procesamiento.
1.5.3.3 Ingeniería inversa de interfaces de usuario
Las interfaces de usuario sofisticadas son indispensables en productos de software, debido a esto,
desarrollar de nuevo interfaces de usuario es uno de los tipos más comunes de reingeniería. Y para
lograrlo se necesita de la ingeniería inversa.
Para entender una interfaz de usuario se requiere especificar la estructura y el comportamiento de
la interfaz. Para esto se sugiere responder tres preguntas básicas:
1. ¿Cuáles son las acciones básicas (por ejemplo, presiones de teclas o clics de ratón) que
debe procesar la interfaz?
2. ¿Cuál es la descripción compacta de las respuestas del comportamiento del sistema a
estas acciones?
3. ¿Qué se entiende por “reemplazo” o, más exactamente, que concepto de equivalencia de
interfaces es relevante en este caso?
Mucha de la información necesaria para crear el patrón de comportamiento se puede obtener
observando la manifestación externa de la interfaz existente, pero la información adicional se
debe extraer del código.
1.5.4 Reestructuración
La reestructuración de software modifica el código fuente o los datos con la finalidad de
adecuarlos para futuros cambios, no modifica la arquitectura global del programa, se enfoca en los
detalles del diseño de los módulos individuales y en las estructuras locales definidos dentro de los
módulos. Ocurre cuando la arquitectura del software es sólida, aun que el interior necesite
trabajarse. Se inicia cuando grandes partes del software son funcionales y solo un subconjunto de
los componentes y datos necesitan una modificación.
50
1.5.4.1 Restructuración de código
Algunos sistemas heredados tienen una arquitectura solida, pero sus módulos individuales se
codificaron de tal forma que dificulta comprenderlos, probarlos y mantenerlos. Es estos casos se
reestructura el código dentro del módulo.
Se realiza para generar un diseño que produzca la misma función que el programa original, pero
con mayor calidad, para ello se utilizan técnicas de reestructuración de código que modelan la
lógica del programa utilizando algebra booleana y aplican una serie de reglas de transformación
que producen lógica estructurada.
1.5.4.2 Restructuración de datos
Es una actividad de reingeniería a gran escala y comienza con una actividad de reingeniería
inversa. La arquitectura de datos actual se analiza y se definen los modelos de datos necesarios. Se
identifican los objetos de datos y atributos y después se revisa la calidad de las estructuras de
datos existentes.
Debido a que la arquitectura de datos tiene una gran influencia sobre la arquitectura del
programa, los cambios en los datos resultarán en cambios arquitectónicos.
La actividad con la que inicia la reestructuración de datos es la de análisis del código fuente.
Primero se evalúan todos los enunciados del lenguaje de programación que contengan
definiciones de datos, descripciones de archivos, I/O y descripciones de interfaz, con la finalidad
de extraer elementos y objetos de datos para obtener información acerca del flujo de datos y
comprender las estructuras de datos que se han implementado. A esto se le llama análisis de
datos.
Una vez completado el análisis de datos comienza el rediseño de datos. En su forma más simple,
un paso de estandarización de registro de datos clarifica las definiciones de datos para lograr
consistencia entre los nombres de elementos de datos o formatos de registro físicos dentro de una
estructura de datos existente o formato de archivo. Otra forma de rediseño, llamada
racionalización del nombre de los datos asegura que todas las convenciones de nombramiento de
los datos concuerdan con el estándar local y que los pseudónimos se eliminan como flujos de
datos a través del sistema.
Cuando la reestructuración rebasa la estandarización y la nacionalización se realizan
modificaciones físicas a las estructuras de datos existentes para lograr que el diseño de los datos
sea más efectivo.
1.5.5 Ingeniería directa
Recupera la información de diseño a partir del software existente y utiliza esta información para
alterar o reconstituir el sistema existente con la finalidad de mejorar su calidad global. En la
mayoría de los casos el software sometido a reingeniería vuelve a implementar la función del
sistema existente y mejora el desempeño global.
51
Imagine que un programa muy extenso, con muy pocos comentarios en su código fuente y sin
documentación se debiera modificar para que se ajuste a los cambiantes requerimientos de los
usuarios. Se tienen las siguientes opciones:
1. Se puede trabajar modificación tras modificación, luchando con el diseño implícito y el
código fuente para implementar los cambios necesarios.
2. Se puede intentar comprender el extenso funcionamiento interno del programa con el
propósito de realizar modificaciones de manera más eficiente.
3. Se puede rediseñar, recodificar y probar aquellas porciones del software que requieran
modificación mediante la aplicación de un enfoque de ingeniería del software.
4. No existe una opción correcta, las circunstancias pueden dictar la primera opción, aunque
las otras sean más deseables.
Si en lugar de esperar que se reciba la solicitud de mantenimiento, la organización de desarrollo
utiliza los resultados del análisis de inventarios para seleccionar un programa que:
a) Se empleará durante un número determinado de años.
b) Actualmente se utiliza con éxito.
c) Es probable que experimentará grandes modificaciones o mejoras en el futuro cercano.
Entonces se emplearían las opciones 2, 3 ó 4.
Tal vez resulte un poco extraño hablar del desarrollo de un nuevo programa cuando aún existe una
versión operativa, pero tómese a consideración lo siguiente:
El costo de mantener una línea de código oscila entre 20 y 40 veces el costo de su
desarrollo inicial.
Rediseñar la arquitectura de software empleando conceptos modernos de diseño, facilita
el mantenimiento.
Debido a que existe un prototipo de software, el desarrollo de la productividad debe ser
mucho mayor que el promedio.
Ya que el cliente tiene experiencia con el software, los nuevos requisitos y la dirección del
cambio pueden afirmarse con mayor facilidad.
Antes de terminar el mantenimiento preventivo existirá una configuración completa del
software (documentos, programas y datos).
Cuando una organización de desarrollo de software vende software como producto el
mantenimiento preventivo se considera como “nuevas liberaciones” de un programa.
En la mayoría de los casos la ingeniería directa no solo crea versiones modernas de un programa,
utilizando los nuevos requisitos de usuario y nuevas tecnologías, se crea un nuevo programa que
amplía las capacidades del anterior.
52
1.5.5.1 Ingeniería directa de interfaces de usuario
Se sugiere el siguiente modelo para la reingeniería de interfaces de usuario:
1. Comprender la interfaz original y los datos que se trasladan entre ella y el resto de la
aplicación. Tiene como finalidad entender como otros elementos de un programa
interactúan con el código existente que implementa la interfaz. Si se desarrolla una nueva
interfaz, los datos que fluyan entre esta y el programa deben ser consistentes con los
datos que actualmente fluyen entre la interfaz a reemplazar y el programa.
2. Remodelar el comportamiento implícito en la interfaz existente en una serie de
abstracciones que tengan sentido en el contexto de una interfaz gráfica. Aunque el modo
de interacción puede ser diferente, el comportamiento de negocios que muestran los
usuarios de las interfaces nueva y vieja debe permanecer igual.
3. Introducir mejoras que hagan más eficiente el modo de interacción. Las fallas ergonómicas
de la interfaz existente se estudian y se corrigen en el diseño de la nueva interfaz gráfica.
4. Construir e integrar la nueva interfaz gráfica de usuario. La existencia de bibliotecas y
herramientas automatizadas reduce significativamente el trabajo para construir la interfaz
gráfica de usuario. Sin embargo la integración con el software de la aplicación existente
puede requerir más tiempo. Se debe tener especial cuidado de garantizar que la interfaz
nueva no introduzca efectos colaterales adversos al resto de la aplicación.
Con este modelo de reingeniería y el modelo de la ingeniería de la usabilidad se dispondrá a
realizar este trabajo de investigación sobre el objeto de estudio que a continuación se expondrá.
53
Capítulo 2 Distribución Ubuntu y el proyecto GNOME En este capítulo se presentarán los conceptos del proyecto GNU, el Kernel Linux, se hablará de
cómo la unión de estas dos tecnologías da paso a las distribuciones GNU/Linux, además se
adentrará en el proyecto Ubuntu y el proyecto GNOME que son los objetos de estudio de este
proyecto de investigación y para finalizar se explicará el funcionamiento del editor de
configuraciones gconf.
2.1 Antecedentes GNU/Linux
El sistema operativo GNU/Linux es concebido gracias a la unión de aplicaciones del proyecto GNU
y el kernel Linux, ambos, las aplicaciones y el kernel están registrados bajo la Licencia Publica
General GNU (GPL). A continuación se explicará los antecedentes de GNU y Linux.
2.1.1 El proyecto GNU
El proyecto GNU consiste en la creación de un sistema operativo libre, funcional y compatible con
Unix, su nombre es el acrónimo recursivo GNU is not Unix (GNU no es Unix). Lo que en esta
sección se expondrá está basado en lo descrito en (Stallman, 1999), (GNU.org) y
(FundacionCopyleft.org).
En 1971 Richard Stallman comenzó su carrera en el MIT (Instituto de Tecnología de
Massachusetts), donde formó parte de una comunidad en donde se compartía software, de hecho
compartir el software era una actividad muy común hasta inicios de los ochenta.
Las computadoras del laboratorio que él utilizaba, tenían un sistema operativo creado por los
propios administradores y siendo parte del grupo de administradores, su trabajo era mejorarlo.
Cuando otra universidad o empresa deseaba portar o usar un programa, los administradores lo
permitían y de la misma forma cuando Stallman deseaba ver el código fuente para leerlo,
modificarlo o crear un nuevo programa a partir de código existente solo necesitaba pedirlo.
Para 1980, las computadoras del laboratorio se descontinuaron, así que el sistema operativo
creado por los administradores se volvió obsoleto.
En 1981 la empresa llamada Symbolics contrató a la mayoría de administradores del laboratorio y
en 1982 el laboratorio reemplazó los equipos de cómputo y los administradores en turno,
decidieron usar el sistema operativo de los nuevos equipos el cual no era libre. En este punto
Stallman, quien tiene la firme creencia de que el software privativo limita los derechos del usuario
al prohibir que el código fuente sea compartido y mejorado, sintió que como programador debía
hacer un cambio para que los programadores de la época pudieran compartir software en un
entorno libre de restricciones, y lo primero que vino a su mente fue la creación de un sistema
operativo ya que este es el software crucial para usar una computadora.
54
Siendo Stallman un programador de sistemas operativos, pensó que el trabajo era adecuado para
él y decidió que este nuevo sistema operativo fuera compatible con UNIX por dos razones, la
primera es la portabilidad y la segunda fue para que los usuarios de UNIX pudieran cambiarse con
facilidad.
Fue así como creó los principios del software libre:
“Un programa es software libre si un usuario en particular:
Tiene la libertad de ejecutar el programa, como quiera, para cualquier propósito.
Tiene la libertad de adaptar el programa de acuerdo a sus necesidades (para que esta libertad sea efectiva en la práctica, debe tener acceso al código fuente; porque modificar un programa sin disponer del código fuente es extraordinariamente difícil).
Tiene la libertad para redistribuir copias, tanto gratis como por un precio.
Tiene la libertad para distribuir versiones modificadas del programa, de modo que la comunidad pueda beneficiarse de sus mejoras.”1
Como se puede ver el proyecto surgió a manera de liberación social, para eliminar las ataduras que
el software privativo imponía a sus usuarios, y nada tiene que ver con que el software se
distribuya sin costo.
En 1984 Richard Stallman decidió dejar su trabajo en el MIT, para evitar que el software que el
desarrollara fuera reclamado por la institución, sin embargo se le dio la oportunidad de usar las
instalaciones para realizar su proyecto.
El primer software que Richard Stallman escribió para el proyecto GNU fue Emacs, el cual es un
editor extensible, en 1984 y un año más tarde el programa ya era usable, de tal forma que la gente
pedía usarlo, en tal punto Stallman respondió a la demanda, colocando el programa en un servidor
ftp del MIT. Esta solución fue factible para las personas que tenían internet, pero había muchas
otras que no contaban con este servicio, así que anunció que proporcionaría una cinta con una
copia del programa a quien le mandara 150 dolares, de esta forma Stallman comenzó a ganar
dinero con el software libre, dando inicio a las compañías que actualmente distribuyen sistemas
completos de GNU/Linux.
El software libre ya se estaba distribuyendo, pero no había forma de evitar que alguien modificara
este software y lo envolviera con acuerdos de confidencialidad, no existía medio alguno para
asegurar que el software de GNU siguiera siendo libre una vez distribuido, es por esto que se creó
un término de distribución llamado Copyleft.
1 18. Stallman, Richard. The GNU Operating System and the Free Software Movement. Open
Sources : Voices from the Open Source Revolution. s.l. : O'REILLY, 1999.
55
El Copyleft es un grupo de licencias cuyo objetivo es garantizar que cada persona que recibe una
copia de una obra pueda a su vez usar, modificar y redistribuir el propio trabajo y las versiones
derivadas del mismo, pero prohíbe agregar restricciones por su cuenta. Unas veces se permite el
uso comercial de dichos trabajos y en otras ocasiones no, dependiendo de los derechos que quiera
ceder el autor. En lugar de ser un medio para restringir un programa, se transforma en un medio
para mantener al programa libre.
La implementación específica de Copyleft que se usa para la mayoría del software de GNU es la
Licencia Pública General de GNU (GNU General Public License) o GPL de GNU. Pero hay otras
clases de Copyleft que se usan en circunstancias específicas, por ejemplo, los manuales de GNU
están bajo la Licencia de documentación libre de GNU (FDL de GNU) y ciertas librerías como la
biblioteca C de GNU usa una clase especial de Copyleft denominado GNU Lesser General Public
License (Licencia Publica General Reducida de GNU), que da permiso para enlazar software
privativo con la biblioteca.
Debido al éxito de Emacs, muchas personas se interesaron por el proyecto GNU, así que una vez
más fue necesario buscar fondos, fue por este motivo que en 1985 se crea la Free Software
Foundation (fundación del software libre FSF), la cual es una organización sin ánimo de lucro para
el desarrollo de software libre. Esta fundación se dedicó a vender cintas con más software libre y
manuales libres. Hoy en día sigue vendiendo productos, pero la mayor parte del apoyo lo dan las
cuotas de los socios.
La meta de GNU es ser software libre, y aunque GNU no tuviese ventajas técnicas sobre Unix,
tendría una ventaja social, permitir cooperar a los usuarios, y una ventaja ética, respetar la
libertad de los usuarios.
La forma de implementar módulos de GNU consistía en reemplazar el existente de Unix por el
nuevo de GNU, es decir, cada componente podía ser utilizado en ambientes Unix, antes de que
existiera un sistema GNU completo, esto hizo posible que muchas aplicaciones se hicieran
populares y atrajeran fondos y contribuyentes, pero también ocasionó una demora en la
conclusión de un sistema mínimo por varios años, ya que el tiempo de los desarrolladores se
centraba en extender y portar los módulos a sistemas Unix incompatibles y en agregar
características, en vez de desarrollar uno tras otro los módulos GNU que hacían falta.
Es así que en 1990, el sistema GNU ya contaba con GCC, que es un compilador de C, gracias al cual
muchas aplicaciones habían sido desarrolladas y la mayor parte de las bibliotecas y utilidades que
componen un sistema operativo Unix típicos, se podría decir que el sistema estaba casi
completado, el único módulo importante que hacía falta era el núcleo. El Hurd de GNU es una
colección de servidores que corren encima de un micro núcleo desarrollado en la Carnegie Mellon
University y luego en la Universidad de Utah llamado Mach, el Hurd se ocupa de las diversas tareas
del núcleo Unix.
El Hurd de GNU aún no está listo para el uso en producción, debido a que ha sido muy difícil de
depurar, sin embargo en 1992 se liberó un núcleo compatible con Unix, el kernel Linux y al
56
combinar este kernel con el incompleto sistema GNU, se hizo posible tener un sistema operativo
libre.
2.1.2 El kernel Linux
Linux es el núcleo de un sistema operativo libre tipo Unix, su desarrollo comenzó en 1991 por
Linus Benedict Torvalds, actualmente participan en su desarrollo un incontable número de
programadores y se encuentra en la versión estable 3.1.7.
Para conocer la historia de Linux, es necesario narrar la evolución del sistema operativo Unix, ya
que Linux fue creado a partir de una versión inspirada en este. Linux y su historia puede ser
consultada en (Sánchez Prieto, 1999), (S. Tanenbaum, 2003), (González Sánchez & Gazo Cervero,
2003) y (Torvald, 1999).
En 1964 los laboratorios Bell de AT&T en cooperación con el MIT y la General Electric trabajaban
en la creación de un sistema operativo que se suponía que debía atender a muchos usuarios,
muchas computadoras y una gran cantidad de periféricos al mismo tiempo, su nombre era Multics
(Multiplexed Information and Computing Service) y era desarrollado para ser utilizado en un
mainframe modelo GE-635 , pero en 1969 los laboratorios Bell dejaron el proyecto por
considerarlo muy poco útil y demasiado complejo.
En ese entonces, un programador de los laboratorios Bell llamado Ken Thompson, encontró una
computadora DEC PDP-7 inactiva y se puso a desarrollar un juego al que nombró Space Travel, el
desarrollo de este juego, aportó a Thompson un gran conocimiento de la PDP-7 (Sánchez Prieto,
1999). Con estos conocimientos, decidió escribir un MULTICS “austero” en ensamblador, el cual
fue llamado UNICS (UNiplexed Information and Computing Service), por otro investigador de los
laboratorios Bell de nombre Brian Kernighan, pronto la ortografía del nombre del sistema cambió
a UNIX.
El desarrollo de Thompson impresionó a sus compañeros en los laboratorios Bell y pronto se le
unió Denis Ritchie y su departamento, quien anteriormente había trabajado en el proyecto
MULTICS.
Por estas fechas el sistema se migró de la PDP-7 a máquinas mejores como eran la PDP-11/45 y la
PDP-11/70, con lo cual se comprobó que no era nada fácil el tener que reescribir el sistema en
ensamblador para cada máquina, así que Ken Thompson realizó una modificación al lenguaje
BCPL de Martin Richard, al cual nombró lenguaje B, todo esto se debía a que buscaba reescribir el
código de UNIX en un lenguaje de alto nivel que fuera portable y flexible en lugar del ensamblador,
pero fue hasta 1972, que Dennis Ritchie crea el lenguaje C, (Saavedra Gutierrez), el cual es una
modificación del lenguaje B y también crea un compilador de C. En conjunto, Dennis Ritchie y Ken
Thompson migraron todo el sistema UNIX a este lenguaje.
Una vez que UNIX fue portable se hizo popular en los laboratorios Bell y cada vez más gente lo usó
en sus computadoras. AT&T puso UNIX a disposición de las universidades, empresas privadas y del
gobierno de los Estados Unidos a través de licencias.
57
El Departamento de Computación de la Universidad de California, con sede en Berkeley recibió
una de estas licencias, y en 1975 desarrolló y publicó su propio sistema parecido a UNIX, conocido
como Berkeley Software Distribution (BSD), que más tarde se convertiría en un fuerte competidor
del UNIX de AT&T.
El desarrollo del sistema prosiguió por parte de AT&T quien creó una división comercial
denominada Unix Systems Laboratories para la explotación comercial del sistema, entregando las
versiones 4, 5 y 6 a lo largo de 1975.
En 1979 entró en circulación la última versión del UNIX original, la versión 7, y en la década de los
ochentas se desarrollaron las versiones 8, 9 y 10 pero solo fueron distribuidas a universidades, el
resultado de estas versiones fue la creación de Plan 9 de los laboratorios Bell, el cual fue diseñado
para ser el sucesor de UNIX.
Cabe resaltar que hasta la versión 6 AT&T permitía ver el código fuente del sistema, John Lions de
la Universidad de New South Wales en Australia, llegó a escribir un pequeño libro que describía su
operación, línea por línea. Este libro se utilizó, con permiso de AT&T, como libro de texto en
muchos cursos universitarios sobre sistemas operativos. Pero con la llegada de la versión 7, AT&T
se dio cuenta que UNIX era un buen producto comercial y emitió la versión con una licencia que
impedía el estudio del código fuente.
En 1981 AT&T desarrolló UNIX System III, que se baso en la versión 7 como una variante para
comercializar, otras compañías vendían ya otros Unix basados en versiones distintas a la 7, es así
que se creaba confusión entre versiones, por tal motivo AT&T decidió unir las versiones que había
en las universidad y otras empresas, para conformar en 1983 el UNIX System V y es de este
sistema que se desprenden las variantes que existen hoy en día.
Para mediados de los ochenta, solo compañías comerciales fabricaban y mantenían los sistemas
operativos y programas que las computadoras necesitaban. Estas compañías hacían firmar
contratos de licencia a los usuarios, a quienes comprometían a no modificar sus programas, a no
compartirlos y no permitían ver el código fuente, lo cual fue intolerable para muchos usuarios y
como reacción surgió el proyecto GNU.
Fue entonces que Andrew Tannebaum decidió escribir un sistema operativo desde cero que sería
compatible con UNIX desde el punto de vista del usuario, pero sin una sola línea de código de
AT&T, este sistema evadía los contratos de licencia y podía ser utilizado para enseñar en las
universidades. Minix fue el nombre de este sistema operativo, además de eliminar los problemas
con las licencias, Minix fue escrito de una forma más modular, lo cual permitió que los estudiantes
pudieran comprenderlo mejor. Fue publicado en 1987 en el libro Operating Systems: Design and
Implementation de Tannebaum.
Como sistema operativo, Minix no era el mejor, pero había una ventaja, cualquiera que comprara
el libro de Tannebaum podía tener acceso al código fuente.
58
Entonces en 1991 un estudiante de informática de la Universidad de Helsinki llamado Linus
Benedict Torvalds a los 21 años de edad impulsado por el movimiento de GNU y tras haber usado
Minix, decidió crear un sistema operativo libre parecido a Minix, el 25 de agosto Linus mandó un
correo al grupo de noticias de Minix en el que señalaba su impulso y anunciando que estaba
utilizando software de GNU.
La versión 0,01 de Linux fue lanzada a mediados de septiembre de 1991 y fue puesta en la red. El
entusiasmo rodeó la nueva creación, y los códigos fuente fueron descargados, probados,
modificados y devueltos a Linus. La versión 0.02 llegó el 5 de octubre, esta versión ya podía ser
ejecutada.
La versión 0.03 de Linux llegó en pocas semanas. En diciembre llegó la versión 0.10. Todavía Linux
no era más que un pequeño esqueleto. Sólo tenía soporte para discos duros AT, no tenía login. La
versión 0.11 fue mucho mejor con soporte para teclados multilingües, controlador para la
disquetera, soporte para VGA, EGA, Hercules, etc. Las versiones pasaron enseguida desde la 0.12 a
la 0.95 y 0.96. Rápidamente, el código se distribuyó a lo largo de todo el mundo desde sitios ftp de
Finlandia y algunos otros lugares.
Al principio Linux fue distribuido con una licencia de código fuente compartida (share source),
pero a mediados de diciembre de 1992 con la salida de la versión 0.99, Linus decidió publicar la
versión bajo la licencia GPL de GNU.
El desarrollo de este núcleo hizo posible que el sistema operativo libre del proyecto GNU por fin
pudiera ser desarrollado como un todo, dando paso al llamado sistema operativo GNU/Linux.
2.1.3 Distribución GNU/Linux
Se denomina como distribución GNU/Linux a la unión de tecnologías del proyecto GNU, el kernel
Linux y programas de aplicación de propósitos específicos o generales. Tienen como objetivo
ofrecer ediciones del sistema que realicen trabajos para satisfacer las necesidades de un cierto
grupo de usuarios.
Antes de que existiesen las distribuciones, un usuario que deseara probar el funcionamiento de
GNU/Linux debía tener el conocimiento suficiente de Unix para saber que bibliotecas, que
ejecutables y que configuración de archivos en el sistema debía usar para que el sistema fuera
operable.
No se sabe con precisión cuál fue la primera distribución, pero este título se le atribuye a MCC
Interim Linux, desarrollada en 1992 por Owen Le Blanc del Manchester Computing Centre, era
capaz de ser instalada en una computadora, pero no corría en modo gráfico. Después surgió Tamu
Linux desarrollada por la Universidad Texas A&M, esta distribución fue la primera en implementar
el modo gráfico.
A mediados de 1992 la distribución más usada era Softlanding Linux System (SLS), hecha por Peter
MacDonald y era descendiente de MCC, se convirtió en la más usada ya que contenía más
59
utilidades que otras distribuciones. Tiempo después Patrick Volkerding modificó SLS, corrigiendo
algunos errores e incluyendo numerosas mejoras, al producto terminado lo llamó Slackware y lo
liberó el 16 de julio de 1993, esta distribución aun en la actualidad se encuentra soportada, su
versión más reciente es la 13.37.
Siendo Slackware basada en SLS, pronto la popularidad de SLS disminuyó y la mayoría de gente se
cambio a Slackware.
En 1993 se desarrolló la primer distribución comercial llamada Yggdrasil Linux/GNU/X, o LGX, fue
desarrollada por Yggdrasil Computing, Incorporated, una empresa fundada por Adam J. Richter en
Berkeley, California, se le considera como la propulsora de las distribuciones live cd, ya que se
distribuyó en cd-rom.
El 16 de agosto de 1993 nace el proyecto Debian, comenzado por Ian Murdock, quien desarrolló
una herramienta llamada apt la cual es una de las herramientas mejor planeadas para instalar,
mantener y actualizar un sistema operativo.
En 1994 nacen SUSE y RedHat, dos de las más importantes distribuciones, ya que de ellas se han
derivado bastantes más.
En 1996 surge Conectiva, que es de origen brasileño y en 1998 Mandrake de origen francés, las
cuales en el 2005 se unen para formar Mandriva.
Con el paso del tiempo se fueron desarrollando nuevas distribuciones, algunas cambiaron al
esquema comercial y otras desaparecieron, es así que en el 2004 nace Ubuntu, en la cual este
trabajo de investigación será desarrollado, pero del cual, hablaremos en el punto 2.3.
2.2 GNU/Linux en el mercado actual
Desde que en 1992 se introdujo el kernel de Linux en el proyecto GNU, se logró la implementación
de un sistema operativo tipo UNIX completamente libre. Cuando a esta unión se le adicionaron
aplicaciones de propósito específico se dio origen a lo que llamamos distribución GNU/Linux y
estas distribuciones son ampliamente usadas. A continuación se hablará acerca del uso que se le
da a las distribuciones en la actualidad.
La empresa de investigación de negocios y medios Focus publicó una lista de 50 sitios que usan
GNU/Linux como sistema operativo, en su estudio hace la separación en tres ramas: Gobierno,
Educación y Negocios (FOCUS). A continuación se darán los nombres de algunos sitios del estudio
junto con la distribución que usan:
Gobierno:
Como ejemplo pueden señalarse: El departamento de defensa de Estados Unidos usando Red Hat;
la ciudad de Munich, Alemania que decidió migrar 14000 equipos a Debian; algunos organismos en
España crearon su propia distribución llamada LinEx basada en Debian; La Administración Federal
60
de Aviación en Estados Unidos usa Red Hat Enterprise Linux; el Parlamento francés decidió migrar
de Windows a Ubuntu; el gobierno de Cuba que desarrolló su distribución llamada Nova; el
servicio de correo Checo cambió a SuSe desde 2005; etc.
Educación:
Universidades Alemanas desde 2007, unos 600 mil estudiantes alemanes de 33 universidades
están soportados por sistemas de Novell SuSe Linux Enterprise Desktop; Filipinas usa Ubuntu y
Fedora en las escuelas desde 1997, debido a los menores costos de instalación y mantenimiento;
el estado de Georgia, EE.UU, usa Kubuntu, Ubuntu y Fedora desde 2004 en sus escuelas; existe un
programa llamado One Laptop Per Child (Una Laptop Por Niño), el cual tiene instalado alguna
versión de GNU/Linux; etc.
Negocios:
El cluster de servidores usado por Google corre bajo una versión personalizada de Ubuntu
denominada Goobuntu; Virgin America, una aerolínea económica de Estados Unidos, usa Red Hat
y Fedora para su sistema de entretenimiento en vuelo; Peugeot, en 2007 anunció que instalaría
20 mil copias de Novell Desktop Linux y 2500 de SuSe Linux Enterprise Server; Wikipedia migró 400
servidores a Ubuntu en 2008, luego de haber usado Red Hat y Fedora; la Bolsa de New York usa
Red Hat Enterprise Linux para su plataforma de compraventa de acciones; Equipos Dell y otros
fabricantes venden algunos equipos con Ubuntu y otras distribuciones; etc.
Aparte de lo anteriormente mencionado, distribuciones GNU/Linux son usadas en el 91.4% de las
500 supercomputadoras de propósito general en el mundo, según estadísticas llevadas a cabo en
el mes de Noviembre de 2011 por TOP500, como lo podemos ver en la ilustración 2.1.
61
Ilustración 2.1 Sistemas operativos usados por supercomputadoras en Noviembre de 2011. Fuente: top500.org
Además, la tendencia del uso de GNU/Linux en supercomputadoras va en aumento como lo
podemos ver en la figura 2.2.
Ilustración 2.2 Tendencia del uso de GNU/Linux en supercomputadoras. Fuente: top500.org
62
En el ambiente de escritorio GNU/Linux no es el más usado, según estadísticas del sitio
www.w3counter.com, al mes de Diciembre de 2011, Linux se encuentra con el 1.64% en uso
dentro del ambiente personal, como se puede ver en la figura 2.3.
Ilustración 2.3 Porcentaje del uso de GNU/Linux en computadoras personales. Fuente: w3counter.com
Pero de igual manera que en las supercomputadoras, su uso en computadoras personales va en
aumento teniendo en Enero de 2011 1.38%, en Agosto de 2011 1.55% y por último en el mes de
Diciembre 2011 1.64%, según datos de www.w3counter.com.
No existe método para saber que distribución es la más usada, sin embargo existe un sitio en
internet que mide cual es la más popular, ese sitio es distrowatch.com y según su información
medida en Enero de 2012 la distribución más popular es Linux Mint como se puede ver en la figura
2.4, esta figura muestra la popularidad de las distribuciones un mes, tres meses, seis meses y doce
meses atrás.
63
Ilustración 2.4 Puntos de popularidad por clic al día para cada distribución. Fuente: ditrowatch.com
La distribución de interés para este trabajo de investigación es Ubuntu así que en el siguiente
punto hablaremos acerca de ella.
2.3 Ubuntu y su filosofía
En este apartado se hablará acerca del hombre y equipo fundador del proyecto Ubuntu, se
explicará la filosofía que hay detrás del proyecto y por último se tocarán los objetivos principales
de este, la información se encuentra disponible en (Mako Hill, Helmke, Graner, & Burger) y en
(Ubuntu.org).
2.3.1 Mark Shuttleworth y “The Warthogs”
Mark Shuttleworth es el iniciador del proyecto Ubuntu, nació en 1973 en Welkom, Sudáfrica,
estudió finanzas y tecnologías de la información en la Universidad de Cape Town y durante este
tiempo fundó una empresa de seguridad en internet llamada Thawte.
Con el paso del tiempo Thawte creció y se convirtió en la segunda entidad más grande emisora de
certificados en internet, detrás de VeriSign. Los productos de su compañía eran construidos en su
mayoría con herramientas libres.
En 1999 Mark Shuttleworth, decide vender Thawte a VeriSign, quien paga por la compañía varios
cientos de millones de dólares. Con el dinero de la venta, Shuttleworth decide cumplir su sueño de
visitar el espacio, es así que se convierte en el segundo astronauta civil en la historia. En 2001
funda The Shuttleworth Foundation (TSF) que es una organización sin fines de lucro dedicada a la
innovación social la cual patrocina proyectos educativos y de software libre en Sudafrica.
64
Shuttleworth se inclinaba por el uso de la distribución Debian, en la cual también participó como
desarrollador. Tenía en mente un nuevo proyecto, el cual era construir un nuevo y mejor sistema
GNU/Linux que fuera desarrollado de la mano del proyecto Debian.
Para iniciar el proyecto, en el 2004, Shuttleworth invitó a su departamento a varios
desarrolladores en los que él confiaba, hubo una lluvia de ideas acerca de cómo debería ser el
sistema operativo ideal, se señalaron lo que ahora se define como objetivos de Ubuntu y se
decidió que en un plazo de seis meses a partir de esa fecha se tendría un avance del nuevo sistema
GNU/Linux. Shuttleworth aceptó financiar el trabajo y el equipo de trabajo se llamó a sí mismo
“The Warthogs”.
2.3.2 “La humanidad hacia los demás”
En esa reunión se logró establecer una fecha para el primer lanzamiento, algunos objetivos a
cumplir para tal fecha y se reunió un gran equipo, pero aun no se le daba un nombre al proyecto.
Fue entonces cuando Shuttleworth decidió llamar al proyecto Ubuntu, el cual es un concepto de
varias lenguas sur africanas incluyendo Zulu y Xhosa y se refiere a una ideología sur africana que se
podría traducir como “La humanidad hacia los demás” o "Yo soy lo que soy por lo que todos
somos". El obispo africano defensor de los derechos humanos llamado Desmond Tutu, define a
ubuntu como: “Una persona con ubuntu es abierta y está disponible para los demás, respalda a los
demás, no se siente amenazado cuando otros son capaces y son buenos en algo, porque está
seguro de sí mismo ya que sabe que pertenece a una gran totalidad, que se decrece cuando otras
personas son humilladas o menospreciadas, cuando otros son torturados u oprimidos.”
El nombre Ubuntu era un término que reflejaba de donde venia el proyecto, a donde iba el
proyecto y como el proyecto planeaba alcanzar sus objetivos.
En el 2004 Shuttleworth crea Canonical Ltd., que tiene como primer objetivo el desarrollo y
soporte de Ubuntu y también crea la Fundación Ubuntu con un fondo inicial de $10 millones de
dólares, esta fundación se asegura del futuro del proyecto.
2.3.3 Objetivos de Ubuntu
Los objetivos del proyecto Ubuntu van mas allá de ser solo un buen producto de software, por lo
que además de objetivos tecnológicos, cuenta con objetivos filosóficos y objetivos de conducta. En
este apartado se hablará acerca de los ya mencionados objetivos y además se tratará el objetivo
final de Ubuntu.
2.3.3.1 Objetivos tecnológicos
Siendo Ubuntu un proyecto técnico, debe cumplir con ciertos objetivos, los cuales son los
siguientes:
1. La coordinación regular y predecible de nuevos lanzamientos cada seis meses. Esto es
importante, ya que los usuarios pueden hacer uso de nuevo software en cada liberación,
65
además ser predecible es de gran ayuda para las organizaciones, ya que pueden planear
sus operaciones en torno a Ubuntu.
2. Ofrecer soporte. La comunidad de Ubuntu trabaja en encontrar y minimizar cualquier tipo
de error después de los lanzamientos. Los lanzamientos normales tienen 18 meses de
soporte y para aquellos lanzamientos LTS (Long Time Support), el soporte ofrecido es de 3
años para usuarios personales y de 5 años para usuarios con la configuración de servidor.
3. Ubuntu ha trabajado para tratar de asegurar que el lenguaje de programación empleado
en el sistema sea Phyton, ya que esto supone que el usuario solo debe aprender este
lenguaje para sacar el mayor provecho de su sistema.
2.3.3.2 Objetivos filosóficos
Una vez explicados los objetivos técnicos, se hablará acerca de los principios filosóficos, los cuales
son los más importantes en el proyecto Ubuntu y se encuentran en una serie de documentos
dentro de su página en internet http://www.ubuntu.com/.
1. Cada usuario de una computadora debe ser libre para descargar, ejecutar, copiar,
distribuir, estudiar, compartir, cambiar y mejorar el software para cualquier propósito, sin
pagar ninguna licencia.
2. Cada usuario de una computadora debe poder usar el software en el idioma que él elija.
3. Cada usuario de una computadora debe poder hacer uso del software aunque posea
alguna discapacidad.
Como se puede observar, los ideales del proyecto Ubuntu van mas allá de los ideales compartidos
con el software libre, añade dos objetivos importantes, el primero es que el sistema se pueda usar
en cualquier idioma y el segundo es que cualquier usuario, aunque este sufra de alguna
discapacidad, debe poder hacer uso del software.
2.3.3.3 Objetivos de conducta y el código de conducta
El código de conducta de Ubuntu describe una serie de reglas para trabajar y cooperar en el
proyecto. Expresar estar de acuerdo con el código te convierte en un activista de Ubuntu
(Ubuntero) y es parte primordial para ser parte del proyecto. Lo que el código expresa es como
debe ser el comportamiento de un miembro de la comunidad Ubuntu, en cualquier foro, sitio de
internet, canal de IRC, etc., marcando ser lo siguiente:
Considerado.
Respetuoso.
Colaborativo.
Cuando estás en desacuerdo, debes consultar a otro.
Cuando estés inseguro, debes pedir ayuda.
66
Las discusiones son similares a las de cualquier proyecto, pero el código de conducta provoca un
conocimiento común de que las discusiones deben pasar en un ambiente de colaboración y
respeto mutuo.
2.3.3.4 “Bug #1”
Los objetivos de Ubuntu no constan solo de construir un sistema operativo que vaya de acuerdo a
su filosofía, que cumpla con los objetivos técnicos y que se haga de acuerdo al código de conducta,
el objetivo primordial de Ubuntu es ser el sistema operativo más usado en el mundo y para ilustrar
esto, el primer bug reportado en Ubuntu por Shuttleworth, marcado como crítico, actualmente
abierto y que puede ser visto online en https://launchpad.net/distros/ubuntu/+bug/1 es el
siguiente:
Microsoft tiene una cuota mayoritaria en el mercado de las PC de escritorio actual.
Esto es un error, que Ubuntu está diseñado para corregir.
El software no libre está frenando la innovación en la industria de las Tecnologías de la
Información (TI), restringiendo el acceso a las TI para una pequeña parte de la población
mundial y limitando la capacidad de los desarrolladores de software para alcanzar su
máximo potencial, a nivel mundial. Este error es muy evidente en la industria de las PC.
Pasos a repetir:
1. Visite una tienda de PC local.
Lo que sucede:
2. Observe que la mayoría de los ordenadores a la venta tienen software no-libre preinstalado.
3. Observe muy pocos PCs con Ubuntu y software libre preinstalado.
Lo que debería ocurrir:
1. La mayoría de los PCs a la venta debe incluir solamente software libre como Ubuntu. 2. Ubuntu debe ser comercializado de una manera tal que sus increíbles características y
los beneficios serían evidentes y conocidos por todos. 3. El sistema deberá ser más amigable para el usuario con el paso del tiempo.
Como se puede apreciar, el desarrollo de Ubuntu no estará completo hasta que no solo sea la
distribución de GNU/Linux más usada, si no que sea el sistema operativo más distribuido a nivel
mundial.
Ubuntu hasta la versión 10.10 usaba como escritorio predeterminado al escritorio GNOME,
después se cambio a Unity, este trabajo de investigación se enfocará a la versión de Ubuntu 10.04
usando el escritorio GNOME 2.30.
67
2.4 El proyecto GNOME
El proyecto GNOME tiene como objetivo el crear un escritorio para el usuario final que sea
completo, libre y fácil de usar, además de que el sistema sea una plataforma potente para los
desarrolladores, la información aquí expuesta se puede ampliar en (Moya, 2002) y (de Icaza).
GNOME es el acrónimo en inglés de "GNU Network Object Model Environment". No tiene
traducción al español, pero de su nombre podemos destacar que es parte del proyecto GNU,
además de que está fuertemente ligado a la programación orientada a objetos y a las redes.
A mediados de 1995, la difusión de Windows 95 en la mayoría de computadoras personales y de
oficina cambio la forma en que los usuarios interactuaban con las computadoras, de la línea de
comandos, se paso a una interfaz bidimensional, en donde el ratón ganó terreno frente al teclado.
Los seguidores del software libre vieron tal éxito y decidieron implementar una alternativa libre.
En 1996 nace el proyecto KDE de la mano de Matthias Ettrich, solo hubo un problema con este
proyecto y es que los desarrolladores utilizaron una biblioteca llamado Qt propiedad de una
empresa noruega llamada TrollTech que no era libre y su distribución no era permitida. Por tal
motivo los mexicanos Miguel de Icaza y Federico Mena evaluaron crear una biblioteca libre similar
a Qt, pero cayeron en cuenta que este proyecto implicaría una labor muy grande y daría como
resultado un software menos eficiente.
En agosto de 1997 los dos mexicanos decidieron comenzar con el proyecto GNOME, al cual le
dedicaban solo su tiempo libre. Gracias a las contribuciones de la gente de la lista de correo en
donde difundieron las bases del proyecto, GNOME fue tomando forma y para Noviembre Miguel y
Federico dejaron otros proyectos para solo dedicarse a GNOME.
En diciembre Miguel y Federico se reunieron con Marc Ewing y DrMike en las oficinas de Red Hat,
en donde se crearon los Red Hat Advanced Development Labs, que fueron los primeros
laboratorios financiados para mejorar GNOME, la creación de estos laboratorios sucedió en enero
de 1998.
En esas fechas, las versiones GNOME 0.13, 0.20 y 0.30 habían sido liberadas. A finales de
noviembre de 1998, TrollTech liberó el código de Qt bajo una licencia que cumplía con la
definición de código abierto. Esto debilitó las razones por las que la gente apoyaría a GNOME, ya
que KDE era totalmente libre.
Pero aun con ese hecho, había varios intereses poderosos para continuar el proyecto, Red Hat
necesitaba un escritorio y muchos desarrolladores habían trabajado duro para que GNOME
avanzara, es así que en marzo de 1999 fue liberado GNOME 1, esta liberación traía consigo
muchos bugs y no era estable, los desarrolladores reforzaron esfuerzos y en la versión OCTUBRE
GNOME 1.0.55 se corrigieron los errores y se llegó a tener un escritorio estable.
68
El escritorio siguió desarrollándose y en agosto del 2000 la fundación GNOME se anunció en la
expo Mundial de Linux en San José California. Tras el anuncio de la fundación un número de
iniciativas de los miembros fundadores fueron anunciadas:
SUN Microsystems adopta las tecnologías de GNOME para su ambiente de usuario en el OS Solaris.
Hewlett-Packard adopta GNOME para su ambiente de usuario en el sistema operativo Hp-UX.
SUN cambiaria su recientemente liberada abierta, suite StarOffice hacia el Gtk+ toolkit y se integrará con la arquitectura de componentes Bonobo de GNOME
IBM contribuyó con el ambiente rápido del desarrollo de SashXB a GNOME.
GNOME adoptaría e integraría Mozilla como parte de su estrategia de escritorio.
El proyecto de GNOME adoptaría las tecnologías de OpenOffice. En septiembre del 2000 Sun crea el laboratorio GNOME ACCESABILITY que ayudaría a mejorar GNOME para ser utilizado por gente con discapacidades. GNOME siguió desarrollándose y en Junio del 2002 evolucionó a la biblioteca GTK2 e introdujo el Human Interface Guidelines (Guías de la interfaz humana de GNOME), que consiste en especificaciones que dicen cómo crear aplicaciones que parezcan correctas, se comporten de forma apropiada y que se ajusten a la interfaz de usuario de GNOME como un todo. Fue entonces cuando empezó el ciclo de liberaciones programadas cada 6 meses, de forma que cada otoño y cada primavera se libera una nueva versión del entorno. La versión más desarrollada de la serie 2.0 llego a ser la 2.30. El 6 de Abril de 2011 se dio un gran
cambio, GNOME 3 apareció, se rediseñó desde cero el escritorio, cambiaron las librerías a GTK3 y
actualmente es la versión más nueva del escritorio, por ser la más reciente aun se encuentran
algunos errores que la comunidad trata de corregir.
2.5 Editor de configuraciones gconf
Para comenzar se expondrá sobre el sistema que permite guardar las configuraciones de las
preferencias del usuario en el escritorio Gnome, ya que toda posible modificación a la interfaz
actual, tendrá que acceder a este sistema, el cual es llamado gconf.
gconf es un sistema que simplifica la administración de las preferencias para los usuarios del
escritorio GNOME. gconf permite a los administradores del sistema:
Establecer valores obligatorios para preferencias particulares para todos los usuarios. De
esta manera, los administradores del sistema pueden controlar si los usuarios pueden
actualizar preferencias particulares.
Establecer valores predeterminados para preferencias particulares para todos los usuarios.
Usar los valores sugeridos para las preferencias especificadas en los archivos de definición
para las preferencias.
69
Leer la documentación para cada preferencia.
gconf también notifica a las aplicaciones cuando un valor de preferencia ha cambiado, localmente
o a través de una red. De esta manera, cuando cambie una preferencia, todas las aplicaciones que
usen la preferencia se actualizarán inmediatamente.
gconf tiene los siguientes componentes:
1. Un repositorio de las preferencias del usuario.
2. Un demonio, gconfd-2.
3. Herramientas para la línea de comandos, gconftool-2 y su editor grafico, gconf-editor.
2.5.1 Repositorio de gconf
Cada preferencia en el repositorio de gconf se expresa como un par valor-clave. Una clave de
preferencia de gconf es un elemento en el repositorio que corresponde a una preferencia en una
aplicación. La interfaz de usuario del escritorio GNOME no contiene todas las claves de preferencia
que el repositorio de gconf tiene.
El repositorio está estructurado como un sistema de archivos jerárquico simple y contiene lo
siguiente:
Direcciones que corresponden a las aplicaciones que usan el repositorio de gconf. Por
ejemplo, el sistema de archivos contiene el directorio /apps/metacity.
Subdirectorios que corresponden con categorías de preferencias. Por ejemplo el sistema
de archivos contiene el directorio /apps/metacity/general.
Archivos especiales que listan las claves de preferencias en el directorio y contienen
información acerca de las claves. Por ejemplo, un archivo que contiene información acerca
de las claves referentes a las preferencias del proxy HTTP está en el
directorio /system/http_proxy.
Un directorio /schemas que contiene archivos que describen todas las claves de
preferencias.
Las claves de preferencia generalmente contienen valores simples, tales como cadenas, enteros o
listas de cadenas y listas de enteros. El formato de las claves de preferencias en el repositorio
depende del módulo de backend usado para leer el repositorio.
El siguiente ejemplo muestra la clave de preferencia/desktop/gnome/interface/font_name cuando
un módulo backend de «Extensible Markup Language» (XML) se usa para leer el repositorio:
<entry name="font_name" mtime="1038323555" muser="user123" type="string"> <stringvalue>Sans 10</stringvalue></entry>
70
2.5.1.1 Fuentes de configuración de gconf
El repositorio de gconf contiene una serie de lugares de almacenamiento llamados fuentes de
configuración. Las fuentes de configuración son listadas en el archivo de ruta de gconf. La
ubicación del archivo de ruta de gconf es /etc/gconf/número-de-versión-de-gconf/path. Cada
usuario tiene un archivo de ruta. El archivo de ruta especifica la siguiente información para cada
fuente de configuración:
El módulo backend a usar para leer el repositorio.
Los permisos sobre el repositorio.
La ubicación del repositorio.
La ruta de archivo de gconf también contiene instrucciones include. De forma predeterminada el
contenido del archivo de ruta de gconf es el siguiente:
xml:readonly:/etc/gconf/gconf.xml.mandatory include /etc/gconf/2/local-mandatory.path include "$(HOME)/.gconf.path" include /etc/gconf/2/local-defaults.path xml:readwrite:$(HOME)/.gconf xml:readonly:/etc/gconf/gconf.xml.defaults
Cuando gconf busca el valor de una preferencia, gconf lee las fuentes de configuración en el orden
especificado por el archivo de ruta. La siguiente tabla describe las fuentes de configuración en el
archivo de ruta.
Configuración fuente Descripción
Obligatorio Los permisos sobre esta configuración fuente están establecidos a sólo
lectura. Los usuarios no pueden sobrescribir los valores en esta fuente, de tal forma que las preferencias en la fuente son obligatorias.
Usuario Esta configuración fuente se almacena en el directorio .gconf dentro del
directorio de inicio del usuario. Cuando el usuario establece una preferencia, la nueva información de la preferencia se añade a esta ubicación.
Puede usar el Editor de configuración para modificar la configuración fuente
de un usuario.
Predeterminado
Esta configuración fuente contiene los ajustes predeterminados de preferencias.
La secuencia de las fuentes de configuración en el archivo de ruta asegura que los ajustes de
preferencias obligatorias sobrescriben los ajustes de preferencias del usuario. La secuencia
también se asegura que los ajustes de preferencias del usuario sobrescriben los ajustes de
preferencias predeterminados. Esto es, gconf aplica las preferencias con la siguiente prioridad:
1. Preferencias obligatorias
71
2. Preferencias especificadas por el usuario
3. Preferencias predeterminadas
Las instrucciones include en la ruta de archivo de gconf permiten a los administradores del sistema
especificar otras fuentes de configuración.
Fuente de configuración incluida Descripción
/etc/gconf/2/local-mandatory.path Use esta fuente configuración para almacenar valores de preferencias obligatorios para un sistema particular.
$(HOME)/.gconf.path El usuario especifica la ubicación de la configuración fuente en el directorio de inicio, en un archivo llamado .gconf.path.
/etc/gconf/2/local-defaults.path Use esta configuración fuente para almacenar los valores de preferencias predeterminados para un sistema particular.
2.5.1.2 Esquemas de gconf
Un esquema de gconf es un término colectivo para una clave de esquema de gconf y un objeto de
esquema de gconf. La siguiente tabla describe las claves y objetos de esquema y su relación con
las claves de preferencias.
Elemento Descripción
Clave de preferencia Un elemento en el repositorio de gconf que
corresponde con la preferencia de una
aplicación.
Clave de esquema Una clave que almacena un objeto de esquema
para una clave de preferencia.
Objeto de esquema Un elemento en una configuración fuente que
contiene información para una clave de
preferencia, tal como:
El nombre de la aplicación que usa la
clave de preferencia.
El tipo de valor requerido por la clave
de preferencia, por ejemplo entero,
booleano y demás.
Un valor predeterminado para la clave de
preferencia.
Breve documentación sobre la clave de
preferencia.
La siguiente tabla proporciona ejemplos de una clave de preferencia, una clave de esquema y un
objeto esquema:
Elemento Ejemplo
Clave de preferencia /desktop/gnome/interface/font_name
Clave de esquema /schemas/desktop/gnome/interface/font_name
Objeto de esquema <schema>
72
<applyto>/desktop/gnome/interface/font_name</applyto>
<key>/schemas/desktop/gnome/interface/font_name</key>
<owner>gnome</owner>
<type>string</type>
<default>Sans 10</default>
<locale name="C">
<short>Default font</short>
<long>Name of the default font used by gtk+.</long>
</locale>
</schema>
Se puede asociar una clave de esquema con una clave de preferencia. Por ejemplo, la siguiente
clave/desktop/gnome/interface/font_name incluye una clave de esquema:
<entry name="font_name" mtime="1034873859" schema="/schemas/desktop/gnome/interface/font_name"/>
Cuando se asocia una clave de esquema con una clave de preferencia, la preferencia usa el valor
sugerido especificado en el objeto esquema de la clave de esquema. El valor sugerido está
contenido en el elemento <default> dentro del objeto esquema. De forma predeterminada todas
las claves de preferencias en su configuración fuente predeterminada están asociadas con claves
de esquema.
Generalmente los esquemas están almacenados en la configuración fuente original.
2.5.1.3 Archivos de definición de esquemas de gconf
Los esquemas se generan desde archivos de definición de esquemas. Un archivo de definición de
esquemas define las características de todas las claves de una aplicación en particular. Estos
archivos tienen una extensión .schema.
Los archivos de definición de esquema están incluidos en el directorio /etc/gconf/schemas. Se
pueden usar los archivos para crear una nueva fuente de configuración.
Algunos archivos de definición de esquemas corresponden con una parte de la interfaz de usuario
del escritorio GNOME. Por ejemplo, system_http_proxy.schemas corresponde con la herramienta
de preferencias Proxy de la red. Otros archivos de definición de esquemas contienen claves de
preferencias que no están presentes en el interfaz de usuario del escritorio GNOME. Por ejemplo,
la clave /apps/panel/global/tooltips_enabled no está presente en la interfaz de usuario.
Algunas partes de la interfaz de usuario del escritorio GNOME contienen preferencias que
representan claves de preferencias de más de un archivo de definición de esquemas. Por ejemplo,
73
la herramienta de preferencias Combinaciones de teclas contiene preferencias que representan
claves de los archivos panel-global-config.schemas y metacity.schemas.
2.5.2 Demonio de gconf
El demonio de gconf se llama gconfd-2. Este demonio notifica a las aplicaciones cuándo un valor
de preferencia ha cambiado. Por ejemplo, puede que seleccione mostrar sólo los iconos en las
barras de herramientas. Cuando seleccione esta opción en la herramienta de preferencias, se
actualizan todas las barras de herramientas en todas las aplicaciones. El demonio de gconf puede
operar localmente o a través de una red.
Una instancia del demonio se inicia para cada usuario. El demonio de gconf no tiene que tratar con
problemas complejos tales como la autenticación y seguridad de los datos. Cuando el demonio se
inicia, el demonio carga el archivo de ruta de gconf y gestiona todo acceso entre las aplicaciones y
las fuentes de configuración.
Cuando una aplicación pide el valor de una clave de preferencia, el demonio busca la fuente de
configuración como sigue:
1. Busca el valor de la clave de preferencia en cada fuente de configuración, en el orden
especificado en el archivo de ruta. Si el valor se encuentra, lo devuelve.
2. Si no se encuentra el valor, busca la clave de esquema que corresponde con la clave de
preferencia en cada fuente de configuración, en el orden especificado en el archivo de
ruta.
3. Si se encuentra la clave de esquema, comprueba el valor de esa clave de esquema.
4. Si el valor de la clave de esquema es un objeto esquema, devuelve el valor sugerido en el
elemento <default> del objeto esquema.
El demonio de gconf también pone en cache los valores de las claves de preferencias. Todas las
aplicaciones usan esta caché, de tal forma que las aplicaciones sólo necesitan acceder a las fuentes
de configuración una vez.
2.5.3 Herramientas para la línea de comandos y su editor gráfico
gconf incluye una herramienta para la línea de comandos, gconftool-2. Se puede usar el comando
gconftool-2 para realizar las siguientes tareas:
Ajustar los valores de las claves.
Mostrar los valores de las claves.
Instalar esquemas desde archivos de definiciones de esquemas cuando instala una
aplicación.
Por ejemplo, se podría usar el siguiente comando para mostrar los valores de todas las claves en el
directorio y subdirectorios /desktop/gnome.
gconftool-2 --recursive-list /desktop/gnome
74
No se detallarán las opciones de gconftool-2, basta señalar que este es el comando con el cual se
pueden realizar las modificaciones a las claves.
Existe una equivalencia gráfica de gconftool-2, la cual es llamada gconf-editor, esta resulta ser una
interfaz amigable del comando y sirve para realizar las mismas tareas, solo que en un ambiente
gráfico.
gconf-editor facilita la modificación de las claves, pero para un usuario inexperto que no está
acostumbrado, ni conoce esta utilidad puede resultar difícil su manipulación.
A continuación se presenta una descripción de la interfaz de gconf-editor:
Ilustración 2.5 Interfaz de gconf-editor.
Panel del árbol: Permite navegar por la jerarquía de claves en gconf. Muestra las claves que se
pueden modificar en el panel de modificaciones. El panel del árbol está a la parte izquierda de
la ventana.
Panel de modificaciones: Muestra las claves en la ubicación gconf seleccionada en el panel del
árbol. Este panel se usa para seleccionar las claves que se quieran modificar así como para
Panel de árbol.
Panel de modificación.
Panel de documentación.
75
modificar los valores de las claves. El panel de modificaciones está situado en la parte superior
derecha de la ventana.
Los iconos al lado de las claves del panel de modificaciones indican qué tipo de valor se puede
introducir para la clave.
Panel de documentación: Muestra la documentación para la clave actualmente seleccionada.
Sirve para leer más información acerca de las preferencias de las claves gconf.
Estas dos opciones gconftool-2 y gconf-editor son ofrecidas por el escritorio GNOME, para poder
cambiar la configuración de las preferencias del sistema.
Cabe señalar que gconf-editor es el más sencillo de utilizar debido a su interfaz gráfica, pero para
poder usarlo, se debe tener una cierta experiencia en el sistema GNOME.
Con esto podemos decir que cualquier usuario nuevo, llegado de otros escritorios como los
implementados en entornos Windows y Mac, cuando quisieran cambiar la configuración de algún
elemento de la interfaz del escritorio GNOME, se encontrarian con distintas dificultades
ocasionadas por fallos en los atributos de la usabilidad como son:
Facilidad de aprendizaje, ya que el uso de un editor de configuración como lo es gconftool-2 o
gconf-editor no les resultaría familiar.
Consistencia, debido a que el acceso de algunas preferencias del escritorio GNOME si se
pueden hacer a través de interfaces gráficas, y otras solo a través del editor de configuración,
ya sea gconftool-2 o gconf-editor.
Disminución de la carga cognitiva, los usuarios nuevos no tendrían el conocimiento del
comando gconftool-2 y no sabrían como usar de manera intuitiva, ni como cambiar valores de
las claves usando gconf-editor, ellos están acostumbrados a realizar sus tareas de manera
gráfica.
Ya que se sabe de la existencia y la forma en que opera gconf, se dispondrá a analizar la interfaz en
el siguiente capítulo en busca de fallos de usabilidad para proponer mejoras.
76
Capítulo 3 Análisis y diseño de la propuesta de Mejora. Utilizando el modelo de proceso de la ingeniería de la usabilidad y el modelo de reingeniería
podremos modificar las interfaces gráficas del escritorio GNOME que carezcan de funcionalidad de
acuerdo a las opciones disponibles en el editor de configuraciones del escritorio.
Para realizar este trabajo, se seguirá el modelo del proceso de reingeniería utilizando las técnicas
de prototipado y evaluación y las actividades para el análisis y diseño que propone el modelo de la
ingeniería de la usabilidad.
3.1 Análisis de inventarios
El proceso de la reingeniería de software comienza con esta actividad, la cual como ya se expuso
anteriormente, busca encontrar programas aptos para la reingeniería.
Se tomará como inventario una lista enunciativa de módulos de la interfaz del escritorio GNOME,
se analizará y comparará las claves disponibles en gconf-editor con la interfaz grafica que permita
establecer dichas claves para cada módulo analizado y, ya que la interfaz de usuario es la puerta
que tiene el usuario para acceder a la funcionalidad del sistema, serán candidatos a reingeniería
de interfaz de usuario aquellos módulos los cuales no tengan implementadas de manera gráfica las
claves de preferencia existentes en gconf-editor.
Una vez detectada alguna clave que no se encuentre disponible a modificar de manera gráfica, se
enlistará el modulo y la descripción del comportamiento que la clave es capaz de modificar.
77
La interfaz de GNOME 2.30 en una instalación nueva de Ubuntu 10.04 luce como sigue:
Ilustración 3.1 Interfaz de Ubuntu 10.04 usando GNOME 2.30 como escritorio.
1. Mini aplicación de indicadores de sesión.
2. Reloj.
3. Mini aplicación de indicadores.
4. Área de notificación.
5. El panel superior de GNOME.
6. Lanzadores de aplicaciones.
7. Barra de menú.
8. Mini aplicación de la papelera.
9. Selector de áreas de trabajo.
10. El panel inferior de GNOME.
11. Lista de ventanas.
12. Botón para mostrar el escritorio.
13. Escritorio.
14. Barra de Título.
15. Menú principal
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
78
Al analizar los elementos del escritorio, los applets del panel y la barra de título de las ventanas, se
encontró que varias claves de dichos elementos no tienen manera de ser configuradas
intuitivamente por el usuario. A continuación se proporciona una tabla en donde se enlista el
elemento, la clave y la funcionalidad que proporciona.
Elemento Clave Funcionalidad
Reloj. /apps/panel/applets/clock_screen0/prefs/custom_format
Utiliza la función strftime () la cual puede formatear por medio de caracteres especiales la configuración de una fecha, lo cual nos da la posibilidad de hacer modificaciones al String del applet del reloj, para que su presentación se pueda modificar por el usuario.
El panel superior e inferior de GNOME.
/apps/panel/toplevels/top_panel_screen0/enable_animations
Permite establecer si el panel al ocultarse lo hace de una manera animada, si esta desactivado, solo aparece y desaparece.
/apps/panel/toplevels/top_panel_screen0/animation_speed
Dicta la velocidad de la animación con la que el panel debe aparecer y desaparecer.
/apps/panel/toplevels/top_panel_screen0/auto_hide_size
Cuando el panel desaparece, este aún queda visible unos cuantos pixeles, para que su localización sea rápida aún oculto. La clave permite establecer el valor de esos pixeles.
/apps/panel/toplevels/top_panel_screen0/hide_delay
Al estar seleccionada la opción de ocultar automáticamente del panel, se puede establecer el retardo en milisegundos para que esto ocurra.
/apps/panel/toplevels/top_panel_screen0/unhide_delay
Establece el tiempo en milisegundos en que una vez oculto el panel, éste vuelve a aparecer.
/apps/panel/toplevels/top_panel_screen0/background/fit
Establece que la imagen del fondo sea como en mosaico.
/apps/panel/toplevels/top_panel_screen0/background/stretch
Establece que la imagen del fondo se estire.
Barra de menú
/apps/panel/objects/menu_bar_screen0/use_custom_icon
Permite determinar si se usará un icono personalizado en lugar del icono del tema.
/apps/panel/objects/menu_bar_scr Permite establecer el icono que se
79
Elemento Clave Funcionalidad
een0/custom_icon usará en lugar del determinado por el tema.
Escritorio
/apps/nautilus/desktop/computer_icon_visible
Permite mostrar un icono denominado “Equipo” en el escritorio, similar a “Mi PC” en Windows.
/apps/nautilus/desktop/home_icon_visible
Permite mostrar un icono denominado “Carpeta Personal” en el escritorio, similar a “Mis Documentos” en Windows.
/apps/nautilus/desktop/network_icon_visible
Permite mostrar un icono denominado “Servidores de Red” en el escritorio, similar a “Redes” en Windows.
/apps/nautilus/desktop/text_ellipsis_limit
Permite determinar la cantidad de líneas visibles en el nombre de los iconos.
/apps/nautilus/desktop/trash_icon_visible
Permite mostrar un icono denominado “Papelera” en el escritorio, similar a “Papelera de Reciclaje” en Windows.
/apps/nautilus/desktop/volumes_visible
Permite mostrar los iconos de las unidades montadas en el sistema.
Barra de Título
/apps/gwd/metacity_theme_active_opacity
Permite establecer el nivel de opacidad de la ventana activa del tema de Metacity.
/apps/gwd/metacity_theme_active_shade_opacity
Permite activar o desactivar la opacidad de sombra de la ventana activa del tema de Metacity
/apps/gwd/metacity_theme_opacity
Permite establecer el nivel de opacidad del tema de Metacity
/apps/gwd/metacity_theme_shade_opacity
Permite activar o desactivar la opacidad de sombra del tema de Metacity
/apps/gwd/mouse_wheel_action Permite establecer la acción de la rueda del ratón en la barra de título
/apps/gwd/use_metacity_theme Permite activar o desactivar el uso del tema Metacity
/apps/metacity/general/action_double_click_titlebar
Permite establecer la acción del doble clic en la ventana de título.
/apps/metacity/general/action_middle_click_titlebar
Permite establecer la acción del clic del botón central en la ventana de título.
80
Elemento Clave Funcionalidad
/apps/metacity/general/action_right_click_titlebar
Permite establecer la acción del clic con el botón derecho en la ventana de título.
/apps/metacity/general/button_layout
Permite establecer la disposición de los botones en la barra de título.
Menú Principal
/apps/panel/objects/object_0/use_custom_icon
Permite determinar si se usará un icono personalizado en lugar del icono del tema.
/apps/panel/objects/object_0/custom_icon
Permite establecer el icono que se usará en lugar del determinado por el tema.
Con esta información y tomando a la interfaz de usuario actual de cada componente como un prototipo de software se realizó la primer fase de pruebas de acuerdo al plan de pruebas de usabilidad. Los resultados de esta primera evaluación se pueden consultar en el Anexo 1. Con los resultados arrojados de la prueba y los cuestionarios realizados a los usuarios representativos es posible realizar las actividades de análisis de requisitos y diseño que marca el modelo del proceso de la usabilidad.
3.2 Análisis de requisitos
En esta sección se hablará acerca de las actividades realizadas para poder obtener información relevante acerca de los requisitos del sistema.
3.2.1 Análisis etnográfico
Para esta actividad se examinó el comportamiento y la forma de abordar las tareas que se pidieron realizar en la prueba con el prototipo, teniendo los siguientes resultados: 1. La mayoría de los usuarios, cada vez que se disponían a cambiar alguna preferencia del
elemento del escritorio, posicionaban el cursor en el elemento y oprimían el botón derecho del mouse buscando en el menú contextual alguna opción de preferencias que les permitiera cambiar la configuración del elemento.
2. Una vez leída la petición de realizar alguna tarea de la prueba, todos los usuarios sin excepción
tomaron el mouse y observaron el cursor en pantalla, lo que dicta que el mouse es la principal opción de los usuarios representativos para desplazarse por la pantalla.
3. En esta primera prueba la consecución de las tareas no fue satisfactoria para los usuarios
representativos debido a la pobre funcionalidad de la interfaz grafica para establecer preferencias de los elementos del escritorio. Todas las tareas requeridas en la prueba actualmente se tienen que realizar de la siguiente manera:
81
1. Oprimir la combinación de teclas Alt + F2. 2. Escribir gconf-editor en la ventana “Ejecutar una aplicación” y presionar el botón de
Ejecutar. 3. Navegar por el panel de árbol de la interfaz gráfica de gconf-editor hasta encontrar el
elemento del escritorio deseado y seleccionarlo. 4. Navegar por el panel de modificación de la interfaz de gconf-editor hasta encontrar la
clave que se desea modificar. 5. Modificar la clave con un valor adecuado.
3.2.2 Análisis de implicados
Al realizar el análisis para detectar a los implicados se encontró lo siguiente:
Se tiene como responsable del diseño y desarrollo, al ingeniero de software autor de este trabajo de investigación, el cual tiene interés en mejorar la interfaz gráfica de los elementos que constituyen el escritorio GNOME debido a que él es un usuario activo del sistema.
Los implicados con algún interés financiero, son todas aquellas empresas de software libre que implementen el escritorio GNOME en sus soluciones de software.
Si tratáramos de encontrar los implicados responsables de la implantación y mantenimiento, bastaría con exponer que son aquellos quienes sustituyeran los módulos antiguos por los modificados en su distribución Linux que implemente el escritorio GNOME a la cual dan soporte.
Este proyecto se trata de enfocar en usuarios los cuales no cuentan con conocimientos de informática y que tengan deseos de probar una solución alternativa de escritorio a los sistemas comerciales. Pero debido a la naturaleza del proyecto, una vez liberado, la cantidad de usuarios y su perfil, resulta imposible de enumerar.
3.2.3 Clasificar a los usuarios
Al realizar un análisis para detectar el perfil de usuario que hará uso de las modificaciones al sistema se pudo obtener la siguiente clasificación: 1. Inexperto; es aquel usuario que posee escasos conocimientos en informática, este tipo de
usuarios lo único que desean del sistema es utilizarlo para realizar tareas básicas como la ofimática y navegar por internet y cuando mucho personalizar su ambiente de trabajo, pero para conseguirlo no desean tener que editar archivos de configuración.
2. Intermedio; son aquellos usuarios que tienen un nivel mayor de conocimientos en informática,
tienen interés en saber cómo funcionan las cosas y les gusta investigar acerca de formas nuevas de editar las opciones de sus sistemas.
3. Avanzado; son los usuarios que dominan el sistema y tienen amplios conocimientos sobre él,
no temen en usar programas con interfaces basadas en texto. Como ya se ha comentado anteriormente, el proyecto está enfocado a aquellos usuarios que son principiantes en el uso de alguna distribución de GNU/Linux y sientan la necesidad de personalizar
82
la interfaz gráfica del escritorio GNOME, aunque no excluye que los usuarios intermedios y avanzados hagan uso de las mejoras que la consecución de este proyecto aportará. En este proyecto no se hará distinción entre roles ya que el uso del sistema es muy general y los usuarios no tienen que realizar tareas específicas ya que no hay ningún tipo de organización.
3.2.4 Identificación de objetos
Utilizando el análisis etnográfico se pudo observar lo siguiente:
1. Los usuarios prefieren utilizar el mouse en lugar del teclado. 2. Por la naturaleza del proyecto es necesario tener el conocimiento de valores, ya sean
cadenas de texto, códigos de colores RGB, ubicaciones de archivos, etc. para introducirlas en las opciones del editor de configuraciones para establecer las preferencias.
3.2.5 Características de la plataforma de ejecución
Debido a que Ubuntu es la distribución en la que se trabajará, se expondrán las características de hardware mínimas que son requeridas para que el sistema opere eficientemente:
Procesador x86 a 1 GHz.
Memoria RAM de 1 GB.
Disco Duro de 15 GB (swap incluida).
Tarjeta gráfica y monitor capaz de soportar una resolución de 800x600.
Lector de CD-ROM, puerto USB o tarjeta de red. Ahora, gracias a que se desarrollará en el escritorio GNOME, se hará uso de las librerías de GTK+ (GIMP Tooolkit), las cuales permiten desarrollar aplicaciones con interfaz gráfica. GTK+ se ha diseñado para permitir programar con lenguajes como C, C++, C#, Java, Perl, PHP o Python. Es así que se tendrá a disposición una amplia gama de lenguajes y widgets para poder elegir los más convenientes.
3.2.6 Objetivos de usabilidad
Al analizar el estado actual de las interfaces gráficas de los elementos del escritorio GNOME se pudo apreciar que los mecanismos para configurar algunas opciones de preferencias no son adecuadas para el tipo de usuario al cual se enfoca este trabajo de investigación por las siguientes razones: 1. Para poder realizar el cambio de opciones a las preferencias el usuario debe investigar en
algún buscador en internet como hacerlo, consultar la ayuda del sistema o en su defecto acercarse a alguien con experiencia lo cual requiere tiempo y esfuerzo.
2. Los usuarios están acostumbrados a la forma de operar de otros sistemas operativos, en este
caso, la manera en que operan es en modo gráfico, evitando el uso de archivos de configuración para establecer preferencias.
83
3. En este momento, el sistema carece de flexibilidad en cuanto a la manera en que se han desarrollado las interfaces gráficas, dictando que para cambiar las preferencias, se tenga que acceder directamente al administrador de configuraciones.
4. El sistema soporta varias opciones de configuración, pero no están a la vista de un usuario
nuevo, por lo que se puede decir que las interfaces graficas para la configuración de los elementos no soportan todas las tareas disponibles y el sistema no ha adecuado las tareas a un usuario inexperto.
5. Una vez se han cambiado las opciones de preferencias por la manera en la que el sistema lo
hace actualmente, si el usuario sintiera la necesidad de volverlas a modificar, tendría que recordar una gran cantidad de información como puede ser el directorio de la clave de la preferencia, la opción a modificar y el contenido de la clave a modificar.
Con estas observaciones podemos definir los objetivos de usabilidad del proyecto: 1. Minimizar el tiempo necesario que se requiere desde el no conocimiento de alguna clave a su
uso aplicado para cambiar dicha clave. 2. Mantener la forma de establecer las preferencias de los objetos como el usuario está
acostumbrado en los sistemas propietarios. 3. Crear interfaces que le den control al usuario y la posibilidad de elegir la manera en cómo
establecer las preferencias de los usuarios.
4. El sistema debe soportar vía interfaz gráfica las opciones de configuración que el editor de configuraciones dispone para cada elemento del escritorio GNOME.
5. La carga cognitiva para el usuario debe mantenerse a un nivel bajo, permitiendo que los
usuarios realicen las modificaciones de una manera intuitiva, sin necesidad de recordar información adicional.
6. El sistema debe mantener el grado de robustez actual. 7. El tiempo de respuesta actual es el adecuado, así que no debe sufrir modificación alguna.
84
3.2.7 Requisitos funcionales y no funcionales
Al haber realizado todas las actividades anteriores, se descubrieron los siguientes requisitos: Requisitos funcionales: La interfaz de preferencias de cada elemento del escritorio GNOME debe ofrecer un mecanismo para modificar su comportamiento según las claves disponibles en el editor de configuraciones.
1. Establecer formato personalizado para el reloj del panel. 2. Activar y desactivar animación al ocultar el panel. 3. Establecer la velocidad con la que el panel se oculta. 4. Establecer la cantidad de pixeles visibles cuando el panel se oculta automáticamente. 5. Establecer el retardo en milisegundos para que el panel se oculte. 6. Establecer el retardo en milisegundos para que el panel aparezca. 7. Establecer una imagen como fondo del panel como en mosaico. 8. Establecer una imagen como fondo del panel de manera ajustada. 9. Establecer un icono personalizado para la barra de menú. 10. Activar o desactivar el icono de “Equipo” en el escritorio. 11. Activar o desactivar el icono de “Carpeta Personal” en el escritorio. 12. Activar o desactivar el icono de “Papelera” en el escritorio. 13. Activar o desactivar el icono de “Servidores de Red” en el escritorio. 14. Determinar el número de líneas visibles en los nombres de los archivos. 15. Activar o desactivar los iconos de las unidades montadas en el sistema. 16. Establecer el nivel de opacidad de la ventana activa. 17. Activar o desactivar la opacidad de la ventana activa. 18. Establecer el nivel de opacidad del tema de Metacity. 19. Activar o desactivar la opacidad del tema de Metacity. 20. Establecer la acción de la rueda del ratón en la barra de título. 21. Activar o desactivar el uso de Metacity. 22. Establecer la acción del doble clic en la ventana de título. 23. Establecer la acción del clic del botón central en la ventana de título. 24. Establecer la acción del clic con el botón derecho en la ventana de título. 25. Establecer la disposición de los botones en la barra de título. 26. Establecer un icono personalizado para el Menú principal.
Requisitos no funcionales:
1. Minimizar el tiempo necesario que se requiere desde el no conocimiento de alguna clave a su uso aplicado para cambiar dicha clave.
2. Mantener la forma de establecer las preferencias de los objetos como el usuario está acostumbrado en los sistemas propietarios.
3. Crear interfaces que le den control al usuario y la posibilidad de elegir la manera en cómo establecer las preferencias de los usuarios.
4. La carga cognitiva para el usuario debe mantenerse a un nivel bajo, permitiendo que los usuarios realicen las modificaciones de una manera intuitiva, sin necesidad de recordar información adicional.
85
5. El sistema debe mantener el grado de robustez actual. 6. El sistema debe mantener el tiempo de respuesta actual. 7. El lenguaje de programación debe ser GTK+. 8. Las interfaces a rediseñar deben tener el mismo estilo que la interfaz actual.
3.3 Diseño
El modelo del proceso de la ingeniería de la usabilidad dicta que en la fase de diseño se debe realizar el análisis de tareas, establecer el modelo conceptual, definir el estilo de las interfaces e iterar estas actividades para conseguir un análisis detallado. A continuación se mostrarán estas actividades desarrolladas.
3.3.1 Análisis de tareas y modelo conceptual
Lo que a continuación se mostrará serán capturas de prototipos con las interfaces mejoradas, los diagramas HTA y diagramas de actividad UML de cada uno de los módulos a modificar, con la intención de analizar y establecer el modelo conceptual de cada una de las tareas.
3.3.1.1 Análisis de tareas y modelo conceptual del Reloj
Análisis de tareas. A continuación se muestra el diagrama HTA de la solución propuesta para establecer las preferencias del formato personalizado del reloj, dando solución al requisito funcional:
1. Establecer formato personalizado para el reloj del panel.
0. Realizar Formato
Personalizado al
Reloj.
1. Acceso a
Preferencias del
Reloj.
2. Acceder a la
pestaña Formato.
3. Pulsar tipografía
para fecha.
4. Pulsar color para
fecha.
Plan 0:
> Si NO en preferencias, hacer 1
> Hacer 2, 3, 4, 5, 6, 7, 8
>Hacer 9 cuando se hayan seleccionado
todas las opciones.
Plan 3:
> Realizar 3.1, 3.2 y 3.3
repetidamente hasta ver
la tipografía deseada.
3.1 Seleccionar
Familia.
3.2 Seleccionar
Estilo.
3.3 Seleccionar
Tamaño.
4.1 Seleccionar
Color.
5.1 Seleccionar
Familia.
Plan 4:
> Realizar 4.1
repetidamente hasta ver
el color deseado.
5. Pulsar tipografía
para la hora.
6. Pulsar color para
la hora.
7. Seleccionar
Disposicion.
8. Seleccionar Orden.
9. Seleccionar
Formato
Personalizado.
6.1 Seleccionar
Color.
5.2 Seleccionar
Estilo.
5.3 Seleccionar
Tamaño.
Plan 5:
> Realizar 5.1, 5.2 y 5.3
repetidamente hasta ver
la tipografía deseada.
Plan 6:
> Realizar 6.1
repetidamente hasta ver
el color deseado.
Ilustración 3.2 Diagrama HTA que muestra la actividad de personalizar el reloj de GNOME 2.30.
87
Una vez descrito el proceso para modificar el formato personalizado, se muestran capturas de un prototipo de software señalando los elementos introducidos para dar solución al requisito. Se ha agregado la pestaña de formato.
Ilustración 3.3 Interfaz de las preferencias del reloj,
mostrando la inclusión de la pestaña de Formato.
A continuación se muestra el contenido de la pestaña Formato.
1
2
3
4
5
6
7
Ilustración 3.4 Contenido de la pestaña Formato.
En la pestaña de Formato se han introducido: 1. Botón para seleccionar nueva fuente para la fecha nombrado letra_fecha. 2. Botón para seleccionar nuevo color para la fecha nombrado color_fecha. 3. Botón para seleccionar nueva fuente para la hora nombrado letra_hora. 4. Botón para seleccionar nuevo color para la hora nombrado color_hora.
88
5. Un par de botones de radio para seleccionar la disposición, el primero nombrado una_linea, ya que mostrará en una línea la fecha y la hora y el segundo denominado dos_linea, mostrará la fecha y hora en líneas separadas.
6. Un par de botones de radio para seleccionar el orden en que aparezcan los elementos, el primero llamado primero_fecha, que mostrará primero la fecha y después la hora y el segundo llamado primero_hora, el cual mostrará primero la hora y después la fecha.
7. Un checkbox para confirmar el uso del formato personalizado llamado aceptarFormato.
Al seleccionar algún botón para modificar la fuente, lo que aparecerá es la siguiente ventana, donde se puede seleccionar el formato de la tipografía.
Ilustración 3.5 Interfaz desplegada para
establecer una tipografía.
Al seleccionar algún botón para modificar el color, lo que aparecerá es esta ventana, donde se puede seleccionar el color del elemento.
Ilustración 3.6 Interfaz desplegada para
establecer un color.
89
Modelo conceptual. El modelo conceptual para el cambio a la apariencia del reloj es el siguiente: 1. El usuario debe ingresar a las preferencias del reloj. 2. Se debe seleccionar la pestaña de Formato. 3. El usuario puede especificar una tipografía y un color para la fecha y para la hora. 4. Se puede seleccionar que la fecha y la hora aparezcan en una línea o dos. 5. Se puede elegir el orden en que aparezca la fecha y la hora. 6. Para que los cambios tengan efecto se debe activar el checkbox de Formato personalizado. El diagrama de actividades del modelo conceptual se muestra a continuación:
Establecer Formato
Personalizado
[Checkbox de formato
personalizado activado]
[Checkbox de formato
personalizado desactivado]
Seleccionar Color
para la Fecha
Seleccionar Tipografía
para la Fecha
Seleccionar Tipografía
para la Hora
Seleccionar Color
para la Hora
Seleccionar
Disposición
Seleccionar
Orden
Activar checkbox de Formato Personalizado
Ilustración 3.7 Diagrama de actividades UML para establecer el formato del reloj.
3.3.1.2 Análisis de tareas y modelo conceptual del Panel
Análisis de tareas. A continuación se muestran los diagramas HTA de la solución propuesta para establecer las preferencias del panel, dando solución a los requisitos funcionales: 1. Activar y desactivar animación al ocultar el panel. 2. Establecer la velocidad de la animación con la que el panel se oculta. 3. Establecer la cantidad de pixeles visibles cuando el panel se oculta automáticamente. 4. Establecer el retardo en milisegundos para que el panel se oculte. 5. Establecer el retardo en milisegundos para que el panel aparezca. 6. Establecer una imagen como fondo del panel como en mosaico. 7. Establecer una imagen como fondo del panel de manera ajustada.
0. Establecer
preferencias generales
del panel
1. Acceso a Preferencias
del Panel
2. Acceder a la pestaña
general
3. Seleccionar orientaciòn
5. Seleccionar si se
expande el panel
4. Seleccionar Tamaño
6. Seleccionar si ocultar
automáticamente el panel
Plan 0:
> Si NO en preferencias, hacer 1
> Hacer 2, 3, 4, 5, 6, 7 hasta que se
encuentren las opciones deseadas
7. Seleccionar si mostrar
botones de ocultador
6.3 Seleccionar los pixeles
visibles del panel una vez
oculto
Plan 6:
> Realizar 6.1, 6.2, 6.3
repetidamente hasta ver
las opciones deseadas
6.2 Seleccionar retardo en
desaparecer
6.1Seleccionar retardo en
aparecer
Seleccionar si mostrar
flechas en los botones de
ocultador
Ilustración 3.8 Diagrama HTA que muestra la actividad de establecer las preferencias generales del panel.
0. Establecer preferencias de
Fondo del panel
1. Acceso en preferencias
del panel
2. Acceder a la pestaña
Fondo
3. Seleccionar el tema del
sistema
5. Seleccionar imagen de
fondo
4. Seleccionar color solido
Plan 0:
> Si NO en preferencias, hacer 1
> Hacer 2
> Hacer 3,4 y 5 según elección
4.2 Seleccionar estilo
4.1 Seleccionar color
Plan 4:
>Realizar 4.1 y 4.2
hasta encontrar opciones
adecuadas
Plan 5:
>Realizar 5.1, 5.2 y 5.3
hasta encontrar opciones
adecuadas
5.3 Seleccionar si
extendido
5.2. Seleccionar si
mosaico
5.1. Seleccionar Imágen
Ilustración 3.9 Diagrama HTA que muestra la actividad de establecer preferencias de fondo del panel.
91
Lo siguiente que se muestra son capturas de la interfaz gráfica de un prototipo de software para dar solución a los requerimientos anteriormente descritos:
Ilustración 3.10 Interfaz con elementos nuevos para
realizar la modificación al panel.
En la pestaña General se añadió: 1. Un spinbutton para establecer el retardo en que aparece el panel denominado
unhide_delay_spinbutton. 2. Un spinbutton para establecer el retardo en que desaparece el panel denominado
hide_delay_spinbutton. 3. Un spinbutton que nos permite establecer el número de pixeles visibles del panel una vez que
este está oculto denominado auto_hide_size_spinbutton. 4. Un checkbox para activar o desactivar la animación del panel nombrado
enable_animations_checkbutton. 5. Un combobox para determinar la velocidad de la animación del panel nombrado
enable_animations_combobox.
1
2
3
4
5
92
En la pestaña de Fondo se agregaron un par de ToggleButtons para poder seleccionar entre una imagen expandida o una de mosaico en la imagen de fondo. El primero se nombró image_stretch_radiobutton y el segundo image_fit_radiobutton.
Ilustración 3.11 Modificación a la pestaña de Fondo.
Modelo conceptual. El modelo conceptual para el cambio a las propiedades generales del panel es el siguiente: 1. El usuario debe ingresar a las preferencias del panel. 2. Se debe seleccionar la pestaña General. 3. El usuario puede seleccionar una Orientación para el panel. 4. Se puede seleccionar un tamaño para el panel. 5. Se puede seleccionar si el panel se expandirá. 6. Se puede seleccionar si el panel se ocultará, si se oculta se puede seleccionar el retardo para
aparecer y de ocultación, además de el número de pixeles visibles del panel. 7. Se puede seleccionar si el panel tendrá animación al ocultarse, si es así, se puede configurar la
velocidad de la animación. 8. Se puede seleccionar si se deberán mostrar botones para ocultar el panel, si se activan, se
puede seleccionar si deben aparecer flechas en los botones de ocultación.
2
1
93
El diagrama de actividades del modelo conceptual se muestra a continuación:
Establecer Preferencias
Generales del Panel
Seleccionar
Tamaño
Seleccionar
Orientación
Seleccionar si
expandir
Seleccionar si Ocultar
Automáticamente
Seleccionar si Mostrar
Botones de Ocultación
Seleccionar si
Flechas en los Botones
Seleccionar
Pixeles Visibles
Seleccionar Retardo
en Aparecer
Seleccionar Retardo
en Desaparecer
Seleccionar si Animación
al Ocultar el pixel
Seleccionar Velocidad
de Animación
Ilustración 3.12 Diagrama de actividades UML para establecer las preferencias generales del panel.
El modelo conceptual para el cambio a las propiedades del fondo del panel es el siguiente: 1. El usuario debe ingresar a las preferencias del panel. 2. Se debe seleccionar la pestaña Fondo. 3. El usuario puede seleccionar si usar el tema del sistema. 4. El usuario puede seleccionar si usar un color sólido, si es seleccionada esta opción, deberá
seleccionar el color y la transparencia deseada. 5. El usuario puede seleccionar si usar una imagen como fondo del panel, si se selecciona esta
opción, se deberá escoger una imagen y si se desea en mosaico o extendida.
94
El diagrama de actividades del modelo conceptual se muestra a continuación:
Establecer Formato Fondo
Del Panel
Seleccionar si
Usar el Tema del SistemaSeleccionar si
Color SólidoSeleccionar Imagen
de Fondo
Seleccionar Estilo
Seleccionar Color
Seleccionar si Mosaico
Seleccionar si Expandido
Seleccionar Archivo
Ilustración 3.13 Diagrama de actividades UML para establecer el formato de fondo del panel.
95
3.3.1.3 Análisis de tareas y modelo conceptual de la barra de menú
Análisis de tareas. A continuación se muestra el diagrama HTA de la solución propuesta para establecer la preferencia de la barra de menú, dando solución al requisito funcional:
9. Establecer un icono personalizado para la barra de menú.
0. Establecer Icono
Personalizado para la
Barra de Menú.
1. Acceso a Propiedades
del Menú.
2. Seleccionar si utilizar
Icono del Tema.
3. Seleccionar si utilizar
Icono Personalizado.
4. Cerrar ventana de
propiedades.
Plan 0:
> Si NO en propiedades, hacer 1
> Hacer 2, 3
>Hacer 4 cuando se hayan seleccionado
las opciones deseadas.
Plan 3:
> Realizar 3.1
repetidamente hasta ver
el icono deseado.
3.1 Escoger Icono
Personalizado.
Ilustración 3.14 Diagrama HTA que muestra la actividad de establecer icono personalizado en la barra de
menú.
Lo siguiente que se muestra, son capturas de la interfaz gráfica de un prototipo de software para dar solución al requerimiento anteriormente descrito:
3
12
4
Ilustración 3.15 Interfaz para realizar el cambio de icono de la barra de menú.
96
Se creó una ventana en tiempo de ejecución con los siguientes elementos: 1. Un botón de radio para escoger utilizar el icono del tema. 2. Un botón de radio para seleccionar utilizar un icono personalizado. 3. Un botón para seleccionar el archivo del icono. 4. Un botón para cerrar. Al pulsar el botón para seleccionar el archivo se mostrará un cuadro de diálogo para poder navegar entre los directorios y seleccionar el archivo adecuado.
Ilustración 3.16 Interfaz para seleccionar un nuevo icono.
97
Modelo conceptual. El modelo conceptual para el cambio de icono a la barra de menú es el siguiente: 1. El usuario debe ingresar a las propiedades de la barra de menú. 2. Se debe seleccionar entre usar el icono del tema o usar algún icono personalizado. 3. Si se escoge usar el icono personalizado, se deberá seleccionar un archivo de imagen para
establecer como icono personalizado, para realizar esto se debe pulsar el botón de selección de archivo.
4. Se deberá navegar entre los directorios para seleccionar el archivo del icono personalizado elegido y pulsar el botón Abrir.
5. Se deberá cerrar la ventana de propiedades de la barra del menú. El diagrama de actividades del modelo conceptual se muestra a continuación:
Establecer Icono
Personalizado a la Barra de Menú
[Botón de radio de icono
personalizado activado]
[Botón de radio de icono
personalizado desactivado]
Seleccionar Archivo de
Imagen del Nuevo Icono
Activar botón de radio para
Utilizar Icono Personalizado
Seleccionar Archivo de
Imagen del Nuevo Icono
Ilustración 3.17 Diagrama de actividades UML que muestra la actividad de establecer un icono
personalizado en la barra de menú.
3.3.1.4 Análisis de tareas y modelo conceptual de los iconos especiales en el
Escritorio
Análisis de tareas. A continuación se muestra el diagrama HTA de la solución propuesta para activar o desactivar los iconos de “Equipo”, “Carpeta Personal”, “Papelera”, “Servidores de Red” y de los volúmenes montados, además de determinar el número de líneas visibles en los nombres de los archivos, dando solución a los siguientes requisitos funcionales:
10. Activar o desactivar el icono de “Equipo” en el escritorio. 11. Activar o desactivar el icono de “Carpeta Personal” en el escritorio. 12. Activar o desactivar el icono de “Papelera” en el escritorio. 13. Activar o desactivar el icono de “Servidores de Red” en el escritorio. 14. Determinar el número de líneas visibles en los nombres de los archivos. 15. Activar o desactivar los iconos de las unidades montadas en el sistema.
0. Establecer iconos
especiales en el escritorio
y líneas visibles en el
nombre de archivos.
1. Acceso a Preferencias
del Escritorio.
2. Acceder a la Pestaña
Escritorio.
3. Activar/Desactivar el
Icono de “Equipo”.
5. Activar/Desactivar el
Icono de “Papelera”.
4. Activar/Desactivar el
Icono de “Carpeta
Personal”.
6. Activar/Desactivar el
Icono de “Servidores de
Red”.
Plan 0:
> Si NO en preferencias, hacer 1
> Hacer 2, 3, 4, 5, 6, 7, 8 hasta
obtener el resultado
deseado.
Plan 3:
> Realizar 3.1
repetidamente hasta
obtener el resultado
deseado.
7. Activar/Desactivar Ver
los Volúmenes Montados
en el Escritorio.
8. Seleccionar Cantidad de
Líneas en el Nombre de
Archivos.
3.1 Tildar Checkbox
“Mostrar icono de equipo” .
4.1 Tildar Checkbox
“Mostrar icono de la
carpeta personal”.
6.1 Tildar Checkbox
“Mostrar icono de red”.
5.1 Tildar Checkbox
“Mostrar icono de la
papelera”.
Plan 5:
> Realizar 5.1
repetidamente hasta
obtener el resultado
deseado.
Plan 4:
> Realizar 4.1
repetidamente hasta
obtener el resultado
deseado.
Plan 6:
> Realizar 6.1
repetidamente hasta
obtener el resultado
deseado.
7.1 Tildar Checkbox
“Mostrar iconos de
volumenes montados”.
8.1 Aumentar/ Disminuir el
Spinbutton “Limite de la
elipsis del texto”.
Plan 7:
> Realizar 7.1
repetidamente hasta
obtener el resultado
deseado.
Plan 8:
> Realizar 8.1
repetidamente hasta
obtener el resultado
deseado.
Ilustración 3.18 Diagrama HTA que muestra la actividad de Activar/Desactivar iconos especiales en el escritorio y determinar la cantidad de líneas a aparecer
en el nombre de los iconos.
99
Una vez descrito el proceso para Activar/Desactivar iconos especiales en el escritorio y la opción de seleccionar el número de líneas para el nombre de los iconos, se muestran capturas de un prototipo de software señalando los elementos introducidos para dar solución a los requisitos. Se ha agregado la pestaña Escritorio.
Ilustración 3.19 Interfaz de
las preferencias del reloj,
mostrando la inclusión de la
pestaña de Formato.
Ilustración 3.20 Contenido de
la pestaña Escritorio.
1
123
456
100
En la pestaña Escritorio se han introducido: 1. Un checkbox para activar/desactivar el icono de “Equipo” en el escritorio nombrado
computer_icon_visible_checkbutton. 2. Un checkbox para activar/desactivar el icono de “Carpeta Personal” en el escritorio nombrado
home_icon_visible_checkbutton. 3. Un checkbox para activar/desactivar el icono de “Servidores de Red” en el escritorio
nombrado network_icon_visible_checkbutton. 4. Un checkbox para activar/desactivar el icono de “Papelera” en el escritorio nombrado
trash_icon_visible_checkbutton. 5. Un checkbox para activar/desactivar los iconos de los volúmenes montados en el escritorio
nombrado volumes_visible_checkbutton. 6. Un spinbutton para seleccionar el número de líneas de texto que aparecerá como nombre de
icono en el escritorio, llamado text_ellipsis_limit_spinbutton.
Modelo conceptual. El modelo conceptual para el proceso de Activar/Desactivar iconos especiales en el escritorio y la opción de seleccionar el número de líneas para el nombre de los iconos es el siguiente: 1. El usuario debe ingresar a las Preferencias de la Apariencia. 2. Se debe seleccionar la pestaña Escritorio. 3. El usuario puede activar o desactivar la aparición del icono de “Equipo” en el escritorio. 4. El usuario puede activar o desactivar la aparición del icono de “Carpeta Personal” en el
escritorio. 5. El usuario puede activar o desactivar la aparición del icono de “Servidores de Red” en el
escritorio. 6. El usuario puede activar o desactivar la aparición del icono de “Papelera” en el escritorio. 7. El usuario puede activar o desactivar la aparición de los iconos de los volúmenes montados en
el escritorio. 8. El usuario puede aumentar o disminuir la cantidad de líneas visibles en el texto que aparece
debajo de los iconos en el escritorio.
Los diagramas de actividades del modelo conceptual se muestran a continuación:
Activar icono de “Equipo”
en el escritorio
[Checkbox “Mostrar icono
de equipo” activado]
[Checkbox “Mostrar icono
de equipo” desactivado]
Activar checkbox
“Mostrar icono de equipo”
Ilustración 3.21 Diagrama de actividades UML para activar el icono de "Equipo" en el escritorio.
101
Activar icono de
“Carpeta Personal”
[Checkbox “Mostrar icono de
la carpeta personal” activado]
[Checkbox “Mostrar icono de la
carpeta personal” desactivado]
Activar checkbox “Mostrar
icono de la carpeta personal”
Ilustración 3.22 Diagrama de actividades UML para activar el icono de "Carpeta Personal" en el escritorio.
Activar icono de “Servidores
de Red” en el escritorio
[Checkbox “Mostrar icono
de red” activado]
[Checkbox “Mostrar icono
de red” desactivado]
Activar checkbox
“Mostrar icono de red”
Ilustración 3.23 Diagrama de actividades UML para activar el icono de "Servidores de Red" en el escritorio.
Activar icono de “Papelera”
en el escritorio
[Checkbox “Mostrar icono
de la papelera” activado]
[Checkbox “Mostrar icono
de la papelera” desactivado]
Activar checkbox
“Mostrar icono de la papelera”
Ilustración 3.24 Diagrama de actividades UML para activar el icono de "Papelera" en el escritorio.
Activar iconos de Volúmenes
Montados en el escritorio
[Checkbox “Mostrar iconos de
volúmenes montados” activado]
[Checkbox “Mostrar iconos de
volúmenes montados” desactivado]
Activar checkbox “Mostrar
iconos de volúmenes montados”
Ilustración 3.25 Diagrama de actividades UML para activar los iconos de los volumenes montados en el
escritorio.
102
Seleccionar numero de líneas
de texto debajo de los iconos.
[El numero de líneas
es adecuado]
[El numero de líneas no es
adecuado]
Establecer valor adecuado con el
spinbutton “Limite de la elipsis del texto”
Ilustración 3.26 Diagrama de actividades UML para seleccionar el número de lineas de texto debajo de los
iconos.
3.3.1.5 Análisis de tareas y modelo conceptual de la barra de título.
Análisis de tareas. A continuación se muestran los diagramas HTA de la solución propuesta para dar respuesta a los siguientes requisitos funcionales:
16. Establecer el nivel de opacidad de la ventana activa. 17. Activar o desactivar la opacidad de la ventana activa. 18. Establecer el nivel de opacidad de la ventana inactiva. 19. Activar o desactivar la opacidad de la ventana inactiva. 20. Establecer la acción de la rueda del ratón en la barra de título. 21. Activar o desactivar el uso de Metacity. 22. Establecer la acción del doble clic en la ventana de título. 23. Establecer la acción del clic del botón central en la ventana de título. 24. Establecer la acción del clic con el botón derecho en la ventana de título. 25. Establecer la disposición de los botones en la barra de título.
0. Establecer la
Decoración de Ventanas.
1. Acceso a Preferencias
de la Apariencia.
2. Acceder a la Pestaña
Ventanas.
3. Activar/Desactivar el
Uso de Metacity.
5. Seleccionar el Grado de
Opacidad de la Ventana
Activa.
4. Activar/Desactivar
Transparencia de la
Ventana Activa.
6. Activar/Desactivar
Transparencia de la
Ventana Inactiva.
Plan 0:
> Si NO en preferencias, hacer 1
> Hacer 2, 3, 4, 5, 6 y 7 hasta
obtener el resultado
deseado.
Plan 3:
> Realizar 3.1
repetidamente hasta
obtener el resultado
deseado.
7. Seleccionar el Grado de
Opacidad de la Ventana
Inactiva.
3.1 Tildar Checkbox “Usar
el tema de Metacity”.
4.1 Tildar Checkbox
“Activar transparencia de
la ventana activa”.
6.1 Tildar Checkbox
““Activar transparencia de
la ventana inactiva”.
5.1 Aumentar/ Disminuir el
Spinbutton “Nivel de
transparencia de la
ventana activa”.
Plan 5:
> Realizar 5.1
repetidamente hasta
obtener el resultado
deseado.
Plan 4:
> Realizar 4.1
repetidamente hasta
obtener el resultado
deseado.
Plan 6:
> Realizar 6.1
repetidamente hasta
obtener el resultado
deseado.
7.1 Aumentar/ Disminuir el
Spinbutton “Nivel de
transparencia de la
ventana inactiva”.
Plan 7:
> Realizar 7.1
repetidamente hasta
obtener el resultado
deseado.
Ilustración 3.27 Diagrama HTA que muestra la actividad de establecer la decoración de las ventanas.
0. Establecer las Acciones
de la Barra de Título.
1. Acceso a Preferencias
de la Apariencia.
2. Acceder a la Pestaña
Ventanas.
3. Seleccionar la Acción de
la Rueda del Ratón en la
Barra de Título.
5. Seleccionar la Acción
del Botón central del Ratón
en la Barra de Título.
4. Seleccionar la Acción
del Doble Click en la Barra
de Título.
6. Seleccionar la Acción
del Botón Derecho del
Ratón en la Barra de
Título.
Plan 0:
> Si NO en preferencias, hacer 1
> Hacer 2, 3, 4, 5 y 6 hasta
obtener el resultado
deseado.
Plan 3:
> Realizar 3.1
repetidamente hasta
obtener el resultado
deseado.
3.1 Seleccionar una
Opción del Combobox
“Acción de la rueda del
ratón en la barra de título”.
4.1 Seleccionar una
Opción del Combobox
“Acción de pulsar dos
veces en la barra de título”
6.1 Seleccionar una
Opción del Combobox
“Acción del botón derecho
en la barra de título”
5.1 Seleccionar una
Opción del Combobox
“Acción del botón central
en la barra de título”
Plan 5:
> Realizar 5.1
repetidamente hasta
obtener el resultado
deseado.
Plan 4:
> Realizar 4.1
repetidamente hasta
obtener el resultado
deseado.
Plan 6:
> Realizar 6.1
repetidamente hasta
obtener el resultado
deseado.
Ilustración 3.28 Diagrama HTA que muestra la actividad de Establecer las acciones de la barra de título.
0. Establecer la
Disposición de los botones
en la Barra de Título.
1. Acceso a Preferencias
de la Apariencia.
2. Acceder a la Pestaña
Ventanas.
3. Seleccionar una Opción
del Primer Combobox.
5. Seleccionar una Opción
del Tercer Combobox..
4. Seleccionar una Opción
del Segundo Combobox.
6.Seleccionar una Opción
del Cuarto Combobox.
Plan 0:
> Si NO en preferencias, hacer 1
> Hacer 2, 3, 4, 5, 6, 7, 8 hasta
obtener el resultado
deseado.
7. Seleccionar una Opción
del Quinto Combobox.
8. Seleccionar una Opción
del Sexto Combobox.
Ilustración 3.29 Diagrama HTA que muestra la actividad de establecer la disposicion de los botones de la barra de título.
105
Una vez descrito los procesos con los diagramas HTA, se muestran capturas de un prototipo de software señalando los elementos introducidos para dar solución a los requisitos. Se ha agregado la pestaña Ventanas.
1
Ilustración 3.30 Interfaz de las preferencias de la apariencia, mostrando la inclusión de la pestaña de
Ventana.
123
45
6
7
8
9
10
Ilustración 3.31 Contenido de la pestaña Ventana.
106
En la pestaña Escritorio se han introducido: 1. Un checkbox para activar/desactivar el uso de Metacity como gestor de ventanas nombrado
use_metacity_theme_checkbutton. 2. Un checkbox para activar/desactivar la transparencia de la ventana activa nombrado
metacity_theme_active_shade_opacity_checkbutton. 3. Un spinbutton para seleccionar el nivel de transparencia de la ventana activa, nombrado
metacity_theme_active_opacity_spinbutton. 4. Un checkbox para activar/desactivar la transparencia de la ventana inactiva nombrado
metacity_theme_shade_opacity_checkbutton. 5. Un spinbutton para seleccionar el nivel de transparencia de la ventana inactiva, nombrado
metacity_theme_opacity_spinbutton. 6. Un combobox para seleccionar la acción de la rueda del ratón en la barra de título, nombrado
mouse_wheel_action_combobox. 7. Un combobox para seleccionar la acción del doble clic en la barra de título, nombrado
action_double_click_titlebar_combobox. 8. Un combobox para seleccionar la acción del botón central del ratón en la barra de título,
nombrado action_middle_click_titlebar_combobox. 9. Un combobox para seleccionar la acción del botón derecho del ratón en la barra de título,
nombrado action_right_click_titlebar_combobox. 10. Seis combobox para seleccionar la disposición de los botones en la barra de título, nombrados
button_layout_combobox1, button_layout_combobox2, button_layout_combobox3, button_layout_combobox4, button_layout_combobox5 y button_layout_combobox6 respectivamente.
Modelo conceptual. El modelo conceptual para el proceso de Activar/Desactivar iconos especiales en el escritorio y la opción de seleccionar el número de líneas para el nombre de los iconos es el siguiente: 1. El usuario debe ingresar a las Preferencias de la Apariencia. 2. Se debe seleccionar la pestaña Ventanas. 3. El usuario puede activar/desactivar el uso de Metacity como gestor de ventanas. 4. El usuario puede activar/desactivar la transparencia de la ventana activa. 5. El usuario puede seleccionar el nivel de transparencia de la ventana activa. 6. El usuario puede activar/desactivar la transparencia de la ventana inactiva. 7. El usuario puede seleccionar el nivel de transparencia de la ventana inactiva. 8. El usuario puede seleccionar la acción de la rueda del ratón en la barra de título 9. El usuario puede seleccionar la acción del doble clic en la barra de título. 10. El usuario puede seleccionar la acción del botón central del ratón en la barra de título. 11. El usuario puede seleccionar la acción del botón derecho del ratón en la barra de título. 12. El usuario puede seleccionar la disposición de los botones en la barra de título, haciendo clic
en los combobox dispuestos para este fin. Los diagramas de actividades del modelo conceptual se muestran a continuación:
107
Activar Metacity como
gestor de ventanas
[Checkbox “Usar el tema
de Metacity” activado]
[Checkbox “Usar el tema
de Metacity” desactivado]
Activar checkbox
“Usar el tema de Metacity”
Ilustración 3.32 Diagrama de actividades UML para activar Metacitycomo gestor de ventanas.
Activar transparencia
de ventana activa
[Checkbox “Activar
transparencia de ventana
activa” activado]
[Checkbox “Activar transparencia
de ventana activa” desactivado]
Activar checkbox “Activar
transparencia de ventana activa”
Ilustración 3.33 Diagrama de actividades UML para activar la transparencia de la ventana activa.
Seleccionar nivel de
opacidad de la ventana activa
[La opacidad es correcta]
[La opacidad no es
correcta]
Establecer valor adecuado con el spinbutton
“Nivel de transparencia de la ventana activa”
Ilustración 3.34 Diagrama de actividades UML para seleccionar el nivel de opacidad de la ventana activa.
Activar transparencia
de ventana inactiva
[Checkbox “Activar
transparencia de ventana
inactiva” activado]
[Checkbox “Activar transparencia
de ventana inactiva” desactivado]
Activar checkbox “Activar
transparencia de ventana inactiva”
Ilustración 3.35 Diagrama de actividades UML para activar la transparencia de la ventana inactiva.
108
Seleccionar nivel de
opacidad de la ventana inactiva
[La opacidad es correcta]
[La opacidad no es
correcta]
Establecer valor adecuado con el spinbutton
“Nivel de transparencia de la ventana inactiva”
Ilustración 3.36 Diagrama de actividades UML para seleccionar el nivel de opacidad de la ventana inactiva.
Seleccionar acción de la rueda
central del ratón en la barra de título
[La acción es correcta]
[La acción no es correcta]
Establecer valor adecuado con el combobox “Acción
de la rueda central del ratón en la barra de título”
Ilustración 3.37 Diagrama de actividades UML para seleccionar la acción de la rueda central en la barra de
título.
Seleccionar acción al pulsar
dos veces en la barra de título
[La acción es correcta]
[La acción no es correcta]
Establecer valor adecuado con el combobox
“Acción al pulsar dos veces en la barra de título”
Ilustración 3.38 Diagrama de actividades UML para seleccionar la acción al doble clic en la barra de título.
Seleccionar acción del botón
central en la barra de título
[La acción es correcta]
[La acción no es correcta]
Establecer valor adecuado con el combobox
“Acción del botón central en la barra de título”
Ilustración 3.39 Diagrama de actividades UML para seleccionar la acción del botón central en la barra de
título.
109
Seleccionar acción del botón
derecho en la barra de título
[La acción es correcta]
[La acción no es correcta]
Establecer valor adecuado con el combobox
“Acción del botón derecho en la barra de título”
Ilustración 3.40 Diagrama de actividades UML para seleccionar la acción del botón derecho en la barra de
título.
Establecer disposición de
los botones de la barra de título
[Disposición correcta]
[Disposición incorrecta]
Establecer valor adecuado
con el segundo combobox
Establecer valor adecuado
con el primer combobox
Establecer valor adecuado
con el tercer combobox
Establecer valor adecuado
con el cuarto combobox
Establecer valor adecuado
con el quinto combobox
Establecer valor adecuado
con el sexto combobox
Ilustración 3.41 Diagrama de actividades UML para establecer la disposición de los botones en la barra de
título.
110
3.3.1.6 Análisis de tareas y modelo conceptual del Menú principal
Análisis de tareas. A continuación se muestra el diagrama HTA de la solución propuesta para establecer la preferencia del menú principal, dando solución al requisito funcional:
26. Establecer un icono personalizado para el menú principal.
0. Establecer Icono
Personalizado para Menú
Principal.
1. Acceso a Propiedades
del Menú.
2. Seleccionar si utilizar
Icono del Tema.
3. Seleccionar si utilizar
Icono Personalizado.
4. Cerrar ventana de
propiedades.
Plan 0:
> Si NO en propiedades, hacer 1
> Hacer 2, 3
>Hacer 4 cuando se hayan seleccionado
las opciones deseadas.
Plan 3:
> Realizar 3.1
repetidamente hasta ver
el icono deseado.
3.1 Escoger Icono
Personalizado.
Ilustración 3.42 Diagrama HTA que muestra la actividad de establecer un icono personalizado en el menú
principal.
Lo siguiente que se muestra son capturas de la interfaz gráfica de un prototipo de software para dar solución al requerimiento anteriormente descrito:
3
12
4
Ilustración 3.43 Interfaz diseñada para seleccionar el uso de un icono personalizado para el menú
principal.
111
Se creó una ventana en tiempo de ejecución con los siguientes elementos: 1. Un botón de radio para escoger utilizar el icono del tema. 2. Un botón de radio para seleccionar utilizar un icono personalizado. 3. Un botón para seleccionar el archivo del icono. 4. Un botón para cerrar. Al pulsar el botón para seleccionar el archivo se mostrará un cuadro de diálogo para poder navegar entre los directorios y seleccionar el archivo adecuado.
Ilustración 3.44 Interfaz para seleccionar un nuevo icono.
Modelo conceptual. El modelo conceptual para el cambio de icono al Menú principal es el siguiente: 1. El usuario debe ingresar a las propiedades del menú principal. 2. Se debe seleccionar entre usar el icono del tema o usar algún icono personalizado. 3. Si se escoge usar el icono personalizado, se deberá seleccionar un archivo de imagen para
establecer como icono personalizado, para realizar esto se debe pulsar el botón de selección de archivo.
4. Se deberá navegar entre los directorios para seleccionar el archivo del icono personalizado elegido y pulsar el botón Abrir.
5. Se deberá cerrar la ventana de propiedades de la barra del menú.
112
El diagrama de actividades del modelo conceptual se muestra a continuación:
Establecer Icono
Personalizado al Menú Principal
[Botón de radio de icono
personalizado activado]
[Botón de radio de icono
personalizado desactivado]
Seleccionar Archivo de
Imagen del Nuevo Icono
Activar botón de radio para
Utilizar Icono Personalizado
Seleccionar Archivo de
Imagen del Nuevo Icono
Ilustración 3.45 Diagrama de actividades UML que muestra la actividad de establecer un icono
personalizado en el menú principal.
3.3.2 Estilo
Debido a que el proyecto consiste en modificar interfaces ya existentes se utilizarán los estándares
generales, las metáforas y colores por defecto del sistema, el cual ya tiene implementado un
mecanismo para que el estilo sea modificado, la descripción de ese mecanismo queda fuera del
alcance de este proyecto de investigación.
Ya descrito el análisis de los requisitos y el diseño de la propuesta de solución, se pasará al
desarrollo, tema que se tratará en el siguiente capítulo.
113
Capítulo 4 Construcción de la solución En el capitulo anterior se realizó el análisis de inventarios para determinar que módulos son
candidatos para una reestructuración, se realizó el análisis de tareas, se diseñaron prototipos y el
modelo conceptual de cada una de las soluciones que darán respuesta a los requisitos del
proyecto. Con base en los resultados obtenidos, en este capítulo se realizarán las actividades
restantes del modelo de la reingeniería del software.
Ya que los módulos son independientes, se realizarán las actividades para cada modulo individual.
4.1 Modificaciones al Reloj
A continuación se mostrará el desarrollo de las actividades necesarias para realizar las
modificaciones al reloj.
4.1.1 Ingeniería inversa
El código fuente analizado en esta etapa se encuentra en el archivo llamado clock.c y el archivo de
interfaz modificado fue clock.ui, ambos se encuentran en el directorio gnome-panel-
2.30.2/applets/clock del código fuente del panel de GNOME.
4.1.1.1 Ingeniería inversa para comprender datos
El archivo clock.c define el nombre con que hará referencia a las claves de gconf-editor de la
siguiente manera:
Definición de claves de gconf en el archivo clock.c
#define N_GCONF_PREFS 11 /* Keep this in sync with the number of keys below! */ #define KEY_FORMAT "format" #define KEY_SHOW_SECONDS "show_seconds" #define KEY_SHOW_DATE "show_date" #define KEY_SHOW_WEATHER "show_weather" #define KEY_SHOW_TEMPERATURE "show_temperature" #define KEY_CUSTOM_FORMAT "custom_format" #define KEY_SHOW_WEEK "show_week_numbers" #define KEY_CITIES "cities" #define KEY_TEMPERATURE_UNIT "temperature_unit" #define KEY_SPEED_UNIT "speed_unit"
Por ejemplo, la llave format de gconf-editor, será referenciada por la constante KEY_FORMAT. De
esta lista las claves que utilizaremos son: KEY_FORMAT y KEY_CUSTOM_FORMAT.
De igual forma se define una lista llamada format_type_enum_map con los valores determinados
de hora:
114
Definición de format_type_enum_map en el archivo clock.c
static GConfEnumStringPair format_type_enum_map [] = { { CLOCK_FORMAT_12, "12-hour" }, { CLOCK_FORMAT_24, "24-hour" }, { CLOCK_FORMAT_UNIX, "unix" }, { CLOCK_FORMAT_INTERNET, "internet" }, { CLOCK_FORMAT_CUSTOM, "custom" }, { 0, NULL } };
También se define una estructura de datos denominada _ClockData, el cual contiene todas las
variables usadas por el reloj.
Extracto de la definición de la estructura ClockData en el archivo clock.c
typedef struct _ClockData ClockData; struct _ClockData {
... /* widgets */ GtkWidget *applet; GtkWidget *panel_button; /* main toggle button for the whole clock */ GtkWidget *main_obox; /* orientable box inside panel_button */ GtkWidget *weather_obox; /* orientable box for the weather widgets */ GtkWidget *clockw; /* main label for the date/time display */ ...
};
4.1.1.2 Ingeniería inversa para comprender el procesamiento y de interfaz de
usuario
Al dar clic con el botón derecho del mouse sobre el reloj y seleccionar la opción de preferencias,
se llama a la función verb_display_properties_dialog (), la cual a su vez invoca a
display_properties_dialog (), esta se encarga de mostrar la interfaz gráfica de las propiedades,
pero solo la ventana principal; para darle funcionalidad a la ventana, se hace referencia a otra
función con nombre ensure_prefs_window_is_created () y por último se llama a
fill_prefs_window () que se encarga de llenar las preferencias y crear los eventos de todos los
objetos que estan relacionados con las preferencias del reloj.
4.1.2 Ingeniería directa
Para agregar las funcionalidades faltantes al reloj se realizó lo siguiente:
Se utilizaron las variables KEY_FORMAT y KEY_CUSTOM_FORMAT definidas en
clock.c y CLOCK_FORMAT_CUSTOM definida en la lista format_type_enum_map [].
Se modificó la estructura _ClockData añadiendo lo siguiente:
115
Extracto de la definición de la estructura ClockData en el archivo clock.c
typedef struct _ClockData ClockData; struct _ClockData {
... /* widgets */ GtkWidget *applet; GtkWidget *panel_button; /* main toggle button for the whole clock */ GtkWidget *main_obox; /* orientable box inside panel_button */ GtkWidget *weather_obox; /* orientable box for the weather widgets */ GtkWidget *clockw; /* main label for the date/time display */ GtkWidget *radio_p_f; GtkWidget *radio_p_h; GtkWidget *radio_una_linea; GtkWidget *radio_dos_linea; GtkWidget *letra_fecha; GtkWidget *letra_hora; GtkWidget *color_fecha; GtkWidget *color_hora; gboolean aceptarformato; ...
};
Como se puede observar, son las declaraciones de los Widgets creados en la interfaz gráfica, para
que puedan ser usados por clock.c, además de una variable booleana llamada aceptarformato, la
cual nos permitirá aceptar los cambios al formato realizados.
Se modificó el procedimiento fill_prefs_window () agregando lo siguiente:
Extracto de la implementación de la función fill_prefs_window () en el archivo clock.c
//Se define una referencia a un widget. GtkWidget *widget; //Se crea la referencia al GtkCheckButton llamado aceptarFormato widget = _clock_get_widget (cd, "aceptarFormato"); //Se crea un listener para que al ser seleccionado el checkbutton aceptarFormato se llame a la //función set_aceptar_formato_personalizado () pasando cd como parámetro. g_signal_connect (widget, "toggled", G_CALLBACK (set_aceptar_formato_personalizado), cd); //Se crea un listener para que al ser seleccionado el checkbutton aceptarFormato se llame a la //función set_aceptar_formato () pasando cd como parámetro. g_signal_connect (widget, "toggled", G_CALLBACK (set_aceptar_formato),cd); //Si la variable format es igual a CLOCK_FORMAT_CUSTOM, entonces aceptarformato es igual a //verdadero, en caso contrario es igual a falso. if(cd->format==CLOCK_FORMAT_CUSTOM){ cd->aceptarformato=TRUE; }else{ cd->aceptarformato=FALSE; }
116
//Establece el valor de activado en el checkbutton recién creado. gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (widget),cd->aceptarformato);
set_aceptar_formato_personalizado () y set_aceptar_formato () fueron creados para asignar
valores a la variable booleana aceptarformato y crear la cadena que será usada para definir el
formato personalizado respectivamente, estos procedimientos se explicarán más tarde.
A continuación se mostrarán las funciones creadas set_aceptar_formato_personalizado () y
set_aceptar_formato ().
Implementación de la función set_aceptar_formato_personalizado() en el archivo clock.c
//Función que activa o desactiva el formato personalizado. static void set_aceptar_formato_personalizado (GtkWidget *w, ClockData *clock) { /* Si el GtkCheckButton aceptarFormato se desactivó, cambiar el valor de la KEY_FORMAT de gconf-editor a 12-hour y pasar el valor de falso a la variable booleana aceptarformato. */ if( !gtk_toggle_button_get_active (GTK_TOGGLE_BUTTON (w))){ panel_applet_gconf_set_string (PANEL_APPLET (clock->applet), KEY_FORMAT, "12-hour", NULL); clock->aceptarformato=FALSE; }else{ /*Si el GtkCheckButton aceptarFormato se activó cambiar el valor de la KEY_FORMAT de gconf-editor a custom, pasar el valor de verdadero a la variable booleana aceptarformato y por ultimo crea cada uno de los Widgets que definimos anteriormente para la manipulación de las preferencias personalizadas, añadiéndoles una señal que llama a set_aceptar_formato.*/ panel_applet_gconf_set_string (PANEL_APPLET (clock->applet), KEY_FORMAT, "custom", NULL); clock->aceptarformato=TRUE; clock->letra_fecha = _clock_get_widget (clock, "letra_fecha"); g_signal_connect (clock->letra_fecha, "font-set", G_CALLBACK (set_aceptar_formato),clock); clock->letra_hora = _clock_get_widget (clock, "letra_hora"); g_signal_connect (clock->letra_hora, "font-set", G_CALLBACK (set_aceptar_formato), clock); clock->color_fecha = _clock_get_widget (clock, "color_fecha"); g_signal_connect (clock->color_fecha, "color-set", G_CALLBACK (set_aceptar_formato), clock); clock->color_hora = _clock_get_widget (clock, "color_hora"); g_signal_connect (clock->color_hora, "color-set", G_CALLBACK (set_aceptar_formato), clock); clock->radio_una_linea = _clock_get_widget (clock, "una_linea"); g_signal_connect (clock->radio_una_linea, "toggled", G_CALLBACK (set_aceptar_formato), clock); clock->radio_dos_linea = _clock_get_widget (clock, "dos_linea"); g_signal_connect (clock->radio_dos_linea, "toggled", G_CALLBACK (set_aceptar_formato), clock);
117
clock->radio_p_f = _clock_get_widget (clock, "primero_fecha"); g_signal_connect (clock->radio_p_f, "toggled", G_CALLBACK (set_aceptar_formato), clock); clock->radio_p_h = _clock_get_widget (clock, "primero_hora"); g_signal_connect (clock->radio_p_h, "toggled", G_CALLBACK (set_aceptar_formato), clock); } }
Implementación de la función set_aceptar_formato en el archivo clock.c
//Función que prepara y envía una cadena especificando el formato personalizado a gconf-editor. static void set_aceptar_formato (GtkWidget *w, ClockData *clock) { //Si la variable booleana aceptarformato es verdadera puede continuar if(clock->aceptarformato==TRUE){ GdkColor *fecha; GdkColor*hora; fecha = (GdkColor *)malloc(sizeof(GdkColor)); hora = (GdkColor *)malloc(sizeof(GdkColor)); //Se obtiene el color del botón color_fecha y se guarda en fecha. gtk_color_button_get_color (GTK_COLOR_BUTTON(clock->color_fecha), fecha); //Se obtiene el color del botón color_hora y se guarda en hora gtk_color_button_get_color (GTK_COLOR_BUTTON(clock->color_hora), hora); // Si el radio button radio_una_linea está activado sigue adelante. if(gtk_toggle_button_get_active (GTK_TOGGLE_BUTTON (clock->radio_una_linea))!=FALSE){ /*Si el radio button de primero fecha está activo, llena la variable custom format con la concatenación de cadenas para cambiar el formato.*/ if(gtk_toggle_button_get_active (GTK_TOGGLE_BUTTON (clock->radio_p_f))!=FALSE){ clock->custom_format= g_strconcat ("<span font=\"", gtk_font_button_get_font_name (GTK_FONT_BUTTON(clock->letra_fecha)), "\" color=\"", gdk_color_to_string (fecha),"\">%a %d de %b,</span> <span font=\"", gtk_font_button_get_font_name (GTK_FONT_BUTTON(clock->letra_hora)),"\" color=\"", gdk_color_to_string (hora),"\">%H:%M</span>",NULL); }else{ /*Si el radio button de primero hora está activo, llena la variable custom_format con la concatenación de cadenas para cambiar el formato.*/ if(gtk_toggle_button_get_active (GTK_TOGGLE_BUTTON (clock->radio_p_h))!=FALSE){ clock->custom_format= g_strconcat ("<span font=\"", gtk_font_button_get_font_name (GTK_FONT_BUTTON(clock->letra_hora)),"\" color=\"", gdk_color_to_string (hora),"\">%H:%M,</span><span font=\"", gtk_font_button_get_font_name (GTK_FONT_BUTTON(clock->letra_fecha)), "\" color=\"", gdk_color_to_string (fecha),"\">%a %d de %b</span>" ,NULL); } } } // Si el radio button radio_dos_linea está activado sigue adelante.
118
if(gtk_toggle_button_get_active (GTK_TOGGLE_BUTTON (clock->radio_dos_linea))!=FALSE){ /*Si el radio button de primero fecha está activo, llena la variable custom format con la concatenación de cadenas para cambiar el formato.*/ if(gtk_toggle_button_get_active (GTK_TOGGLE_BUTTON (clock->radio_p_f))!=FALSE){ clock->custom_format= g_strconcat ("<span font=\"", gtk_font_button_get_font_name (GTK_FONT_BUTTON(clock->letra_fecha)), "\" color=\"", gdk_color_to_string (fecha),"\">%a %d de %b,</span>%n <span font=\"", gtk_font_button_get_font_name (GTK_FONT_BUTTON(clock->letra_hora)),"\" color=\"", gdk_color_to_string (hora),"\">%H:%M</span>",NULL); }else{ /*Si el radio button de primero hora está activo, llena la variable custom format con la concatenación de cadenas para cambiar el formato.*/ if(gtk_toggle_button_get_active (GTK_TOGGLE_BUTTON (clock->radio_p_h))!=FALSE){ clock->custom_format= g_strconcat ("<span font=\"", gtk_font_button_get_font_name (GTK_FONT_BUTTON(clock->letra_hora)),"\" color=\"", gdk_color_to_string (hora),"\">%H:%M,</span>%n<span font=\"", gtk_font_button_get_font_name (GTK_FONT_BUTTON(clock->letra_fecha)), "\" color=\"", gdk_color_to_string (fecha),"\">%a %d de %b</span>" ,NULL); } } } //Establece el valor de custom_format a gconf-editor. panel_applet_gconf_set_string (PANEL_APPLET (clock->applet), KEY_CUSTOM_FORMAT, clock->custom_format, NULL); } }
Con esto se le da la funcionalidad de establecer el formato personalizado al reloj.
4.2 Modificaciones al Panel
A continuación se mostrará el desarrollo de las actividades necesarias para realizar las
modificaciones al panel.
4.2.1 Ingeniería inversa
El código fuente analizado en esta etapa se encuentra en los archivos panel-typebuiltins.c en
donde estan definidas algunas constantes utilizadas en toda la programación del panel, panel-
profile.c que contiene la implementación de código necesario para establecer y obtener
información de gconf, panel-profile.h es el archivo que contiene la definición de las funciones
implementadas en panel-profile.c, y panel-properties-dialog.c que es el archivo con el código
necesario para dotar de funcionalidad al panel. El archivo de interfaz modificado fue panel-
properties-dialog.ui. Todos los archivos se encuentran en el directorio gnome-panel-
2.30.2/gnome-panel del código fuente del panel de GNOME.
119
4.2.1.1 Ingeniería inversa para comprender datos
En el archivo panel-properties-dialog.c se define una estructura de datos llamada
PanelPropertiesDialog, la cual nos permitirá referenciar la ventana de diálogo panel-properties-
dialog.ui modificada con algún editor de interfaces.
Extracto de la definición de la estructura PanelPropertiesDialog en el archivo panel-properties-dialog.c
typedef struct { PanelToplevel *toplevel; GtkWidget *properties_dialog; GtkWidget *general_table; GtkWidget *general_vbox; GtkWidget *orientation_combo; GtkWidget *orientation_label; GtkWidget *size_widgets; GtkWidget *size_spin; int selection_emitted; … } PanelPropertiesDialog;
De igual forma en el archivo panel-typebuiltins.c se define una lista llamada
_panel_animation_speed_values, que contiene constantes de la velocidad de la animación para
ocultar el panel:
Definición de la estructura _panel_animation_speed_values en el archivo panel-properties-dialog.c
static const GEnumValue _panel_animation_speed_values[] = { { PANEL_ANIMATION_SLOW, "PANEL_ANIMATION_SLOW", "slow" }, { PANEL_ANIMATION_MEDIUM, "PANEL_ANIMATION_MEDIUM", "medium" }, { PANEL_ANIMATION_FAST, "PANEL_ANIMATION_FAST", "fast" }, { 0, NULL, NULL } };
4.2.1.2 Ingeniería inversa para comprender el procesamiento y de interfaz de
usuario
Al dar clic con el botón derecho del mouse sobre el panel y seleccionar la opción de preferencias,
se hace referencia a una función llamada panel_properties_dialog_new (), el cual llama a varias
funciones que crean e inicializan cada uno de los widgets de la interfaz de usuario, además de
implementar los listeners que captarán los eventos realizados a cada uno de los elementos.
Existen definidas dos funciones genéricas, una para los checkbuttons, la cual sirve para obtener
información y establecer el estado de las claves de gconf, esta función se llama
SETUP_TOGGLE_BUTTON (wid, n, p) y otra que ayuda a establecer la dirección de las claves de
gconf para cada widget que modifica la clave, esta función se llama TOPLEVEL_GET_SET_FUNCS (k,
p, t, s, a) y está implementada en el archivo panel-profile.c.
120
4.2.2 Ingeniería directa.
Para agregar las funcionalidades faltantes al panel se realizó lo siguiente:
Se utilizaron las constantes definidas en panel-typebuiltins.c para la velocidad de la animación del
panel, además de la función genérica para los checkbuttons, la función genérica para establecer la
dirección de las claves y se agregaron algunas funciones nuevas.
Se modificó la estructura PanelPropertiesDialog añadiéndo los widgets nuevos, quedando como
sigue:
Extracto de la definición de la estructura PanelPropertiesDialog en el archivo panel-properties-dialog.c
typedef struct { PanelToplevel *toplevel; GtkWidget *properties_dialog; GtkWidget *general_table; GtkWidget *general_vbox; GtkWidget *orientation_combo; GtkWidget *orientation_label; GtkWidget *size_widgets; GtkWidget *size_spin;
/*Se agregan las referencias a los spinbuttons para el retardo en aparecer y desaparecer, la cantidad de pixeles visibles, el checkbox para activar las animaciones, el combobox para seleccionar la velocidad de la animación y los radiobuttons para seleccionar el formato de la imagen.*/
GtkWidget *unhide_delay_spinbutton; GtkWidget *hide_delay_spinbutton; GtkWidget *auto_hide_size_spinbutton; GtkWidget *enable_animations_checkbutton; GtkWidget *animation_speed_combobox; GtkWidget *image_fit_radiobutton; GtkWidget *image_fit_hbox; GtkWidget *image_stretch_radiobutton; GtkWidget *image_stretch_hbox; int selection_emitted;
… } PanelPropertiesDialog;
Como se puede observar, son las declaraciones de los widgets creados en la interfaz gráfica, para
que puedan ser usados por panel-properties-dialog.c.
Se modificó el procedimiento panel_properties_dialog_new () agregando lo siguiente:
121
Extracto de la implementación de la función panel_properties_dialog_new () en el archivo panel-properties-dialog.c
static PanelPropertiesDialog * panel_properties_dialog_new (PanelToplevel *toplevel, GtkBuilder *gui) { PanelPropertiesDialog *dialog; dialog = g_new0 (PanelPropertiesDialog, 1); …
//Se llaman a las funciones para crear e inicializar los widgets de la interfaz modificada panel_properties_dialog_setup_animation_speed_combobox (dialog, gui); panel_properties_dialog_setup_unhide_delay_spinbutton (dialog, gui); panel_properties_dialog_setup_hide_delay_spinbutton (dialog, gui); panel_properties_dialog_setup_auto_hide_size_spinbutton (dialog, gui); panel_properties_dialog_setup_enable_animations_checkbutton (dialog, gui); panel_properties_dialog_setup_image_fit_radiobutton (dialog, gui); panel_properties_dialog_setup_image_stretch_radiobutton (dialog, gui); //Función para establecer si los widgets de ocultación se activan o desactivan panel_properties_update_hide_options_toggle_visible ( dialog, GTK_TOGGLE_BUTTON (dialog->autohide_toggle)); //Se define un listener para captar eventos del checkbutton autohide_toggle g_signal_connect_swapped (dialog->autohide_toggle, "toggled", G_CALLBACK panel_properties_update_hide_options_toggle_visible), dialog); //Función para establecer si los widgets de animación se activan o desactivan panel_properties_update_animation_speed_combobox_visible ( dialog, GTK_TOGGLE_BUTTON (dialog->enable_animations_checkbutton)); //Se define un listener para captar eventos del enable_animations_checkbutton g_signal_connect_swapped (dialog->enable_animations_checkbutton, "toggled",
G_CALLBACK (panel_properties_update_animation_speed_combobox_visible), dialog); …
return dialog; }
Como se puede apreciar, la función panel_properties_dialog_new () llama a algunas funciones
nuevas, las cuales se ocupan de inicializar los widgets y activar listeners para captar eventos. A
continuación se expondrán las funciones que se agregaron.
Las modificaciones para establecer el retardo en aparecer del panel, el retardo en ocultarse del
panel y la cantidad de pixeles visibles del panel cuando se encuentra oculto son similares entre sí,
el procedimiento es el mismo para los tres casos con la única diferencia en las variables y nombre
de funciones creadas.
122
A continuación se mencionaran las modificaciones para establecer el retardo en aparecer del
panel.
Implementación de la función panel_properties_dialog_setup_unhide_delay_spinbutton () en el archivo panel-properties-dialog.c
//Función que crea a unhide_delay_spinbutton y lo establece con el valor de la clave de gconf. static void panel_properties_dialog_setup_unhide_delay_spinbutton (PanelPropertiesDialog *dialog, GtkBuilder *gui) { //Se llama a la función que devuelve un widget valido y se le asigna a unhide_delay_spinbutton dialog->unhide_delay_spinbutton=PANEL_GTK_BUILDER_GET (gui, "unhide_delay_spinbutton"); //Si existe algún error en la creación del widget, que referencie a nulo g_return_if_fail (dialog->unhide_delay_spinbutton != NULL); //Se le asigna a unhide_delay_spinbutton el valor de la clave unhide_delay de gconf gracias a la //función TOPLEVEL_GET_SET_FUNCS(k, p, t, s, a) gtk_spin_button_set_value (GTK_SPIN_BUTTON (dialog->unhide_delay_spinbutton), panel_profile_get_toplevel_unhide_delay (dialog->toplevel)); //Se crea un listener que capta cambios en unhide_delay_spinbutton y llama a // panel_properties_dialog_unhide_delay_changed g_signal_connect_swapped (dialog->unhide_delay_spinbutton, "value_changed", G_CALLBACK (panel_properties_dialog_unhide_delay_changed), dialog); //Se verifica que se tenga permiso para modificar la clave de unhide_delay if ( ! panel_profile_is_writable_toplevel_unhide_delay (dialog->toplevel)) { gtk_widget_set_sensitive (dialog->unhide_delay_spinbutton, FALSE); gtk_widget_show (dialog->writability_warn_general); } }
Implementación de la función panel_properties_dialog_unhide_delay_changed () en el archivo panel-properties-dialog.c
//función que es llamada por el listener implementado a unhide_delay_spinbutton static void panel_properties_dialog_unhide_delay_changed (PanelPropertiesDialog *dialog,
GtkSpinButton *spin_button) { //Se le asigna a la clave unhide_delay de gconf el valor establecido en // unhide_delay_spinbutton gracias a la función TOPLEVEL_GET_SET_FUNCS(k, p, t, s, a)
panel_profile_set_toplevel_unhide_delay (dialog->toplevel, gtk_spin_button_get_value_as_int (spin_button));
}
Modificaciones para activar las animaciones y establecer su velocidad.
La función panel_properties_dialog_new () llama a la función
panel_properties_dialog_setup_enable_animations_checkbutton (), que consiste en invocar a
la función genérica SETUP_TOGGLE_BUTTON(wid, n, p), la cual crea el checkbutton, establece el
123
valor de la clave enable_animation de gconf en enable_animations_checkbutton y crea el listener
que revisa al checkbutton a través de su método panel_properties_dialog_setup_##n ().
Para poder seleccionar la velocidad de la animación se creó una estructura llamada
AnimationSpeedComboItem, la cual nos permitirá rellenar el animation_speed_combobox y una
lista de clave valor para rellenar la estructura con las constantes de velocidad establecidos en
panel-typebuiltins.c.
Definición de la estructura AnimationSpeedComboItem en el archivo panel-properties-dialog.c
typedef struct { const char *name; PanelAnimationSpeed animation_speed; } AnimationSpeedComboItem;
Definición de la estructura animation_speed_items en el archivo panel-properties-dialog.c
static AnimationSpeedComboItem animation_speed_items [] = { { NC_("animation_speed", "Lento"), PANEL_ANIMATION_SLOW }, { NC_("animation_speed", "Medio"), PANEL_ANIMATION_MEDIUM }, { NC_("animation_speed", "Rápido"), PANEL_ANIMATION_FAST }, };
La función panel_properties_dialog_new () llama a la función
panel_properties_dialog_setup_animation_speed_combobox (), la cual es la siguiente:
Implementación de la función panel_properties_dialog_setup_animation_speed_combobox () en el archivo panel-properties-dialog.c
//Función que inicializa a animation_speed_combobox y crea el listener que capta cambios en él. static void panel_properties_dialog_setup_animation_speed_combobox (PanelPropertiesDialog *dialog, GtkBuilder *gui) { PanelAnimationSpeed animation_speed; GtkListStore *model; GtkTreeIter iter; GtkCellRenderer *renderer; int i; //Se llama a la función que devuelve un widget valido y se le asigna a //animation_speed_combobox dialog->animation_speed_combobox=PANEL_GTK_BUILDER_GET(gui, "animation_speed_combobox"); g_return_if_fail (dialog->animation_speed_combobox != NULL); //Se llama la función que devuelve el valor de la clave animation_speed de gconf y la asigna a // animation_speed animation_speed = panel_profile_get_toplevel_animation_speed (dialog->toplevel);
124
//Se crea el modelo para llenar el combobox model = gtk_list_store_new (NUMBER_COLUMNS, G_TYPE_STRING, G_TYPE_POINTER); //Se le asigna el modelo al combobox gtk_combo_box_set_model (GTK_COMBO_BOX (dialog->animation_speed_combobox), GTK_TREE_MODEL (model)); for (i = 0; i < G_N_ELEMENTS (animation_speed_items); i++) { gtk_list_store_append (model, &iter); gtk_list_store_set (model, &iter, COLUMN_TEXT, g_dpgettext2 (NULL,"animation_speed", animation_speed_items [i].name), COLUMN_ITEM,
&(animation_speed_items [i]), -1); if (animation_speed == animation_speed_items [i].animation_speed) gtk_combo_box_set_active_iter( GTK_COMBO_BOX (dialog-animation_speed_combobox), &iter); } renderer = gtk_cell_renderer_text_new (); gtk_cell_layout_pack_start (GTK_CELL_LAYOUT (dialog->animation_speed_combobox),
renderer, TRUE); gtk_cell_layout_set_attributes (GTK_CELL_LAYOUT (dialog->animation_speed_combobox), renderer, "text", COLUMN_TEXT, NULL); //Se crea el listener que llama a panel_properties_dialog_animation_speed_changed() cada vez //que se selecciona una nueva opción del animation_speed_combobox g_signal_connect_swapped (dialog->animation_speed_combobox, "changed", G_CALLBACK (panel_properties_dialog_animation_speed_changed), dialog); if (! panel_profile_is_writable_toplevel_animation_speed (dialog->toplevel)) { gtk_widget_set_sensitive (dialog->animation_speed_combobox, FALSE); gtk_widget_show (dialog->writability_warn_general); } }
A continuación se explica lo que realiza la función que el listener controla:
Implementación de la función panel_properties_dialog_animation_speed_changed() en el archivo panel-properties-dialog.c
static void panel_properties_dialog_animation_speed_changed (PanelPropertiesDialog *dialog,
GtkComboBox *combo_box) { GtkTreeIter iter; GtkTreeModel *model; AnimationSpeedComboItem *item; //Se corrobora que el combobox esté activo g_assert (dialog->animation_speed_combobox == GTK_WIDGET (combo_box)); //Se corrobora que una opción del animation_speed_combobox esté seleccionada if (!gtk_combo_box_get_active_iter (combo_box, &iter)) return; //Se crea un modelo para desplegar opciones model = gtk_combo_box_get_model (combo_box);
125
//Se obtiene la opción seleccionada en el animation_speed_combobox gtk_tree_model_get (model, &iter, COLUMN_ITEM, &item, -1); if (item == NULL) return; //Se llama a la función que escribe en gconf los cambios panel_profile_set_toplevel_animation_speed (dialog->toplevel,
item->animation_speed); }
La función que se encarga de escribir los cambios en gconf se encuentra en el archivo panel-
profile.c y es la siguiente:
Implementación de la función panel_profile_set_toplevel_animation_speed () en el archivo panel-profile.c
void panel_profile_set_toplevel_animation_speed (PanelToplevel *toplevel,
PanelAnimationSpeed animation_speed) { GConfClient *client; const char *key; //Se crea un cliente de gconf client = panel_gconf_get_client (); //Se obtiene la ruta de la clave de gconf animation_speed para ese panel key = panel_profile_get_toplevel_key (toplevel, "animation_speed"); //Se escribe el valor de animation_speed en la clave de gconf gconf_client_set_string (client, key, panel_profile_map_animation_speed (animation_speed), NULL); }
Modificaciones para establecer el fondo del panel con una imagen en formato expandido y
mosaico.
Ya que los procesos son similares solo se explicaran las modificaciones para configurar la clave fit
de gconf.
La función panel_properties_dialog_new () llama a la función
panel_properties_dialog_setup_image_fit_radiobutton (), la cual hace referencia a la función
genérica SETUP_TOGGLE_BUTTON () estableciendo el valor de la clave fit de gconf en
image_fit_radiobutton y crea el listener que revisa al botón de radio a través de su método
panel_properties_dialog_setup_##n ().
A continuación se mostrarán las funciones genéricas y sus modificaciones para una mejor
comprensión.
SETUP_TOGGLE_BUTTON () que se encuentra en el archivo panel-properties-dialog.c
126
Implementación de la función SETUP_TOGGLE_BUTTON() en el archivo panel-properties-dialog.c
#define SETUP_TOGGLE_BUTTON(wid, n, p) \ static void \ panel_properties_dialog_##n (PanelPropertiesDialog *dialog, \ GtkToggleButton *n) \ { \ panel_profile_set_toplevel_##p (dialog->toplevel, \ gtk_toggle_button_get_active (n)); \ } \ static void \ panel_properties_dialog_setup_##n (PanelPropertiesDialog *dialog, \ GtkBuilder *gui) \ { \ dialog->n = PANEL_GTK_BUILDER_GET (gui, wid); \ gtk_toggle_button_set_active (GTK_TOGGLE_BUTTON (dialog->n), \ panel_profile_get_toplevel_##p (dialog->toplevel)); \ g_signal_connect_swapped (dialog->n, "toggled", \ G_CALLBACK (panel_properties_dialog_##n), dialog); \ if ( ! panel_profile_is_writable_toplevel_##p (dialog->toplevel)) { \ gtk_widget_set_sensitive (dialog->n, FALSE); \ gtk_widget_show (dialog->writability_warn_general); \ } \ } SETUP_TOGGLE_BUTTON ("expand_toggle", expand_toggle, expand) //Modificación para dotar de funcionalidad al enable_animations_checkbutton SETUP_TOGGLE_BUTTON("enable_animations_checkbutton", enable_animations_checkbutton, enable_animations) SETUP_TOGGLE_BUTTON ("autohide_toggle", autohide_toggle, auto_hide) SETUP_TOGGLE_BUTTON ("hidebuttons_toggle", hidebuttons_toggle, enable_buttons) SETUP_TOGGLE_BUTTON ("arrows_toggle", arrows_toggle, enable_arrows) // Modificación para dotar de funcionalidad al image_fit_radiobutton SETUP_TOGGLE_BUTTON ("image_fit_radiobutton", image_fit_radiobutton, fit) // Modificación para dotar de funcionalidad al image_stretch_radiobutton SETUP_TOGGLE_BUTTON ("image_stretch_radiobutton", image_stretch_radiobutton, stretch)
Función genérica TOPLEVEL_GET_SET_FUNCS () que se encuentra en el archivo panel-profile.c
Implementación de la función OPLEVEL_GET_SET_FUNCS() en el archivo panel-profile.c
#define TOPLEVEL_GET_SET_FUNCS(k, p, t, s, a) \ void \ panel_profile_set_##p##_##s (PanelToplevel *toplevel, a s) \ { \ GConfClient *client; \ const char *key; \ client = panel_gconf_get_client (); \
127
key = panel_profile_get_toplevel_key (toplevel, k); \ gconf_client_set_##t (client, key, s, NULL); \ } \ a \ panel_profile_get_##p##_##s (PanelToplevel *toplevel) \ { \ GConfClient *client; \ const char *key; \ a retval; \ client = panel_gconf_get_client (); \ key = panel_profile_get_toplevel_key (toplevel, k); \ retval = gconf_client_get_##t (client, key, NULL); \ return retval; \ } \ TOPLEVEL_IS_WRITABLE_FUNC(k, p, s) TOPLEVEL_GET_SET_FUNCS ("size", toplevel, int, size, int) //Modificación para poder leer y escribir en la clave unhide_delay TOPLEVEL_GET_SET_FUNCS ("unhide_delay", toplevel, int, unhide_delay, int) // Modificación para poder leer y escribir en la clave hide_delay TOPLEVEL_GET_SET_FUNCS ("hide_delay", toplevel, int, hide_delay, int) // Modificación para poder leer y escribir en la clave hide_size TOPLEVEL_GET_SET_FUNCS ("auto_hide_size", toplevel, int, auto_hide_size, int) TOPLEVEL_GET_SET_FUNCS ("expand", toplevel, bool, expand, gboolean) // Modificación para poder leer y escribir en la clave enable_animations TOPLEVEL_GET_SET_FUNCS ("enable_animations", toplevel, bool, enable_animations,
gboolean) TOPLEVEL_GET_SET_FUNCS ("auto_hide", toplevel, bool, auto_hide, gboolean) TOPLEVEL_GET_SET_FUNCS ("enable_buttons", toplevel, bool, enable_buttons, gboolean) TOPLEVEL_GET_SET_FUNCS ("enable_arrows", toplevel, bool, enable_arrows, gboolean) // Modificación para poder leer y escribir en la clave fit TOPLEVEL_GET_SET_FUNCS ("background/fit", toplevel, bool, fit, gboolean) // Modificación para poder leer y escribir en la clave stretch TOPLEVEL_GET_SET_FUNCS ("background/stretch", toplevel, bool, stretch, gboolean) TOPLEVEL_GET_SET_FUNCS ("background/rotate", background, bool, rotate, gboolean)
Cabe señalar que todas las implementaciones en panel-profile.c deben ir acompañadas de sus
definiciones en panel-profile.h.
Con esto damos por terminadas las modificaciones al panel.
128
4.3 Modificaciones a la Barra de Menú
A continuación se mostrará el desarrollo de las actividades necesarias para realizar las
modificaciones a la barra de menú.
4.3.1 Ingeniería inversa.
El código fuente analizado en esta etapa se encuentra en el archivo panel-menu-bar.c que se
encuentra en el directorio gnome-panel-2.30.2/gnome-panel del código fuente del panel de
GNOME. Este archivo contiene todo lo referente a la programación de la barra de menú. En esta
modificación no reutilizaremos ningún archivo de interfaz ya que originalmente no se cuenta con
uno, se optará por crear una ventana con los widgets suficientes de manera dinámica.
4.3.1.1 Ingeniería inversa para comprender datos
En el archivo panel-menu-bar.c se define una estructura de datos llamada _PanelMenuBarPrivate,
la cual nos permitirá acceder a todos los miembros privados de la barra de menu.
Definición de la estructura _PanelMenuBarPrivate en el archivo panel-menu-bar.c
struct _PanelMenuBarPrivate { AppletInfo *info; PanelWidget *panel; GtkWidget *applications_menu; GtkWidget *applications_item; GtkWidget *places_item; GtkWidget *desktop_item; PanelOrientation orientation; };
Y se utilizará una constante llamada PANEL_ICON_MAIN_MENU que está definida en el archivo
panel-icon-names.h y apunta al archivo del icono del tema que se esté usando en el momento.
Definición de la constante PANEL_ICON_MAIN_MENU en el archivo panel-icon-names.h
#define PANEL_ICON_MAIN_MENU "start-here"
4.3.1.2 Ingeniería inversa para comprender el procesamiento y de interfaz de
usuario
En este caso, al dar clic con el botón derecho del mouse sobre el panel no aparecía ninguna
opción para poder modificar las preferencias de la barra de menú, por lo tanto no existía una
interfaz gráfica, solo aparecía el menú contextual el cual es creado por la función
panel_menu_bar_load (), una vez seleccionada la opción en el menu contextual se invoca a la
función panel_menu_bar_invoke_menu () que se encarga de llamar a las funciones
correspondientes con la opción seleccionada.
129
4.3.2 Ingeniería directa.
Para agregar las funcionalidades faltantes a la barra de menú se realizó lo siguiente en el archivo
panel-menu-bar.c:
A la estructura _PanelMenuBarPrivate se le añadió un miembro más, custom_icon, que representa
la cadena con la ruta del archivo del icono personalizado.
Definición de la estructura _PanelMenuBarPrivate en el archivo panel-menu-bar.c
struct _PanelMenuBarPrivate { AppletInfo *info; PanelWidget *panel; GtkWidget *applications_menu; GtkWidget *applications_item; GtkWidget *places_item; GtkWidget *desktop_item; //Variable para almacenar la cadena del icono personalizado. char *custom_icon; PanelOrientation orientation; };
Se agregaron tres variables globales:
1. char *id, para guardar la identificación de la barra de menú. 2. GtkWidget *use_custom_icon_radiobutton, que será el botón de radio para seleccionar el uso
del icono personalizado. 3. GtkWidget *default_radiobutton, que será el botón de radio para seleccionar el uso del icono
del tema. Se modificó la función panel_menu_bar_load () con el propósito de mostrar la opción de
“Propiedades” en el menú contextual de la barra de menú y de capturar la identificación del
objeto, quedando de la siguiente manera:
Extracto de la implementación de la función panel_menu_bar_load () en el archivo panel-menu-bar.c
static void panel_menu_bar_load (PanelWidget *panel, gboolean locked, int position, gboolean exactpos,
const char *ide) { PanelMenuBar *menubar; //Se captura la identificación de la barra de menú en la variable global id para su futuro uso en //la función use_custom_icon_is_activated() id=ide; g_return_if_fail (panel != NULL); menubar = g_object_new (PANEL_TYPE_MENU_BAR, NULL); menubar->priv->info = panel_applet_register ( GTK_WIDGET (menubar), NULL, NULL, panel, locked, position, exactpos, PANEL_OBJECT_MENU_BAR, ide); //Función que revisa si la clave use_custom_icon de la barra de menú se encuentra activa
130
use_custom_icon_is_activated(menubar); if (!menubar->priv->info) { gtk_widget_destroy (GTK_WIDGET (menubar)); return; } panel_applet_add_callback (menubar->priv->info, "help", GTK_STOCK_HELP, _("_Help"), NULL); //Se agrega en el menú contextual la entrada “Propiedades” y se crea un callback llamado //properties panel_applet_add_callback (menubar->priv->info, "properties", GTK_STOCK_HELP, _("_Propiedades"), NULL); … }
A continuación se mostrará la función creada llamada use_custom_icon_is_activated () encargada
de revisar que la clave use_custom_icon de la barra de menú se encuentre activa en gconf, si es así
asigna el valor de la clave custom_icon en el miembro privado custom_icon de la barra de menú y
por el caso contrario asigna el nombre del icono del tema.
Implementación de la función use_custom_icon_is_activated () en el archivo panel-menu-bar.c
void use_custom_icon_is_activated (PanelMenuBar *menubar) { GConfClient *client; const char *key; //Variable en la que se depositará el valor de la clave use_custom_icon de gconf gboolean use_custom_icon; char *ide; //Si el menubar aun no está inicializado entonces la variable ide toma el valor de la variable //global id if(menubar->priv->custom_icon == NULL){ ide=id; // Si el menubar está inicializado entonces la variable ide toma el valor del miembro privado id //de menubar }else ide=menubar->priv->info->id; //Se crea un cliente de gconf client = panel_gconf_get_client (); //Se establece la llave de la clave de gconf a consultar key =panel_gconf_full_key (PANEL_GCONF_OBJECTS, ide, "use_custom_icon"); //Se asigna el valor de la clave de gconf a la variable booleana de la función use_custom_icon=gconf_client_get_bool(client, key, NULL); /*Si el valor de la clave de gconf es verdadero toma la ruta del archivo del icono personalizado de la clave custom_icon de gconf y pasa esta cadena al miembro privado custom_icon del menubar.*/ if(use_custom_icon!=0){ key =panel_gconf_full_key (PANEL_GCONF_OBJECTS, ide, "custom_icon");
menubar->priv->custom_icon=gconf_client_get_string (client, key, NULL);
131
//Si el valor de la clave use_custom_icon es falso, pasa el valor de la constante //PANEL_ICON_MAIN_MENU al miembro privado custom_icon del menúbar }else menubar->priv->custom_icon=PANEL_ICON_MAIN_MENU; }
Ahora se enlistará la modificación a la función panel_menu_bar_invoke_menu () que se llama cada
vez que se selecciona una opción del menú contextual.
Implementación de la función panel_menu_bar_invoke_menu () en el archivo panel-menu-bar.c
void panel_menu_bar_invoke_menu (PanelMenuBar *menubar, const char *callback_name) { GdkScreen *screen; g_return_if_fail (PANEL_IS_MENU_BAR (menubar)); g_return_if_fail (callback_name != NULL); screen = gtk_widget_get_screen (GTK_WIDGET (menubar)); //Si el callback detectado es properties se deberá invocar a la función //prop_window_menubar(); if (!strcmp (callback_name, "properties")) { prop_window_menubar(menubar); }else if (!strcmp (callback_name, "help")) { panel_show_help (screen, "user-guide", "menubar", NULL); } else if (!strcmp (callback_name, "edit")) { GError *error = NULL; panel_launch_desktop_file_with_fallback ("alacarte.desktop", "alacarte",screen, &error); if (error) { g_error_free (error); panel_launch_desktop_file_with_fallback ("gmenu-simple-editor.desktop", "gmenu-simple-editor", screen, NULL); } } }
Se mostrará la función prop_window_menubar () que es la encargada de crear la interfaz de
propiedades de la barra de menú, de visualizar los widgets y crear los listeners correspondientes.
Implementación de la función prop_window_menubar () en el archivo panel-menu-bar.c
//Función que crea, llena y destruye la ventana de preferencias del menu int prop_window_menubar (PanelMenuBar *menubar) { GtkWidget *pref_window; GtkWidget *pref_frame; GtkWidget *pref_table;
132
GtkWidget *pref_table2; GtkWidget *close_button; GtkWidget *vbox; GSList *pref_grupo; vbox = gtk_vbox_new (FALSE, 0); //Se crea la ventana pref_window = gtk_window_new (GTK_WINDOW_TOPLEVEL); gtk_window_set_title(GTK_WINDOW(pref_window), "Propiedades del Menu"); //Se crea el listener para cerrar la ventana gtk_signal_connect (GTK_OBJECT (pref_window), "destroy", GTK_SIGNAL_FUNC (gtk_main_quit), NULL); //Se crean contenedores para acomodar los widgets y mejorar su presentación gtk_widget_set_usize(pref_window, 350, 300); gtk_container_set_border_width (GTK_CONTAINER (pref_window), 10); pref_frame = gtk_frame_new(NULL); gtk_container_add(GTK_CONTAINER(pref_window), vbox); gtk_box_pack_start (vbox, pref_frame, TRUE, TRUE, 0); gtk_frame_set_label( GTK_FRAME(pref_frame), "Propiedades del Menu" ); gtk_frame_set_label_align( GTK_FRAME(pref_frame), 0.5, 0.0); gtk_frame_set_shadow_type( GTK_FRAME(pref_frame), GTK_SHADOW_ETCHED_OUT); //Se crea el default_radiobutton encargado de seleccionar utilizar icono del tema default_radiobutton = gtk_radio_button_new_with_label (NULL, "Utilizar icono del tema"); pref_grupo=gtk_radio_button_get_group (default_radiobutton); //Se crea el use_custom_icon_radiobutton encargado de seleccionar utilizar icono //personalizado use_custom_icon_radiobutton = gtk_radio_button_new_with_label (pref_grupo, "Utilizar icono personalizado"); pref_table = gtk_table_new (6,6,TRUE); pref_table2 = gtk_table_new (1,6,TRUE); //Se crea el botón de cerrar y su listener para destruir la aplicación. close_button=gtk_button_new_from_stock ("gtk-close"); g_signal_connect_swapped (close_button, "clicked",G_CALLBACK (gtk_widget_destroy), G_OBJECT (pref_window)); gtk_table_attach (GTK_TABLE (pref_table2), close_button, 4, 6, 1, 2, GTK_EXPAND | GTK_FILL, GTK_FILL, 0, 0); //Se crea el botón para seleccionar el archivo con el nuevo icono menu_icon_button = gtk_file_chooser_button_new ("Selecciona un archivo", GTK_FILE_CHOOSER_ACTION_OPEN); pref_label1=gtk_label_new("Seleccionar icono"); //Se asignan a los widgets sus capacidades de escritura gtk_widget_set_sensitive(menu_icon_button, FALSE); gtk_widget_set_sensitive(pref_label1, FALSE); if(0!= g_strcmp0 (PANEL_ICON_MAIN_MENU, menubar->priv->custom_icon)){ gtk_file_chooser_set_filename (menu_icon_button, menubar->priv->custom_icon); gtk_toggle_button_set_active(use_custom_icon_radiobutton,TRUE); gtk_widget_set_sensitive(menu_icon_button, TRUE); gtk_widget_set_sensitive(pref_label1, TRUE); }else
133
{ gtk_toggle_button_set_active(default_radiobutton,TRUE); } //Se crea el listener de use_custom_icon_radiobutton, cualquier cambio debe llamar a la //función menubar_default_radiobutton_toggled(). g_signal_connect_swapped (use_custom_icon_radiobutton, "toggled", G_CALLBACK (menubar_default_radiobutton_toggled), menubar); //Se crea el listener de default_radiobutton, cualquier cambio debe llamar a la función // menubar_default_radiobutton_toggled() g_signal_connect_swapped (default_radiobutton, "toggled", G_CALLBACK (menubar_default_radiobutton_toggled), menubar); //Se crea el listener de menu_icon_button, cualquier cambio debe llamar a la función // change_image () g_signal_connect_swapped (menu_icon_button, "selection-changed", G_CALLBACK (change_image), menubar); //Se acomodan los widgets en los contenedores gtk_table_attach (GTK_TABLE (pref_table), default_radiobutton, 0, 6, 1, 2, GTK_EXPAND | GTK_FILL, GTK_FILL, 0, 0); gtk_table_attach (GTK_TABLE (pref_table), use_custom_icon_radiobutton, 0, 6, 2, 3, GTK_EXPAND | GTK_FILL, GTK_FILL, 0, 0); gtk_table_attach (GTK_TABLE (pref_table), menu_icon_button, 3, 6, 3, 4, GTK_EXPAND | GTK_FILL, GTK_FILL, 0, 0); gtk_table_attach (GTK_TABLE (pref_table), pref_label1, 0, 3, 3, 4, GTK_EXPAND | GTK_FILL, GTK_FILL, 0, 0); gtk_container_add(GTK_CONTAINER(pref_frame), pref_table); gtk_box_pack_start (vbox, pref_table2, FALSE, FALSE, 0); //Se muestran los widgets en la ventana gtk_widget_show(use_custom_icon_radiobutton); gtk_widget_show(default_radiobutton); gtk_widget_show(menu_icon_button); gtk_widget_show(pref_table2); gtk_widget_show(close_button); gtk_widget_show(pref_label1); gtk_widget_show(pref_table); gtk_widget_show(pref_frame); gtk_widget_show (vbox); gtk_widget_show (pref_window); gtk_main (); return(0); }
134
A continuación se mostrara la función menubar_default_radiobutton_toggled (), que es llamada
cuando algún botón de radio es seleccionado, esta función activa y desactiva el icono
personalizado.
Implementación de la función menubar_default_radiobutton_toggled () en el archivo panel-menu-bar.c
void menubar_default_radiobutton_toggled (PanelMenuBar *menubar) { GConfClient *client; GtkWidget *image; const char *key; //Se crea un cliente de gconf client = panel_gconf_get_client (); //Si default_radiobutton está activo se escribe falso en la clave use_custom_icon de gconf, el //miembro privado de menubar custom_icon apunta al icono del tema y los widgets para //establecer el icono personalizado se desactivan if(gtk_toggle_button_get_active(default_radiobutton)==TRUE){ key =panel_gconf_full_key (PANEL_GCONF_OBJECTS, menubar->priv->info->id, "use_custom_icon"); gconf_client_set_bool(client, key, FALSE, NULL); menubar->priv->custom_icon=PANEL_ICON_MAIN_MENU; image = gtk_image_new_from_icon_name (menubar->priv->custom_icon, panel_menu_bar_icon_get_size ());
gtk_image_menu_item_set_image (GTK_IMAGE_MENU_ITEM ( menubar->priv->applications_item), image);
gtk_widget_set_sensitive(menu_icon_button, FALSE); gtk_widget_set_sensitive(pref_label1, FALSE); } //Si use_custom_icon_radiobutton está activo se escribe verdadero en la clave //use_custom_icon de gconf y los widgets para establecer el icono personalizado se activan If (gtk_toggle_button_get_active (use_custom_icon_radiobutton)==TRUE){ key =panel_gconf_full_key (PANEL_GCONF_OBJECTS, menubar->priv->info->id, "use_custom_icon"); gconf_client_set_bool(client, key, TRUE, NULL); gtk_widget_set_sensitive(menu_icon_button, TRUE); gtk_widget_set_sensitive(pref_label1, TRUE); //Si el menu_icon_button no apunta a ningún archivo el miembro privado de menubar //custom_icon toma el valor de la clave custom_icon de gconf y se establece la imagen con //esa ruta if(gtk_file_chooser_get_filename(menu_icon_button)!=NULL){ key =panel_gconf_full_key (PANEL_GCONF_OBJECTS, menubar->priv->info->id, "custom_icon"); menubar->priv->custom_icon=gconf_client_get_string (client, key, NULL); image = gtk_image_new_from_file (menubar->priv->custom_icon); gtk_image_menu_item_set_image (GTK_IMAGE_MENU_ITEM (
menubar->priv->applications_item), image); } } }
135
Se mostrará la función change_image () que es invocada cuando el listener de menu_icon_button
detecta algún cambio en la selección de archivo.
Implementación de la función change_image() en el archivo panel-menu-bar.c
void change_image (PanelMenuBar *menubar) { GConfClient *client; GtkWidget *image; const char *key; //Se obtiene el nombre del archivo seleccionado con menu_icon_button y se asigna al miembro //privado de menubar, custom_icon menubar->priv->custom_icon=gtk_file_chooser_get_filename(menu_icon_button); image = gtk_image_new_from_file (menubar->priv->custom_icon); //Se cambia el icono al menú con la ruta del archivo gtk_image_menu_item_set_image (GTK_IMAGE_MENU_ITEM ( menubar->priv->applications_item), image); //Se escribe la ruta del archivo en la clave custom_icon de gconf client = panel_gconf_get_client (); key =panel_gconf_full_key (PANEL_GCONF_OBJECTS, menubar->priv->info->id, "custom_icon"); gconf_client_set_string(client, key, menubar->priv->custom_icon, NULL); }
Con esto damos por concluidas las modificaciones a la barra de menú.
4.4 Modificaciones al Escritorio
A continuación se mostrará el desarrollo de las actividades necesarias para realizar las
modificaciones al escritorio.
4.4.1 Ingeniería inversa
El código fuente analizado en esta etapa se encuentra en los archivos appearance-main.c,
appearance-desktop.c, appearance-desktop.h, appearance.h y gnome-wp-item.h, y el archivo de
interfaz modificado fue appearance.ui, todos ellos se encuentran en el directorio gnome-control-
center-2.30.1/capplets/appearance del código fuente de gnome-control-center.
4.4.1.1 Ingeniería inversa para comprender datos
El archivo gnome-wp-item.h define el nombre con que se hará referencia a las claves de gconf-
editor de la siguiente manera:
Extracto de definición de claves de gconf en el archivo gnome-wp-item.h
136
#define WP_PATH_KEY "/desktop/gnome/background" #define WP_FILE_KEY WP_PATH_KEY "/picture_filename" #define WP_OPTIONS_KEY WP_PATH_KEY "/picture_options" #define WP_SHADING_KEY WP_PATH_KEY "/color_shading_type" #define WP_PCOLOR_KEY WP_PATH_KEY "/primary_color" #define WP_SCOLOR_KEY WP_PATH_KEY "/secondary_color"
El archivo appearance.h define una estructura de datos denominada AppearanceData, la cual
contiene todas las variables usadas por la ventana Preferencia de la apariencia.
Extracto de la definición de la estructura AppearanceData en el archivo appearance.h
typedef struct { GConfClient *client; GtkBuilder *ui; GnomeDesktopThumbnailFactory *thumb_factory; gulong screen_size_handler; gulong screen_monitors_handler; /* desktop */ GHashTable *wp_hash; gboolean wp_update_gconf; GtkIconView *wp_view; GtkTreeModel *wp_model; GtkWidget *wp_scpicker; GtkWidget *wp_pcpicker; GtkWidget *wp_style_menu; … } AppearanceData;
4.4.1.2 Ingeniería inversa para comprender el procesamiento y de interfaz de
usuario
Al dar clic con el botón derecho del mouse sobre el escritorio y seleccionar la opción de “Cambiar
el fondo del escritorio”, se invoca a una función llamada main () la cual se encarga de inicializar la
ventana “Preferencia de la apariencia” y crea una instancia de la estructura AppearanceData. Esta
función llama a una serie de funciones que tienen como objetivo inicializar los widgets necesarios
para dotar de funcionalidad a la interfaz.
4.4.2 Ingeniería directa
Para agregar las funcionalidades faltantes al escritorio se realizó lo siguiente:
Se añadió en el archivo gnome-wp-item.h la definición de las claves de gconf necesarias para la
modificación quedando como sigue:
Extracto de la definición de claves de gconf en el archivo gnome-wp-item.h
137
#define WP_PATH_KEY "/desktop/gnome/background" #define WP_FILE_KEY WP_PATH_KEY "/picture_filename" #define WP_OPTIONS_KEY WP_PATH_KEY "/picture_options" #define WP_SHADING_KEY WP_PATH_KEY "/color_shading_type" #define WP_PCOLOR_KEY WP_PATH_KEY "/primary_color" #define WP_SCOLOR_KEY WP_PATH_KEY "/secondary_color" //Se define la ruta de las claves de nautilus #define NAUTILUS_PATH_KEY "/apps/nautilus/desktop" //Se define la ruta de la clave computer_icon_visible #define COMPUTER_KEY NAUTILUS_PATH_KEY "/computer_icon_visible" //Se define la ruta de la clave computer_icon_visible #define HOME_KEY NAUTILUS_PATH_KEY "/home_icon_visible" //Se define la ruta de la clave home_icon_visible #define NETWORK_KEY NAUTILUS_PATH_KEY "/network_icon_visible" //Se define la ruta de la clave text_ellipsis_limit #define TEXT_KEY NAUTILUS_PATH_KEY "/text_ellipsis_limit" //Se define la ruta de la clave trash_icon_visible #define TRASH_KEY NAUTILUS_PATH_KEY "/trash_icon_visible" //Se define la ruta de la clave volumes_visible #define VOLUMES_KEY NAUTILUS_PATH_KEY "/volumes_visible"
Se modificó la estructura AppearanceData, agregando los widgets necesarios para dotar las nuevas
funcionalidades, quedando como sigue:
Extracto de la definición de la estructura AppearanceData en el archivo appearance.h
typedef struct { GConfClient *client; GtkBuilder *ui; GnomeDesktopThumbnailFactory *thumb_factory; gulong screen_size_handler; gulong screen_monitors_handler; /* style */ GdkPixbuf *gtk_theme_icon; GdkPixbuf *window_theme_icon; GdkPixbuf *icon_theme_icon; GtkWidget *style_message_area; GtkWidget *style_message_label; GtkWidget *style_install_button; //Se agrega la definición de los widgets necesarios /*Escritorio*/ GtkWidget *computer_icon_visible_checkbutton; GtkWidget *home_icon_visible_checkbutton; GtkWidget *network_icon_visible_checkbutton; GtkWidget *trash_icon_visible_checkbutton; GtkWidget *volumes_visible_checkbutton; GtkWidget *text_ellipsis_limit_spinbutton;
138
… } AppearanceData;
Se agrega a main () la llamada a una función nueva denominada desktop_icon_init (), la cual tiene
como fin inicializar los widgets nuevos y crear los listeners para controlarlos. Esta función recibe
una estructura AppearanceData. La modificación es la siguiente:
Extracto de la implementación de la función main () en el archivo appearance-main.c
int main (int argc, char **argv) { AppearanceData *data; GtkWidget *w; … desktop_init (data, (const gchar **) wallpaper_files); g_strfreev (wallpaper_files); font_init (data); //Se agrega llamada a desktop_icon_init() desktop_icon_init (data); /* prepare the main window */ w = appearance_capplet_get_widget (data, "appearance_window"); capplet_set_icon (w, "preferences-desktop-theme"); gtk_widget_show_all (w); … g_free (data); return 0; }
Para poder realizar la llamada, se modificó el archivo de definiciones appearance-desktop.h de la siguiente manera:
Definición de desktop_icon_init() en el archivo appearance-desktop.h
void desktop_init (AppearanceData *data, const gchar **uris); void desktop_shutdown (AppearanceData *data); //Se define la función desktop_icon_init(). void desktop_icon_init (AppearanceData *data); void computer_icon_visible_checkbutton_toggled (AppearanceData *data);
La implementación de la función desktop_icon_init () es la siguiente:
Implementación de la función desktop_icon_init () en el archivo appearance-desktop.c
void desktop_icon_init (AppearanceData *data) { //Se crean los widgets. data->computer_icon_visible_checkbutton=appearance_capplet_get_widget (data,
139
"computer_icon_visible_checkbutton"); data->home_icon_visible_checkbutton=appearance_capplet_get_widget (data, "home_icon_visible_checkbutton"); data->network_icon_visible_checkbutton=appearance_capplet_get_widget (data, "network_icon_visible_checkbutton"); data->trash_icon_visible_checkbutton=appearance_capplet_get_widget (data, "trash_icon_visible_checkbutton"); data->volumes_visible_checkbutton=appearance_capplet_get_widget (data, "volumes_visible_checkbutton"); data->text_ellipsis_limit_spinbutton=appearance_capplet_get_widget (data, "text_ellipsis_limit_spinbutton"); //Se obtiene el valor de la clave text_ellipsis_limit y se asigna al spinbutton. gtk_spin_button_set_value (data->text_ellipsis_limit_spinbutton, gconf_client_get_int (data->client, TEXT_KEY, NULL)); //Se llama a una función nueva para establecer el valor de los checkbuttons. setup_checkbutton (data, data->computer_icon_visible_checkbutton); setup_checkbutton (data, data->network_icon_visible_checkbutton); setup_checkbutton (data, data->trash_icon_visible_checkbutton); setup_checkbutton (data, data->volumes_visible_checkbutton); setup_checkbutton (data, data->home_icon_visible_checkbutton); /Se crea el listener que controlara los cambios en el spinbutton. g_signal_connect_swapped (data->text_ellipsis_limit_spinbutton, "value-changed", (GCallback) text_ellipsis_limit_spinbutton_changed, data); }
Como se puede apreciar, la función desktop_icon_init () llama a la recién creada función setup_checkbutton (), con la intención de inicializar y crear los listeners de los checkbuttons, esta nueva función recibe como parámetros una estructura AppearanceData y un GtkToggleButton. Además en la implementación del listener del spinbutton text_ellipsis_limit_spinbutton, se nombra a la nueva función text_ellipsis_limit_spinbutton_changed (), la cual recibe como parámetro una estructura AppearanceData y establece los procesos que se deben realizar cuando el spinbutton cambia su valor. Primero se analizará la implementación de la función text_ellipsis_limit_spinbutton_changed () y posteriormente la implementación de setup_checkbutton ().
Implementación de la función text_ellipsis_limit_spinbutton_changed () en el archivo appearance-desktop.c
void text_ellipsis_limit_spinbutton_changed (AppearanceData *data) { //Se obtiene el valor del spinbutton y se ingresa en la clave text_ellipsis_limit gconf_client_set_int (data->client, TEXT_KEY, gtk_spin_button_get_value_as_int GTK_SPIN_BUTTON((data->text_ellipsis_limit_spinbutton)), NULL); }
140
Implementación de la función setup_checkbutton () en el archivo appearance-desktop.c
static void setup_checkbutton (AppearanceData *data, GtkToggleButton *toggle_button) { //Se declara una variable para guardar el nombre de la clave de gconf gchar *key; //Se compara el checkbutton inicializado y dependiendo de cuál sea se asigna la clave. if(data->computer_icon_visible_checkbutton== GTK_WIDGET (toggle_button)){ key=COMPUTER_KEY; }else if(data->home_icon_visible_checkbutton== GTK_WIDGET (toggle_button)){ key=HOME_KEY; }else if(data->network_icon_visible_checkbutton== GTK_WIDGET (toggle_button)){ key=NETWORK_KEY; }else if(data->trash_icon_visible_checkbutton== GTK_WIDGET (toggle_button)){ key=TRASH_KEY; }else if(data->volumes_visible_checkbutton== GTK_WIDGET (toggle_button)){ key=VOLUMES_KEY; } //Se obtiene el valor de la clave de gconf y se establece en el checkbutton correspondiente. gtk_toggle_button_set_active (toggle_button, gconf_client_get_bool (data->client, key, NULL)); //Se crea el listener para detectar cambios en el checkbutton. g_signal_connect_swapped (toggle_button, "toggled", (GCallback) checkbutton_changed, data); }
Al observar la implementación de setup_checkbutton () podemos apreciar que el listener
implementado a cada checkbutton llama a una nueva función denominada
checkbutton_changed(), la cual recibe una estructura AppearanceData y un GtkToggleButton. Esta
función se encarga de establecer el valor de algún checkbutton en alguna clave de gconf dada. Su
implementación es la siguiente:
Implementación de la función checkbutton_changed () en el archivo appearance-desktop.c
static void checkbutton_changed (AppearanceData *data, GtkToggleButton *toggle_button) { //Se declara una variable para almacenar la clave de gconf. gchar *key; //Según el checkbutton la clave cambia. if(data->computer_icon_visible_checkbutton== GTK_WIDGET (toggle_button)){ key=COMPUTER_KEY; }else if(data->home_icon_visible_checkbutton== GTK_WIDGET (toggle_button)){ key=HOME_KEY; }else if(data->network_icon_visible_checkbutton== GTK_WIDGET (toggle_button)){ key=NETWORK_KEY; }else if(data->trash_icon_visible_checkbutton== GTK_WIDGET (toggle_button)){
141
key=TRASH_KEY; }else if(data->volumes_visible_checkbutton== GTK_WIDGET (toggle_button)){ key=VOLUMES_KEY; } // Se obtiene el valor del checkbutton y se establece en la clave correspondiente de gconf. gconf_client_set_bool (data->client, key, gtk_toggle_button_get_active GTK_TOGGLE_BUTTON((toggle_button)), NULL); }
Con esto se da por concluida la modificación al escritorio.
4.5 Modificaciones a la Barra de Título
A continuación se mostrará el desarrollo de las actividades necesarias para realizar las
modificaciones a la barra de título.
4.5.1 Ingeniería inversa
Las modificaciones serán implementadas en la interfaz “Preferencia de la apariencia”, así que los
archivos y estructuras de las modificaciones al escritorio serán reusadas en esta modificación.
El código fuente analizado en esta etapa se encuentra en los archivos appearance-main.c,
appearance-desktop.c, appearance-desktop.h, appearance.h y gnome-wp-item.h, y el archivo de
interfaz modificado fue appearance.ui, todos ellos se encuentran en el directorio gnome-control-
center-2.30.1/capplets/appearance del código fuente de gnome-control-center.
4.5.1.1 Ingeniería inversa para comprender datos
El archivo gnome-wp-item.h define el nombre con que se hará referencia a las claves de gconf-
editor de la siguiente manera:
Extracto de definición de claves de gconf en el archivo gnome-wp-item.h
#define WP_PATH_KEY "/desktop/gnome/background" #define WP_FILE_KEY WP_PATH_KEY "/picture_filename" #define WP_OPTIONS_KEY WP_PATH_KEY "/picture_options" #define WP_SHADING_KEY WP_PATH_KEY "/color_shading_type" #define WP_PCOLOR_KEY WP_PATH_KEY "/primary_color" #define WP_SCOLOR_KEY WP_PATH_KEY "/secondary_color"
142
El archivo appearance.h define una estructura de datos denominada AppearanceData, la cual
contiene todas las variables usadas por la ventana “Preferencia de la apariencia”.
Extracto de la definición de la estructura AppearanceData en el archivo appearance.h
typedef struct { GConfClient *client; GtkBuilder *ui; GnomeDesktopThumbnailFactory *thumb_factory; gulong screen_size_handler; gulong screen_monitors_handler; /* desktop */ GHashTable *wp_hash; gboolean wp_update_gconf; GtkIconView *wp_view; GtkTreeModel *wp_model; GtkWidget *wp_scpicker; GtkWidget *wp_pcpicker; GtkWidget *wp_style_menu; … } AppearanceData;
4.5.1.2 Ingeniería inversa para comprender el procesamiento y de interfaz de
usuario
Al dar clic con el botón derecho del mouse sobre el escritorio y seleccionar la opción de “Cambiar
el fondo del escritorio”, se llama a una función llamada main (), la cual se encarga de inicializar la
ventana “Preferencia de la apariencia” y crea una instancia de la estructura AppearanceData. Esta
función llama a una serie de funciones que tienen como objetivo inicializar los widgets necesarios
para dotar de funcionalidad a la interfaz.
4.5.2 Ingeniería directa
Para agregar las funcionalidades faltantes al escritorio se realizó lo siguiente:
Se añadió en el archivo gnome-wp-item.h la definición de las claves de gconf necesarias para la
modificación quedando como sigue:
Extracto de la definición de claves de gconf en el archivo gnome-wp-item.h
#define WP_PATH_KEY "/desktop/gnome/background" #define WP_FILE_KEY WP_PATH_KEY "/picture_filename" #define WP_OPTIONS_KEY WP_PATH_KEY "/picture_options" #define WP_SHADING_KEY WP_PATH_KEY "/color_shading_type" #define WP_PCOLOR_KEY WP_PATH_KEY "/primary_color" #define WP_SCOLOR_KEY WP_PATH_KEY "/secondary_color" //Se define la ruta de las claves de GWD
143
#define GWD_PATH_KEY "/apps/gwd" //Se define la ruta de la clave use_metacity_theme #define USE_METACITY_THEME_KEY GWD_PATH_KEY "/use_metacity_theme" //Se define la ruta de la clave mouse_wheel_action #define MOUSE_ACTION_KEY GWD_PATH_KEY "/mouse_wheel_action" //Se define la ruta de la clave metacity_theme_shade_opacity #define INACTIVE_SHADE_OPACITY_KEY GWD_PATH_KEY "/metacity_theme_shade_opacity" //Se define la ruta de la clave metacity_theme_opacity #define INACTIVE_OPACITY_KEY GWD_PATH_KEY "/metacity_theme_opacity" //Se define la ruta de la clave metacity_theme_active_shade_opacity #define ACTIVE_SHADE_OPACITY_KEY GWD_PATH_KEY "/metacity_theme_active_shade_opacity" //Se define la ruta de la clave metacity_theme_active_opacity #define ACTIVE_OPACITY_KEY GWD_PATH_KEY "/metacity_theme_active_opacity" //Se define la ruta de la clave action_double_click_titlebar #define DOUBLE_CLIC_KEY "/apps/metacity/general/action_double_click_titlebar" //Se define la ruta de la clave action_middle_click_titlebar #define MIDDLE_CLIC_KEY "/apps/metacity/general/action_middle_click_titlebar" //Se define la ruta de la clave action_right_click_titlebar #define RIGHT_CLIC_KEY "/apps/metacity/general/action_right_click_titlebar" //Se define la ruta de la clave button_layout #define BUTTON_LAYOUT_KEY "/apps/metacity/general/button_layout"
Se modificó la estructura AppearanceData, agregando los widgets necesarios y algunas variables
para dotar las nuevas funcionalidades, quedando como sigue:
Extracto de la definición de la estructura AppearanceData en el archivo appearance.h
typedef struct { GConfClient *client; GtkBuilder *ui; GnomeDesktopThumbnailFactory *thumb_factory; gulong screen_size_handler; gulong screen_monitors_handler; /*escritorio*/ GtkWidget *computer_icon_visible_checkbutton; GtkWidget *home_icon_visible_checkbutton; GtkWidget *network_icon_visible_checkbutton; GtkWidget *trash_icon_visible_checkbutton; GtkWidget *volumes_visible_checkbutton; GtkWidget *text_ellipsis_limit_spinbutton; /*Window*/ //Declaración de widgets. GtkWidget *use_metacity_theme_checkbutton; GtkWidget *metacity_theme_active_shade_opacity_checkbutton; GtkWidget *metacity_theme_active_opacity_spinbutton; GtkWidget *metacity_theme_shade_opacity_checkbutton; GtkWidget *metacity_theme_opacity_spinbutton;
144
GtkWidget *mouse_wheel_action_combobox; GtkWidget *action_double_click_titlebar_combobox; GtkWidget *action_middle_click_titlebar_combobox; GtkWidget *action_right_click_titlebar_combobox; //Declaración de widgets que darán lugar a la modificación a la clave BUTTON_LAYOUT_KEY. GtkWidget *button_layout_combobox1; GtkWidget *button_layout_combobox2; GtkWidget *button_layout_combobox3; GtkWidget *button_layout_combobox4; GtkWidget *button_layout_combobox5; GtkWidget *button_layout_combobox6; GtkWidget *botones_label; //Declaración de un entero que llevará la cuenta del tamaño del vector buttons_array. int contador; //Declaración de un apuntador a un vector que contendrá las cadenas de la clave //BUTTON_LAYOUT_KEY gchar **buttons_array; /*Declaración de longs que guardarán el identificador de los listener de los widgets ocupados de modificar la clave BUTTON_LAYOUT_KEY */ gulong id_signal_combo1; gulong id_signal_combo2; gulong id_signal_combo3; gulong id_signal_combo4; gulong id_signal_combo5; gulong id_signal_combo6; } AppearanceData;
Se crean cinco estructuras: MouseWheelAction, mouse_wheel_action_map [], WheelActionComboItem, action_items [] y un enum que servirán para llenar la lista desplegable del combobox encargado de establecer la acción de la rueda del mouse en la barra de título.
Definición de estructuras para establecer la acción de la rueda del mouse en la barra de título en el archivo appearance-desktop.c
//Se definen las claves con un valor. typedef enum { GWD_MWA_SHADE = 0, GWD_MWA_NONE = 1 } MouseWheelAction; //Se define el nombre de unas columnas que posteriormente contendrán datos. enum { COLUMN_TEXT, COLUMN_ITEM, NUMBER_COLUMNS }; //Se define un mapeo entre string y claves. static GConfEnumStringPair mouse_wheel_action_map [] = { { GWD_MWA_SHADE, "shade" }, { GWD_MWA_NONE, "none" },
145
{ 0, NULL } }; //Se define una estructura con dos miembros. typedef struct { const char *name; MouseWheelAction action; } WheelActionComboItem; //Se define la lista a desplegar ligado con una clave. static WheelActionComboItem action_items [] = { { NC_("action", "Enrollar"), GWD_MWA_SHADE }, { NC_("action", "Ninguno"), GWD_MWA_NONE }, };
Se crean cuatro estructuras para la configuración de la acción de los botones del mouse en la barra de título usadas por action_double_click_titlebar_combobox, action_middle_click_titlebar_combobox y action_right_click_titlebar_combobox. Las estructuras se muestran a continuación:
Definición de estructuras para establecer la acción de los botones del mouse en la barra de título en el archivo appearance-desktop.c
//Se definen las claves con un valor. typedef enum { METACITY_CLIC_TOGGLE_SHADE = 0, METACITY_CLIC_TOGGLE_MAXIMIZE = 1, METACITY_CLIC_TOGGLE_MAXIMIZE_HORIZONTALLY= 2, METACITY_CLIC_TOGGLE_MAXIMIZE_VERTICALLY = 3, METACITY_CLIC_MINIMIZE = 4, METACITY_CLIC_MENU = 5, METACITY_CLIC_LOWER = 6, METACITY_CLIC_NONE = 7 } ClicAction; //Se define un mapeo entre string y claves. static GConfEnumStringPair clic_action_map [] = { { METACITY_CLIC_TOGGLE_SHADE, "toggle_shade" }, { METACITY_CLIC_TOGGLE_MAXIMIZE, "toggle_maximize" }, { METACITY_CLIC_TOGGLE_MAXIMIZE_HORIZONTALLY, "toggle_maximize_horizontally" }, { METACITY_CLIC_TOGGLE_MAXIMIZE_VERTICALLY, "toggle_maximize_vertically" }, { METACITY_CLIC_MINIMIZE, "minimize" }, { METACITY_CLIC_MENU, "menu" }, { METACITY_CLIC_LOWER, "lower" }, { METACITY_CLIC_NONE, "none" }, { 0, NULL } }; //Se define una estructura con dos miembros. typedef struct { const char *name;
146
ClicAction clic_action; } ClicActionComboItem; //Se define la lista a desplegar ligado con una clave. static ClicActionComboItem clic_action_items [] = { { NC_("clic_action", "Enrollar"), METACITY_CLIC_TOGGLE_SHADE }, { NC_("clic_action", "Maximizar"), METACITY_CLIC_TOGGLE_MAXIMIZE }, { NC_("clic_action", "Maximizar Horizontalmente"), METACITY_CLIC_TOGGLE_MAXIMIZE_HORIZONTALLY }, { NC_("clic_action", "Maximizar Verticalmente"), METACITY_CLIC_TOGGLE_MAXIMIZE_VERTICALLY }, { NC_("clic_action", "Minimizar"), METACITY_CLIC_MINIMIZE }, { NC_("clic_action", "Menu"), METACITY_CLIC_MENU }, { NC_("clic_action", "Bajar"), METACITY_CLIC_LOWER }, { NC_("clic_action", "Ninguno"), METACITY_CLIC_NONE }, };
Se crean cuatro estructuras usadas por los seis combobox dedicados a establecer la organización de los botones en la barra de título.
Definición de estructuras para establecer la organización de los botones en la barra de título. en el archivo appearance-desktop.c
//Se definen las claves con un valor. typedef enum { BUTTON_NAME_MENU = 0, BUTTON_NAME_COLON = 1, BUTTON_NAME_MINIMIZE= 2, BUTTON_NAME_MAXIMIZE = 3, BUTTON_NAME_SPACER = 4, BUTTON_NAME_CLOSE = 5, BUTTON_NAME_NONE = 6 } ButtonName; //Se define un mapeo entre string y claves. static GConfEnumStringPair button_name_map [] = { { BUTTON_NAME_MENU, "menu" }, { BUTTON_NAME_COLON, ":" }, { BUTTON_NAME_MINIMIZE, "minimize" }, { BUTTON_NAME_MAXIMIZE, "maximize" }, { BUTTON_NAME_SPACER, "spacer" }, { BUTTON_NAME_CLOSE, "close" }, { BUTTON_NAME_NONE, "" }, { 0, NULL } }; //Se define una estructura con dos miembros. typedef struct { const char *name; ButtonName button_name; } ButtonNameComboItem; //Se define la lista a desplegar ligado con una clave.
147
static ButtonNameComboItem button_name_items [] = { { NC_("button_name", "Menú"), BUTTON_NAME_MENU }, { NC_("button_name", "Título"), BUTTON_NAME_COLON }, { NC_("button_name", "Minimizar"), BUTTON_NAME_MINIMIZE }, { NC_("button_name", "Maximizar"), BUTTON_NAME_MAXIMIZE }, { NC_("button_name", "Espaciador"), BUTTON_NAME_SPACER }, { NC_("button_name", "Cerrar"), BUTTON_NAME_CLOSE }, { NC_("button_name", ""), BUTTON_NAME_NONE }, };
Se agrega a main () la llamada a una función nueva denominada window_init (), la cual tiene como fin inicializar los widgets nuevos y crear los listeners para controlarlos. Esta función recibe una estructura AppearanceData. La modificación es la siguiente:
Extracto de la implementación de la función main () en el archivo appearance-main.c
int main (int argc, char **argv) { AppearanceData *data; GtkWidget *w; … desktop_init (data, (const gchar **) wallpaper_files); g_strfreev (wallpaper_files); font_init (data); desktop_icon_init (data); //Llamada a window_init () window_init (data); /* prepare the main window */ w = appearance_capplet_get_widget (data, "appearance_window"); capplet_set_icon (w, "preferences-desktop-theme"); gtk_widget_show_all (w); … g_free (data); return 0; }
Para poder realizar la llamada, se modificó el archivo de definiciones appearance-desktop.h de la siguiente manera:
Definición de window_init () en el archivo appearance-desktop.h
void desktop_init (AppearanceData *data, const gchar **uris); void desktop_shutdown (AppearanceData *data); void desktop_icon_init (AppearanceData *data); //Se define la función window_init (). void window_init (AppearanceData *data); void computer_icon_visible_checkbutton_toggled (AppearanceData *data);
148
La implementación de la función window_init () es la siguiente:
Implementación de la función window_init () en el archivo appearance-desktop.c
void window_init (AppearanceData *data) { //Se crean los widgets. data->use_metacity_theme_checkbutton= appearance_capplet_get_widget (data, "use_metacity_theme_checkbutton"); data->metacity_theme_active_shade_opacity_checkbutton= appearance_capplet_get_widget (data, "metacity_theme_active_shade_opacity_checkbutton"); data->metacity_theme_active_opacity_spinbutton= appearance_capplet_get_widget (data, "metacity_theme_active_opacity_spinbutton"); data->metacity_theme_shade_opacity_checkbutton= appearance_capplet_get_widget (data, "metacity_theme_shade_opacity_checkbutton"); data->metacity_theme_opacity_spinbutton= appearance_capplet_get_widget (data, "metacity_theme_opacity_spinbutton"); data->mouse_wheel_action_combobox= appearance_capplet_get_widget (data, "mouse_wheel_action_combobox"); data->action_double_click_titlebar_combobox= appearance_capplet_get_widget (data, "action_double_click_titlebar_combobox"); data->action_middle_click_titlebar_combobox= appearance_capplet_get_widget (data, "action_middle_click_titlebar_combobox"); data->action_right_click_titlebar_combobox= appearance_capplet_get_widget (data, "action_right_click_titlebar_combobox"); data->mouse_wheel_action_combobox = appearance_capplet_get_widget (data, "mouse_wheel_action_combobox"); data->action_double_click_titlebar_combobox = appearance_capplet_get_widget (data, "action_double_click_titlebar_combobox"); data->action_middle_click_titlebar_combobox = appearance_capplet_get_widget (data, "action_middle_click_titlebar_combobox"); data->action_right_click_titlebar_combobox = appearance_capplet_get_widget (data, "action_right_click_titlebar_combobox"); //Se crea el conjunto de combobox para establecer la clave BUTTON_LAYOUT_KEY data->button_layout_combobox1 = appearance_capplet_get_widget (data, "button_layout_combobox1"); data->button_layout_combobox2 = appearance_capplet_get_widget (data, "button_layout_combobox2"); data->button_layout_combobox3 = appearance_capplet_get_widget (data, "button_layout_combobox3"); data->button_layout_combobox4 = appearance_capplet_get_widget (data, "button_layout_combobox4"); data->button_layout_combobox5 = appearance_capplet_get_widget (data, "button_layout_combobox5"); data->button_layout_combobox6 = appearance_capplet_get_widget (data, "button_layout_combobox6"); //Se llama a la función setup_checkbutton () para configurar los checkbuttons
149
setup_checkbutton (data, data->use_metacity_theme_checkbutton); setup_checkbutton (data, data->metacity_theme_active_shade_opacity_checkbutton); setup_checkbutton (data, data->metacity_theme_shade_opacity_checkbutton); //Se obtiene el valor de la clave dada de gconf y se establece en los spinbuttons dados. gtk_spin_button_set_value (data->metacity_theme_active_opacity_spinbutton, gconf_client_get_float (data->client, ACTIVE_OPACITY_KEY, NULL)); gtk_spin_button_set_value (data->metacity_theme_opacity_spinbutton, gconf_client_get_float (data->client, INACTIVE_OPACITY_KEY, NULL)); //Se crean los listener para cada spinbutton. g_signal_connect_swapped (data->metacity_theme_active_opacity_spinbutton, "value-changed", (GCallback) metacity_theme_active_opacity_spinbutton_changed, data); g_signal_connect_swapped (data->metacity_theme_opacity_spinbutton, "value-changed", (GCallback) metacity_theme_opacity_spinbutton_changed, data); //Se llama a una función para configurar el mouse_wheel_action_combobox. setup_mouse_wheel_action_combobox(data); //Se llama la función setup_combobox () para configurar las acciones del mouse en la barra setup_combobox(data, data->action_double_click_titlebar_combobox); setup_combobox(data, data->action_middle_click_titlebar_combobox); setup_combobox(data, data->action_right_click_titlebar_combobox); //Se llama a la función load_gconf_buttons() encargada de leer la clave BUTTON_LAYOUT_KEY load_gconf_buttons(data); //Se configuran los combobox encargados de establecer la clave BUTTON_LAYOUT_KEY setup_button_combobox(data, data->button_layout_combobox1,0); setup_button_combobox(data, data->button_layout_combobox2,1); setup_button_combobox(data, data->button_layout_combobox3,2); setup_button_combobox(data, data->button_layout_combobox4,3); setup_button_combobox(data, data->button_layout_combobox5,4); setup_button_combobox(data, data->button_layout_combobox6,5); /*Se crean los listeners de cada combobox destinado a establecer la clave BUTTON_LAYOUT_KEY y sus identificadores son guardados en variables de tipo long, esto hará posible su futura interrupción.*/ data->id_signal_combo1=g_signal_connect_swapped (data->button_layout_combobox1, "changed", G_CALLBACK (layout_combobox_changed), data); data->id_signal_combo2=g_signal_connect_swapped (data->button_layout_combobox2, "changed", G_CALLBACK (layout_combobox_changed), data); data->id_signal_combo3=g_signal_connect_swapped (data->button_layout_combobox3, "changed", G_CALLBACK (layout_combobox_changed), data); data->id_signal_combo4=g_signal_connect_swapped (data->button_layout_combobox4, "changed", G_CALLBACK (layout_combobox_changed), data); data->id_signal_combo5=g_signal_connect_swapped (data->button_layout_combobox5, "changed", G_CALLBACK (layout_combobox_changed), data); data->id_signal_combo6=g_signal_connect_swapped (data->button_layout_combobox6, "changed", G_CALLBACK (layout_combobox_changed), data); }
Como se puede apreciar, la función window_init () llama a la función setup_checkbutton () que fue creada en la modificación del escritorio con la intención de inicializar y crear los listeners de los
150
checkbuttons, esta nueva función sufrió unas adiciones para poder trabajar, las cuales serán exhibidas mas tarde. Además en la implementación del listener de los spinbuttons metacity_theme_active_opacity_spinbutton y metacity_theme_opacity_spinbutton, se nombra a las nuevas funciones metacity_theme_active_opacity_spinbutton_changed () y metacity_theme_opacity_spinbutton_changed () respectivamente, las cuales reciben como parámetro una estructura AppearanceData y establecen los procesos que se deben realizar cuando los spinbuttons cambian su valor. Después aparece una nueva función llamada setup_mouse_wheel_action_combobox (), la cual recibe como parámetro una estructura AppearanceData, y se encarga de configurar a mouse_wheel_action_combobox. Más adelante se hace referencia a la función setup_combobox (), esta función recibe una estructura AppearanceData y un GtkComboBox como parámetros y se encarga de configurar a los combobox dedicados a establecer las acciones de los botones del ratón en la barra de título. Más tarde tenemos a la función load_gconf_buttons () que de igual forma recibe una estructura AppearanceData y su funcionalidad es leer el valor de la clave BUTTON_LAYOUT_KEY separarla en tokens y crear el arreglo buttons_array con ellos, este arreglo servirá para inicializar y manejar el contenido de los combobox destinados a establecer la clave BUTTON_LAYOUT_KEY. Siguiendo, se llama a una nueva función denominada setup_button_combobox (), la cual recibe una estructura AppearanceData, un GtkComboBox y un entero como parámetros, el objetivo de esta función es inicializar y configurar cada uno de los combobox destinados a establecer la disposición de los botones en la barra de título. La última función nueva llamada por window_init () es aquella referenciada por los listeners que controlan la disposición de los botones de la barra, su nombre es layout_combobox_changed (), recibe una estructura AppearanceData y un GtkComboBox como argumento. A continuación se presentará la implementación de cada función por orden de aparición, mostrando la implementación de nuevas funciones según sea el caso. La modificación a setup_checkbutton () es la siguiente:
Implementación de la función setup_checkbutton () en el archivo appearance-desktop.c
static void setup_checkbutton (AppearanceData *data, GtkToggleButton *toggle_button) { //Se declara una variable para guardar el nombre de la clave de gconf gchar *key; //Se compara el checkbutton inicializado y dependiendo de cuál sea se asigna la clave. if(data->computer_icon_visible_checkbutton== GTK_WIDGET (toggle_button)){ key=COMPUTER_KEY; }else if(data->home_icon_visible_checkbutton== GTK_WIDGET (toggle_button)){ key=HOME_KEY; }else if(data->network_icon_visible_checkbutton== GTK_WIDGET (toggle_button)){ key=NETWORK_KEY; }else if(data->trash_icon_visible_checkbutton== GTK_WIDGET (toggle_button)){ key=TRASH_KEY; }else if(data->volumes_visible_checkbutton== GTK_WIDGET (toggle_button)){ key=VOLUMES_KEY; //Se añade la comparación para los nuevos checkbutton. } else if(data->use_metacity_theme_checkbutton== GTK_WIDGET (toggle_button)){
151
key=USE_METACITY_THEME_KEY; }else if(data->metacity_theme_active_shade_opacity_checkbutton== GTK_WIDGET (toggle_button)){ key=ACTIVE_SHADE_OPACITY_KEY; }else if(data->metacity_theme_shade_opacity_checkbutton== GTK_WIDGET (toggle_button)){ key=INACTIVE_SHADE_OPACITY_KEY; } //Se obtiene el valor de la clave de gconf y se establece en el checkbutton correspondiente. gtk_toggle_button_set_active (toggle_button, gconf_client_get_bool (data->client, key, NULL)); //Se crea el listener para detectar cambios en el checkbutton. g_signal_connect_swapped (toggle_button, "toggled", (GCallback) checkbutton_changed, data); }
Al haber agregado nuevos checkbuttons a la función, es necesario modificar checkbutton_changed(), que es la función a la que el listener de cada checkbutton hace referencia.
Implementación de la función checkbutton_changed() en el archivo appearance-desktop.c
static void checkbutton_changed (AppearanceData *data, GtkToggleButton *toggle_button) { //Se declara una variable para almacenar la clave de gconf. gchar *key; //Según el checkbutton la clave cambia. if(data->computer_icon_visible_checkbutton== GTK_WIDGET (toggle_button)){ key=COMPUTER_KEY; }else if(data->home_icon_visible_checkbutton== GTK_WIDGET (toggle_button)){ key=HOME_KEY; }else if(data->network_icon_visible_checkbutton== GTK_WIDGET (toggle_button)){ key=NETWORK_KEY; }else if(data->trash_icon_visible_checkbutton== GTK_WIDGET (toggle_button)){ key=TRASH_KEY; }else if(data->volumes_visible_checkbutton== GTK_WIDGET (toggle_button)){ key=VOLUMES_KEY; //Se añade la comparación para los nuevos checkbutton. } else if(data->use_metacity_theme_checkbutton== GTK_WIDGET (toggle_button)){ key=USE_METACITY_THEME_KEY; }else if(data->metacity_theme_active_shade_opacity_checkbutton== GTK_WIDGET (toggle_button)){ key=ACTIVE_SHADE_OPACITY_KEY; }else if(data->metacity_theme_shade_opacity_checkbutton== GTK_WIDGET (toggle_button)){ key=INACTIVE_SHADE_OPACITY_KEY; } // Se obtiene el valor del checkbutton y se establece en la clave correspondiente de gconf. gconf_client_set_bool (data->client, key, gtk_toggle_button_get_active GTK_TOGGLE_BUTTON((toggle_button)), NULL); }
152
Ahora se mostrará la implementación de las funciones
metacity_theme_active_opacity_spinbutton_changed() y
metacity_theme_opacity_spinbutton_changed().
Implementación de la función metacity_theme_active_opacity_spinbutton_changed () en el archivo appearance-desktop.c
void metacity_theme_active_opacity_spinbutton_changed (AppearanceData *data) { /*Se obtiene el valor de metacity_theme_active_opacity_spinbutton y se establece en la clave ACTIVE_OPACITY_KEY de gconf.*/ gconf_client_set_float (data->client, ACTIVE_OPACITY_KEY, gtk_spin_button_get_value_as_float GTK_SPIN_BUTTON(( data->metacity_theme_active_opacity_spinbutton)), NULL); }
Implementación de la función metacity_theme_opacity_spinbutton_changed () en el archivo appearance-desktop.c
void metacity_theme_opacity_spinbutton_changed (AppearanceData *data) { /*Se obtiene el valor de metacity_theme_opacity_spinbutton y se establece en la clave INACTIVE_OPACITY_KEY de gconf.*/ gconf_client_set_float (data->client, INACTIVE_OPACITY_KEY, gtk_spin_button_get_value_as_float GTK_SPIN_BUTTON(( data->metacity_theme_opacity_spinbutton)), NULL); }
A continuación se detallará la implementación de la función
setup_mouse_wheel_action_combobox ().
Implementación de la función setup_mouse_wheel_action_combobox () en el archivo appearance-desktop.c
static void setup_mouse_wheel_action_combobox (AppearanceData *data) { //Se declara un objeto MouseWheelAction MouseWheelAction action; GtkListStore *model; GtkTreeIter iter; int i; //Se obtiene la acción. action = get_mouse_wheel_action (data); //Se crea un model y se añade al combobox.
153
model = gtk_list_store_new (NUMBER_COLUMNS, G_TYPE_STRING, G_TYPE_POINTER); gtk_combo_box_set_model (GTK_COMBO_BOX (data->mouse_wheel_action_combobox), GTK_TREE_MODEL (model)); //Se añaden los elementos de la estructura action_items a la lista desplegable del combobox. for (i = 0; i < G_N_ELEMENTS (action_items); i++) { gtk_list_store_append (model, &iter); gtk_list_store_set (model, &iter, COLUMN_TEXT, g_dpgettext2 (NULL, "action", action_items [i].name), COLUMN_ITEM, &(action_items [i]), -1); // Establece el elemento activo en el combobox. if (action == action_items [i].action) gtk_combo_box_set_active_iter (GTK_COMBO_BOX (data->mouse_wheel_action_combobox), &iter); } //Se implemente el listener del combobox. g_signal_connect_swapped (data->mouse_wheel_action_combobox, "changed", G_CALLBACK (mouse_wheel_action_combobox_changed), data); }
Al observar la implementación setup_mouse_wheel_action_combobox (), podemos ver que
declara y usa un objeto MouseWheelAction cuya definición se encuentra al inicio de la sección, se
hace uso de la función get_mouse_wheel_action (), la cual recibe una estructura AppearanceData
y devuelve un objeto MouseWheelAction y por último el listener asignado al combobox llama a la
función mouse_wheel_action_combobox_changed (), la cual recibe una estructura
AppearanceData.
A continuación veremos la implementación de get_mouse_wheel_action () y de una función de la
cual hace uso, llamada map_mouse_wheel_action_string ().
Implementación de la función get_mouse_wheel_action () en el archivo appearance-desktop.c
//Leer empezando por la última función. gboolean map_mouse_wheel_action_string (const char *str, MouseWheelAction *action) { int mapped; g_return_val_if_fail (action != NULL, FALSE); if (!str) return FALSE; //Si la cadena es encontrada se mapea y regresa TRUE. if (!gconf_string_to_enum (mouse_wheel_action_map, str, &mapped)) return FALSE; *action = mapped;
154
return TRUE; } MouseWheelAction get_mouse_wheel_action (AppearanceData *data) { MouseWheelAction action; char *str; //obtiene el valor de la clave MOUSE_ACTION_KEY y la asigna a un string str = gconf_client_get_string (data->client, MOUSE_ACTION_KEY, NULL); //Mapea el valor del string obtenido if (map_mouse_wheel_action_string (str, &action)){ g_free (str); return action; } }
A continuación se verá la función invocada por el listener de mouse_wheel_action_combobox:
mouse_wheel_action_combobox_changed (), y las funciones que esta llama:
set_mouse_wheel_action () y map_mouse_wheel_action ().
Implementación de la función mouse_wheel_action_combobox_changed () en el archivo appearance-desktop.c
//Leer empezando por la última función. const char * map_mouse_wheel_action (MouseWheelAction action) { //Regresa el nombre del objeto MouseWheelAction. return gconf_enum_to_string (mouse_wheel_action_map, action); } void set_mouse_wheel_action (AppearanceData *data, MouseWheelAction action) { //Mapea el objeto MouseWheelAction y escribe su nombre en gconf. gconf_client_set_string (data->client, MOUSE_ACTION_KEY, map_mouse_wheel_action (action), NULL); } static void mouse_wheel_action_combobox_changed (AppearanceData *data, GtkComboBox *combo_box) { GtkTreeIter iter; GtkTreeModel *model; WheelActionComboItem *item;
155
g_assert (data->mouse_wheel_action_combobox == GTK_WIDGET (combo_box)); if (!gtk_combo_box_get_active_iter (combo_box, &iter)) return; model = gtk_combo_box_get_model (combo_box); //Se obtiene el ítem activo del combobox. gtk_tree_model_get (model, &iter, COLUMN_ITEM, &item, -1); if (item == NULL) return; //Se llama a la función que escribe en gconf. set_mouse_wheel_action (data, item->action); }
Una vez explicado el proceso para configurar y manejar el mouse_wheel_action_combobox, será
más fácil entender la configuración y administración de los combobox
action_double_click_titlebar_combobox, action_middle_click_titlebar_combobox y
action_right_click_titlebar_combobox, destinados a establecer la acción de los botones del ratón
en la barra de título, ya que el proceso es idéntico, lo único que cambia es el nombre de las
funciones y de las estructuras empleadas.
A continuación se muestra la implementación de la función setup_combobox ().
Implementación de la función setup_combobox () en el archivo appearance-desktop.c
static void setup_combobox (AppearanceData *data, GtkComboBox *combo_box) { ClicAction clic_action; GtkListStore *model; GtkTreeIter iter; int i; gchar *key; //Se comprueba cual combobox es el que se activa y se asigna una clave. if(data->action_right_click_titlebar_combobox== GTK_WIDGET (combo_box)){ key=RIGHT_CLIC_KEY; }else if(data->action_middle_click_titlebar_combobox== GTK_WIDGET (combo_box)){ key=MIDDLE_CLIC_KEY; }else if(data->action_double_click_titlebar_combobox== GTK_WIDGET (combo_box)){ key=DOUBLE_CLIC_KEY; }else if(data->button_layout_combobox1== GTK_WIDGET (combo_box)){ key=DOUBLE_CLIC_KEY; } //Se obtiene un action clic_action = get_clic_action (data, key); model = gtk_list_store_new (NUMBER_COLUMNS,G_TYPE_STRING, G_TYPE_POINTER); gtk_combo_box_set_model (GTK_COMBO_BOX (combo_box), GTK_TREE_MODEL (model)); /*Se añaden los elementos de la estructura clic_action_items a la lista desplegable del
156
combobox.*/ for (i = 0; i < G_N_ELEMENTS (clic_action_items); i++) { gtk_list_store_append (model, &iter); gtk_list_store_set (model, &iter, COLUMN_TEXT, g_dpgettext2 (NULL, "clic_action", clic_action_items [i].name), COLUMN_ITEM, &(clic_action_items [i]), -1); // Establece el elemento activo en el combobox. if (clic_action == clic_action_items [i].clic_action) gtk_combo_box_set_active_iter (GTK_COMBO_BOX (combo_box), &iter); } //Se implementa el listener para el combobox. g_signal_connect_swapped (combo_box, "changed", G_CALLBACK (action_combobox_changed), data); }
A continuación se enlistará la implementación de la función get_clic_action (), la cual recibe como parámetros dos objetos, el primero una estructura AppearanceData y el segundo una String y devuelve un objeto ClicAction. Además se incluirá a la función map_clic_action_string (), ya que la primera hace uso de esta.
Implementación de la función get_clic_action () en el archivo appearance-desktop.c
//Leer empezando por la última función. map_clic_action_string (const char *str, ClicAction *clic_action) { int mapped; g_return_val_if_fail (clic_action != NULL, FALSE); if (!str) return FALSE; //Mapea el valor del string obtenido. if (!gconf_string_to_enum (clic_action_map, str, &mapped)) return FALSE; *clic_action = mapped; return TRUE; } ClicAction get_clic_action (AppearanceData *data, gchar *key) { ClicAction clic_action; char *str; //Obtiene el valor de la variable key y la asigna a un string. str = gconf_client_get_string (data->client, key, NULL); //Si la cadena es encontrada se mapea y regresa TRUE. if (map_clic_action_string (str, &clic_action)){ g_free (str); return clic_action; } }
157
A continuación se verá la función invocada por el listener del combobox configurado por
setup_combobox (): action_combobox_changed () y las funciones que esta utiliza:
set_mouse_wheel_action () y map_mouse_wheel_action ().
Implementación de la función action_combobox_changed () en el archivo appearance-desktop.c
//Leer empezando por la última función. const char * map_clic_action (ClicAction clic_action) { //Regresa el nombre del objeto clic_action. return gconf_enum_to_string (clic_action_map, clic_action); } void set_clic_action (AppearanceData *data, ClicAction clic_action, gchar *key) { //Se obtiene el nombre del objeto clic_action y ese valor se escribe en gconf. gconf_client_set_string (data->client, key, map_clic_action (clic_action), NULL); } static void action_combobox_changed (AppearanceData *data, GtkComboBox *combo_box) { GtkTreeIter iter; GtkTreeModel *model; ClicActionComboItem *item; gchar *key; //Se revisa el combobox afectado y se establece una clave. if(data->action_right_click_titlebar_combobox== GTK_WIDGET (combo_box)){ key=RIGHT_CLIC_KEY; }else if(data->action_middle_click_titlebar_combobox== GTK_WIDGET (combo_box)){ key=MIDDLE_CLIC_KEY; }else if(data->action_double_click_titlebar_combobox== GTK_WIDGET (combo_box)){ key=DOUBLE_CLIC_KEY; } if(!gtk_combo_box_get_active_iter (combo_box, &iter)) return; model = gtk_combo_box_get_model (combo_box); //Se obtiene el ítem activo en el combobox. gtk_tree_model_get (model, &iter, COLUMN_ITEM, &item, -1); if (item == NULL) return; //Se establece el valor en gconf. set_clic_action (data, item->clic_action, key); }
158
Ya que se explicó el código para manipular los combobox encargados de establecer el
comportamiento de la barra de título de acuerdo con las acciones de la rueda y botones del ratón,
se expondrá la implementación de las funciones que hacen posible el establecer la distribución de
botones en la barra de titulo. Para ello es necesario comenzar con la función
load_gconf_buttons(), la cual recibe como parámetro un objeto AppearanceData y se encarga de
leer la clave BUTTON_LAYOUT_KEY de gconf, crea un arreglo de cadenas con el nombre de los
botones y lo asigna a buttons_array y asigna el valor del tamaño del arreglo a la variable contador.
Implementación de la función load_gconf_buttons () en el archivo appearance-desktop.c
void load_gconf_buttons(AppearanceData *data) { char *str; //Se obtiene el valor de la clave. str = gconf_client_get_string (data->client, BUTTON_LAYOUT_KEY, NULL); //La clave se divide en tokens separados por comma “,” y se guarda en buttons_array. data->buttons_array=g_strsplit (str,",",-1); data->contador=0; //Se itera hasta que se obtiene el valor del tamaño del arreglo y se guarda en data->contador. while (data->buttons_array[data->contador] != NULL) { data->contador=data->contador+1; } }
Después de tener el valor de la clave es necesario inicializar cada uno de los seis combobox
destinados a establecer la distribución de los botones para eso se llama a la función
setup_button_combobox (), esta función recibe una estructura AppearanceData, un GtkComboBox
y un entero. El entero representa la posición del arreglo al que el combobox debe prestar
atención.
El código es el siguiente:
Implementación de la función setup_button_combobox () en el archivo appearance-desktop.c
void setup_button_combobox (AppearanceData *data, GtkComboBox *combo_box, gint id) { ButtonName button_name; GtkListStore *model; GtkTreeIter iter; GtkCellRenderer *renderer; int i, x; //Se obtiene un button_name. button_name = get_button_name (data, id); model = gtk_list_store_new (NUMBER_COLUMNS, G_TYPE_STRING, G_TYPE_POINTER); gtk_combo_box_set_model (GTK_COMBO_BOX (combo_box), GTK_TREE_MODEL (model)); //Se limpia cualquier referencia que pudiera haber entre las estructuras y la lista del combobox.
159
g_object_unref (model); gtk_cell_layout_clear (GTK_CELL_LAYOUT (GTK_COMBO_BOX (combo_box))); renderer = gtk_cell_renderer_text_new (); gtk_cell_layout_pack_start (GTK_CELL_LAYOUT (combo_box), renderer, TRUE); gtk_cell_layout_set_attributes (GTK_CELL_LAYOUT (combo_box), renderer, "text", COLUMN_TEXT, NULL); //Se agrega cada elemento de button_name_items a la lista del combobox. for (i = 0; i < G_N_ELEMENTS (button_name_items); i++) { gboolean esta= FALSE; /*Comprobar que el elemento de button_name_items no se encuentre en data->buttons_array*/ for (x = 0; x < id; x++) { if(get_button_name (data, x)==button_name_items [i].button_name){ esta=TRUE; } } //Si el elemento no está, se agregue a la lista del combobox. if(esta==FALSE){ gtk_list_store_append (model, &iter); gtk_list_store_set (model, &iter, COLUMN_TEXT, g_dpgettext2 (NULL, "button_name", button_name_items [i].name), COLUMN_ITEM, &(button_name_items [i]), -1); //Si el button_name coincide, que se marque como ítem activo. if (button_name == button_name_items [i].button_name) gtk_combo_box_set_active_iter (GTK_COMBO_BOX (combo_box), &iter); } } }
Como se puede observar se hace uso de get_button_name () cuya implementación es la siguiente:
Implementación de la función get_button_name () en el archivo appearance-desktop.c
//Leer empezando por la última función. gboolean map_button_name_string (const gchar *str, ButtonName *button_name) { int mapped; g_return_val_if_fail (button_name != NULL, FALSE); if (!str) return FALSE; //Mapea el botón. if (!gconf_string_to_enum (button_name_map, str, &mapped)) return FALSE; *button_name = mapped; return TRUE; } ButtonName
160
get_button_name (AppearanceData *data, gint id) { ButtonName button_name; //Si el identificador del combobox es mayor al número de elementos en buttons_array, mapea //la cadena vacía, si no, toma el valor de la posición de id en buttons_array y se mapea. if (id>=data->contador){ if (map_button_name_string ("", &button_name)){ return button_name; } }else{ if (map_button_name_string (data->buttons_array[id], &button_name)){ return button_name; } } }
La última función referenciada en window_init ( ) es: layout_combobox_changed (), esta función
es la encargada de realizar operaciones cuando el valor de alguno de los seis combobox es
modificado. Su función es de leer los ítems activos de los seis combobox,
El código es el siguiente:
Implementación de la función layout_combobox_changed () en el archivo appearance-desktop.c
static void layout_combobox_changed (AppearanceData *data, GtkComboBox *combo_box) { /*Se declaran seis variables que almacenarán las cadenas que son apuntadas por cada uno de los combobox*/ gchar *combo1; gchar *combo2; gchar *combo3; gchar *combo4; gchar *combo5; gchar *combo6; //Se leen las cadenas de cada combobox y se prepara añadiendo una coma combo1=add_comma(set_button_name (data->button_layout_combobox1)); combo2=add_comma(set_button_name (data->button_layout_combobox2)); combo3=add_comma(set_button_name (data->button_layout_combobox3)); combo4=add_comma(set_button_name (data->button_layout_combobox4)); combo5=add_comma(set_button_name (data->button_layout_combobox5)); combo6=set_button_name (data->button_layout_combobox6); //Se escribe la concatenación de cadenas en la clave de gconf. gconf_client_set_string (data->client, BUTTON_LAYOUT_KEY, g_strconcat (combo1,combo2,combo3,combo4,combo5,combo6,NULL), NULL); //Se actualiza buttons_array. load_gconf_buttons(data);
161
//Con el Nuevo arreglo, se actualizan los item referenciados por cada combobox. update_combobox(data, data->button_layout_combobox1,0); update_combobox(data, data->button_layout_combobox2,1); update_combobox(data, data->button_layout_combobox3,2); update_combobox(data, data->button_layout_combobox4,3); update_combobox(data, data->button_layout_combobox5,4); update_combobox(data, data->button_layout_combobox6,5); }
La función layout_combobox_changed () hace uso de las funciones add_comma (),
set_button_name () y update_combobox (), cuya implementación se mostrará a continuación.
La función add_comma () solo es funcional para agregar una coma al final del nombre de algún
botón, lo cual sirve para que la clave de gconf lea correctamente el nombre de cada botón.
Implementación de la función add_comma () en el archivo appearance-desktop.c
const char * add_comma(gchar *string) { if(string==NULL||0!=g_strcasecmp (string, "")){ return g_strconcat (string,",",NULL); }else{ return string; } }
set_button_name () sirve para obtener el item activo de algún combobox y llama a
map_button_name (), para mapear ese item con su nombre.
Implementación de la función set_button_name () en el archivo appearance-desktop.c
//Leer empezando por la última función. const char * map_button_name (ButtonName button_name) { //Regresa el string ligado al botón. return gconf_enum_to_string (button_name_map, button_name); } const char * set_button_name (GtkComboBox *combo_box) { GtkTreeIter iter; GtkTreeModel *model; ButtonNameComboItem *item; if (!gtk_combo_box_get_active_iter (combo_box, &iter)) return; //Se obtiene el ítem seleccionado en el combobox.
162
model = gtk_combo_box_get_model (GTK_COMBO_BOX(combo_box)); gtk_tree_model_get (model, &iter, COLUMN_ITEM, &item, -1); if (item == NULL) return; //Se regresa el nombre del botón. return map_button_name (item->button_name); }
La función encargada de actualizar la lista desplegable de cada combobox evitando que
desplieguen las mismas cadenas es update_combobox () cuya implementación es la siguiente:
Implementación de la función update_combobox () en el archivo appearance-desktop.c
void update_combobox (AppearanceData *data, GtkComboBox *combo_box, gint id) { ButtonName button_name; GtkListStore *model; GtkTreeIter iter; GtkCellRenderer *renderer; int i, x; // Se declara la referencia a un identificador de un listener. gulong *id_signal; /*Se detecta el combobox que realizó el cambio de ítem y se asigna el identificador de su listener*/ if(combo_box==data->button_layout_combobox1){ id_signal=data->id_signal_combo1; }else if(combo_box==data->button_layout_combobox2){ id_signal=data->id_signal_combo2; }else if(combo_box==data->button_layout_combobox3){ id_signal=data->id_signal_combo3; }else if(combo_box==data->button_layout_combobox4){ id_signal=data->id_signal_combo4; }else if(combo_box==data->button_layout_combobox5){ id_signal=data->id_signal_combo5; }else if(combo_box==data->button_layout_combobox6){ id_signal=data->id_signal_combo6; } //Se bloquea el listener del combobox. g_signal_handler_block (combo_box, id_signal); //Se obtiene un botón. button_name = get_button_name (data, id); //Se crea todo lo necesario para configurar un combobox. model = gtk_list_store_new (NUMBER_COLUMNS, G_TYPE_STRING, G_TYPE_POINTER); gtk_combo_box_set_model (GTK_COMBO_BOX (combo_box), GTK_TREE_MODEL (model)); g_object_unref (model); gtk_cell_layout_clear (GTK_CELL_LAYOUT (GTK_COMBO_BOX (combo_box))); renderer = gtk_cell_renderer_text_new ();
163
gtk_cell_layout_pack_start (GTK_CELL_LAYOUT (combo_box), renderer, TRUE); gtk_cell_layout_set_attributes (GTK_CELL_LAYOUT (combo_box), renderer, "text", COLUMN_TEXT, NULL); //Se llena la lista desplegable del combobox con el nombre de los elementos. for (i = 0; i < G_N_ELEMENTS (button_name_items); i++) { gboolean esta= FALSE; /*Comprobar que el elemento de button_name_items no se encuentre en data->buttons_array*/ for (x = 0; x < id; x++) { if(get_button_name (data, x)==button_name_items [i].button_name){ esta=TRUE; } } //Si el elemento no está, se agregue a la lista del combobox. if(esta==FALSE){ gtk_list_store_append (model, &iter); gtk_list_store_set (model, &iter, COLUMN_TEXT, g_dpgettext2 (NULL, "button_name", button_name_items [i].name), COLUMN_ITEM, &(button_name_items [i]), -1); //Si el button_name coincide, se marque como ítem activo. if (button_name == button_name_items [i].button_name){ gtk_combo_box_set_active_iter (GTK_COMBO_BOX (combo_box), &iter); } } } //Se desbloquea el listener del combobox. g_signal_handler_unblock (combo_box, id_signal); }
Con esto se termina la modificación a la barra de título.
164
4.6 Modificaciones al Menú Principal
A continuación se mostrará el desarrollo de las actividades necesarias para realizar las
modificaciones al menú principal.
4.6.1 Ingeniería inversa.
El código fuente a analizar en esta etapa se encuentra en el archivo panel-menu-button.c que está
en el directorio gnome-panel-2.30.2/gnome-panel del código fuente del panel de GNOME. Este
archivo contiene todo lo referente a la programación del Menú principal. En esta modificación no
reutilizaremos ningún archivo de interfaz ya que originalmente no se cuenta con uno, se optará
por crear una ventana con los widgets suficientes de manera dinámica.
4.6.1.1 Ingeniería inversa para comprender datos
En el archivo panel-menu-button.c se define una estructura de datos llamada
_PanelMenuButtonPrivate, la cual nos permitirá acceder a todos los miembros privados de la
barra de menú. Los miembros que se utilizarán serán custom_icon y use_custom_icon.
Definición de la estructura _PanelMenuButtonPrivate en el archivo panel-menu-button.c
struct _PanelMenuButtonPrivate { PanelToplevel *toplevel; guint gconf_notify; char *applet_id; GtkWidget *menu; char *menu_path; char *custom_icon; char *tooltip; MenuPathRoot path_root; guint use_menu_path : 1; guint use_custom_icon : 1; guint dnd_enabled : 1; };
4.6.1.2 Ingeniería inversa para comprender el procesamiento y de interfaz de
usuario
En este caso, al dar clic con el botón derecho del mouse sobre el panel no aparecía ninguna
opción para poder modificar las preferencias del menú principal, por lo tanto no existía una
interfaz gráfica, solo aparecía el menú contextual el cual es creado por la función
panel_menu_button_load (), una vez seleccionada la opción en el menu contextual se invoca a la
función panel_menu_button_invoke_menu () que se encarga de llamar a las funciones
correspondientes con la opción seleccionada.
165
4.6.2 Ingeniería directa.
Para agregar las funcionalidades faltantes al Menú principal se realizó lo siguiente en el archivo
panel-menu-button.c:
Se modificó la función panel_menu_button_load () con el propósito de mostrar la opción de
“Propiedades” en el menú contextual de la barra de menú y de capturar la identificación del
objeto, quedando de la siguiente manera:
Extracto de la implementación de la función panel_menu_button_load () en el archivo panel-menu-button.c
static void panel_menu_button_load (const char *menu_path, gboolean use_menu_path, const char *custom_icon, gboolean use_custom_icon, const char *tooltip, PanelWidget *panel, gboolean locked, int position, gboolean exactpos, const char *id) { PanelMenuButton *button; AppletInfo *info; g_return_if_fail (panel != NULL); … button->priv->applet_id = g_strdup (info->id); panel_applet_add_callback (info, "help", GTK_STOCK_HELP, _("_Help"), NULL); /*Se agrega en el menú contextual la entrada “Propiedades” y se crea un callback llamado properties.*/ panel_applet_add_callback (info, "properties", NULL, _("_Propiedades"), NULL); if (panel_is_program_in_path ("alacarte") || panel_is_program_in_path ("gmenu-simple-editor")) panel_applet_add_callback (info, "edit", NULL, _("_Edit Menus"), NULL); … }
Ahora se enlistará la modificación a la función panel_menu_button_invoke_menu () que se llama
cada vez que se selecciona una opción del menú contextual.
Implementación de la función panel_menu_button_invoke_menu () en el archivo panel-menu-button.c
void panel_menu_button_invoke_menu (PanelMenuButton *button,
166
const char *callback_name) { GdkScreen *screen; g_return_if_fail (PANEL_IS_MENU_BUTTON (button)); g_return_if_fail (callback_name != NULL); screen = gtk_widget_get_screen (GTK_WIDGET (button)); /*Si el callback detectado es properties se deberá invocar a la función prop_window_menubutton().*/ if (!strcmp (callback_name, "properties")) { prop_window_menubutton(button); } if (!strcmp (callback_name, "help")) { panel_show_help (screen, "user-guide", "gospanel-37", NULL); } else if (!strcmp (callback_name, "edit")) { GError *error = NULL; panel_launch_desktop_file_with_fallback ("alacarte.desktop", "alacarte", screen, &error); if (error) { g_error_free (error); panel_launch_desktop_file_with_fallback ( "gmenu-simple-editor.desktop", "gmenu-simple-editor", screen, NULL); } } }
Se mostrará la función prop_window_menubutton () que es la encargada de crear la interfaz de
propiedades de la barra de menú, de visualizar los widgets y crear los listeners correspondientes.
Implementación de la función prop_window_menubutton () en el archivo panel-menu-button.c
int prop_window_menubutton (PanelMenuButton *button) { //Función que crea, llena y destruye la ventana de preferencias del menu GtkWidget *pref_window; GtkWidget *pref_frame; GtkWidget *pref_table; GtkWidget *use_custom_icon_radiobutton; GtkWidget *default_radiobutton; GSList *pref_grupo; GtkWidget *vbox; GtkWidget *pref_table2; GtkWidget *close_button;
167
vbox = gtk_vbox_new (FALSE, 0); //Se crea la ventana. pref_window = gtk_window_new (GTK_WINDOW_TOPLEVEL); gtk_window_set_title(GTK_WINDOW(pref_window), "Propiedades del Menu"); //Se crea el listener para cerrar la ventana gtk_signal_connect (GTK_OBJECT (pref_window), "destroy", GTK_SIGNAL_FUNC (gtk_main_quit), NULL); gtk_widget_set_usize(pref_window, 350, 300); gtk_container_set_border_width (GTK_CONTAINER (pref_window), 10); pref_frame = gtk_frame_new(NULL); //Se crean contenedores para acomodar los widgets y mejorar su presentación gtk_container_add(GTK_CONTAINER(pref_window), vbox); gtk_box_pack_start (vbox, pref_frame, TRUE, TRUE, 0); gtk_frame_set_label( GTK_FRAME(pref_frame), "Propiedades del Menu" ); gtk_frame_set_label_align( GTK_FRAME(pref_frame), 0.5, 0.0); gtk_frame_set_shadow_type( GTK_FRAME(pref_frame), GTK_SHADOW_ETCHED_OUT); //Se crea el default_radiobutton encargado de seleccionar utilizar icono del tema default_radiobutton = gtk_radio_button_new_with_label (NULL, "Utilizar icono del tema"); pref_grupo=gtk_radio_button_get_group (default_radiobutton); /*Se crea el use_custom_icon_radiobutton encargado de seleccionar utilizar icono Personalizado*/ use_custom_icon_radiobutton = gtk_radio_button_new_with_label (pref_grupo, "Utilizar icono personalizado"); pref_table = gtk_table_new (6,6,TRUE); pref_table2 = gtk_table_new (1,6,TRUE); //Se crea el botón de cerrar y su listener para destruir la aplicación. close_button=gtk_button_new_from_stock ("gtk-close"); g_signal_connect_swapped (close_button, "clicked", G_CALLBACK (gtk_widget_destroy), G_OBJECT (pref_window)); gtk_table_attach (GTK_TABLE (pref_table2), close_button, 4, 6, 1, 2, GTK_EXPAND | GTK_FILL, GTK_FILL, 0, 0); //Se crea el botón para seleccionar el archivo con el nuevo icono menu_icon_button = gtk_file_chooser_button_new ("Selecciona un archivo", GTK_FILE_CHOOSER_ACTION_OPEN); pref_label1=gtk_label_new("Seleccionar icono:"); gtk_widget_set_sensitive(menu_icon_button, FALSE); gtk_widget_set_sensitive(pref_label1, FALSE); //Se inicializan los togglebuttons. if(button->priv->use_custom_icon!=0){ gtk_toggle_button_set_active(use_custom_icon_radiobutton,TRUE); gtk_file_chooser_set_filename (menu_icon_button, button->priv->custom_icon); gtk_widget_set_sensitive(menu_icon_button, TRUE); gtk_widget_set_sensitive(pref_label1, TRUE); }else { gtk_toggle_button_set_active(default_radiobutton,TRUE); gtk_file_chooser_set_filename (menu_icon_button, button->priv->custom_icon);
168
} //Se crea el listener de menu_icon_button, cualquier cambio debe llamar a la función // menu_icon_button_changed () g_signal_connect_swapped (menu_icon_button, "selection-changed", G_CALLBACK (menu_icon_button_changed), button); //Se crea el listener de default_radiobutton, cualquier cambio debe llamar a la función // default_radiobutton_toggled() g_signal_connect_swapped (default_radiobutton, "toggled", G_CALLBACK (default_radiobutton_toggled), button); //Se crea el listener de use_custom_icon_radiobutton, cualquier cambio debe llamar a la //función use_custom_icon_radiobutton_toggled (). g_signal_connect_swapped (use_custom_icon_radiobutton, "toggled", G_CALLBACK (use_custom_icon_radiobutton_toggled), button); //Se acomodan los widgets en los contenedores gtk_table_attach (GTK_TABLE (pref_table), default_radiobutton, 0, 6, 1, 2, GTK_EXPAND | GTK_FILL, GTK_FILL, 0, 0); gtk_table_attach (GTK_TABLE (pref_table), use_custom_icon_radiobutton, 0, 6, 2, 3, GTK_EXPAND | GTK_FILL, GTK_FILL, 0, 0); gtk_table_attach (GTK_TABLE (pref_table), menu_icon_button, 3, 6, 3, 4, GTK_EXPAND | GTK_FILL, GTK_FILL, 0, 0); gtk_table_attach (GTK_TABLE (pref_table), pref_label1, 0, 3, 3, 4, GTK_EXPAND | GTK_FILL, GTK_FILL, 0, 0); gtk_container_add(GTK_CONTAINER(pref_frame), pref_table); gtk_box_pack_start (vbox, pref_table2, FALSE, FALSE, 0); //Se muestran los widgets en la ventana gtk_widget_show(use_custom_icon_radiobutton); gtk_widget_show(default_radiobutton); gtk_widget_show(menu_icon_button); gtk_widget_show(pref_table2); gtk_widget_show(close_button); gtk_widget_show(pref_label1); gtk_widget_show(pref_table); gtk_widget_show(pref_frame); gtk_widget_show (vbox); gtk_widget_show (pref_window); gtk_main (); return(0); }
Como se puede observar se usa un widget llamado menu_icon_button que resulta ser empleado
para implementar un file_chooser_button, la declaración de este widget es global y es como sigue:
GtkWidget *menu_icon_button.
169
A continuación se mostrará la función menu_icon_button_changed () que es llamada cuando se selecciona un nuevo icono.
Implementación de la función menu_icon_button_changed () en el archivo panel-menu-button.c
//Función que establece en gconf la clave custom_icon del menu-button void menu_icon_button_changed (PanelMenuButton *button) { GConfClient *client; const char *key; char *image; //Se toma la ruta del Nuevo icono. image = gtk_file_chooser_get_filename (GTK_FILE_CHOOSER (menu_icon_button)); //Se obtiene un cliente de gconf para este Menú principal. client = panel_gconf_get_client (); //Se obtiene una clave de gconf para este Menú principal. key =panel_gconf_full_key (PANEL_GCONF_OBJECTS, button->priv->applet_id, "custom_icon"); //Se establece la ruta del archivo en la clave de gconf. gconf_client_set_string(client, key, image, NULL); }
Se mostrará la función default_radiobutton_toggled () que es invocada cuando el
default_radiobutton es seleccionado.
Implementación de la función default_radiobutton_toggled () en el archivo panel-menu-button.c
void default_radiobutton_toggled (PanelMenuButton *button) { //Función que establece inactiva la clave use_custom_icon en gconf GConfClient *client; const char *key; gtk_widget_set_sensitive(pref_label1, FALSE); gtk_widget_set_sensitive(menu_icon_button, FALSE); client = panel_gconf_get_client (); key =panel_gconf_full_key (PANEL_GCONF_OBJECTS, button->priv->applet_id, "use_custom_icon"); gconf_client_set_bool(client, key, FALSE, NULL); }
Se mostrará la función use_custom_icon_radiobutton_toggled () que es invocada cuando el
use_custom_icon_radiobutton es seleccionado.
170
Implementación de la función use_custom_icon_radiobutton_toggled () en el archivo panel-menu-button.c
void use_custom_icon_radiobutton_toggled (PanelMenuButton *button) { //Función que establece como activa la clave use_custom_icon en gconf GConfClient *client; const char *key; gtk_widget_set_sensitive(pref_label1, TRUE); gtk_widget_set_sensitive(menu_icon_button, TRUE); client = panel_gconf_get_client (); key =panel_gconf_full_key (PANEL_GCONF_OBJECTS, button->priv->applet_id, "use_custom_icon"); gconf_client_set_bool(client, key, TRUE, NULL); }
Con esto damos por concluidas las modificaciones al Menú principal.
171
Evaluación Para realizar la evaluación de las modificaciones realizadas al sistema, se usará la información
obtenida en las fases de prueba según el plan de prueba que se puede encontrar en el Anexo 1 de
este trabajo de investigación.
Se comparará el reporte de la primera fase de pruebas con el reporte de la segunda fase de
pruebas y con ello se determinará si es que las modificaciones han tenido éxito.
Tasa de tareas completadas satisfactoriamente
A continuación se muestra una tabla enunciando el porcentaje de completitud de las tareas según su fase de prueba:
Porcentaje Completitud
Tarea 1 Tarea 2 Tarea 3 Tarea 4 Tarea 5
Fase de pruebas 1
0% 10% 10% 40% 60%
Fase de pruebas 2
100% 100% 100% 90% 100%
Diferencia 100% 90% 90% 50% 40%
Con estos datos se puede apreciar la comparación entre el sistema antiguo y las modificaciones
realizadas. El incremento de completitud en la tarea 1 es del 100%, en las tareas 2 y 3 es del 90%,
en la tarea 4 es del 50% y en la tarea 5 es del 40%. Cabe mencionar que en la segunda fase de
pruebas, los usuarios representativos no hicieron uso de internet para poder llevar a cabo las
configuraciones.
Valoración de tareas
A continuación se muestra la tabla comparativa del promedio de la percepción de familiaridad y de adaptabilidad de los sujetos de prueba según la fase en la que participaron:
Fase de prueba
¿Familiar? ¿Cómodo?
1 1.58 1.6
2 3.92 4.22
Diferencia 2.34 2.62
Porcentaje 148% 163.75%
Con estos datos se puede afirmar que hubo un aumento del 148% en la percepción de familiaridad y un aumento del 163.75% en la percepción de comodidad al realizar las tareas.
172
Tiempo en tareas
A continuación se mostrará la tabla comparativa del promedio de minutos empleado en realizar las tareas entre las fases de prueba:
Fase de prueba
Tarea 1 Tarea 2 Tarea 3 Tarea 4 Tarea 5
1 5:00 4:50 4:59 4:23 4:35
2 0:54 1:29 1:05 2:54 3:25
Diferencia 4:06 3:21 3:54 1:29 1:10
Porcentaje 82% 69.31% 78.26% 33.84% 25.45%
Como se puede apreciar, existe una reducción del tiempo con las modificaciones: 82% en la actividad 1, 69.31% en la tarea 2, 78.26% en la actividad 3, 33.84% en la actividad 4 y 25.45% en la última actividad. Cabe señalar que los tiempos de la fase 1 en su mayoría son estimados, ya que en esa fase la consecución de las tareas fue muy pobre.
Valoración del sistema
A continuación se muestra la comparación entre fases al evaluar los promedios de la percepción del usuario acerca de recuperabilidad, del tiempo de respuesta, de la adaptación de las tareas y de la carga cognitiva
Fase de prueba
¿No es recuperable?
¿Veloz? ¿Adaptado? ¿Fácil de recordar?
1 1 5 1.4 1.7
2 1 5 4.5 4.7
Diferencia 0 0 3.1 3
Porcentaje 0% 0% 68.88% 63.82%
Con la tabla se puede apreciar que las modificaciones no dañaron a la recuperabilidad del sistema, ni disminuyeron la velocidad de respuesta, sin embargo aumentaron en un 68.88% la adaptación de las tareas para un nivel de usuario inexperto-medio y en un 63.82% la facilidad de realizar las tareas en un futuro sin usar internet.
Por todo lo anterior es posible afirmar que las modificaciones a la interfaz del escritorio Ubuntu
10.04 han resultado exitosas.
173
Conclusión Este trabajo de investigación tuvo como propósito el analizar las interfaces del escritorio de
Ubuntu, detectar problemas de usabilidad y realizar modificaciones para corregirlas.
Ubuntu es una distribución GNU/Linux orientada a un público de usuarios provenientes de
entornos comerciales como lo es Windows, por consiguiente se enfoca en la facilidad de uso para
realizar tareas cotidianas y para ello utiliza el escritorio GNOME que proporciona una interfaz
gráfica limpia, estética y fácil de usar. Sin embargo, GNOME tiene opciones de configuración para
que el usuario personalice los elementos del escritorio, algunas de estas opciones no se
encuentran disponibles en interfaz grafica alguna, solo pueden ser manipuladas a través del editor
de configuración de GNOME.
El editor de configuración de GNOME fue diseñado para tener las opciones de configuración del
escritorio agrupadas, con el propósito de que los administradores navegaran rápidamente entre
claves de configuración y establecieran las preferencias del sistema. Lo anterior da como resultado
que un usuario sin los conocimientos necesarios para realizar las configuraciones tenga dificultad
para acceder a estas opciones de configuración. En consecuencia es necesario modificar algunas
interfaces y mejorar la usabilidad en la manipulación de las opciones, para facilitar dichos accesos.
Las modificaciones se realizaron siguiendo dos modelos, el modelo de la ingeniería de la usabilidad
y el modelo de la reingeniería de software, el primero nos permite asegurarnos que las interfaces
del sistema serán altamente usables y el segundo modelo nos garantiza llevar un control en las
modificaciones a cualquier sistema.
Se realizó una serie de pruebas con tareas representativas usando el sistema original, lo que arrojó
una cierta cantidad de métricas que sirvieron de referencia para ser comparadas con el sistema
modificado.
Al realizar las pruebas a las modificaciones de las interfaces gráficas del escritorio GNOME para
lograr una mejora en la usabilidad de la configuración de opciones de personalización del
escritorio, se encontró lo siguiente:
Un notable ascenso en la completitud de tareas representativas.
La manera de realizar las tareas con las interfaces modificadas les pareció a los usuarios más
familiar y por lo tanto más fáciles de aprender.
Según los datos comparativos los usuarios creen que las modificaciones se adaptan más a su
forma de realizar las tareas por lo tanto estas modificaciones hacen que el sistema tenga
mayor grado de flexibilidad.
Además los usuarios están de acuerdo en que la manera de realizar los cambios a las opciones
de configuración es de la forma en que ellos se imaginaban, sin necesidad de recordar claves,
174
códigos de color, etc., de tal forma, se puede decir que se logró un aumento en la adaptación
de las tareas y una disminución en la carga cognitiva.
Todas estas mejoras se lograron sin afectar la robustez, la recuperabilidad y el tiempo de
respuesta del sistema original.
Con la realización de estas modificaciones y con el resultado de las pruebas se afirma que se logró
mejorar la usabilidad en aspectos de configuración gráfica del escritorio, acercando así a Ubuntu a
ser más usable en relación a sus interfaces gráficas de opciones de configuración.
175
Anexo 1
Plan de Pruebas de Usabilidad
176
1. Introducción
Este documento describe el plan de pruebas para conducir pruebas de usabilidad durante el
desarrollo de las modificaciones al escritorio GNOME. Los objetivos de las pruebas de
usabilidad incluyen el establecer una base de rendimiento e identificar posibles problemas
de diseño que deben abordarse con el fin de mejorar la eficiencia, productividad y
satisfacción del usuario final.
Los objetivos de la prueba de usabilidad son:
Determinar las inconsistencias de diseño y usabilidad en áreas problemáticas dentro de la interfaz de usuario. Las posibles fuentes de error puede incluir:
o Errores de navegación – fallas en encontrar funciones, excesivas pulsaciones del mouse para completar una función.
o Errores de presentación – fallas en localizar y actuar de forma correcta con la información presentada en pantallas.
o Controlar problemas de uso – uso indebido de campos de entrada.
Enfrentar a la aplicación bajo condiciones de pruebas controladas con usuarios representativos. Los datos se utilizarán para constatar que los objetivos de usabilidad con respecto a la interfaz de usuario han sido alcanzados.
Establecer una base del rendimiento y del nivel de satisfacción de usuario de la interfaz para futuras evaluaciones de usabilidad.
2. Metodología
Este plan de prueba contempla dos fases. La primera consistirá en evaluar la interfaz gráfica
de un sistema Ubuntu 10.04 recién instalado y en la segunda fase se evaluará el conjunto de
modificaciones realizadas al escritorio.
El número de participantes en cada fase será de diez personas, las cuales interactuarán con
el sistema, con la intención de medir la facilidad de aprendizaje, la flexibilidad, la
recuperabilidad, el tiempo de respuesta, la adaptación de las tareas, la carga cognitiva, el
tiempo que les toma realizar las actividades propuestas, considerar los elementos que les
gustaron y no les gustaron, y si es que las hay, revisar sus recomendaciones.
2.1 Participantes
En la prueba se espera tener a diez participantes quienes serán reclutados de manera
aleatoria, teniendo como única restricción que sean usuarios activos de computadoras.
Las responsabilidades de los participantes serán tratar de completar un conjunto de tareas
representativas tan eficientemente y tan a tiempo como sea posible y proveer una
retroalimentación sobre la facilidad de uso de la interfaz. Se les pedirá a los participantes
177
que den una opinión honesta acerca de la usabilidad del sistema y a participar en la
respuesta de varias preguntas que se realizarán después de cada tarea.
2.2 Entrenamiento
A los participantes se les dará una pequeña plática acerca de los objetivos de la prueba,
además se señalarán los nombres de los objetos que conforman la interfaz del sistema con
el objetivo de que se familiaricen con el entorno.
2.3 Procedimiento
El presente plan se dividirá en dos etapas las cuales tendrán como única diferencia el objeto
de estudio. En la primera etapa, el objeto de estudio será la interfaz de la distribución
Ubuntu 10.04 recién instalada, sin modificación alguna, con el objetivo de detectar posibles
fallas en la usabilidad. La segunda etapa evaluará al conjunto de modificaciones y mejoras
que tendrán lugar una vez se analice la primera etapa, esta segunda etapa nos permitirá
evaluar si las modificaciones solucionan los posibles problemas detectados con anterioridad.
A continuación se explicará el procedimiento que tendrá lugar en las dos etapas.
Los participantes serán parte de la prueba de usabilidad que tendrá sede en el laboratorio
de computación destinado al uso de los alumnos de maestría de la SEPI UPIICSA. El objeto de
estudio será instalado en una computadora personal. La interacción de los participantes será
observada por el facilitador, quien tomará notas acerca del progreso del participante.
El facilitador recordará a los participantes que se está evaluando al sistema dado y no a los
participantes, además de mencionar que la participación es voluntaria y puede terminar en
cualquier momento. Por último, el facilitador debe preguntar al participante si ha quedado
alguna duda.
Los participantes responderán un cuestionario para determinar su perfil. Se les explicará que
la cantidad de tiempo para realizar las tareas será medido. Al inicio de cada tarea el
evaluador leerá en voz alta la descripción de la tarea y el tiempo comenzará a contar una vez
que el participante comience la tarea.
Después de cada tarea el participante deberá contestar un cuestionario relacionado con la
tarea realizada. Una vez que todos los escenarios de las tareas fueron realizados, el
participante deberá contestar un último cuestionario de satisfacción.
178
3. Roles
En la prueba existirán los siguientes roles:
Entrenador
Proveerá entrenamiento antes de la prueba.
Facilitador
Proporcionará una visión global del estudio a los participantes.
Definirá el objetivo de la prueba a los participantes.
Proporcionará ayuda al participante en caso de dudas.
Observador de la prueba
Identificará problemas con la interfaz, bugs, etc.
Tomará notas.
Participante de la prueba
Contestará cuestionario pre-prueba, post-tarea y post-prueba.
Realizará tareas.
Expondrá su opinión acerca de la interfaz.
4. Tareas de usabilidad
Las tareas seleccionadas para llevar a cabo la prueba de usabilidad son las siguientes:
Cambiar el icono de la barra de menú.
Cambiar el color del reloj.
Desactivar la animación de ocultación del panel.
Mostrar la papelera de reciclaje en el escritorio.
Restablecer los botones de la barra de menú.
5. Métricas de usabilidad
Las métricas de usabilidad se refieren a la comparación entre el rendimiento medido en las
dos fases. Las tasas de facilidad de aprendizaje, de flexibilidad, de recuperabilidad, del
tiempo de respuesta, de la adaptación de las tareas, de la carga cognitiva serán usadas. El
tiempo para realizar cada una de las tareas también será medido.
5.1 Facilidad de aprendizaje
179
Al finalizar cada tarea existe la siguiente pregunta escalar ¿La manera de realizar la tarea, le
resultó familiar?, cuyos valores van del 1 al 5, con el promedio de esta pregunta en las cinco
actividades se evaluará esta métrica.
5.2 Flexibilidad
Al finalizar cada tarea existe la siguiente pregunta escalar ¿Le resultó cómodo realizar la
tarea?, cuyos valores van del 1 al 5, con el promedio de esta pregunta en las cinco
actividades se evaluará esta métrica.
5.3 Recuperabilidad
Al concluir todas las tareas existe la siguiente pregunta escalar ¿Al seleccionar opciones que
no solucionaban la tarea, el sistema se detuvo?, cuyos valores van del 1 al 5, con esta
pregunta se evaluara esta métrica.
5.4 Tiempo de respuesta
Al concluir todas las tareas existe la siguiente pregunta escalar ¿La velocidad de respuesta
del sistema es adecuada?, cuyos valores van del 1 al 5, con esta pregunta se evaluara esta
métrica.
5.5 Adaptación de las tareas
Al concluir todas las tareas existe la siguiente pregunta escalar ¿La manera de realizar las
tareas fue como usted se imaginaba?, cuyos valores van del 1 al 5, con esta pregunta se
evaluara esta métrica.
5.6 Carga cognitiva
Al concluir todas las tareas existe la siguiente pregunta escalar ¿Si alguna de estas
actividades las tuviera que realizar la siguiente semana, sería capaz de hacerlo sin usar
internet?, cuyos valores van del 1 al 5, con esta pregunta se evaluara esta métrica.
5.7 Tiempo de escenario completado adaptación de las tareas
Consiste en el tiempo en completar cada escenario, sin incluir la evaluación subjetiva.
6. Reportes de resultados
Los reportes de las pruebas de usabilidad se proporcionarán a la conclusión de cada fase de
pruebas. Consistirán en un reporte de resultados, mostrando el grado de las métricas que el
usuario alcanzó a percibir.
180
Reporte de la Primer Fase de Pruebas de Usabilidad
181
1. Introducción
Las pruebas realizadas de acuerdo a la primera fase de pruebas de usabilidad se llevaron a cabo en el laboratorio de computación destinado al uso de los alumnos de maestría de la SEPI UPIICSA. En este documento se mostrarán los resultados que se obtuvieron después de analizar el sistema Ubuntu sin modificaciones.
2. Metodología
Sesiones
El autor de esta tesis contactó y reclutó a los participantes vía telefónica y por correo, informando de la logística de las pruebas y pidiendo la disponibilidad y participación de los asistentes. Los participantes respondieron en tiempo y forma. Cada sesión duró aproximadamente cuarenta minutos. Durante la sesión el facilitador explicó a cada participante los objetivos de la prueba, además de dar una introducción al sistema Ubuntu y pidió a los participantes llenar un cuestionario para determinar el perfil del usuario. Los participantes leyeron los escenarios e intentaron realizar las tareas. Después de cada tarea el facilitador pidió a cada participante contestar el cuestionario post-tarea, el cual incluía las siguientes medidas:
¿La manera de realizar la tarea, le resultó familiar?
¿Le resultó cómodo realizar la tarea?
Cuando la última tarea fue terminada, se les pidió a los participantes contestaran un cuestionario post-prueba que incluía las siguientes preguntas:
¿Al seleccionar opciones que no solucionaban la tarea, el sistema se detuvo?
¿La velocidad de respuesta del sistema es adecuada?
¿La manera de realizar las tareas fue como usted se imaginaba?
¿Si alguna de estas actividades las tuviera que realizar la siguiente semana, sería capaz de hacerlo sin usar internet?
¿Qué fue lo que más te gusto de la manera de hacer las modificaciones?
¿Qué fue lo que no te gusto de la manera de hacer las modificaciones?
¿Qué recomendarías para mejorar?
Participantes
En total se hicieron participes de esta prueba a 10 personas de las cuales: La mitad fueron hombres. De acuerdo a su ocupación, el 50% son estudiantes, el 30% profesionistas y el 20% restante empleados. Según el uso con computadoras el 50% tienen un nivel medio, el 30% son principiantes y el 20% avanzados y del total de participantes, el 60% ha utilizado alguna vez Ubuntu.
182
Evaluación de Tareas
El encargado de realizar los escenarios fue el autor de este trabajo de investigación, y consistió en realizar las siguientes tareas:
Cambiar el icono de la barra de menú.
Cambiar el color del reloj.
Desactivar la animación de ocultación del panel.
Mostrar la papelera de reciclaje en el escritorio.
Restablecer los botones de la barra de menú.
3. Resultados
Tasa de tareas completadas satisfactoriamente
A continuación se muestra una tabla enunciando el número de tareas completadas por los participantes:
Participante Tarea 1 Tarea 2 Tarea 3 Tarea 4 Tarea 5
1 NO NO NO NO SI
2 NO SI NO NO SI
3 NO NO NO SI SI
4 NO NO NO SI SI
5 NO NO NO NO NO
6 NO NO NO NO NO
7 NO NO NO SI SI
8 NO NO SI SI SI
9 NO NO NO NO NO
10 NO NO NO NO NO
Éxito 0 1 1 4 6
Porcentaje Completitud
0% 10% 10% 40% 60%
Con estos datos se puede apreciar que la tarea más completada por los participantes es la
tarea 5 y la menos completada es la tarea 1.
Valoración de tareas
Al completar cada tarea, los participantes calificaron la familiaridad y comodidad de la interfaz al realizar la tarea, con dos preguntas escalares con valores del 1 al 5:
183
¿La manera de realizar la tarea, le resultó familiar?
¿Le resultó cómodo realizar la tarea? A continuación se muestra la tabla con el promedio de la suma de las respuestas de las cinco actividades por participante:
Participante ¿Familiar? ¿Cómodo?
1 1.6 1
2 1 2
3 1.8 1.4
4 1.6 2.2
5 2.8 1.2
6 1 1
7 1.4 1.6
8 1.8 1.6
9 1.8 1.8
10 1 1
Total 15.8 16
Promedio 1.58 1.6
Con estos datos podemos afirmar que en una escala del 1 al 5, a los participantes les resulta el sistema 1.58 unidades familiar y 1.6 unidades cómodo.
Tiempo en tareas
Se grabó el tiempo de cada tarea por cada participante. Algunas tareas fueron más complicadas que otras, por lo tanto consumieron más tiempo, esto se muestra en la siguiente tabla:
Participante Tarea 1 Tarea 2 Tarea 3 Tarea 4 Tarea 5
1 5:00 5:00 5:00 5:00 4:02
2 5:00 3:19 5:00 5:00 3:59
3 5:00 5:00 5:00 3:17 4:08
4 5:00 5:00 5:00 3:17 4:40
5 5:00 5:00 5:00 5:00 5:00
6 5:00 5:00 5:00 5:00 5:00
184
Participante Tarea 1 Tarea 2 Tarea 3 Tarea 4 Tarea 5
7 5:00 5:00 5:00 3:50 4:32
8 5:00 5:00 4:50 3:26 4:25
9 5:00 5:00 5:00 5:00 5:00
10 5:00 5:00 5:00 5:00 5:00
Total 50:00 48:19 49:50 43:50 45:46
Tiempo Promedio
5:00 4:50 4:59 4:23 4:35
Nota: Aunque las actividades no hayan sido completadas se tomará un tiempo de 5 minutos para obtener un valor simbólico.
Con esto se puede apreciar que la tarea en la que se invirtió más tiempo fue en la tarea 1 y que la tarea 4 fue la más rápida de realizar.
Valoración del sistema
Al completar la prueba, los participantes calificaron la recuperabilidad, el tiempo de respuesta, la adaptación de las tareas y la carga cognitiva con las siguientes preguntas escalares:
¿Al seleccionar opciones que no solucionaban la tarea, el sistema se detuvo?
¿La velocidad de respuesta del sistema es adecuada?
¿La manera de realizar las tareas fue como usted se imaginaba?
¿Si alguna de estas actividades las tuviera que realizar la siguiente semana, sería capaz de hacerlo sin usar internet?
A continuación se muestra la tabla con los valores de las respuestas a las preguntas escalares por participante:
Participante ¿No es
recuperable? ¿Veloz? ¿Adaptado?
¿Fácil de recordar?
1 1 5 2 2
2 1 5 2 3
3 1 5 1 1
4 1 5 2 2
5 1 5 1 2
6 1 5 1 1
7 1 5 1 1
8 1 5 2 2
185
Participante ¿No es
recuperable? ¿Veloz? ¿Adaptado?
¿Fácil de recordar?
9 1 5 1 1
10 1 5 1 2
Suma 10 50 14 17
Promedio 1 5 1.4 1.7
Con estos datos se puede afirmar que el sistema en una escala del 1 al 5, no se recupera de errores producidos por los usuarios en 1 unidad, que tiene una velocidad de 5 unidades, que está adaptado al usuario 1.4 unidades y que es 1.7 unidades fácil de recordar.
4. Conclusion
Con las tablas anteriormente presentadas, se obtiene lo siguiente:
1. La completitud de las tareas es demasiado baja, incluso hubo participantes que no completaron ninguna tarea.
2. A los participantes no les resulta familiar la manera en que se trabaja en el sistema.
3. A los participantes no les resulta cómodo trabajar con la interfaz actual para realizar las modificaciones.
4. El tiempo que se toma un participante para realizar las tareas es demasiado, incluso hay tareas que no se completaron por falta de tiempo.
5. El sistema actual se recupera de errores fácilmente. 6. El sistema actual es veloz. 7. El sistema no esta adaptado para un usuario principiante–medio. 8. El procedimiento para realizar las configuraciones no es fácil de recordar.
186
Reporte de la Segunda Fase de Pruebas de Usabilidad
187
1. Introducción
Las pruebas realizadas de acuerdo a la segunda fase de pruebas de usabilidad se llevaron a cabo en el laboratorio de computación destinado al uso de los alumnos de maestría de la SEPI UPIICSA. En este documento se mostrarán los resultados que se obtuvieron después de analizar el sistema Ubuntu con las modificaciones realizadas en este trabajo de investigación.
2. Metodología
Sesiones
El autor de esta tesis contactó y reclutó a los participantes vía telefónica y por correo, informando de la logística de las pruebas y pidiendo la disponibilidad y participación de los asistentes. Los participantes respondieron en tiempo y forma. Cada sesión duró aproximadamente cuarenta minutos. Durante la sesión el facilitador explicó a cada participante los objetivos de la prueba, además de dar una introducción al sistema Ubuntu y pidió a los participantes llenar un cuestionario para determinar el perfil del usuario. Los participantes leyeron los escenarios e intentaron realizar las tareas. Después de cada tarea el facilitador pidió a cada participante contestar el cuestionario post-tarea, el cual incluía las siguientes medidas:
¿La manera de realizar la tarea, le resultó familiar?
¿Le resultó cómodo realizar la tarea?
Cuando la última tarea fue terminada, se les pidió a los participantes contestaran un cuestionario post-prueba que incluían las siguientes preguntas:
¿Al seleccionar opciones que no solucionaban la tarea, el sistema se detuvo?
¿La velocidad de respuesta del sistema es adecuada?
¿La manera de realizar las tareas fue como usted se imaginaba?
¿Si alguna de estas actividades las tuviera que realizar la siguiente semana, sería capaz de hacerlo sin usar internet?
¿Qué fue lo que más te gusto de la manera de hacer las modificaciones?
¿Qué fue lo que no te gusto de la manera de hacer las modificaciones?
¿Qué recomendarías para mejorar?
Participantes
En total se hicieron participes de esta prueba a 10 personas de las cuales: La mitad fueron hombres. De acuerdo a su ocupación, el 50% son estudiantes, el 30% profesionistas y el 20% restante empleados. Según el uso con computadoras el 50% tienen
188
un nivel medio, el 30% son principiantes y el 20% avanzados y del total de participantes, el 60% ha utilizado alguna vez Ubuntu.
Evaluación de Tareas
El encargado de realizar los escenarios fue el autor de este trabajo de investigación, y consistió en realizar las siguientes tareas:
Cambiar el icono de la barra de menú.
Cambiar el color del reloj.
Desactivar la animación de ocultación del panel.
Mostrar la papelera de reciclaje en el escritorio.
Restablecer los botones de la barra de menú.
3. Resultados
Tasa de tareas completadas satisfactoriamente
A continuación se muestra una tabla enunciando el número de tareas completadas por los participantes:
Participante Tarea 1 Tarea 2 Tarea 3 Tarea 4 Tarea 5
1 SI SI SI SI SI
2 SI SI SI SI SI
3 SI SI SI NO SI
4 SI SI SI SI SI
5 SI SI SI SI SI
6 SI SI SI SI SI
7 SI SI SI SI SI
8 SI SI SI SI SI
9 SI SI SI SI SI
10 SI SI SI SI SI
Éxito 10 10 10 9 10
Porcentaje Completitud
100% 100% 100% 90% 100%
Con estos datos se puede apreciar que la mayoría de tareas se completaron con éxito sin
embargo un participante falló en encontrar respuesta a la tarea 4.
189
Valoración de tareas
Al completar cada tarea, los participantes calificaron la familiaridad y comodidad de la interfaz al realizar la tarea, con dos preguntas escalares con valores del 1 al 5:
¿La manera de realizar la tarea, le resultó familiar?
¿Le resulto cómodo realizar la tarea? A continuación se muestra la tabla con el promedio de la suma de las respuestas de las cinco actividades por participante:
Participante ¿Familiar? ¿Cómodo?
1 3.8 4.4
2 4.4 4.2
3 4.4 4
4 4.8 4.4
5 3.6 4.2
6 3.2 4.8
7 3.4 4.6
8 3.8 3.8
9 4 4.2
10 3.8 3.6
Total 39.2 42.2
Promedio 3.92 4.22
Con estos datos podemos afirmar que en una escala del 1 al 5, a los participantes les resulta el sistema 3.92 unidades familiar y 4.22 unidades cómodo.
Tiempo en tareas
Se grabó el tiempo de cada tarea por cada participante. Algunas tareas fueron más complicadas que otras, por lo tanto consumieron más tiempo, esto se muestra en la siguiente tabla:
Participante Tarea 1 Tarea 2 Tarea 3 Tarea 4 Tarea 5
1 0:14 1:22 1:35 2:52 2:39
2 0:45 0:31 0:25 2:45 4:34
3 0:18 1:00 0:11 5:00 3:15
4 0:18 1:06 0:17 3:50 3:02
190
Participante Tarea 1 Tarea 2 Tarea 3 Tarea 4 Tarea 5
5 1:50 0:41 1:12 2:30 4:50
6 2:14 2:32 0:41 1:05 2:10
7 0:25 1:59 1:02 2:35 4:08
8 0:45 2:32 1:54 3:12 3:50
9 0:52 2:17 1:39 1:44 2:35
10 1:22 0:48 1:52 3:22 3:12
Total 9:03 14:48 10:48 28:55 34:15
Tiempo Promedio
0:54 1:29 1:05 2:54 3:25
Nota: Aunque las actividades no hayan sido completadas se tomará un tiempo de 5 minutos para obtener un valor simbólico.
Con esto se puede apreciar que la tarea en la que se invirtió más tiempo fue en la tarea 5 y que la tarea 1 fue la más rápida de realizar.
Valoración del sistema
Al completar la prueba, los participantes calificaron la recuperabilidad, el tiempo de respuesta, la adaptación de las tareas y la carga cognitiva con las siguientes preguntas escalares:
¿Al seleccionar opciones que no solucionaban la tarea, el sistema se detuvo?
¿La velocidad de respuesta del sistema es adecuada?
¿La manera de realizar las tareas fue como usted se imaginaba?
¿Si alguna de estas actividades las tuviera que realizar la siguiente semana, sería capaz de hacerlo sin usar internet?
A continuación se muestra la tabla con los valores de las respuestas a las preguntas escalares por participante:
Participante ¿No es
recuperable? ¿Veloz? ¿Adaptado?
¿Fácil de recordar?
1 1 5 5 4
2 1 5 4 5
3 1 5 3 4
4 1 5 5 4
5 1 5 5 5
6 1 5 5 5
191
Participante ¿No es
recuperable? ¿Veloz? ¿Adaptado?
¿Fácil de recordar?
7 1 5 3 5
8 1 5 5 5
9 1 5 5 5
10 1 5 5 5
Suma 10 50 45 47
Promedio 1 5 4.5 4.7
Con estos datos se puede afirmar que el sistema en una escala del 1 al 5, no se recupera de errores producidos por los usuarios en 1 unidad, que tiene una velocidad de 5 unidades, que está adaptado al usuario 4.5 unidades y que es 4.7 unidades fácil de recordar.
4. Conclusión
Con las tablas anteriormente presentadas, se obtiene lo siguiente:
1. La completitud de las tareas es alta, sin embargo no fue del 100% ya que un participante no logró terminar una tarea.
2. A los participantes les resulta familiar en 3.92 unidades la manera en que se trabaja en el sistema.
3. A los participantes les resulta 4.22 unidades cómodo trabajar con la interfaz actual para realizar las configuraciones.
4. Todas las tareas a excepción de una, se llevaron a cabo en corto tiempo y sin necesidad de usar internet.
5. El sistema actual se recupera de errores fácilmente. 6. El sistema actual es veloz. 7. El sistema está adaptado en un 4.5 unidades para un usuario principiante–medio. 8. El procedimiento para realizar las configuraciones es 4.7 unidades fácil de
recordar.
192
Ejemplo de las pruebas de usabilidad
193
Prueba de usabilidad
Perfil de usuario
Por favor conteste las siguientes preguntas:
1. ¿Cuál es su nombre?
_____________________________________________________________________________
2. ¿Cuál es su ocupación?
_____________________________________________________________________________
3. ¿Qué nivel de experiencia tiene usted en el uso de computadoras?
Principiante.
Medio.
Avanzado.
4. Señale con que sistemas se encuentra más familiarizado.
Sistemas Linux.
Sistemas Windows.
Sistemas Mac OS.
5. ¿Ha usado la distribución Ubuntu como sistema operativo?
Si.
No.
6. ¿Ha usado GNOME como entorno de escritorio?
Si.
No.
Escenarios
Antes de comenzar con las tareas a realizar con el sistema se debe comentar que lo más probable
es que en la presente prueba haya ciertas acciones que no podrá completar, si esto ocurre,
significará que el sistema debe ser perfeccionado y la prueba será exitosa, por otra parte, si la
consecución de las actividades son exitosas, significará que el sistema fue diseñado pensando en el
usuario y que esta prueba alcanzó el éxito. La prueba tiene una duración máxima de 30 minutos
aproximadamente.
Las preguntas que surjan en la navegación sólo podrán ser resueltas al final de la prueba.
Se permite el uso de internet para realizar las actividades.
194
Tarea 1
Suponga que desea cambiar el icono de la barra de menú por el icono de UPIICSA que se
encuentra en el escritorio. Por favor realice la modificación.
1. ¿La manera de realizar la tarea, le resultó familiar?
Poco|1|2|3|4|5|Mucho
2. ¿Le resultó cómodo realizar la tarea?
Poco|1|2|3|4|5|Mucho
Tarea 2
Suponga que desea cambiar el color actual del reloj del panel al color azul. Por favor realice la
modificación.
1. ¿La manera de realizar la tarea, le resultó familiar?
Poco|1|2|3|4|5|Mucho
2. ¿Le resultó cómodo realizar la tarea?
Poco|1|2|3|4|5|Mucho
Tarea 3
Al ocultar el panel existe una pequeña animación. Suponga que la animación le resulta incomoda,
por favor desactive la animación.
1. ¿La manera de realizar la tarea, le resultó familiar?
Poco|1|2|3|4|5|Mucho
2. ¿Le resultó cómodo realizar la tarea?
Poco|1|2|3|4|5|Mucho
Tarea 4
Suponga que desea mostrar la papelera de reciclaje en el escritorio. Por favor realice la
modificación.
1. ¿La manera de realizar la tarea, le resultó familiar?
195
Poco|1|2|3|4|5|Mucho
2. ¿Le resultó cómodo realizar la tarea?
Poco|1|2|3|4|5|Mucho
Tarea 5
Suponga que la ubicación de los botones en la barra de titulo resulta incómoda para usted, por
favor establezca los botones de la siguiente manera.
Titulo, minimizar, maximizar y cerrar.
1. ¿La manera de realizar la tarea, le resultó familiar?
Poco|1|2|3|4|5|Mucho
2. ¿Le resultó cómodo realizar la tarea?
Poco|1|2|3|4|5|Mucho
Preguntas generales
3. ¿Al seleccionar opciones que no solucionaban la tarea, el sistema se detuvo?
Poco|1|2|3|4|5|Mucho
4. ¿La velocidad de respuesta del sistema es adecuada?
Poco|1|2|3|4|5|Mucho
5. ¿La manera de realizar las tareas fue como usted se imaginaba?
Poco|1|2|3|4|5|Mucho
6. ¿Si alguna de estas actividades las tuviera que realizar la siguiente semana, sería capaz de
hacerlo sin usar internet?
Poco|1|2|3|4|5|Mucho
196
Conclusiones
Tomando en cuenta el éxito conseguido en la ejecución de las cinco actividades anteriores
conteste lo siguiente:
¿Qué fue lo que a usted le agrado más de la interfaz actual?
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
____________________________________________________________________
¿Qué fue lo que a usted no le agrado de la interfaz actual?
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
____________________________________________________________________
¿Qué recomendaciones daría usted para mejorar la interfaz actual?
________________________________________________________________________________
________________________________________________________________________________
________________________________________________________________________________
____________________________________________________________________
197
Bibliografía
1. BUSH, V. (1945). AS WE MAY THINK. THE ATLANTIC MONTHLY .
2. de Icaza, M. (s.f.). primates.ximian.com. Recuperado el 19 de Enero de 2012, de
http://primates.ximian.com/~miguel/gnome-history.html
3. Dix, A., & al, e. (2003). Human-computer interaction. Londres: Prentice Hall.
4. E. Kendall, K., & E. Kendall, J. (2005). ANÁLISIS Y DISEÑO DE SISTEMAS. México: PEARSON
EDUCACIÓN.
5. Engelbart, D. (1962). AUGMENTING HUMAN INTELLECT: A Conceptual Framework.
6. González Sánchez, J. L., & Gazo Cervero, A. (2003). Red Hat Linux 8. Madrid: ANAYA
MULTIMEDIA.
7. i Saltiveri, T. G., Lorés Vidal, J., & Cañas Delgado, J. J. (2005). Diseño de sistemas interactivos
centrados en el usuario. Barcelona: Editorial UOC.
8. Kotonya, G., & Sommerville, I. (1997). Requirements engineering. Processes and techniques.
Chichester: Jhon Wiley.
9. Mako Hill, B., Helmke, M., Graner, A., & Burger, C. The Official Ubuntu Book. México: PRENTICE
HALL.
10. Moya, R. e. (2002). Programación en el entorno GNOME. Recuperado el 23 de Enero de 2012,
de http://www.calcifer.org/documentos/librognome/
11. Nielsen, J. (1993). Usability engineering. Academic Press.
12. Reimer, J. (2006). http://arstechnica.com/. Recuperado el 15 de 04 de 2012, de
http://arstechnica.com/old/content/2005/05/gui.ars/4
13. Rosson, M. B., & Carroll, J. M. (2002). Usability engineering: scenario-based development of
HCI. San Francisco: Morgan Kaufmann.
14. S. Pressman, R. (2002). INGENIERÍA DEL SOFTWARE UN ENFOQUE PRÁCTICO. España: Mc
Graw Hill.
15. S. Tanenbaum, A. (2003). SISTEMAS OPERATIVOS MODERNOS. México: PEARSON EDUCACIÓN.
16. Saavedra Gutierrez, J. A. (s.f.). El Mundo Informático. Recuperado el 11 de Enero de 2012, de
http://jorgesaavedra.wordpress.com/2006/12/09/breve-historia-de-c-c-c/
198
17. Sánchez Prieto, S. (1999). UNIX y LINUX Guía práctica. México, D.F.: ALFAOMEGA GRUPO
EDITOR, S.A. de C.V.
18. Stallman, R. (1999). The GNU Operating System and the Free Software Movement. En Open
Sources : Voices from the Open Source Revolution. O'REILLY.
19. Torvald, L. (1999). The Linux Edge. En Open Sources: Voices from the Open Source Revolution.
O'REILLY.
Paginas de internet
1. Clavel, D. (15 de 05 de 2009). http://blog.ibcmass.com/. Recuperado el 17 de 04 de 2012, de
http://blog.ibcmass.com/mass-diseno/historia-de-la-interaccion-parte-3-de-3-
%E2%80%9Calan-kay-y-lisa%E2%80%9D/
2. DistroWatch.com. (s.f.). DistroWatch.com. Recuperado el 24 de Enero de 2012, de
http://distrowatch.com/
3. FOCUS. (s.f.). FOCUS. Recuperado el 23 de Enero de 2012, de http://www.focus.com/fyi/50-
places-linux-running-you-might-not-expect/
4. fundacioncopyleft.org. (s.f.). FundacionCopyleft. Recuperado el 11 de Enero de 2012, de
http://fundacioncopyleft.org/es/9/que-es-copyleft
5. GNU.org. (s.f.). GNU Operating System. Recuperado el 10 de Enero de 2012, de
http://www.gnu.org/gnu/gnu.es.html
6. Lagoa Caridad, F. B., & Montero Manso, P. (s.f.). http://sabia.tic.udc.es/. Recuperado el 01 de
04 de 2012, de
http://sabia.tic.udc.es/gc/Contenidos%20adicionales/trabajos/Interfaces/enlightment/
7. Sidar, F. (20 de 12 de 2011). http://www.sidar.org/. Recuperado el 05 de 03 de 2012, de
http://www.sidar.org/recur/desdi/traduc/es/visitable/introduccion.htm
8. SITES, T. S. (s.f.). TOP500 SUPERCOMPUTER SITES. Recuperado el 23 de Enero de 2012, de
http://www.top500.org/
9. Ubuntu.org. (s.f.). Ubuntu. Recuperado el 24 de Enero de 2012, de
http://www.ubuntu.com/project/about-ubuntu
10. W3Counter. (s.f.). W3Counter. Recuperado el 24 de Enero de 2012, de
https://www.w3counter.com/globalstats.php
