Un análisis de usabilidad del escritorio de Ubuntu y...

of 208 /208
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

Transcript of Un análisis de usabilidad del escritorio de Ubuntu y...

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