ESCUELA TECNICA´ SUPERIOR DE INGENIER´IA INFORMATICA´
Ingenier´ıa Informatica´
Extension´ para Clasificacion´ de Correo Electronico´ en Mozilla Thunderbird
Realizado por Jos´eMar´ıaCarmona Cejudo
Dirigido por Manuel Baena Garc´ıay Rafael Morales Bueno
Departamento Lenguajes y Ciencias de la Computaci´on
UNIVERSIDAD DE MALAGA´
MALAGA,´ Febrero 2008
UNIVERSIDAD DE MALAGA´ escuela tecnica´ superior de ingenier´ıa informatica´ Ingenier´ıa Informatica´
Reunido el tribunal examinador en el d´ıa de la fecha, constituido por: Presidente Do/Da. Secretario Do/Da. Vocal Do/Da. para juzgar el proyecto Fin de Carrera titulado: Extensi´onpara Clasificaci´onde Correo en Mozilla Thun- derbird del alumno Do. Jos´eMar´ıaCarmona Cejudo dirigido por Do. Rafael Morales Bueno y Da. Manuel Baena Garc´ıa
ACORDO´ POR OTORGAR LA CALIFICACION´ DE
Y PARA QUE CONSTE, SE EXTIENDE FIRMADA POR LOS COMPA- RECIENTES DEL TRIBUNAL, LA PRESENTE DILIGENCIA.
M´alaga, a de del 2003
El Presidente El Secretario El Vocal
Fdo: Fdo: Fdo:
Agradecimientos
A Manuel Baena, por estar siempre dispuesto a ayudar, y por sus bue- nas ideas y consejos.
A todos los que comparten en Internet su experiencia sobre Thunder- bird.
A mi familia, por apoyarme siempre.
A Brise, por estar a mi lado en los buenos y en los malos momentos.
8 ´Indice general
1. Introducci´on 15 1.1. El correo electr´onico ...... 15 1.1.1. Introducci´on al correo electr´onico ...... 15 1.2. La necesidad de clasificar el correo electr´onico ...... 17 1.2.1. Clasificaci´on de correo usando t´ecnicas bayesianas . . . 18 1.2.2. genusmail ...... 20 1.3. Thunderbird y el proyecto Mozilla ...... 21 1.3.1. Breve historia de Mozilla Thunderbird ...... 22 1.3.2. Caracter´ısticas de Mozilla Thunderbird ...... 24
2. Objetivos 27 2.1. Prop´osito de este proyecto ...... 27 2.2. Objetivos ...... 27
3. Consideraciones t´ecnicas 29 3.1. Consideraciones sobre usabilidad ...... 29 3.2. Desarrollo para la suite Mozilla ...... 39 3.2.1. Arquitectura de la suite Mozilla. XPCOM ...... 39 3.2.2. XUL...... 41 3.2.3. JavaScript...... 43 3.2.4. Internacionalizaci´on y localizaci´on ...... 44 3.2.5. Gecko ...... 44 3.2.6. Chrome ...... 45 3.2.7. RDF...... 47
9 10 ´INDICE GENERAL
3.2.8. Seguridad ...... 48
4. An´alisis y dise˜no 51 4.1. An´alisis preliminar: Diagramas ...... 52 4.1.1. Casosdeuso ...... 52 4.1.2. Diagramas de clase ...... 54 4.1.3. Diagrama de paquetes ...... 55 4.1.4. Diagrama de estados ...... 56 4.1.5. Diagramas de secuencia ...... 58 4.2. An´alisis de interfaces de usuario similares ...... 61 4.2.1. An´alisis ...... 62 4.2.2. Implementaci´on los escenarios de uso por parte de las herramientas ...... 65 4.2.3. An´alisis de las herramientas atendiendo a heur´ısticas dedise˜no ...... 70 4.3. Dise˜no de la interfaz ...... 72 4.4. Comunicaci´on con Genusmail ...... 77
5. Implementaci´on 79 5.1. Flujo de trabajo para la implementaci´on de extensiones para Thunderbird...... 79 5.2. Implementaci´on de la interfaz sin funcionalidad ...... 80 5.2.1. Estructura del programa: carpetas ...... 80 5.2.2. Overlays...... 82 5.3. Implementaci´on de la funcionalidad de la interfaz ...... 86 5.3.1. De la interfaz al clasificador ...... 86 5.3.2. Llamada al clasificador ...... 91 5.4. Componente XPCOM ...... 93 5.5. Sistema de preferencias de la extensi´on ...... 98
6. Despliegue de la extensi´on 101 6.1. Estructura de directorios ...... 101 ´INDICE GENERAL 11
6.2. Ficheros de configuraci´on ...... 104 6.2.1. chrome.manifest ...... 104 6.2.2. install.rdf ...... 105
7. Manual de usuario 107 7.1. Instalaci´on y desinstalaci´on de Another Mail Classifier . . 107 7.2. Configuraci´on de las preferencias ...... 110 7.3. Uso de la extensi´on ...... 111 7.3.1. Entrenar...... 111 7.3.2. Requerir clasificaci´on ...... 113 7.3.3. Mover e-mail a clasificaci´on ...... 113 7.3.4. Eliminar clasificaci´on ...... 114 7.3.5. Forzar clasificaci´on ...... 114
8. Conclusiones 115
A. Contenido del soporte ´optico 119
B. Convenciones de codificaci´on 121 B.1. Convenciones de codificaci´on ...... 121
C. Programas usados 125 C.1. Recursos hardware y software usados ...... 125 C.2. Snipplets de c´odigo externos usados ...... 126
Bibliograf´ıa 127 12 ´INDICE GENERAL ´Indice de figuras
1.1. Logo de Mozilla Thunderbird ...... 24
3.1. Captura del buscador Google, donde se aprecia el uso de la Ley de la Cercan´ıa ...... 32 3.2. Captura del portal de noticias BBC, para ilustrar la Ley de la Semejanza ...... 33 3.3. Panel principal de la Wikipedia, claro ejemplo de la Ley de Clausura...... 34 3.4. P´agina principal de Amazon.com, para ilustrar la Ley de la FigurayelFondo...... 34 3.5. Parte inferior de una p´agina de la Wikipedia, donde se observa el uso combinado de varias leyes ...... 35
4.1. Men´ude Bayesweep en Outlook Express ...... 66 4.2. Configuraci´on de categor´ıas en Bayesweep ...... 69 4.3. Definici´on de una regla en Bayesweep ...... 71 4.4. Captura del men´uprincipal de nuestra extensi´on ...... 73 4.5. Columna a˜nadida al panel de correo de Thunderbird . . . . . 75 4.6. Renombre de las entradas del men´upara mover y copiar e-mails 75 4.7. Ventana de preferencias de la extensi´on ...... 76 4.8. Representaci´on gr´afica del sistema de pseudotuber´ıas usado para comunicarnos con Genusmail ...... 78
5.1. Arbol´ de directorios del c´odigo fuente de la extensi´on . . . . . 81
13 14 ´INDICE DE FIGURAS
5.2. C´odigo fuente del overlay correspondiente a la columna perso- nalizada ...... 82 5.3. C´odigo de inicializaci´on de anothermailclassifier ...... 87 5.4. Fragmento del c´odigo del listener ...... 89 5.5. C´odigo correspondiente al movimiento de un e-mail ...... 90 5.6. Secuencia de acontecimientos en la clasificaci´on de un e-mail . 93 5.7. Definici´on IDL de la interfaz ...... 94 5.8. Interfaz IDL para el Callback ...... 95 5.9. C´odigo C++ correspondiente a la implementaci´on del compo- nente AMCComp ...... 97 5.10. C´odigo JavaScript de las preferencias ...... 99 5.11. Editor de configuraci´on de Mozilla Thunderbird ...... 100
6.1. Organizaci´on de los ficheros de la extensi´on ...... 102
7.1. Men´ude complementos de Thunderbird...... 108 7.2. Explorador de archivos, para encontrar el instalable de la ex- tensi´on...... 108 7.3. Instalaci´on de la extensi´on...... 109 7.4. Instalaci´on de la extensi´on finalizada...... 109 7.5. Instalaci´on de la extensi´on finalizada...... 110 7.6. Advertencia de que el entrenamiento es una operaci´on poten- cialmentelarga ...... 111 7.7. E-mails sin clasificar ...... 112 7.8. El usuario le pide a Genusmail que clasifique dos correos . . . 112 7.9. Los correos han sido clasificados ...... 112 Cap´ıtulo1
Introducci´on
Para comenzar nuestro trabajo, daremos una peque˜na introducci´on al correo electr´onico y nos fijaremos en las razones que llevan a la necesidad de clasificarlo en distintas categor´ıas. Veremos en qu´econsisten las t´ecnicas bayesianas de clasificaci´on, y una herramienta concreta, Genusmail. Poste- riormente hablaremos del programa al que est´adirigida nuestra extensi´on, Mozilla Thunderbird, de su historia y caracter´ısticas m´as notables, ya que el objetivo final de este trabajo consiste en integrar en Thunderbird una interfaz con el sistema de clasificaci´on Genusmail.
1.1. El correo electr´onico
1.1.1. Introducci´onal correo electr´onico
El correo electr´onico o e-mail/email 1 naci´oa finales de los a˜nos 60, siendo al principio una herramienta de intercambio de informaci´on para peque˜nos grupos de investigaci´on. Hoy en d´ıa lo utilizan sin embargo miles de millo- nes de usuarios. El correo electr´onico funciona, grosso modo, de la siguiente
1Existe controversia respecto a la necesidad de usar gui´ono no en la palabra “e-mail”. El CMS (Chicago Manual of Style, [Wie05]), est´andar de facto para la escritura y el perio- dismo en ´ambitos tecnol´ogicos, recomienda usar el gui´on; por lo tanto, nosotros usaremos esta recomendaci´on
15 16 CAP´ITULO 1. INTRODUCCION´ manera:
Mediante cualquier cliente de correo, como es el caso de Mozilla Thun- derbird, se escribe el mensaje y se env´ıa a una direcci´on de correo.
Entonces, el cliente env´ıa su mensaje al servidor de correo.
Cuando el servidor recibe el correo, analiza la direcci´on2, etc, del desti- natario, y, si es necesario, transfiere el correo a otro servidor. Es decir, el mensaje es enrutado a trav´esde una ruta de servidores, hasta que llega al servidor final. Todo esto es lo controla el protocolo SMTP.
El mensaje permanece en el servidor de destino hasta que el usuario so- licita leerlo. En ese momento, el cliente de correo descarga el mensaje al ordenador del usuario, para que lo pueda leer. La solicitud del correo se puede hacer mediante protocolos como POP, o el m´as moderno IMAP.
El mensaje en s´ımismo consta de dos partes: cabecera y cuerpo.
La cabecera contiene informaciones como la ruta que ha seguido el e-mail hasta llegar a sus destinatario, la fecha en que el mensaje fue enviado, la direcci´on de correo del emisor3, la lista de destinatarios, la lista de destinatarios de una copia de carb´on (CC o BCC), el subject o tema del e-mail, el identificador del mensaje, y m´as. La sintaxis exacta de la cabecera est´adescrita en el RFC 2822[Res01].
El cuerpo estaba compuesto inicialmente de texto plano codificado en ASCII de 7 bytes. El est´andar MIME4 permite incorporar caracteres no ASCII, archivos adjuntos, y cuerpos de varias partes [Gra93]. MIME est´aespecificado por hasta seis RFCs: RFC 2045, RFC 2046, RFC 2047, RFC 4288, RFC 4289 y RFC 2077. MIME ofrece la posibilidad de codificar dentro del correo electr´onico texto, im´agenes, audio, v´ıdeo,
2Una direcci´onde correo est´aformada por dos partes, el nombre de usuario y un dominio, separadas por el s´ımbolo @, por ejemplo [email protected] 3Esta direcci´onse puede falsificar, para hacer creer que el emisor ha sido otra persona 4Multipurpose Internet Mail Extensions 1.2. LA NECESIDAD DE CLASIFICAR EL CORREO ELECTRONICO´ 17
e incluso aplicaciones, y de entrelazar todos estos elementos, de forma secuencial o paralela.
1.2. La necesidad de clasificar el correo elec- tr´onico
El r´apido crecimiento de las comunicaciones mediante correo electr´onico hace necesario organizar la informaci´on para hacer m´as r´apido el procesado y la b´usqueda. Almacenar los e-mails en carpetas organizadas jer´arquicamente, d´onde cada carpeta corresponde a una categor´ıa conceptual, ha demostrado ser ´util en este sentido [Its97]. Los problemas de detectar e-mail no solicitado (spam), detectar r´apidamente mensajes importantes, o analizar mensajes de listas de correo est´an a la orden del d´ıa, y mantiene ocupados a los usuarios durante m´as tiempo del que ser´ıa deseable.
Se han implementado varias herramientas para organizar la bandeja de entra- da de los usuarios. Por ejemplo, la mayor´ıa de los clientes de correo actuales incorporan filtros, que analizan si el mensaje contiene o no unas palabras dadas para asignarle una clasificaci´on. Este concepto, sin embargo, no es tan ´util para grandes cantidades de correo, con conceptos muy distintos y que en ocasiones se solapan. Adem´as, obligan al usuario a reorganizar sus filtros cuando quiere cambiar la organizaci´on de sus carpetas. Existen m´etodos au- tom´aticos de clasificaci´on, como los denominados bayesianos, que tienen un mayor porcentaje de aciertos que los sistemas de filtros [MMRT], al ser ca- paces de adaptarse de forma autom´atica al usuario. En el siguiente apartado estudiaremos el funcionamiento de este tipo de clasificadores, y hablaremos de un ejemplo concreto. 18 CAP´ITULO 1. INTRODUCCION´
1.2.1. Clasificaci´onde correo usando t´ecnicas bayesia- nas
Dentro de los m´etodos que se basan en el contenido de los e-mails para decidir si son o no spam (o, generalizando, para decidir su categor´ıa), los es- t´aticos resultan simples de implementar, ya que se basan en la suposici´on de que si un mensaje contiene una palabra concreta, o proviene de un dominio concreto, se trata de correo basura. Sin embargo, este tipo de m´etodos no resulta demasiado fiable, ya que los spammers, para conseguir que sus mensa- jes lleguen al destinatario, simplemente tendr´ıan que evitar ciertas palabras en sus e-mails, las que se sabe que probablemente ser´an interceptadas por los filtros del usuario t´ıpico, o escribir desde otro dominio. Pos esta raz´on, se hacen necesarios m´etodos que sean capaces de adaptarse en dos dimensiones:
Usuario: Para muchos usuarios, un e-mail que contenga repetidamente la palabra Viagra ser´aprobablemente spam, pero para una farmacia que realice pedidos de este producto, en principio no tiene por qu´e. Por lo tanto, un m´etodo de clasificaci´on de e-mail debe ser capaz de adaptarse al usuario concreto que lo est´ausando.
Tiempo: Las t´ecnicas usadas por los spammers pueden cambiar a lo lar- go del tiempo, incluyendo por ejemplo nuevas variaciones de palabras usadas normalmente (v-i-a-g-r-a o v**gr* en vez de viagra). Tam- bi´enpuede cambiar a lo largo del tiempo la clasificaci´on de los correos para cierto usuario: por ejemplo ejemplo, una compa˜n´ıa de software que decida implementar un nuevo producto X para gesti´on de facturas. El m´etodo que se use para clasificar debe aprender que, a partir de ese momento, el nombre del producto (X) est´arelacionado con la gesti´on de facturas.
Los clasificadores adaptativos basados en t´ecnicas bayesianas funcionan de forma realmente prometedora: el porcentaje de aciertos supera el 99,5 %[Cor]. Esta t´ecnica, propuesta por primera vez en [SDHH98], se basa en t´ecnicas 1.2. LA NECESIDAD DE CLASIFICAR EL CORREO ELECTRONICO´ 19 estad´ısticas, concretamente en el teorema de Bayes, aplicado de la siguiente forma:
P(palabras|Categoria )P(Categoria ) P(Categoria |palabras) = i i i P(palabras)
Es decir, la probabilidad de que un e-mail pertenezca a cierta categor´ıa, dado que contiene ciertas palabras, es igual a la probabilidad de aparici´on de esas palabras en los e-mails a los que anteriormente se les hab´ıa asignado esa ca- tegor´ıa, multiplicada por la probabilidad de que cualquier e-mail pertenezca a esa categor´ıa, dividido entre la probabilidad de encontrar esas palabras en cualquier e-mail.
Por ejemplo, imaginemos que hemos recibido un e-mail con varias apari- ciones de la palabra viagra. La probabilidad de que ese e-mail pertenezca a la categor´ıa spam dado que contiene la palabra viagra es la probabilidad de que los e-mails de la categor´ıa spam contengan la palabra viagra (alta) multiplicado por la probabilidad de que los e-mails que nos lleguen son spam (presumiblemente alta) dividido entre la probabilidad de encontrar la pa- labra viagra en un e-mail cualquiera (normalmente baja). Por lo tanto, el clasificador nos dir´ıa que estamos ante un caso de spam con alta probabilidad.
Para que este tipo de clasificador funcione aceptablemente bien, necesita un entrenamiento previo, que idealmente debe usar e-mails reales del usua- rio, para que su adaptaci´on a este sea m´as precisa, de forma que tengamos una base de datos de probabilidades que realmente represente los h´abitos del usuario. Esta base de datos ir´acambiando con el tiempo, seg´un el usuario acepte la clasificaci´on dada (se reforzar´ael modelo interno) o no (en cuyo caso se cambiar´ael modelo para tener en cuenta el feedback del usuario.) 20 CAP´ITULO 1. INTRODUCCION´
1.2.2. genusmail
Genusmail es un clasificador adaptativo de correo electr´onico que usa m´e- todos bayesianos[Rep07]. Fue desarrollado por Miguel Angel´ Zafra para su Proyecto de Fin de Carrera. En el apartado de su memoria Conclusiones: Posibles ampliaciones(p´ag. 94), Miguel Angel´ afirmaba:
“(...) En el caso de nuestro proyecto, se ha optado por integrar el clasifi- cador en el propio servidor de correo electr´onico; ´estorequiere que el mante- nimiento y configuraci´onde genusmail, sea llevado a cabo por el administra- dor de dicho servidor. Con lo cual parece claro que la siguiente fase de ampliaci´ondel proyecto ser´ıa la transformaci´ondel programa en una extensi´on(o plugin) compatible con alguno de los clientes de correo mayoritarios, como por ejemplo Mozilla Thunderbird, y ha- cer que la integraci´oncon el entorno de usuario sea transparente y gestionable por ´el mismo, adem´asde ser una importante baza tanto para la popularidad, como para la libre distribuci´ondel proyecto. ”
Nosotros cogemos el relevo y nos proponemos realizar la ampliaci´on de la que habla Miguel Angel,´ convirti´endola en una extensi´on para Thunderbird de nombre Another Mail Classifier. Genusmail est´aimplementado en Ja- va, y est´aorganizado en cuatro grandes m´odulos:
El primero, genusmail.core.cnx, pone en contacto la aplicaci´on con el servidor de correo, utilizando el protocolo IMAP.
El segundo, genusmail.filters, extrae la informaci´on requerida por el usuario de los mensajes. Hay definido un conjunto de filtros (asunto del e-mail, emisor, receptor, etc.), que se puede ampliar.
El tercero, genusmail.core, da el formato adecuado a la informaci´on extra´ıda, para almacenarla y recuperarla de modo eficiente y coherente.
El cuarto, genusmail, se encarga de la miner´ıa de datos, y es el encar- 1.3. THUNDERBIRD Y EL PROYECTO MOZILLA 21
gado de interactuar con el usuario y de entrenar al modelo bayesiano.
Esta herramienta utiliza la biblioteca Weka, que contiene implementa- ciones de algoritmos de clasificaci´on y aprendizaje, y varias herramientas auxiliares, por ejemplo para transformar datos.
1.3. Thunderbird y el proyecto Mozilla
Mozilla Thunderbird es un cliente de correo, es decir, un programa usado para leer y escribir correos electr´onicos o e-mails. En este trabajo preten- demos extender su funcionalidad integrando un clasificador adaptativo de correo, una herramienta que prediga a qu´ecarpeta tiene que ir cada correo recibido. Mozilla Thunderbird forma parte de la suite de aplicaciones Mozilla [Moz07c], una plataforma de desarrollo disponible para diferentes sistemas operativos que incluye, entre otras aplicaciones, uno de los navegadores m´as usados del momento [One07], Firefox, y el cliente de correo Thunderbird. Estas aplicaciones son totalmente configurables tanto en el idioma de la apli- caci´on como en la apariencia (skins). Mozilla es software libre y de c´odigo abierto: esto hace que los fallos detectados se puedan corregir r´apidamente, y que cualquiera pueda estudiar y modificar el c´odigo seg´un sus necesidades.
Una de las caracter´ısticas m´as importantes de las aplicaciones de Mozilla es que son ampliable mediante extensiones, lo que permite ampliar la funcio- nalidad de los programas de la suite5, seg´un las necesidades de los distintos usuarios.
A continuaci´on relatamos de forma resumida la historia de Thunderbird, y en la siguiente secci´on veremos algunas de las caracter´ısticas m´as destacadas
5Llama la atenci´onque el n´umero de extensiones disponibles actualmente para Firefox (1956) [Moz07g] quintuplique el n´umero disponible para Thunderbird (358) [Moz07h], y que la mayor´ıa de la documentaci´onoficial sobre construcci´onde extensiones se refiera a Firefox. 22 CAP´ITULO 1. INTRODUCCION´ de este programa.
1.3.1. Breve historia de Mozilla Thunderbird
El predecesor de Mozilla fue Netscape, un navegador que inclu´ıa un clien- te de correo, y que fue l´ıder del mercado hasta que perdi´oeste puesto ante el Internet Explorer de Microsoft, el cual contin´ua siendo l´ıder del mercado hasta hoy d´ıa [One07].
La historia de la suite Mozilla propiamente dicha empez´ocon la liberaci´on del c´odigo fuente de la suite Netscape, como proyecto de c´odigo abierto, en marzo de 1998 [Net98a]. Esta decisi´on dividi´oa los usuarios: unos lo interpretaron como una victoria para el software libre, mientras que otros lo interpretaron como la rendici´on de Netscape ante el Explorer.
Los desarrolladores se dieron cuenta r´apidamente de que no se pod´ıa reutili- zar gran parte del c´odigo fuente original de Netscape, por diversos problemas [Zaw99]:
El c´odigo de Netscape se hab´ıa vuelto enorme y complejo. Los ciclos de desarrollo r´apidos a los que se ve´ıan obligados los desarrolladores de Netscape en plena batalla con Internet Explorer hab´ıan hecho que se sacrificara la modularidad y reusabilidad del c´odigo en favor de la inclusi´on de m´as caracter´ısticas en el producto, con la intenci´on de ser competitivos y hacer frente a su rival, redundando negativamente en la calidad del c´odigo producido.
El hecho de que tuviera que ser desarrollado para varios sistemas ope- rativos diferentes, cada uno con sus propias librer´ıas e idiosincrasias, dificultaba bastante el trabajo.
Algunas partes del c´odigo fuente de Netscape nunca fueron lanzadas como c´odigo abierto, debido a compromisos con terceras partes. 1.3. THUNDERBIRD Y EL PROYECTO MOZILLA 23
Por lo tanto, los desarrolladores decidieron que la opci´on m´as razonable era reescribir desde el principio la mayor parte del c´odigo fuente, para hacer frente a estos problemas. Por ejemplo, para solucionar los problemas que se presentaban al soportar m´ultiples plataformas, se implementar´ıa una nueva biblioteca multiplataforma para interfaces de usuario, y un nuevo motor de renderizado, llamado Gecko, que destacaba por su peque˜no tama˜no y veloci- dad [Net98b].
Pero, en realidad, los desarrolladores de Mozilla ten´ıan en mente algo m´as que un simple navegador. Pretend´ıan crear una plataforma de aplicaciones de Internet, que incluyese un navegador, un cliente de mensajer´ıa instant´anea, un cliente de noticias y correo, etc., con una interfaz de usuario totalmente personalizable y una arquitectura modular. La tarea se vislumbraba tit´anica, y de hecho se necesit´omucho m´as tiempo del que se preve´ıa en un principio, lo que provoc´oescepticismo sobre el proyecto, algo l´ogico, dado que era evi- dente que no avanzaba a la velocidad prevista, dando a muchos la impresi´on de que se estaba quedando estancado.
Sin embargo, Mozilla lanz´ola versi´on 1.0 de su navegador en junio de 2002, un navegador que funcionaba en GNU/Linux, MacOS, Windows y Solaris, con muchas mejoras en comparaci´on con Internet Explorer, notablemente en seguridad, y en un fuerte apoyo a los est´andares del World Wide Web Consortium[Moz06]. A partir de abril del 2003, Mozilla decide que desarro- llar´ıa independientemente el navegador y el cliente de correo[Moz06]6. Este ´ultimo ser´ıa llamado inicialmente Minotaur, y posteriormente Thunderbird, y se tratar´ıa de un redise˜no del componente de correo de Mozilla, con el ob- jetivo de ofrecer un cliente de correo independiente, usando el lenguaje de definici´on de interfaces XUL[Moz03a], del que hablamos m´as adelante.
6El proyecto SeaMonkey sigui´odesarrollando la suite seg´un la filosof´ıa original de Nets- cape y Mozilla, en un solo programa que inclu´ıa navegador y cliente de correo 24 CAP´ITULO 1. INTRODUCCION´
Figura 1.1: Logo de Mozilla Thunderbird
En julio de ese mismo a˜no se crea la fundaci´on Mozilla, para asegurar la supervivencia del proyecto Mozilla, ya que AOL, los creadores de Netscape, redujeron dr´asticamente sus inversiones en Mozilla[Moz03b]. La Corporaci´on Mozilla anunci´oen julio de 2007 que Thunderbird ser´ıa desarrollado en el fu- turo por una organizaci´on independiente, ya que la Corporaci´on Mozilla (la parte “con ´animo de lucro” de la Fundaci´on Mozilla) pretend´ıa centrarse en el desarrollo del navegador, Firefox[IW07]. Seg´un algunos ([IW07]), tambi´en tuvo que ver que Thunderbird (al contrario que Firefox) estaba perdiendo el favor de muchos usuarios, que prefer´ıan usar correo web (Gmail, Hotmail) para cubrir sus necesidades. La falta de soporte para calendario al estilo de Evolution tampoco ayudaba demasiado a Thunderbird, a pesar de la dispo- nibilidad de extensiones como Lightning que cubren esta necesidad. As´ıpues, se decidi´ocrear una subsidiaria de la Fundaci´on Mozilla dedicada al correo electr´onico. El 17 de Septiembre del 2007, David Ascher, de ActiveState, se uni´oa Mozillla como parte de una iniciativa conjunta para ”estimular la innovaci´on en el correo y las comunicaciones en Internet”[Moz].
1.3.2. Caracter´ısticas de Mozilla Thunderbird
En esta secci´on echamos un vistazo a las caracter´ısticas m´as destacables de Mozilla Thunderbird en relaci´on con otros clientes de correo. Muchas de estas caracter´ısticas son compartidas por otros productos de la suite Mozilla, como el apoyo a los est´andares o el soporte multiplataforma, debido a que 1.3. THUNDERBIRD Y EL PROYECTO MOZILLA 25 las tecnolog´ıas usadas para los productos de esta suite, como el lenguaje de definici´on de interfaces XUL, son comunes. Hablaremos m´as a fondo de estas tecnolog´ıas en un cap´ıtulo posterior. Se puede encontrar m´as informaci´on sobre estas caracter´ısticas en la web de Mozilla (ver [Moz07b]).
Vista avanzada de carpetas. Existe una gran flexibilidad en cuando a la forma en la que se pueden visualizar las carpetas de correo: por favoritos, vistos recientemente, no le´ıdos, y mediante carpetas creadas por el usuario.
Filtrado de correo basura. Thunderbird incluye por defecto un filtro antispam basado en redes bayesianas, que aprende a medida que el usuario marca mensajes como spam o no. Tiene la posibilidad de man- dar el correo basura a una carpeta espec´ıfica, para que no se muestre en la bandeja de entrada. Recientemente ha incorporado un filtro anti- phishing7.
F´acil personalizaci´on, en cuando a skins (apariencia gr´afica). El usuario puede dise˜nar la apariencia gr´afica de Thunderbird, o instalarse skins producidos por otros usuarios.
Extensiones. La funcionalidad de Thunderbird se puede extender f´a- cilmente instalando extensiones, como la que desarrollamos para este proyecto. Las extensiones se distribuyen como m´odulos xpi, que se pue- den instalar desde el men´ude Thunderbird.
Soporte de est´andares: POP, IMAP, LDAP, HTML, XML, XHTML, CSS, JavaScript, DOM, MathML, DTD, XSL, XPath, o S/MIME son algunos de los est´andares soportados por Thunderbird (y la suite Mo- zilla en general).
Soporte multiplataforma. Mozilla Thunderbird est´adisponible para Windows, MacOS, y sistemas operativos basados en UNIX, como GNU/Linux
7El phishing es un intento de adquisici´onde informaci´on, como nombres de usuario, contrase˜nas, o n´umeros de tarjeta de cr´edito, haci´endose pasar por otra p´agina [DW05] 26 CAP´ITULO 1. INTRODUCCION´
o Solaris. En realidad se puede utilizar en casi cualquier sistema ope- rativo, ya que el c´odigo fuente est´adisponible y puede ser compilado en el sistema operativo que se elija. Los perfiles de usuario se guardan en un mismo formato para todos los sistemas operativos, con lo que si nos cambiamos de sistema operativo, o utilizamos varios sistemas operativos, podemos importar f´acilmente nuestro perfil.
Internacionalizaci´on y localizaci´on. Thunderbird est´adisponible en 36 idiomas (ver [Moz07a]), gracias a las contribuciones de traductores de todo el mundo.
Seguridad. Thunderbird soporta TLS, firma digital, o certificados digi- tales. En el desarrollo de Thunderbird se le ha dado gran importancia a la seguridad.
Una de las cosas que m´as se le critica a Thunderbird es que le falta funcionali- dad de calendario, como la que ofrece Microsoft Outlook, aunque el proyecto Lightning anunci´oque pretend´ıa integrar un calendario dentro de Thunder- bird, en forma de extensi´on [Moz07f]. La versi´on 0.7 ya est´adisponible para descarga. Cap´ıtulo2
Objetivos
En este cap´ıtulo detallamos con m´as exactitud lo que pretendemos con la realizaci´on de este proyecto. En la primera secci´on, Prop´osito de este proyecto se resume la finalidad del mismo, y a continuaci´on, en Objeti- vos daremos una lista de objetivos m´as detalladamente, especificando las caracter´ısticas que pretendemos que el producto final del proyecto posea.
2.1. Prop´osito de este proyecto
Implementaci´onde una extensi´onpara Mozilla Thunderbird que act´uecomo interfaz de un sistema de clasificaci´onde correo elec- tr´onico,que ya est´adisponible.
2.2. Objetivos
La extensi´on le debe asignar una categor´ıa a cada correo electr´onico que llega a Thunderbird.
El usuario debe ser capaz de modificar la categor´ıa asignada (usando la interfaz gr´afica).
Para ello, la extensi´on tiene que poder notificar al clasificador si el
27 28 CAP´ITULO 2. OBJETIVOS
usuario acepta o no la clasificaci´on, y en el ´ultimo caso, notificar la clasificaci´on propuesta por el usuario, para que el sistema aprenda de sus errores
La extensi´on debe ser dise˜nada de forma que se maximice su usabilidad [8], es decir, que sea f´acil de aprender y usar, eficiente, flexible, tal que prevenga y sea capaz de solucionar posibles errores del usuario.
Adem´as, debe ser f´acil de instalar por un usuario sin demasiados cono- cimientos de inform´atica.
Se pretende que sea compatible al menos con la versi´on 2.0 de Thun- derbird.
La implementaci´on se har´ausando los lenguajes, tecnolog´ıas y herra- mientas t´ıpicos de la suite Mozilla (XUL, JavaScript, XML, etc.)
Se crear´adocumentaci´on adecuada, tanto de cara al usuario (tutoriales o manuales), como la interna al proyecto (control, interfaces usadas, etc.)
Se pretende comparar nuestra soluci´on con otros enfoques a este pro- blema, y con productos similares.
El nombre que le daremos a nuestra extensi´on ser´a, como dijimos en el cap´ıtulo de introducci´on, Another Mail Classifier. En el siguiente cap´ıtu- lo hablaremos de los lenguajes y tecnolog´ıas, y otros aspectos t´ecnicos que nos servir´an para la implementaci´on de nuestra interfaz, intentando dar una visi´on general de ellos, pero centr´andonos de alguna manera en los aspectos m´as relacionados con la extensi´on que pretendemos construir. Cap´ıtulo3
Consideraciones t´ecnicas
Este cap´ıtulo est´adedicado a varios aspectos t´ecnicos relacionados con nuestra extensi´on. Empezaremos hablando de usabilidad, un concepto rela- cionado con la interfaz gr´afica de usuario, de la que se busca que sea lo m´as usable posible, es decir, que se f´acil de utilizar y realice su trabajo de forma simple, eficiente y efectiva. Posteriormente hablaremos de varios lenguajes y tecnolog´ıas usados por los lenguajes de la suite Mozilla, y de la arquitectura de los programas de esta suite, desde un punto de vista general.
3.1. Consideraciones sobre usabilidad
Nuestra enfoque respecto a la usabilidad se basa en las l´ıneas maestras descritas en el ISO1 13407 (Dise˜node aplicaciones interactivas orientado al usuario)[BC97], un proceso que incluye actividades de dise˜no centradas en el usuario a lo largo del ciclo de vida de las aplicaciones. El dise˜no centrado en el usuario es una actividad multidisciplinar, que precisa de conocimiento sobre ergonom´ıa y factores humanos, con el fin de mejorar la efectividad y pro- ductividad del software. Este proceso se basa en cuatro fases, de naturaleza
1ISO, International Standardization es un organismo internacional compuesto de representantes de varios organizaciones estandarizadoras internacionales, y promulga es- t´andares industriales y comerciales a nivel mundial
29 30 CAP´ITULO 3. CONSIDERACIONES TECNICAS´ iterativa:
An´alisis
Por an´alisis entendemos la comprensi´on y especificaci´on del contexto de uso. Si queremos conseguir un sistema con buena usabilidad debemos conocer las caracter´ısticas de los usuarios, y el entorno donde van a trabajar con nues- tro sistema. Tenemos que analizar las necesidades de los usuarios atendiendo a criterios de usabilidad, como los siguientes:
Eficiencia: El usuario consigue su tarea efectuando el m´ınimo n´umero posible de pasos.
Efectividad: El sistema debe ser capaz de completar correctamente las tareas que necesita el usuario
Satisfacci´on: Es algo subjetivo; el usuario considera que interacciona con el sistema de una forma agradable y satisfactoria.
Dise˜node las posibles soluciones
El dise˜no es una actividad compleja, que podemos dividir conceptualmen- te en tres subfases:
Dise˜node las actividades
Es la actividad que se encarga de dise˜nar las actividades b´asicas de nues- tro sistema, desde un punto de vista m´as cercano al software. En esta fase visualizamos c´omo podr´ıa resolver nuestras necesidades la herramienta que estamos construyendo. Una t´ecnica recurrente en esta fase es el uso de me- t´aforas de dise˜no, una forma de relacionar la estructura y funcionalidad de nuestra aplicaci´on con las de un sistema conocido.
Por ejemplo, si estamos dise˜nando un reproductor de m´usica sin idea de qu´e 3.1. CONSIDERACIONES SOBRE USABILIDAD 31 aspecto va a tener la interfaz, podemos utilizar como met´afora un reproduc- tor de CD f´ısico. As´ı, podemos decir cosas como ”para empezar a reproducir la canci´on hacemos como en el reproductor de CD, le damos al bot´on con un tri´angulo”, o ”para cambiar de disco tenemos un bot´on que es como el “ex- pulsar” de nuestro reproductor. Las analog´ıas pueden ser visuales (nuestro programa reproductor de CD’s tendr´ael aspecto de un iPod), funcionales (el funcionamiento de nuestra tienda on-line ser´acomo el de los supermercados: metemos art´ıculos en nuestro carrito virtual, y cuando hayamos terminado, pagamos) o estructurales (nuestro sitio web estar´aorganizado en forma de ´arbol). Gracias a las met´aforas, el usuario no se tiene que enfrentar desde cero a nuestra aplicaci´on, sino que utiliza su conocimiento sobre supermer- cados, reproductores de CD o estructuras de datos arb´oreas para orientarse por nuestra aplicaci´on.
Las met´aforas son algo fundamental de cara a la usabilidad; puede que nos pa- rezca normal que un programa reproductor de m´usica simule un reproductor de CD’s real, pero hay muchas formas diferentes de dise˜narlo, posiblemente no tan intuitivas para el usuario en cuanto al uso.
Dise˜node la informaci´on
. En esta subfase, el objetivo es dise˜nar de qu´eforma se va a represen- tar en la interfaz de usuario la informaci´on que maneja nuestra herramienta. ¿C´omo hacer que el usuario perciba que las funciones X e Y est´an relacio- nadas? ¿C´omo es mejor mostrar cierta funcionalidad, con un bot´on, en un men´u, etc.? Todo esto tiene bases s´olidas en la teor´ıa psicol´ogica conocida como Gestaltpsychologie.
Por ejemplo si tenemos 9 botones y los agrupamos en grupos de 3 (rodeando cada grupo por cajas o simplemente poniendo los botones de un grupo cerca los unos de los otros), el usuario se dar´acuenta inmediatamente de que las funciones est´an relacionadas. Si ponemos un checkbox justo al lado de una 32 CAP´ITULO 3. CONSIDERACIONES TECNICAS´
Figura 3.1: Captura del buscador Google, donde se aprecia el uso de la Ley de la Cercan´ıa etiqueta, el usuario percibir´aque est´an ´ıntimamente relacionados. Esto est´a de acuerdo con la intuici´on de los usuarios; si alguien ve en una p´agina web la descripci´on del art´ıculo, y justo al lado un bot´on“Comprar”, no hace falta de- cirle al usuario que los botones ”Comprar” se refieren al art´ıculo m´as cercano. La Gestaltpsychologie trata de capturar y formalizar los principios que rigen la percepci´on y la intuici´on, y tienen importantes implicaciones en el dise- ˜no de interfaces (entre otras cosas), aunque sean aplicados inconscientemente.
Aunque no es este el lugar adecuado para hablar con demasiada profun- didad de la Gestaltpsychologie, s´ıque hablaremos de los resultados pr´acticos de ´esta, en forma de leyes, en tanto en cuanto tienen implicaciones para el dise˜no de interfaces.
La Ley de la Cercan´ıa consiste en que los objetos que est´an cercanos unos a otros son percibidos como relacionados entre s´ı. Podemos ver en la figura 3.1 como los servicios que ofrece Google (b´usqueda de im´agenes, mapas, noticias, etc.) se sit´uan muy cerca unos de otros, de forma que el usuario los percibe como un todo (conjunto de servicios ofrecidos). Otra ley es la conocida como Ley de la Semejanza: los objetos que muestran parecido entre s´ı, o que tienen caracter´ısticas en com´un, se perciben como l´ogicamente relacionados. En la p´agina de noticias de la BBC (figura 3.2) podemos ver un ejemplo de c´omo se utiliza este principio. Se ve que se clasifican los titulares seg´un su importan- cia dot´andolos, de una tipograf´ıa diferente en cada caso; los titulares con el mismo tama˜no de letra son percibidos como de similar relevancia, y los que tienen mayor tama˜no se agrupan como el conjunto de titulares principales.
Por su parte, la Ley de la Clausura afirma que los objetos que est´an ence- 3.1. CONSIDERACIONES SOBRE USABILIDAD 33
Figura 3.2: Captura del portal de noticias BBC, para ilustrar la Ley de la Semejanza rrados por un delimitador se perciben como relacionados entre s´ı. En la Wi- kipedia encontramos un ejemplo de uso de este principio (figura 3.3); vemos como los v´ınculos de navegaci´on se encierran en un cuadrado delimitado por una l´ınea continua, al igual que los de interacci´on. As´ıse consiguen crear ca- tegor´ıas l´ogicas. Por ´ultimo, mencionamos la Ley de la Figura y el Fondo, la cual afirma que se tiende a percibir un elemento como la “figura principal”, y el resto como el ”fondo”. Por ejemplo, podemos ver el dise˜no de Amazon.com (figura 3.4).
En cualquier dise˜no de interfaz podemos encontrar ejemplos de estos princi- pios combinados entre s´ıpara lograr el objetivo de estructurar la informaci´on. Otro ejemplo, en la figura 3.5, donde podemos observar c´omo las diferentes secciones l´ogicas (Summary, Licensing) se encierran en cuadrados, y adem´as tienen un dise˜no parecido (misma tipograf´ıa en el t´ıtulo, separador gris deba- jo de este, contenido encerrado en un cuadrado. En el cuadrado de Licensing, vemos como los v´ınculos a otros idiomas tienen la misma tipograf´ıa todos ellos (letra peque˜na, azul y subrayada), y adem´as est´an muy cerca unos de otros, de forma que el usuario descubre de un vistazo que todos los v´ınculos 34 CAP´ITULO 3. CONSIDERACIONES TECNICAS´
Figura 3.3: Panel principal de la Wikipedia, claro ejemplo de la Ley de Clau- sura
Figura 3.4: P´agina principal de Amazon.com, para ilustrar la Ley de la Figura y el Fondo 3.1. CONSIDERACIONES SOBRE USABILIDAD 35
Figura 3.5: Parte inferior de una p´agina de la Wikipedia, donde se observa el uso combinado de varias leyes tienen una funci´on parecida.
Dise˜node la interacci´on
. En esta subfase se decide c´omo acceder a la informaci´on, c´omo manipu- larla, c´omo conseguir que los usuarios sepan f´acilmente qu´etienen que hacer, y que lo hagan en el momento correcto. Esto es algo complejo; el usuario debe saber lo que quiere conseguir, cu´al es su objetivo. Despu´esdebe encontrar en nuestra interfaz herramientas que le hagan posible conseguir su objetivo, y debe ser capaz de utilizar estas herramientas sin complicaciones. La interac- ci´on se debe dise˜nar de forma que sea automatizable; un ejemplo de esto es las funciones cortar, copiar, pegar de los editores de texto, que suelen tener aso- ciado siempre la misma combinaci´on de teclas. Cuando una aplicaci´on tiene una combinaci´on de teclas diferente2, esto supone una carga extra de apren- dizaje para el usuario. A la vez, hay que tener cuidado de que las acciones que tiene automatizado el usuario, y que hace sin pensar (como pulsar OK en los di´alogos) no sean peligrosas (por ejemplo, si se va a borrar un archivo importante como consecuencia de una acci´on del usuario, quiz´as un simple
2El caso de Emacs es notorio en este sentido 36 CAP´ITULO 3. CONSIDERACIONES TECNICAS´ di´alogo “Aceptar”/”Cancelar” no sea suficiente). Tambi´enhay est´andares ISO para el dise˜no de di´alogos en sistemas interactivos (ISO 9241-10), y para la representaci´on de informaci´on (ISO 9241-12). El ISO 9241-10 contiene estos 7 principios fundamentales para el dise˜no de la interacci´on con el usuario:
Adecuaci´on a la tarea a realizar
Capacidad de autodescripci´on
Conformidad a lo esperado
Tolerancia a errores
Capacidad de ser controlado
Capacidad de ser individualizable
Fomento del aprendizaje
Implementaci´on de las soluciones y testeo de las soluciones
Una vez construida la soluci´on, es preciso testearla en cuanto a usabilidad. Para esto se realizan los llamados tests de usabilidad. Existen muchas aproximaciones posibles; la que nosotros vamos a usar en nuestro trabajo es la llamada evaluaci´on heur´ıstica, es decir, se comprueba si la interfaz di- se˜nada cumple unas ciertas condiciones de usabilidad. Un conocido conjunto de heur´ısticas es el propuesto por Molich y Nielsen Improving a human- computer Dialogue[MN90]. Este trabajo describe diez principios generales para el dise˜no de interfaces, concretamente los siguientes:
Visibilidad del estado del sistema. El sistema deber´ıa mantener infor- mado al usuario de lo que est´apasando. 3.1. CONSIDERACIONES SOBRE USABILIDAD 37
Correspondencia entre el sistema y el mundo real. El sistema debe hablar el lenguaje del usuario, con frases y conceptos que le sean fami- liares.
Control y libertad del usuario. A veces, los usuarios seleccionan una funcionalidad del programa por error (por ejemplo, d´andole al bot´on del al lado del que quer´ıan), y necesitan una “salida de emergencia”. Esto normalmente se consigue incluyendo una funcionalidad tipo ”Des- hacer/Rehacer”.
Consistencia y est´andares. El usuario no deber´ıa preguntarse si dife- rentes palabras, situaciones o acciones de la interfaz se refieren a lo mismo. Es bueno seguir las convenciones de la plataforma para la que se desarrolla.
Prevenci´on de los errores. Eliminar situaciones propensas a error; cuan- do el usuario vaya a hacer algo potencialmente peligroso (como borrar un fichero), el sistema deber´ıa asegurarse de que el usuario quiere hacer eso realmente.
Reconocimiento mejor que memoria. Minimizar la carga de memoria del usuario haciendo visibles los objetos, las acciones y las opciones del sistema. Para realizar una tarea, el usuario no deber´ıa tener que recordar informaci´on del panel anterior, sino que debe tener toda la informaci´on que necesita a la vista, o al menos en un lugar al que sea r´apido y f´acil acceder.
Flexibilidad y eficiencia de uso. Permitir que el usuario pueda realizar su tarea de varias formas diferentes, para que pueda elegir la que prefiera. Por ejemplo, los usuarios experimentados posiblemente trabajar´an m´as r´apido con cortocircuitos de teclado que con clicks de rat´on; es m´as r´apido y eficiente pulsar Ctrol-C y Ctrol-V que tener que ir al men´uy elegir las opciones. 38 CAP´ITULO 3. CONSIDERACIONES TECNICAS´
Dise˜no minimalista y est´etico. Los di´alogos del sistema no deber´ıan contener informaci´on irrelevante.
Ayudar al usuario a reconocer, diagnosticar y recuperarse de los erro- res. Los mensajes de error deber´ıan estar en un lenguaje familiar al usuario (por ejemplo, es mejor “Atenci´on: no se pudo escribir en el do- cumento porque se necesitan permisos de root” que ”Error 0A417 en el m´odulo docs.Perxx01”). Tambi´enes buena idea que los mensajes de error sugieran soluciones posibles.
Ayuda y documentaci´on. Lo ideal es que la interfaz sea lo m´as autoex- plicativa posible. Sin embargo, puede ser necesario incluir ayuda extra en la interfaz, en un men´uAyuda, por ejemplo. Esta ayuda tiene que ser f´acil de navegar, centrada en las necesidades del usuario, diciendo exactamente los pasos que tiene que seguir el usuario, y no ser dema- siado extensa, ya que eso har´ıa que muchos usuarios ni se plantearan mirarse la ayuda.
Puede parecer desproporcionado justificar el dise˜no de un men´utan simple de una forma tan detallada, recurriendo incluso a escuelas psicol´ogicas, librer´ıas de patrones de dise˜no, o heur´ısticas de dise˜no, cuando cualquiera llegar´ıa a un dise˜no parecido del men´usin haber o´ıdo hablar de estos conceptos. Pero es que cuando se dise˜na una interfaz, nadie empieza desde cero, sino que se gu´ıa en gran parte por su experiencia e intuici´on. Y la experiencia y la intuici´on es son algo formalizable en gran medida: los patrones de dise˜no de interfaces recogen decisiones de dise˜no que, seg´un ha demostrado la experiencia, son positivas para la usabilidad, y la Gestaltpsychologie estudia los mecanismos por los que la mente humana lee informaci´on “entre l´ıneas” cuando contempla una interfaz (qu´eelementos est´an relacionados entre s´ı, etc.). 3.2. DESARROLLO PARA LA SUITE MOZILLA 39
3.2. Desarrollo para la suite Mozilla
3.2.1. Arquitectura de la suite Mozilla. XPCOM
”La catedral y el bazar” [Ray01] es un ensayo publicado por Eric S. Ray- mond en 1997, en el que habla de su experiencia en la direcci´on de proyectos de software libre. En este ensayo se ponen en contraste dos modelos diferentes de desarrollo de software libre:
Por un lado, est´ael modelo de la “catedral”. En este modelo, el c´odigo fuente est´adisponible para cada lanzamiento (release) del producto, pero el c´odigo que se produce entre lanzamientos no se hace disponible.
Por otro lado, est´ael modelo del“bazar”, en el que el c´odigo se desarrolla en Internet, a la vista del p´ublico, por lo que siempre est´adisponible.
La tesis principal del art´ıculo afirma que “con el n´umero suficiente de ojos, todos los bugs son superficiales”, es decir, mientras m´as disponible est´eel c´odigo fuente para testeo, y experimentaci´on, m´as temprano se descubrir´an bugs. Es decir, aboga por el modelo del ”bazar”, ya que en el modelo de la ”catedral”, como el c´odigo fuente s´olo est´adisponible para unos pocos, se desperdicia m´as energ´ıa buscando y solucionando bugs. Pues esta es precisa- mente la filosof´ıa del proyecto Mozilla: el c´odigo de las aplicaciones de esta suite est´asiempre disponible y a la vista de todo el mundo, siendo la Funda- ci´on Mozilla la encargada de integrar el c´odigo.
Uno de los objetivos de la suite es la unidad de interfaz, es decir, intere- sa m´as los conceptos que la implementaci´on de los mismos. Para entender esto, fij´emonos en el correo electr´onico y las listas de noticias. Aunque se trata de dos cosas distintas, el usuario los percibe como algo similar, y de he- cho en Mozilla Thunderbird se tratan de la misma forma de cara al usuario. Es lo mismo que sucede con las descargas: el usuario percibe lo mismo (un archivo descarg´andose), ya se realice la descarga por FTP o por HTTP. Las aplicaciones Mozilla buscan abstraer lo que tienen en com´un las operaciones, 40 CAP´ITULO 3. CONSIDERACIONES TECNICAS´ y dejar los detalles de implementaci´on que las diferencian en segundo plano. As´ıpues, se busca una reutilizaci´on de las interfaces, y reaprovechar cada interfaz (por ejemplo, descargar un fichero) implementando varios protocolos concretos que la realicen (HTTP, FTP, etc.).
La mayor parte del c´odigo fuente de Mozilla utiliza C++ (compilado) y JavaScript (interpretado). Al iniciar cualquier aplicaci´on Mozilla, se inicia- lizan primero los componentes escritos en C++, pero despu´esse inicializa una tecnolog´ıa llamada XPConnect que permite que JavaScript sea capaz de comunicarse y utilizar los componentes en C++ en tiempo de ejecuci´on. Por supuesto, el c´odigo JavaScript de las p´aginas Web, por ejemplo, no es capaz de comunicarse con los elementos internos de Mozilla, ya que ello supondr´ıa un riesgo a la seguridad notable. En general, la parte del c´odigo escrita en JavaScript es la responsable de los eventos de la interfaz de usuario.
El c´odigo fuente de Mozilla est´aorganizado en varios componentes, para modularizarlo. Esto significa que s´olo se puede acceder a los datos internos de estos a trav´esde las interfaces p´ublicas. Estamos en un entorno de desa- rrollo centrado en componentes. Aqu´ı, la piezas claves son, como el nombre indica, los componentes, que tienen mucho en com´un con el concepto de clases en la programaci´on orientada a objetos, s´olo que los componentes son m´as independientes entre s´ı, ya que s´olo pueden comunicarse entre s´ıpor medio de sus interfaces; un componente puede implementar varias interfaces.
XPCOM
La plataforma que usa Mozilla para desarrollo basado en componentes, al estilo de CORBA, se llama XPCOM; este es la implementaci´on de Mozilla de COM (Components Object Model). El desarrollo basado en componen- tes busca descomponer los sistemas software en componentes l´ogicos con interfaces bien definidas, que posibilitan la interacci´on entre ellos. Esto re- presenta una visi´on m´as abstracta que la del desarrollo orientado a objetos. 3.2. DESARROLLO PARA LA SUITE MOZILLA 41
Un componente deber´ıa ser totalmente reutilizable de forma independiente del contexto. Se trata de ver el concepto de componente de forma an´aloga a las piezas mec´anicas; al igual que el mismo martillo se deber´ıa poder usar para clavar un clavo como para romper una hucha, un componente se deber´ıa poder usar en contextos muy diferentes entre s´ıe imprevisibles. Por ejemplo, un componente manejador de ficheros, con funciones para crear fichero, a˜na- dir car´acter al mismo, etc, podr´ıa ser usado para escribir los logs de eventos de un programa cualquiera o para construir un editor de texto y guardar los archivos; no se puede prever con antelaci´on. Por otra parte, los componentes software deben ser combinables entre s´ı. Al igual que se puede hacer una bicicleta uniendo ruedas, barras de metal, etc, se deber´ıa poder combinar componentes para hacer componentes nuevos.
XPCOM es una plataforma que permite la implementaci´on de componen- tes para que puedan ser usados desde las aplicaciones Mozilla (y tambi´en independientemente). XPCOM est´adisponible para m´ultiples plataformas, como Windows, GNU/Linux o MacOS. Mozilla incluye una gran cantidad de componentes, por ejemplo, para manipular ficheros o conectarnos a un ser- vidor remoto. Podemos acceder a estos componentes desde la extensi´on que estamos haciendo para Thunderbird, desde el c´odigo JavaScript (siempre que las interfaces que usemos para acceder a los componentes est´edefinida como scriptable).
3.2.2. XUL
XUL es un lenguaje basado en XML desarrollado por Mozilla para defi- nici´on de interfaces, que permite la construcci´on de aplicaciones altamente personalizables y multiplataforma [Boj07]. Es similar a DHTML, pero diri- gido a aplicaciones, no a p´aginas web. XUL est´abasado en varios est´andares del W3C 3, como XML, HTML, CSS, DOM, o JavaScript. Adem´as, XUL
3World Wide Web Consortium, la principal organizaci´oninternacional que produce est´andares para la World Wide Web 42 CAP´ITULO 3. CONSIDERACIONES TECNICAS´ facilita la separaci´on de la l´ogica de aplicaci´on (XUL y JavaScript), la pre- sentaci´on (CSS e im´agenes) y el idioma (contenido en las cadenas de texto de los “locales”, los archivos de localizaci´on).
La motivaci´on de usar este lenguaje para definir interfaces de usuario estriba en que Mozilla es multiplataforma y multiaplicaci´on: se necesita un lenguaje que sea independiente de la plataforma y de la aplicaci´on. El lenguaje XUL cumple con estos requisitos, al representar la interfaz de usuario de forma l´ogica, al estilo de HTML. Otra ventaja que tiene este lenguaje es que se tiene mucho control sobre la apariencia de las interfaces, al permitirnos el uso de hojas de estilo CSS.
Aqu´ıpodemos ver un esqueleto de fichero XUL:
title, el texto que aparecer´aen la barra de t´ıtulos de la ventana
orient, describe la orientaci´on de los elementos en la ventana, es decir, si se a˜nadir´an de izquierda a derecha o de arriba a abajo.
xmlns, describe el namespace para los elementos de XUL. Aunque apa- rece una URL, no se descarga nada de ella, sino que Mozilla la reconoce internamente.
Dentro de la window se pueden incluir elementos diversos, como botones, eti- quetas, men´us, etc.
A los elementos se le pueden asociar eventos, que disparan acciones. Por ejemplo, la siguiente l´ınea:
declara un bot´on, con el texto OK, que al ser pulsado hace que aparezca el texto “Has pulsado OK” en una ventana. Las acciones ser´an normalmente funciones de JavaScript declaradas en un fichero externo.
Una de las caracter´ısticas m´as interesantes de XUL de cara a construir ex- tensiones para una aplicaci´on existente (en nuestro caso, Thunderbird), es la posibilidad de usar overlays, un mecanismo para extender una interfaz de usuario ya existente a˜nadi´endole nuevos elementos, como nuevos men´us y botones, con su funcionalidad4. Esto es precisamente lo que haremos para construir nuestra extensi´on.
3.2.3. JavaScript
Las interfaces XUL est´an controladas por JavaScript, un lenguaje de scrip- ting conocido sobre todo por su uso en aplicaciones web (en la parte del
4Tambi´ense pueden usar overlays para sustituir partes de la interfaz, no s´olo para a˜nadir nuevos elementos 44 CAP´ITULO 3. CONSIDERACIONES TECNICAS´ cliente). JavaScript, a pesar de su nombre, no tiene nada que ver con Java, aunque la sintaxis es similar. Se trata de un lenguaje interpretado, de tipado din´amico (los tipos no est´an asociados a las variables sino a los valores), y que permite usar varias caracter´ısticas de la programaci´on orientada a obje- tos, como veremos cuando hablemos de la librer´ıa prototype. La historia de JavaScript est´amuy ligada a Mozilla, ya que este lenguaje fue desarrollado originalmente por Brendan Eich, de Netscape.
3.2.4. Internacionalizaci´ony localizaci´on
Otro de los objetivos de Mozilla es separar el c´odigo del lenguaje humano. Si se usa una cadena de texto para mostrar al usuario, no se deber´ıa incluir directamente en el c´odigo fuente. La alternativa es referirse en este a un identificador (pongamos por ejemplo helloLabel), y guardar el valor de este identificador en un fichero independiente5. Una ventaja inmediata de esto es que podemos tener un fichero para cada idioma, haciendo que nuestra aplicaci´on est´edisponible en varios de ellos, sin tener que modificar el c´odigo fuente. Si alguien quiere que una aplicaci´on Mozilla est´edisponible para su idioma, no tiene m´as que crear los ficheros de cadenas correspondientes. La aplicaci´on Mozilla, al iniciarse, detectar´acu´al es el idioma adecuado.
3.2.5. Gecko
Gecko es el nombre del motor de renderizado de Mozilla. Es un compo- nente vital de Mozilla, ya que contiene los analizadores de HTML, XML y CSS, y la implementaci´on de DOM. Es extremadamente vers´atil y veloz, y por esto es tambi´enusado para renderizar XUL. En otras palabras, cuando vemos la interfaz gr´afica de una aplicaci´on Mozilla como Thunderbird, sus elementos gr´aficos, como men´us, barras, paneles, etc. son renderizados por Gecko6. 5Estos ficheros tienen la extensi´on dtd 6Este conjunto de elementos de la interfaz gr´afica de las aplicaciones es conocido como chrome 3.2. DESARROLLO PARA LA SUITE MOZILLA 45
Un motor de renderizado tiene como objetivo primordial aceptar conteni- do como HTML, XML, im´agenes, applets de Java, hojas de estilo CSS, y representar ese contenido en la ventana del navegador, especificando una po- l´ıtica de posicionamiento de los elementos en la p´agina. Gecko es capaz de renderizar varios tipos de documentos, como HTML, XML, o SVG, aparte de los elementos de la interfaz gr´afica de las aplicaciones Mozilla (barras de desplazamiento, men´us, etc.).
3.2.6. Chrome
En las aplicaciones de la suite Mozilla, se conoce por chrome al conjun- to de elementos de la ventana de la aplicaci´on que est´an fuera del ´area de contenido[Dev00]. Es decir, en en caso de Mozilla, todo lo que ve el usuario excepto el contenido de los e-mails, esto es, botones, men´us, etc, y tambi´en las cadenas de localizaci´on para los distintos idiomas. En el caso de Firefox, el chrome ser´ıa todo lo que ve el usuario, excepto la p´agina web que tiene abierta en ese momento. En el lenguaje de Mozilla se habla de proveedores de chrome, que son los que de alguna forma proporcionan elementos visuales a las aplicaciones. Hay tres tipos de proveedores:
Content (proveedores de contenido), normalmente un fichero XUL. Es- tos proveedores proporcionan elementos como botones, di´alogos, men´us. Los ficheros JavaScript que le a˜naden funcionalidad a estos elementos tambi´enpertenecen a esta categor´ıa.
Locale (proveedores de localizaci´on), normalmente ficheros dtd que contienen todas las cadenas de texto para la aplicaci´on en un idioma determinado. Al utilizar ficheros de localizaci´on, podemos tener la apli- caci´on en varios idiomas sin modificar el c´odigo fuente.
Skin, normalmente im´agenes y ficheros css. Estos proveedores de chrome proporcionan im´agenes (por ejemplo, el conjunto de iconos de la aplica- 46 CAP´ITULO 3. CONSIDERACIONES TECNICAS´
ci´on), y estilo visual (tipos de letra, colores dependiendo del contexto, etc.)
El motor de renderizaci´on Gecko mantiene un servicio conocido como el re- gistro chrome, el cual relaciona la direcci´on virtual de los paquetes chrome con su localizaci´on f´ısica, ya que las aplicaciones Mozilla no acceden a sus ele- mentos mediante rutas de ficheros del sistema operativo, sino con direcciones virtuales de Mozilla (las rutas chrome). As´ı, para Mozilla, la interfaz de Thun- derbird siempre estar´aen chrome://messenger/content/messenger.xul, independientemente de en qu´elocalizaci´on f´ısica se encuentre realmente el fichero messenger.xul; de esto se encarga el registro. Para informar a este servicio de un nuevo proveedor de chrome, se utiliza chrome.manifest,un fichero de texto que contiene una l´ınea por cada proveedor que queramos registrar7. Cada una de estas l´ıneas contiene tres elementos:
El tipo de proveedor del que se trata (content, locale o skin).
El nombre del paquete
La direcci´on f´ısica de los ficheros del proveedor (de los ficheros XUL, de los ficheros de localizaci´on o de los ficheros de skin/im´agenes)
En el caso de que registremos un proveedor de localizaci´on, se necesita otro elemento m´as, el idioma del que se trata (es-ES para espa˜nol, en-US para ingl´esamericano, etc.). Si, para un mismo paquete, registramos m´as de un idioma, el registro seleccionar´ael m´as adecuado teniendo en cuenta las pre- ferencias del usuario.
Tambi´enes posible registrar overlays como proveedores. Un overlay no es m´as que una extensi´on a una interfaz gr´afica ya existente, por ejemplo, un
7Existe una extensi´on para Firefox, que se puede descargar de https://addons.mozilla.org/es-ES/firefox/addon/4453, que muestra todos los paque- tes chrome registrados. Por desgracia, para Thunderbird no disponemos a fecha de hoy de una extensi´onsimilar 3.2. DESARROLLO PARA LA SUITE MOZILLA 47 nuevo men´upara Mozilla Thunderbird. Esto se hace con la palabra clave overlay seguida de la ruta chrome nombre del elemento que queremos ex- tender, en el caso de la interfaz de Mozilla Thunderbird:
chrome://messenger/content/messenger.xul, y la ruta chrome del elemento con el cu´al extendemos al anterior.
3.2.7. RDF
RDF, Resource Description Manager, es un modelo basado en grafos para describir recursos de Internet, como p´aginas o mensajes de correo electr´oni- co. Este modelo es un est´andar del World Wide Web Consortium para la Web Sem´antica, que se basa en tripletas sujeto-predicado-objeto8 (el sujeto se relaciona con el objeto por medio del predicado). El sujeto de esta tripleta representa a un recurso9, que puede tratarse de informaci´on accesible direc- tamente a trav´esde internet, como puede ser una p´agina web, o puede ser tambi´enun concepto abstracto. En resumen, tenemos un grafo de recursos relacionados entre s´ı; para que este grafo sea comprensible para un ordena- dor, y para que pueda extraer informaci´on procesable de ´el, tiene que estar representado de una forma comprensible para la m´aquina, concretamente en XML10.
8El modelo de tripletas, y el grafo etiquetado y dirigido resultante de la uni´onde las tripletas se ajusta naturalmente a la representaci´onde ontolog´ıas, y sobre RDF se han construido lenguajes importantes para representaci´onde ontolog´ıas, como OWL o RDFS. Pero Mozilla no lleva tan lejos su uso, sino que simplemente utiliza RDF para representar internamente cualquier recurso de Internet, ya sea una web, un correo electr´onico o un marcador 9Cada uno de estos recursos, as´ıcomo los predicados, est´anidentificados por un URI (Uniform Resource Identifier); RDF no especifica la sem´antica de estos URIs 10Existen representaciones no XML para RDF, como la notaci´on Notation3, que busca ser m´asf´acil de comprender para un humano que XML; los ficheros XML que representan recursos RDF tienen un aspecto bastante temible para el humano t´ıpico 48 CAP´ITULO 3. CONSIDERACIONES TECNICAS´
Mozilla usa extensivamente este est´andar; por ejemplo, cada marcador de Firefox es uno de estos recursos, y puede estar relacionado a su vez con otro recurso, como una p´agina web o un correo, contenido web din´amico o incluso con otro marcador: el grafo representado en RDF permite construir un ser- vicio de marcadores personalizable, a˜nadiendo relaciones con otros recursos. Un ejemplo pr´actico de esto ser´ıa hacer un marcador para una carpeta de nuestra cuenta de correo; se podr´ıa hacer b´asicamente un marcador a cual- quier recurso.
De modo que RDF nos permite almacenar objetos y relaciones entre ellos; necesitamos tambi´enun mecanismo para hacer consulta a esta base de datos de conocimiento para extraer informaci´on. Este mecanismo es el elemento de XUL. Para entender c´omo funcionan, hagamos una analog´ıa con los lenguajes de consulta a bases de datos relacionales y su uso en apli- caciones web. Imaginemos que tenemos una tabla de una base de datos que queremos usar para llenar una lista desplegable (elemento HTML) de nues- tra aplicaci´on; el lenguaje de desarrollo que utilicemos nos dar´aherramientas para definir de qu´eforma los resultados de la consulta a la base de datos se utilizar´an para llenar la lista. Este es precisamente el papel de las template: definir de qu´emanera el conocimiento extra´ıdo del grafo RDF es usado en la aplicaci´on (por ejemplo, para llenar la lista de marcadores de Firefox, o la lista de correos de Thunderbird.
3.2.8. Seguridad
La seguridad es, como es de esperar, un componente vital del proyecto Mozilla, y de Thunderbird en particular. El “Santo Grial” de la seguridad es, para Mozilla, evitar que un atacante sea capaz de ejecutar c´odigo arbitra- rio en el ordenador del usuario[Moz07e], ya que entonces podr´ıa leer datos del usuario, sobreescribirlos, borrarlos, y usar la m´aquina de la v´ıctima como 3.2. DESARROLLO PARA LA SUITE MOZILLA 49 punto de partida de otros ataques. Otro peligro estriba en que se revelen datos privados del usuario, como contrase˜nas. Esto es especialmente peligroso en el caso del phishing, que consiste en que un atacante se haga pasar por el banco para pedirle la contrase˜na u otros datos al usuario. Esto ata˜ne especialmente a Thunderbird, ya que es una t´ecnica com´un enviar e-mails que simulan ser enviados por el banco del usuario para preguntar por datos confidenciales. Otro tipo de ataques, si bien menos da˜ninos, son los basados en denegaci´on de servicio (DoS, Denial of Service), basados en consumir recursos hasta de- jar la m´aquina de la v´ıctima inusable (abriendo ventanas del navegador en un bucle infinito, o saturando la bandeja de entrada de Thunderbird de e-mails).
El proyecto Mozilla, por su naturaleza, presenta desaf´ıos particulares en cuan- do a seguridad. El c´odigo fuente est´aen todo momento a la vista de todo aquel que lo quiera examinar. Aunque se podr´ıa pensar que esto deja al descubierto las vulnerabilidades de las aplicaciones y hace m´as f´acil que alguien descu- bra un agujero de seguridad para atacar, lo cierto es que toda la comunidad de desarrolladores est´apendiente continuamente de estos posibles agujeros, para solucionarlos inmediatamente. Un gran problema que tiene Mozilla es que se trata de un proyecto extremadamente complejo, y la complejidad es la enemiga de la seguridad[Moz07e]. Por eso, cada m´odulo tiene que ser dise- ˜nado con cuidado, de forma que funcione correctamente aunque otro m´odulo le pase datos incorrectos. Mozilla propone algunas soluciones para aumentar su seguridad:
La regla de oro: no confiar absolutamente en ninguna fuente de datos. Da igual que leamos datos de la red, de ficheros internos, de variables de entorno o de argumentos de funciones, hay que comprobar que est´an en el formato que esperamos. Mozilla recomienda no asumir en ning´un caso que los datos que se le pasan a las funciones, o que se leen de flujos externos de datos, son correctos, sino comprobar esta correcci´on 50 CAP´ITULO 3. CONSIDERACIONES TECNICAS´
expl´ıcitamente.
Tener cuidado con el c´odigo JavaScript; los scripts dentro de las p´aginas webs no son peligrosos, porque son ejecutados dentro de una sandbox, que limita los recursos del ordenador a los que puede acceder este c´odigo (por ejemplo, los scripts de las webs no pueden acceder a componentes XPCOM de Mozilla ni a ficheros de usuario). Los que s´ıque representan un peligro son los que se utilizan para crear elementos de la interfaz de usuario; pensemos por ejemplo en los marcadores din´amicos de Firefox: el contenido de una p´agina web es usado para crear un men´udentro del navegador. Esto es potencialmente peligroso, ya que desde la interfaz de usuario s´ıque hay acceso a los componentes XPCOM y los ficheros.
Evitar usar ciertas funciones: eval(), por si acaso recibe como coman- do c´odigo malicioso. Tambi´ense recomienda usar ToString(object) mejor que object.toString(), por si alguien ha redefinido la funci´on toString de forma maliciosa.
En C++, prevenir los desbordamientos de buffer, renunciando a fun- ciones como strcpy, a las que se les podr´ıa pasar cadenas que desbor- daran el buffer conteniendo c´odigo maligno. Otras funciones peligrosas son gets y sprintf.
Adem´as de estas recomendaciones, Mozilla tambi´entiene una serie de pol´ı- ticas relacionadas con la seguridad. Una de ellas es la pol´ıtica del mismo origen, que establece que un documento, o script cargado desde un origen no puede leer o escribir propiedades de un documento con un origen diferente; dos documentos se considera que tienen el mismo origen si y s´olo si coinciden el host y el puerto en los dos. Para ver una lista de pol´ıticas de seguridad de Mozilla, visitar: http://www.mozilla.org/projects/security/components/[Moz07e]. Cap´ıtulo4
An´alisis y dise˜no
En el cap´ıtulo anterior, repasamos las tecnolog´ıas que vamos a usar en el desarrollo de nuestra extensi´on, Another Mail Classifier. A partir de este cap´ıtulo nos centraremos en la construcci´on en s´ıde esta herramienta, y veremos como se han utilizado en la pr´actica las tecnolog´ıas de las que hemos hablado.
Lo primero de lo que nos vamos a ocupar es del dise˜no de la funcionali- dad de la aplicaci´on, mostrando el an´alisis, de la mano de diagramas UML, de la funcionalidad requerida para la extensi´on, sin entrar en detalles de im- plementaci´on, tanto desde el punto de vista de la estructura de la que la dotaremos, como tambi´ende su comportamiento din´amico; para ello mostra- remos distintos diagramas UML que ilustren nuestras decisiones.
Posteriormente, veremos c´omo podemos plasmar este an´alisis preliminar en un dise˜no para la interfaz, ayud´andonos de otras herramientas similares que implementan de una u otra forma la misma funcionalidad, analizando sus ventajas y evitando sus fallos de dise˜no.
51 52 CAP´ITULO 4. ANALISIS´ Y DISENO˜
4.1. An´alisis preliminar: Diagramas
Empecemos, pues, con los diagramas: mostraremos primero los casos de uso, para tener una visi´on global de la funcionalidad. Despu´esveremos una posible descomposici´on de la aplicaci´on en m´odulos, de la mano de un dia- grama de clases. Y para terminar haremos un estudio del comportamiento din´amico mediante un diagrama de m´aquina de estados, as´ıcomo mediante diagramas de secuencia con m´as detalle.
4.1.1. Casos de uso
En esta secci´on mostramos los casos de uso de nuestra extensi´on, para dar una idea m´as clara de cu´ales son sus funcionalidades, bas´andonos en el siguiente diagrama:
Podemos observar dos actores, Servidor de correo y Usuario, ya que nuestra aplicaci´on responde por una parte a eventos ajenos al usuario (llega un correo al servidor), y por otra parte a eventos provocados por el usuario, (clasificar un e-mail ya disponible en la bandeja de entrada). 4.1. ANALISIS´ PRELIMINAR: DIAGRAMAS 53
Veamos en primer lugar el actor Servidor de correo. Cuando llega un correo al servidor (y se le notifica esta llegada a Thunderbird), si el usuario ha configurado la aplicaci´on para que se clasifiquen los e-mail autom´aticamente a la llegada, se har´aprecisamente ´esto, lo cual incluye naturalmente el caso de uso Clasificar correo. Por su parte, el actor Usuario, que representa al usuario humano que est´ausando la extensi´on en Thunderbird puede realizar dos acciones: pedirle al clasificador que realice una tarea sobre alg´un e-mail (o un grupo de estos), o bien ver el resultado de esta acci´on (una clasificaci´on). Hay tres tipos de tareas que se le pueden pedir a Genusmail:
Petici´on de clasificaci´on, es decir, el usuario selecciona un grupo de e-mails y le pide al clasificador que los clasifique.
Entrenamiento, esto es, el usuario entrena Genusmail con los e-mails ya disponibles en su cuenta.
Reaccionar a clasificaci´on, bien acept´andola, o bien rechaz´andola. En este ´ultimo caso, el usuario mover´ıa el e-mail de carpeta, y se le notificar´ıa a Genusmail la nueva clasificaci´on.
Hay dos tipos de clasificaci´on: autom´atica y manual. La autom´atica es aquella en la que el clasificador lee un e-mail y le asocia una clasificaci´on, seg´un su modelo interno. La manual tiene lugar cuando es el mismo usuario quien le dice a Genusmail que a cierto e-mail le corresponde cierta clasifica- ci´on, para que aprenda y mejore su modelo interno; este caso de uso es usado, por ejemplo, en el entrenamiento, y tambi´enal rechazar una clasificaci´on de Genusmail y proponer una nueva. Por otra parte, vemos que una clasifica- ci´on puede consistir en no asignar ninguna clasificaci´on (puede que al usuario no le interese que todos los e-mails est´enclasificados), y tambi´enes posible que el usuario pretenda que la clasificaci´on est´easociada a un movimiento del e-mail a la carpeta correspondiente a su clasificaci´on (Clasificar y mover).
El objetivo es que el usuario decida si los e-mails recibidos se deben clasifi- car autom´aticamente, o no, y en caso de que deban clasificarse, si se deben 54 CAP´ITULO 4. ANALISIS´ Y DISENO˜ mover a la carpeta correspondiente. M´as adelante dise˜naremos c´omo puede configurar esto el usuario.
A grandes rasgos, este es el conjunto de funcionalidades que pretendemos implementar en nuestra extensi´on; estudiemos con m´as detenimiento c´omo hemos dise˜nado estas funcionalidades, tanto desde el punto de vista est´atico (m´odulos que creemos necesarios) como din´amico (comportamiento).
4.1.2. Diagramas de clase
En la siguiente ilustraci´on se muestra la estructura l´ogica de la extensi´on, a nivel de clases:
La clase EventListener estar´ıa pendiente de los eventos de mensajes, como “nuevo mensaje”, ”mensaje movido” o ”mensaje borrado”. Cuando se produzca un movimiento de e-mail, o llegue un e-mail nuevo, esta clase podr´a realizar acciones con este e-mail (como pas´arselo a Genusmail para que lo clasifique).
La clase Utils implementa acciones como mover un correo de una carpe- ta a otra, o leer el contenido de un mensaje. Se ha decidido incluir esta clase porque hay acciones que nuestra aplicaci´on necesitar´acon frecuencia, y cu- ya implementaci´on no es trivial (como el caso de mover un correo), por lo que encapsular estas acciones en una clase aparte har´aque el desarrollo de nuestra aplicaci´on sea m´as r´apido y menos propenso a fallos (al no tener que 4.1. ANALISIS´ PRELIMINAR: DIAGRAMAS 55 codificar una y otra vez las mismas acciones). Podemos pensar en utils es una especie de biblioteca de utilidades.
Como en principio no sabemos lo que va a durar la llamada a Genusmail, se hace necesario un servicio de callback, para que el propio componente XP- COM sea el que le notifique a nuestra aplicaci´on cu´ando ha terminado su operaci´on, ya que de otra forma no sabr´ıamos desde el c´odigo JavaScript de la aplicaci´on si Genusmail ha terminado de clasificar o no.
Por ´ultimo, hemos incluido una clase observadora, MailReadListener, cuya funci´on consiste en esperar que termine la lectura de un e-mail, que es rea- lizada as´ıncronamente por el servicio de Mozilla MessageService. La raz´on por la que son necesarias estas clases es porque a Genusmail se le debe pasar el cuerpo del e-mail que queremos clasificar, para que pueda ser analizado.
4.1.3. Diagrama de paquetes
En el siguiente diagrama mostramos c´omo se relaciona nuestra extensi´on con Mozilla Thunderbird, mediante un diagrama de paquetes: 56 CAP´ITULO 4. ANALISIS´ Y DISENO˜
Vemos en el paquete AnotherMailClassifier variables y funciones Ja- vaScript que controlan el comportamiento de nuestra aplicaci´on. Como se puede observar, estas tienen acceso a los elementos de la GUI, as´ıcomo a los de la localizaci´on (para extraer cadenas de texto) y a los de skin (para los elementos como iconos o im´agenes), a los que obviamente tambi´entiene acceso la GUI. Las funciones JavaScript tienen tambi´enacceso a las funcio- nes y variables definidas globalmente en Thunderbird, las cuales controlan una gran cantidad de aspectos de la aplicaci´on, desde seleccionar e-mails y obtener la lista de los e-mails seleccionados, hasta obtener datos del sistema operativo en el que estamos.
Generalmente, la funcionalidad de estas funciones JavaScript se implementa por medio de llamadas a componentes XPCOM. Nuestras propias funciones JavaScript tambi´entienen acceso a los componentes XPCOM1 (entre ellos el que vamos a implementar para nuestra extensi´on, AMCComp, del que hablare- mos m´as adelante).
4.1.4. Diagrama de estados
En la secci´on anterior mostr´abamos c´omo est´aorganizada la extensi´on desde el punto de vista est´atico, es decir, los diferentes m´odulos de la misma y sus relaciones. En esta, sin embargo mostramos la funcionalidad desde un punto de vista din´amico, mediante un diagrama UML de m´aquina de esta- dos, ya que como adelant´abamos al presentar el diagrama de clases, nuestra extensi´on est´aguiada por estados; diferentes eventos provocan que cambie el estado de la aplicaci´on, y dependiendo del estado actual cada componente llevar´aa cabo sus acciones de una forma u otra. Veamos el diagrama:
1A los componentes XPCOM hay que acceder a trav´esde la capa XPConnect, que es la que le ofrece a las funciones JavaScript una interfaz para acceder a estos componentes. 4.1. ANALISIS´ PRELIMINAR: DIAGRAMAS 57
El estado central, EMPTY_ACTION es el que espera a que se produzcan eventos que ata˜nan a la extensi´on, ya que en este estado no se necesita hacer nada. Cuando llega un nuevo e-mail (y el usuario no pidi´oque se moviera el e- mail autom´aticamente a su clasificaci´on) nos vamos al estado CLASIFICACION´ DEL E-MAIL A SU LLEGADA, en el que se reacciona al evento de llegada de un e-mail leyendo su contenido y envi´andoselo al clasificador, y notificando a Thunderbird esta clasificaci´on para que se actualice.
Cuando llega un e-mail, pero el usuario ha configurado la extensi´on para que se mueva el e-mail autom´aticamente, nos vamos al estado CLASIFICACION´ Y MOVIMIENTO DE E-MAIL A SU LLEGADA, que llama al clasificador para obte- ner una clasificaci´on, y, una vez obtenida esta, se va al estado MOVIMIENTO FORZADO, en el que el e-mail se mueve a la clasificaci´on que se le ha asignado.
En el caso en que el usuario le indique a la aplicaci´on expl´ıcitamente que quiere clasificar un e-mail concreto (o varios), la aplicaci´on ir´ıa al estado PROPONER CLASIFICACION´ , que propondr´ıa una clasificaci´on mediante una llamada al clasificador, y volver´ıa al estado inicial, al terminar el clasificador.
Por ´ultimo, si el usuario decide clasificar un e-mail (o talvez varios) y mover- 58 CAP´ITULO 4. ANALISIS´ Y DISENO˜ lo inmediatamente a su clasificaci´on propuesta, la aplicaci´on entrar´ıa en el estado PROPONER CLASIFICACION´ Y MOVER, cuando se disponga de una cla- sificaci´on se ir´aal estado MOVIMIENTO FORZADO, en el que se mover´ael e-mail a su clasificaci´on, y se volver´aal estado inicial, en el que de nuevo se esperar´a a que lleguen m´as eventos a los que responder.
4.1.5. Diagramas de secuencia
En esta secci´on especificamos el comportamiento de la extensi´on con m´as detalle, mostrando las llamadas que hacen falta, y en qu´eorden, para llevar a cabo distintos casos de uso, como la clasificaci´on de un e-mail (autom´atica o manual), o el entrenamiento del modelo.
Clasificaci´onautom´atica de un e-mail
Cuando llega un e-mail al buz´on del usuario, Genusmail lo clasifica auto- m´aticamente. En el diagrama de secuencia siguiente vemos los pasos que se siguen para esta clasificaci´on: 4.1. ANALISIS´ PRELIMINAR: DIAGRAMAS 59
Cuando el servicio de notificaciones descubre que ha llegado un nuevo e-mail, se lo notifica a los listeners que tenga asociados, uno de los cuales es el de nuestra extensi´on. Este llama a utils para leer el cuerpo del e-mail, como tambi´enla ruta a Genusmail y los par´ametros que va a necesitar para la llamada, que tendr´an que ser pasados a Genusmail para proceder a la clasi- ficaci´on una vez dispongamos de todos estos datos. La lectura del contenido del e-mail se hace con ayuda del servicio MessageService, y es as´ıncrona; al concluir esta lectura, hay que notific´arselo a la clase StreamListener, que dispondr´adel contenido del e-mail, y de los par´ametros para llamar a Genusmail.
En este momento, puede llamar al componente XPCOM para que este realice la llamada a Genusmail. Esta llamada es llevada a cabo, y una vez termina- da, el propio componente XPCOM avisar´ade que ha terminado, mediante una llamada a otra variable tipo listener, la variable callback, que a su vez ser´ala encargada de mover el e-mail a la carpeta oportuna (y de marcarlo como clasificado). 60 CAP´ITULO 4. ANALISIS´ Y DISENO˜
El callback incluir´ainformaci´on sobre la clasificaci´on propuesta. Para mo- ver un e-mail de carpeta, se llama a la funci´on moveMail de la clase utils; la clasificaci´on propuesta por Genusmail se obtiene redirigiendo a nivel de componente XPCOM la salida est´andar de Genusmail en un archivo tempo- ral, qu´eser´aanalizado para extraer la clasificaci´on propuesta (la cual ser´aun par´ametro del callback). En el siguiente cap´ıtulo entramos m´as en detalle en esto, y en otros detalles t´ecnicos, ya que en este s´olo pretendemos mostrar el modelado de forma general.
Clasificaci´onmanual de un e-mail
Hemos decidido que, cuando un usuario mueve un e-mail a otra carpeta, esto le es notificado a Genusmail como una clasificaci´on manual del e-mail que ha recibido y que, por lo tanto, se rechaza la clasificaci´on asociada an- teriormente a ese e-mail. La secuencia de eventos que se sigue en este caso es b´asicamente la misma que en el caso anterior; lo que cambia es que se le piden a utils los par´ametros correspondientes a la clasificaci´on manual en Genusmail. Por lo tanto, no consideramos necesaria la inclusi´on del diagrama de secuencia, optando por referirnos al anterior.
Entrenamiento del modelo
Veamos cu´al es el procedimiento para entrenar el modelo. Nuestra idea se basa en aprovechar los e-mails disponibles en la cuenta de correo del usuario como conjunto de entrenamiento, recorriendo todas las carpetas recursiva- mente y, de cara a Genusmail, asign´andole a cada e-mail su carpeta actual como clasificaci´on. Con esta estrategia, conseguimos reaprovechar la funcio- nalidad que ya tenemos para clasificar manualmente un e-mail. En el siguiente 4.2. ANALISIS´ DE INTERFACES DE USUARIO SIMILARES 61 diagrama se muestra m´as claramente:
4.2. An´alisis de interfaces de usuario simila- res
Para dise˜nar nuestra herramienta, seguimos las recomendaciones del ISO 13407[BC97]. La metodolog´ıa de desarrollo seguida consta de las cuatro fases, que pueden ser iteradas:
An´alisis: Esta fase tiene por objetivo comprender el problema para el que desarrollamos la aplicaci´on, y decidir qu´em´etodos vamos a utilizar para el dise˜no.
Dise˜no. En esta fase sirve para vislumbrar la soluci´on al problema, en cuanto a flujo de informaci´on, de actividades y de interacci´on con el usuario.
Implementaci´on. La soluci´on se construye seg´un el dise˜no del punto anterior.
Evaluaci´on. La soluci´on que hemos construido es evaluada, para tratar de encontrarle posibles fallos en cuanto a usabilidad. 62 CAP´ITULO 4. ANALISIS´ Y DISENO˜
Una vez que se han completado las cuatro fases, y dependiendo del resul- tado de la evaluaci´on, podemos refinar el an´alisis, y seguir iterando sobre estas cuatro fases, hasta que lleguemos a un punto en el que consideremos el resultado como satisfactorio.
4.2.1. An´alisis
Procedemos ahora a realizar el an´alisis, el primero de los cuatro pun- tos anteriores. El primer paso consiste en descubrir qu´e escenarios forman parte de la aplicaci´on a desarrollar. Despu´esanalizaremos de qu´emanera y mediante qu´emecanismos son llevados a cabo estos escenarios por parte de otras herramientas parecidas que hemos encontrado. Para cada una de ellas evaluaremos, seg´un heur´ısticas de dise˜no, la implementaci´on estos escenarios, con el objetivo de descubrir las caracter´ısticas positivas y negativas de ca- da herramienta en su aproximaci´on al problema de la clasificaci´on de correo electr´onico. Como resultado, podremos adoptar para nuestra herramienta las caracter´ısticas positivas, evitando las caracter´ısticas negativas.
Los escenarios que consideramos para el an´alisis son los siguientes, bas´an- donos en los casos de uso que mencion´abamos en la primera parte de este cap´ıtulo:
Asignar una clasificaci´on a cada e-mail que se recibe. Esto es, decidir autom´aticamente qu´ecategor´ıa se le asigna al correo, nada m´as llegar este al buz´on del usuario. Opcionalmente, se podr´ıa decidir que al correo recibido no le corresponde ninguna categor´ıa, y dejarlo sin asignar. Otra posibilidad es asignarle m´as de una categor´ıa posible, y dejar que el usuario decida.
Ver la clasificaci´on asignada. Es decir, en qu´eforma percibe el usuario cu´al es (o cu´ales son) la categor´ıa que propone la herramienta.
Mover el correo a una carpeta dependiendo de la clasificaci´on asignada. Esto podr´ıa ser llevado a cabo autom´aticamente (cuando se propone 4.2. ANALISIS´ DE INTERFACES DE USUARIO SIMILARES 63
una clasificaci´on, se mueve el correo directamente a la carpeta seleccio- nada), o dejando al usuario mover el correo a la carpeta asignada, en caso de aceptar la clasificaci´on.
Aceptar clasificaci´on asignada. El usuario puede aceptar la clasifica- ci´on, ya sea impl´ıcitamente (si no hace nada, se considera aceptada) o expl´ıcitamente, mediante alg´un bot´on, por ejemplo.
Rechazar clasificaci´on asignada. La herramienta ha propuesto una cla- sificaci´on, pero no coincide con la esperada por el usuario, que le debe indicar al clasificador que no la acepta.
Crear/borrar clasificaciones. Normalmente, el conjunto de posibles ca- tegor´ıas a las que asignar los e-mails no va a venir dado de antemano. Por ejemplo, si un usuario recibe muchos e-mails provenientes de una cierta lista de correo, talvez le interesar´atener configurada una catego- r´ıa espec´ıfica para esa lista, categor´ıa que no le interesar´aa otro usuario que no reciba e-mails de esta misma lista. Es posible que las catego- r´ıas sean jer´arquicas (por ejemplo, en una hipot´etica categor´ıa Trabajo puede que haya categor´ıas como Encargos de clientes y Mensajes de proveedores. Opcionalmente, es posible que las categor´ıas puedan ser borradas, porque una categor´ıa dada ya no le interese al usuario.
Las posibilidades que hay son bastante amplias; posteriormente veremos cu´a- les de estas opciones son ofrecidas por las distintas herramientas.
Como dec´ıamos, hemos localizado algunas herramientas similares a la que pretendemos implementar, concretamente las siguientes:
MailCat [Ric99] es una herramienta que busca simplificar la tarea de la clasificaci´on del correo electr´onico. Usando un clasificador adaptati- vo, predice las tres carpetas a priori m´as adecuadas para un mensaje dado. Se trata del fruto de un trabajo te´orico que busca hacer frente a la carencia de herramientas ´utiles en la pr´actica para clasificaci´on de 64 CAP´ITULO 4. ANALISIS´ Y DISENO˜
correo, y uno de sus objetivo es conseguir una interfaz de usuario f´acil de usar y eficiente.
MailClassifier [Sab07] es una extensi´on de Thunderbird que usa fil- trado bayesiano para mover cada correo a la carpeta correspondiente. Cuando llega un e-mail, la clasificaci´on m´as probable se muestra en una nueva columna en forma de hiperv´ınculo, que el usuario debe pul- sar en caso de estar de acuerdo con la clasificaci´on propuesta. Si no lo estuviese, se puede elegir la clasificaci´on correcta mediante un men´u.
Bayesweep: Se trata de otra extensi´on dise˜nada para un cliente de correo bastante popular hoy d´ıa, Microsoft Outlook. Al igual que las otras, sirve para clasificar el correo entrante, s´olo que en este caso es una herramienta de pago. Tiene una funcionalidad bastante completa: es capaz de mover correos, cambiar prioridades, reproducir sonidos, etc. [Sel06]
Aunque la funcionalidad b´asica de todas estas herramientas es similar (a grandes rasgos, ofrecen una interfaz para la clasificaci´on de correos electr´o- nicos mediante t´ecnicas bayesianas), cada una tiene sus peculiaridades, y su forma de lograr sus objetivos. En la siguiente secci´on vemos uno a uno los escenarios de uso de los que habl´abamos antes, examinando c´omo lleva a ca- bo cada herramienta ese escenario, para comprobar hasta qu´epunto var´ıan las decisiones de dise˜no que se han tomado en cada una: si hay decisiones comunes en los que todas las herramientas est´an de acuerdo, o si alg´un de- talle de estas herramientas es especialmente positivo o negativo de cara a la interacci´on con el usuario. 4.2. ANALISIS´ DE INTERFACES DE USUARIO SIMILARES 65
4.2.2. Implementaci´onlos escenarios de uso por parte de las herramientas
Ver clasificaci´oncuando llega el e-mail, en caso de que se asigne categor´ıaautom´aticamente
MailCat: Cuando llega un correo, analiza su contenido y propone 3 cla- sificaciones, mostradas en 3 botones sobre el cuerpo del correo. Esto es, no le asigna una sola clasificaci´on, sino que propone las tres cla- sificaciones m´as probables. Sin embargo, la clasificaci´on no le aparece inmediatamente al usuario, sino que tiene que abrir el e-mail para ver qu´ees lo que ha propuesto la herramienta.
MailClassifier: Cuando llega un correo, muestra en una columna en la bandeja de entrada la clasificaci´on propuesta (en forma de hiperv´ınculo, que al ser pulsado confirma que se acepta la clasificaci´on).
Bayesweep tiene, al igual que el anterior, una columna “Categories”, donde muestra la clasificaci´on propuesta, y las clasificaciones alternati- vas (es decir, a las que se les ha asignado m´as probabilidad). Al pulsar sobre la clasificaci´on propuesta, en el men´ucontextual aparecen las cla- sificaciones m´as probables.
Mover el correo a una carpeta, dependiendo de la clasificaci´onasig- nada
MailCat: Al pulsar uno de los 3 botones que aparecen con la clasificaci´on propuesta, se mueve el e-mail a la carpeta correspondiente.
MailClassifier: Basta con pulsar el v´ınculo que, en la bandeja de entra- da, muestra la clasificaci´on propuesta. Con esto, aceptamos la clasifi- caci´on y el e-mail se mueve a la carpeta correspondiente. 66 CAP´ITULO 4. ANALISIS´ Y DISENO˜
Figura 4.1: Men´ude Bayesweep en Outlook Express 4.2. ANALISIS´ DE INTERFACES DE USUARIO SIMILARES 67
Bayesweep: Es posible crear filtros tales que todos los e-mails a los que se le haya dado una determinada categor´ıa se muevan a una carpeta dada de forma autom´atica. Pero no es este el comportamiento por de- fecto, sino que se asocia una acci´on a cada mensaje nuevo, dependiendo de su clasificaci´on propuesta, la cual puede consistir en mover el e-mail a una carpeta dada, reproducir un sonido, o incluso colorear el e-mail de un color distintivo de su categor´ıa. Existe por lo tanto mucha flexi- bilidad en cuanto a la acci´on a realizar, como se puede apreciar en la figura 4.1.
Aceptar la clasificaci´onasignada
MailCat: La clasificaci´on se acepta expl´ıcitamente pulsando alguno de los tres botones que aparecen sobre el cuerpo del e-mail.
MailClassifier: La clasificaci´on se considera aceptada cuando el usuario pulsa sobre el v´ınculo que aparece en una columna a˜nadida a la bandeja de entrada.
Bayesweep: Si el usuario no hace nada, se acepta impl´ıcitamente la clasificaci´on. Es decir, la clasificaci´on propuesta se considera aceptada mientras el usuario no la corrija.
Rechazar la clasificaci´on
MailCat: En el art´ıculo de referencia ([Ric99]) no aparece especificada esta opci´on. MailCat se trata de un trabajo eminentemente te´orico, con lo cual es de suponer que los autores no han considerado necesario el dise˜no de cada opci´on del programa.
MailClassifier. En el men´ucontextual se puede seleccionar una catego- r´ıa alternativa (bajo “Change classification and move” se puede elegir la categor´ıa que se desea). 68 CAP´ITULO 4. ANALISIS´ Y DISENO˜
Bayesweep. En el men´ucontextual hay que elegir la opci´on etiquetada como “Others”. Entonces se abre un di´alogo en el que podemos elegir la clasificaci´on que deseamos.
Crear/Borrar clasificaci´on
MailCat. Las categor´ıas se corresponden con las carpetas previamente disponibles en la cuenta del usuario, con lo que crear o eliminar cate- gor´ıas es algo externo a MailClassifier, que se hace creando o borrando carpetas de la cuenta.
MailClassifier. Al igual que en MailCat, las categor´ıas se corresponden con las carpetas que haya creadas en la cuenta del usuario.
Bayesweep. Esta herramienta proporciona un di´alogo para crear cate- gor´ıas, donde se puede incluir una descripci´on. En esta herramienta, en contraste con las otras que hemos analizado, las clasificaciones no tie- nen por qu´ecorresponderse necesariamente con las carpetas que tenga creadas el usuario, al ser algo conceptualmente diferente, pero s´ıque se pueden crear reglas para mover el e-mail de forma autom´atica a una carpeta dada. Mostramos el di´alogo para crear categor´ıas en la figura 4.2.
Otras caracter´ısticas destacables
Bayesweep ofrece un men´ude ayuda en su men´ucontextual, precisamente en el sitio m´as accesible al usuario cuando este quiere llevar a cabo una acci´on, pero no sabe c´omo. Esto es precisamente una de las recomendaciones heur´ısticas de Molich y Nielsen. 4.2. ANALISIS´ DE INTERFACES DE USUARIO SIMILARES 69
Figura 4.2: Configuraci´on de categor´ıas en Bayesweep 70 CAP´ITULO 4. ANALISIS´ Y DISENO˜
4.2.3. An´alisis de las herramientas atendiendo a heu- r´ısticas de dise˜no
Al no mostrar la clasificaci´on propuesta en la bandeja de entrada, opi- namos que MailCat no cumple completamente con la heur´ıstica de Molich y Nielsen “Visibilidad del estado del sistema”, ya que el usuario no ve inmedia- tamente cu´al ha sido la clasificaci´on propuesta por la herramienta.
Por otra parte, si se abre el correo, se obtiene m´as informaci´on que con otras herramientas, ya que muestra no s´olo la clasificaci´on m´as probable, sino las tres m´as probables. Lo mismo se puede decir de Bayesweep, que permite exa- minar las clasificaciones m´as probables. La flexibilidad de Bayesweep es de destacar, ya que permite ver la misma informaci´on en men´us contextuales, en una columna, y al abrir el correo.
Cuando queremos mover a la carpeta correspondiente un e-mail que ha re- cibido ya su clasificaci´on, la ventaja que tiene MailClassifier es que con s´olo pulsar en el v´ınculo que se ofrece con la clasificaci´on, hemos movido el e-mail. Con Bayesweep, por el contrario, tenemos que abrir un men´ucontextual, y elegir alguna de las categor´ıas propuestas. Por lo tanto, MailClassifier es mu- cho m´as eficiente en este sentido (en caso de acierto), y cumple mejor con la heur´ıstica “flexibilidad y eficiencia de uso”. MailCat fuerza al usuario a abrir el e-mail, pero despu´espuede aceptar con un s´olo click a un bot´on la clasificaci´on propuesta, lo cual es r´apido y eficiente. La ventaja de Bayesweep es que permite dejar el correo sin clasificaci´on, lo cual puede venirnos bien en alg´un momento.
En lo que difiere respecto a Bayesweep es en que para mover el mensaje a su carpeta correspondiente, el usuario debe crear una regla, tal que todos los mensajes con una cierta clasificaci´on se muevan a la carpeta correspondiente, lo cual, aunque parezca que puede ahorrar trabajo al usuario, es propenso a errores; por ejemplo, si un e-mail se clasifica err´oneamente como spam, 4.2. ANALISIS´ DE INTERFACES DE USUARIO SIMILARES 71
Figura 4.3: Definici´on de una regla en Bayesweep ir´ıa autom´aticamente a una carpeta “Papelera”, y puede que, si el usuario no mira compruebe regularmente el contenido de esa carpeta, se pierda el e-mail. Por otra parte, si a los e-mails que se han movido autom´aticamente se les asocia una se˜nal visual de alg´un tipo (tenemos en mente el icono de una llama de Thunderbird, que significa que un mensaje ha sido clasificado como spam), entonces el usuario puede reconocer de un vistazo que un email se ha movido de forma autom´atica, con lo que se ve paliado, en menos en parte, este problema. En la figura 4.3 podemos ver c´omo se configura una de estas reglas en Bayesweep.
Como se puede observar, estas reglas son realmente potentes. Pero, seg´un nuestra opini´on, dejar que un e-mail se mueva autom´aticamente a una car- peta vulnera la heur´ıstica “Prevenci´on de errores”, por las razones que se ha 72 CAP´ITULO 4. ANALISIS´ Y DISENO˜ dicho, a no ser que se vea acompa˜nado de medidas que eviten errores poten- ciales.
En caso de que la clasificaci´on (o clasificaciones) que se hayan propuesto no sean aceptadas como correctas, podemos ver que la herramienta que pro- pone una nueva clasificaci´on de forma m´as eficiente es MailClassifier, ya que en el mismo men´ucontextual que permite mover el e-mail en caso de acierto se le da al usuario la opci´on de “cambiar la clasificaci´on y mover”, en la que hay otro submen´ucon odas las categor´ıas posibles. En el caso de Bayesweep, ser´ıa preciso abrir un nuevo di´alogo para seleccionar la nueva clasificaci´on, lo cual es ligeramente menos eficiente para al usuario. Adicionalmente, en el caso de Bayesweep tenemos muy a la vista tanto el e-mail que hemos selec- cionado, como las categor´ıas que le podemos asignar en caso de error, lo cual favorece la ”visibilidad del estado del sistema” y el ”reconocimiento antes que memoria”, dos de las heur´ısticas de Molich y Nielsen.
4.3. Dise˜node la interfaz
En el dise˜no de la interfaz se han tenido en cuenta los resultados del an´a- lisis anterior, buscando la sencillez, pero sin perder usabilidad ni flexibilidad. Por lo tanto, nuestra estrategia es dise˜nar una interfaz con pocos a˜nadidos a la de Thunderbird, pero con la suficiente flexibilidad.
En primer lugar, a˜nadimos un men´uen la secci´on “Herramientas” del men´u principal de Thunderbird, con el nombre ”AnotherMailClassifier”; este men´u tambi´enestar´adisponible como men´ucontextual. Dentro hay un submen´u con las siguientes entradas:
Entrenar modelo.
Proponer clasificaci´on (para los e-mails seleccionados). 4.3. DISENO˜ DE LA INTERFAZ 73
Figura 4.4: Captura del men´uprincipal de nuestra extensi´on
Proponer clasificaci´on y mover (para los e-mails seleccionados).
Mover e-mails seleccionados a su clasificaci´on propuesta.
Eliminar clasificaci´on (para los e-mails seleccionados).
Ayuda
En la figura 4.4 podemos ver qu´easpecto tiene este men´u: Con la ayuda de un separador, hemos organizado los elementos del men´uen varias secciones: la primera para el entrenamiento, otra para asignar clasificaciones (ya sea la predeterminada, o una seleccionada por el usuario), otra para no asignar ninguna clasificaci´on, y otra para ayuda. El que las entradas relacionadas con la clasificaci´on no est´enseparadas pretende transmitir la idea al usuario de que estas funciones est´an relacionadas entre s´ı; este es un resultado pr´actico de una de las leyes de la Gestaltpsychologie, concretamente de la Ley de la Clausura, que afirma que “los elementos rodeados por una l´ınea son percibi- dos como una unidad”.
Por otra parte, si no hay ning´un e-mail seleccionado, las entradas del men´u destinadas a clasificar e-mail estar´an deshabilitadas, con la intenci´on de infor- mar al usuario de que no tiene sentido en ese momento es un patr´onde dise˜no 74 CAP´ITULO 4. ANALISIS´ Y DISENO˜ de interfaces que aparece frecuentemente. Un patr´on de dise˜no, en palabras de Jennifer Tidwell[Tid06] es un conjunto de caracter´ısticas estructurales y procedimentales que facilitan la usabilidad de la interfaz, y es un concepto que tiene cierta analog´ıa al de patrones de dise˜no en la Ingenier´ıa del Sof- tware. Al igual que se han formalizado colecciones de patrones de Ingenier´ıa del Software, por ejemplo en el influyente trabajo de Gamma, Helm, John- son y Vlissides Design Patterns: Abstraction and Reuse of Object-Oriented Design[GHJV93], se han hecho intentos de formalizar tambi´enbibliotecas de patrones de dise˜no de interfaces; un ejemplo es la de Jennifer Tidwell, que contiene el patr´on “Responsible Enabling”.
Para representar gr´aficamente que el bot´on est´adeshabilitado, hacemos que las fuentes salgan grises, como en Mozilla Thunderbird (y otras muchas apli- caciones), con lo cual respetamos los est´andares, algo que recomiendan Niel- sen y Molich en sus heur´ısticas de dise˜no. Aunque esto puedan parecer ob- viedades, volvemos a subrayar que un buen dise˜no de interfaces de usuario es algo que se puede estudiar con la ayuda de estas t´ecnicas, y los principios que hacen que una interfaz sea m´as o menos usable son cada ver mejor com- prendidos y estudiados.
Otro a˜nadido a la interfaz de Mozilla Thunderbird, mostrado en la figura 4.5, es una columna en la que se muestra la clasificaci´on propuesta para cada e-mail. De esta forma, el usuario puede ver de un vistazo si para el e-mail ya se ha propuesto una clasificaci´on o no, y cu´al ha sido esta. Adem´as, en caso de que los e-mails se muevan a su clasificaci´on autom´aticamente al llegar, el usuario tiene f´acil saber que un e-mail ha sido movido, ya que si descubre un e-mail sin abrir en una carpeta diferente a la de entrada, se sabe que ha sido movido autom´aticamente. Adicionalmente, la funcionalidad de Thunderbird de “mover a carpeta original” permite devolverla a la carpeta en la que el mensaje fue recibido originalmente. 4.3. DISENO˜ DE LA INTERFAZ 75
Figura 4.5: Columna a˜nadida al panel de correo de Thunderbird
Figura 4.6: Renombre de las entradas del men´upara mover y copiar e-mails
Un cambio sutil en la interfaz es que extendemos la funci´on normal de mover un e-mail de una carpeta a otra, haciendo que se le notifique a Genusmail que la nueva clasificaci´on del e-mail en movimiento es la correspondiente a la carpeta de destino. Esto se hace de forma transparente al usuario (salvo porque en la columna del e-mail que se acaba de mover se mostrar´asu nueva clasificaci´on). El movimiento se puede hacer arrastrando o soltando el e-mail en la carpeta de destino, o utilizando los men´us de Thunderbird, a los que se le ha cambiado la etiqueta para poner en relieve que se proceder´aa una re- clasificaci´on del e-mail. En la figura 4.6 podemos ver una captura de pantalla.
Por ´ultimo, necesitamos un mecanismo para que el usuario pueda configurar la interfaz seg´un sus necesidades. Hemos localizado los siguientes aspectos susceptibles de ser configurables:
La ruta donde est´alocalizado el ejecutable de Genusmail.
El nombre del ejecutable. 76 CAP´ITULO 4. ANALISIS´ Y DISENO˜
Figura 4.7: Ventana de preferencias de la extensi´on
Los par´ametros con los que llamarlo, seg´un se vaya a proceder a una clasificaci´on autom´atica o a una reclasificaci´on manual.
Si se desea clasificar los e-mails autom´aticamente a su llegada.
Si los e-mails clasificados autom´aticamente a su llegada deben ser mo- vidos a su carpeta de destino.
Controlaremos todos estos par´ametros con la ventana mostrada en la figu- ra 4.7. S´olo se podr´an guardar las preferencias si la ruta y el nombre del ejecutable introducidos existen; si no, no se guardar´an estas preferencias y saltar´aun mensaje de error. Asimismo, es deseable que si se intenta llamar a Genusmail (por ejemplo, para clasificar un e-mail), sin tener configurada una ruta correcta a Genusmail, no se intente llamar al clasificador, lo que pro- vocar´ıa un error en tiempo de ejecuci´on, sino que salte un mensaje de alerta instando al usuario a configurar correctamente la ruta antes de efectuar una clasificaci´on. 4.4. COMUNICACION´ CON GENUSMAIL 77
4.4. Comunicaci´on con Genusmail
Para comunicar nuestra extensi´on con el clasificador Genusmail tenemos a priori varias opciones. Podr´ıamos implementar esta comunicaci´on mediante ficheros, haciendo que Genusmail escriba en un fichero, y que nuestra apli- caci´on los leyese, para extraer la clasificaci´on propuesta. Tambi´enpodr´ıamos usar sockets para establecer la comunicaci´on; el problema est´aen que tendr´ıa- mos que ampliar Genusmail para que pudiera mandar y recibir comunicaci´on mediante sockets, dot´andolo de una capa de comunicaci´on. Otra opci´on es usar tuber´ıas, una para pasarle a Genusmail el cuerpo del mensaje de correo que se quiere clasificar, y otra para leer la salida est´andar del clasificador, con vistas a extraer la clasificaci´on. Tambi´enexiste la posibilidad de comunicar ambos procesos mediante peticiones HTTP.
Nuestra decisi´on ha sido simular un sistema de tuber´ıas como el que he- mos dicho, ya que es una soluci´on simple e independiente de la plataforma. Para ello, hemos utilizando. Lo que queremos conseguir es, b´asicamente, lo siguiente:
Ejecutar Genusmail llam´andolo desde la extensi´on. Para ello, una op- ci´on simple, e independiente de la plataforma, es utilizar la funci´on de C++ cstdlib::system desde un componente XPCOM, pas´andole como par´ametro el comando que utilizar´ıamos para lanzar la clasifica- ci´on desde l´ınea de comandos, que ya incluir´ıa el contenido del e-mail. Con esto conseguir´ıamos ejecutar Genusmail y que nos devolviese la clasificaci´on por la salida est´andar.
Leer la salida est´andar de Genusmail, la cual contiene la clasificaci´on, y analizarla, para obtener esta clasificaci´on. Esto lo haremos v´ıa un fichero temporal al que redirigimos la salida est´andar de Genusmail, por ser un m´etodo simple y, de nuevo, independiente de la plataforma. Por lo tanto, antes de ejecutar la llamada a Genusmail se crear´aun fichero temporal, y el comando de llamada contendr´auna redirecci´on 78 CAP´ITULO 4. ANALISIS´ Y DISENO˜
Figura 4.8: Representaci´on gr´afica del sistema de pseudotuber´ıas usado para comunicarnos con Genusmail
a este fichero, que podr´aser le´ıdo posteriormente.
En la figura 4.8 vemos esquem´aticamente el funcionamiento de la comunica- ci´on.
Trabajo siguiente
En la secci´on que viene a continuaci´on entraremos de lleno en la imple- mentaci´on de la herramienta, introduciendo primero la funcionalidad m´ınima de la interfaz, y despu´esviendo c´omo se comunica con el sistema de compo- nentes XPCOM de Mozilla para llevar a cabo sus funciones. Cap´ıtulo5
Implementaci´on
En este cap´ıtulo detallamos c´omo se ha implementado la extensi´on, una vez que hemos llegado a un dise˜no en el cap´ıtulo anterior.
5.1. Flujo de trabajo para la implementaci´on de extensiones para Thunderbird
Antes de empezar, queremos poner en relieve que, al desarrollar una ex- tensi´on para Thunderbird, no hay que estar continuamente instalando y des- instalando la extensi´on para ver el efecto de nuestros cambios: simplemente basta con tener el c´odigo fuente en una carpeta cualquiera del sistema, y tener un “puntero” a esa carpeta en la carpeta de extensiones de nuestro per- fil en Thunderbird1. Este puntero consiste en un fichero de texto que tiene por nombre el identificador de la extensi´on (t´ıpicamente, un id generado por uuidgen), y por contenido la ruta absoluta a la carpeta donde se almacena el c´odigo fuente. As´ı, cada vez que hagamos un cambio en el c´odigo, bastar´a con reiniciar Thunderbird para ver el efecto de este cambio, lo cual es mucho m´as c´omodo que estar reempaquetando y reinstalando la extensi´on continua- mente.
1En un sistema GNU/Linux, esta carpeta est´anormalmente dentro de la carpeta oculta .thunderbird o .mozilla-thunderbird de nuestro HOME
79 80 CAP´ITULO 5. IMPLEMENTACION´
5.2. Implementaci´on de la interfaz sin funcio- nalidad
Comencemos con la implementaci´on en s´ımisma. Lo primero ser´amos- trar c´omo debe estar estructurado el c´odigo fuente de la extensi´on, ya que esta estructura juega un papel fundamental en las extensiones para Thunder- bird, como tendremos la ocasi´on de comprobar m´as adelante, en el cap´ıtulo dedicado al despliegue.
5.2.1. Estructura del programa: carpetas
El c´odigo fuente de nuestra aplicaci´on estar´acompuesto de diversos fi- cheros, organizados en una jerarqu´ıa de carpetas. La carpeta ra´ız, que llama- remos anothermailclassifier, contiene subcarpetas para los skins, para la localizaci´on (es decir, las cadenas de texto que se mostrar´an al usuario, que como comentamos en el cap´ıtulo 3 est´an separadas del resto de la apli- caci´on), y para la interfaz de usuario y su funcionalidad (carpeta content), que es donde almacenaremos los overlays. Tambi´ense incluye una carpe- ta components, que almacena los ficheros correspondientes a componentes XPCOM que necesitemos instalar. En la carpeta ra´ız hay un fichero llama- do install.rdf, que contiene directivas para la instalaci´on, y otro llamado chrome.manifest, que contiene informaci´on sobre c´omo integrar Thunder- bird con nuestra extensi´on. En la figura 5.1 se muestra gr´aficamente el ´arbol de directorios. En el cap´ıtulo dedicado al empaquetado de la extensi´on ha- blaremos m´as a fondo de esta organizaci´on de carpetas, y de los dos archivos que hemos nombrado. 5.2. IMPLEMENTACION´ DE LA INTERFAZ SIN FUNCIONALIDAD 81
Figura 5.1: Arbol´ de directorios del c´odigo fuente de la extensi´on 82 CAP´ITULO 5. IMPLEMENTACION´
Figura 5.2: C´odigo fuente del overlay correspondiente a la columna persona- lizada
5.2.2. Overlays
Para cada elemento gr´afico que le queramos a˜nadir a la interfaz de Thun- derbird, necesitamos un overlay, que define los elementos que se le a˜nadir´an, y en qu´eparte de la interfaz original de Thunderbird. En el cap´ıtulo dedicado a los aspectos t´ecnicos ya nos acercamos a este concepto; veamos los overlays concretos que hemos utilizado.
Adici´onde una columna personalizada
Uno de los elementos que nuestra extensi´on a˜nade a la interfaz gr´afica de Thunderbird es una columna personalizada, que, para cada e-mail indica si este se ha movido autom´aticamente a consecuencia de una clasificaci´on autom´atica, o no, y cu´al es su clasificaci´on asignada. Para ello, la columna muestra un texto con la clasificaci´on asociada, y, adicionalmente, un peque- ˜no icono, en caso de que la clasificaci´on asociada no coincida con la carpeta actual.
En la figura 5.2 podemos ver el c´odigo fuente utilizado. La primera l´ınea es la t´ıpica de cualquier fichero XML (recordemos que XUL es un lenguaje 5.2. IMPLEMENTACION´ DE LA INTERFAZ SIN FUNCIONALIDAD 83 basado en XML), mientras que la segunda es una referencia a la hoja de estilo, v´ıa chrome, ya que la hoja de estilos definida para nuestra aplicaci´on est´aregistrada en el chrome, al estar incluida en el fichero chrome.manifest, como ya se ha visto. Despu´escomienza el overlay propiamente dicho; se asocia con el script classification_col_overlay.js (que analizaremos inmedia- tamente), y se accede a las cadenas de localizaci´on. La parte m´as importante del overlay est´adelimitada por el tag tree, que es el que indica en qu´eparte de la interfaz de Thunderbird vamos a incluir nuestra columna. Como vemos, va a ser en id-tread-tree, que representa al conjunto de columnas que se pueden ver para cada carpeta de correo, como las de Asunto, Remitente, Fecha, Correo Basura, etc. Nosotros a˜nadimos una nueva columna, con id colClassification.
Con esto hemos conseguido que se muestre la columna al arrancar Thun- derbird con nuestra extensi´on cargada; sin embargo, la columna est´avac´ıa. Para que pueda mostrar algo dependiendo de cada e-mail, tenemos que aso- ciarla a un script controlador, implementado en JavaScript, el ya mencionado classification_col_overlay.js. Los dos siguientes pasos son:
1. Crear una variable controladora de la columna, a la que llamaremos columnHandler, y que deber´aimplementar la interfaz nativa de Mozilla nsIMsgCustomColumnsHandler.
2. Asociar esa variable a la columna, mediante
gDBView.addColumnHandler("colClassification", columnHandler)
Como acabamos de decir, la variable controladora de nuestra columna tiene que implementar la interfaz nsIMsgCustomColumnsHandler, lo que a efec- tos pr´acticos significa que debe implementar obligatoriamente los siguientes m´etodos (aunque sea mediante una funci´on de cuerpo vac´ıo):
getCellText(row, col) 84 CAP´ITULO 5. IMPLEMENTACION´
getSortStringForRow(row, col)
isString(row, col)
getCellProperties(row, col)
getRowProperties(row, col)
getImageSrc(row, col)
getSortLongForRow(row, col)
A nosotros nos interesa especialmente la funci´on getImageSrc, que devuelve la direcci´on de un fichero dependiendo de en qu´efila estemos. En nuestro caso, debe devolver una cadena vac´ıa en caso de que el e-mail no haya sido autom´aticamente clasificado o su clasificaci´on coincida con la actual, y la di- recci´on de un icono, que estar´aen nuestra carpeta de temas, en caso de que s´ı haya sido autom´aticamente clasificado. Tambi´ennos interesa getCellText, que para cada correo muestra la carpeta asociada a su clasificaci´on. Otra funci´on interesante es getSortStringForRow, que devuelve una cadena por la que ordenar las filas, en caso de que las ordenemos seg´un nuestra columna personalizada.
Para obtener el e-mail asociado a cada fila, hay que seguir dos pasos:
1. Conseguir la key del e-mail de esa fila, mediante key = gDBView.getKeyAt (row). row es el n´umero de fila seleccionada, mientras que gDBView es una variable global de Thunderbird, que permite controlar, entre otras cosas, qu´emensajes est´an seleccionados en cada momento, qu´ee-mail est´aabierto, etc.
2. Conseguir el e-mail correspondiente a esa key. En Thunderbird, los men- sajes de correo son objetos que implementan la interfaz nsIMsgDBHdr. Para conseguir este objeto a partir de la key, har´ıamos esto: mail = gDBView.db.GetMsgForKey (key). 5.2. IMPLEMENTACION´ DE LA INTERFAZ SIN FUNCIONALIDAD 85
Los e-mails en Thunderbird (es decir, los objetos nsIMsgDBHdr) tienen aso- ciadas propiedades, que pueden ser personalizadas. Nosotros le hemos creado una propiedad, llamada x-classified, que almacena el valor de la clasifica- ci´on propuesta; m´as adelante explicamos c´omo hemos creado esta propiedad. Lo importante es que, una vez tenemos el e-mail, podemos acceder a esta propiedad “x-classified” y consultar su valor (mediante GetStringProperty, y a partir de ese valor, y de la carpeta actual (mail.folder.URI), devolve- remos el dibujo o no, y en cualquier caso fijaremos el valor del texto de la columna al contenido de x-classified.
Men´us
Otro de los elementos que hemos a˜nadido como overlay han sido los men´us de los que habl´abamos en el dise˜no. Estos se han implementado en thunderbirdOverlay.xul, utilizando el elemento menuitem de XUL.
Opciones de configuraci´on
Las opciones de configuraci´on o preferencias, en el contexto de las aplica- ciones Mozilla son comparables al concepto de variables globales: mediante un identificador, cualquier extensi´on puede acceder a cualquier preferencia declarada. Estas preferencias son persistentes: si se reinicia Thunderbird, conservan el valor. Podemos visualizar las preferencias existentes en cada mo- mento en Thunderbird, en Editar/Preferencias/Avanzadas/Editor de Confi- guraci´on, donde se puede cada preferencia indexada por su nombre, y el valor de cada una de ellas (que es editable desde la misma ventana).
Estas preferencias son gestionadas por el componente preferences-service, que proporciona funciones para leer y escribir preferencias. Para llamar a Ge- nusmail, el usuario necesita fijar las preferencias correspondientes a la ruta en la que se encuentra instalado, el nombre del ejecutable, y los par´ame- tros correspondientes a cada opci´on de este clasificador; esto se podr´ıa hacer directamente desde el editor de configuraci´on de Thunderbird, pero hemos 86 CAP´ITULO 5. IMPLEMENTACION´ decidido implementar una ventana de preferencias de la extensi´on, para que el usuario pueda gestionar las preferencias de un modo m´as f´acil. La ventana de preferencias est´aimplementada en options.xul
5.3. Implementaci´on de la funcionalidad de la interfaz
5.3.1. De la interfaz al clasificador
La funcionalidad de la interfaz est´adirigida por varios archivos JavaScript. Para trabajar con JavaScript se ha usado la la biblioteca Prototype [Ste07], que proporciona varias funcionalidades para producir un c´odigo m´as corto, comprensible y organizado. Por ejemplo, proporciona facilidad para trabajar con orientaci´on a objetos, pudiendo definir clases, y relaciones de herencia entre estas. Tambi´enhace posible acceder a los elementos del DOM como si fuesen variables2. Hay muchas m´as funcionalidades en Prototype, que en general hacen que podamos producir c´odigo a m´as alto nivel. Para poder uti- lizar Prototype, basta con incluir un v´ınculo al archivo prototype.js, que nos podemos bajar de la p´agina oficial ([Ste07]), en una etiqueta