Thematic data analysis and case study approach: an overview

Si bien este formato que parece haber nacido casi paralelamente con los blogs tiene sus orígenes en el año 1999, los que empezaron a explotar este formato fue la gente de Nescape. Sin embargo no fue hasta hace pocos años que cobró mayor popularidad.

La mayoría de los usuarios de Internet no conoce los feeds RSS, pero nos pareció la mejor opción para dar a conocer las notificaciones ya que cuando leemos en una web "Syndicate this site" con un icono XML o RSS, significa que puedes leer las noticias que publican en ese sitio web sin

necesidad de acceder a la página. Ventajas? muchas, la principal es que sólo te avisará cuando se produzcan cambios en la página, sin necesidad de acceder a la misma, la aplicación trabaja para nosotros pero solo se hace presente si hay algo que el usuario necesite saber. Eso era exactamente lo que queríamos ofrecer en nuestra aplicación.

Consta fundamentalmente de:

➢ Channel, que representa la fuente de las noticias. ➢ Title, titulo del canal.

➢ Link, vínculo del canal.

➢ Description, descripción del canal.

Si bien los canales RSS son aceptados por la mayoría de navegadores:Firefox, Opera, MacOS... otros, como es el caso de Internet Explorer solo dispone de lector de RSS a partir de su versión 7. Como ya sabemos las notificaciones por canal RSS se encuentra codificada en formato XML. Presentarle al usuario final la información en este formato, y solo en este, no seria lo más apropiado, ya que requiere un conocimiento de la estructura del formato y el significado de cada un de los ítems que se pueda encontrar. Así pues, las notificaciones mostradas con este formato deberán recibir algún tipo de transformación para hacerlas completamente fáciles de ver para el usuario sin que este necesite disponer de ningún tipo de conocimiento extra sobre esta materia.

6.2.9.1. Maneras de mostrar el RSS

Hemos querido usar RSS por las facilidades que da al usuario final. Por este motivo hemos creado dos métodos para ver nuestras notificaciones siempre y cuando el método de notificación sea RSS:

1. A través del SGD. 2. Sindicándose.

6.2.9.1.1 A través del SGD

Sin perder de vista nuestra Gestión de Documentación, era imposible imaginarnos unas notificaciones vía RSS sin contar con el SGD.

Por este motivo se brinda la posibilidad de disponer de un link directo en el cual se muestran los eventos que han ocurrido y que es necesario conocer. En esta página se crea el XML con todos los

títulos de los eventos que han ocurrido.

Si bien el lenguaje XML puede resultar un tanto descorazonador a primera vista, para un usuario sin conocimientos en este tema, se ha usado la estructura más simple, de este modo con una visión un poco mas profunda al XML permite comprender a cualquier usuario las notificaciones.

Pero este método de información depende directamente del trabajador/a, es él el que debe entrar en el SGD, iniciar sesión con su nombre de usuario y su password y acceder a la Gestión de Eventos y posteriormente al canal RSS.

Figura 2.28. Navegar del GPEvents.

Al hacer clic sobre el icono podemos acceder al código XML: <rss version="2.0">

<channel>

<title>Eventos del SGD</title> <link>http://wsi-shuttle/sgd/</link> <language>es-CL</language>

<description>Notificacion de Eventos ocurridos en el SGD</description> <generator>Autor del RSS</generator>

<item> <title>Primera prueba</title> <description/> <link> http://wsi-shuttle/sgd/Eventos/Mostrar_Evento.php?uid=400&Id_notify=2&Id_root=1 </link> <pubDate/> <category/> </item> <item> <title>Tercer Evento</title> <description/> <link> http://wsi-shuttle/sgd/Eventos/Mostrar_Evento.php?uid=400&Id_notify=10&Id_root=3 </link> <pubDate/> <category/> </item> <item> <title>Cuarto Evento</title> <description/> <link> http://wsi-shuttle/sgd/Eventos/Mostrar_Evento.php?uid=400&Id_notify=12&Id_root=4 </link>

<pubDate/> <category/> </item> </channel> </rss>

Una de las ventajosas características que presenta el formato XML es que separa al contenido del estilo de visualización. Esto quiere decir que un mismo documento en formato XML lo podemos presentar en muchos estilos y formatos diferentes.

Debido al entorno en el que se llevará a termino el trabajo con este tipo de notificaciones, nuestro interés se centra en poder mostrar estas notificaciones en formato HTML, para que se integre perfectamente con las especificaciones de la aplicación de la que formará parte: el Sistema de Gestión Documental (SGD) así como con nuestra primera parte GPEvents-Listas de Distribución.. Esta característica del XML, es una prioridad que hemos estado aplicando en todo nuestro programa, hemos diferenciado en todo momento las página php de las html, y el estilo lo hemos añadido con hojas de estilo en cascada CSS.

6.2.9.1.2. Sindicándose

Si la opción de ver el código XML no les parece alentadora a nuestros usuarios, les damos la posibilidad de que los usuarios se apunten, redifusionen o sindicalicen a nuestro/sus eventos. Para ello es necesario solo unos pequeños pasos que nos permitirán crear un marcador dinámico:

1. En el navegador, al lado se nuestra URL aparecerá un icono RSS:

2. Si clicamos con el botón izquierdo del ratón sobre el icono RSS nos aparecerá un recuadro en el que se nos permite poner un título, por defecto aparece predefinido: Eventos del SGD. Y también permite decidir donde creamos el marcador dinámico:

 Marcadores

 Barra de herramientas de marcadores  Enlaces Firefox y Mozilla

 Bookmarks Toolbar Folder  Búsquedas rápidas

3. Una vez determinado el título y donde guardarlo basta con aceptar y el marcador dinámico ya está creado. Solo hace falta clicar con el botón izquierdo sobre el para disponer de los títulos de los Eventos.

Figura 2.29. Crear marcador dinámico.

Hasta aquí no hay problemas, cada usurario de manera independiente podrá ver los últimos eventos ocurridos en el SGD. Sólo con un clic en su marcador dinámico les abrirá una lista con lo más último. En esta lista nos aparecerán los títulos de los Eventos, será necesario un clic en el título para disponer de mayor información sobre el Evento en cuestión.

Figura 2.30. Ampliación del Evento ocurrido en el SGD.

De esta manera el trabajador/a no necesitará acceder al SGD para comprobar si los eventos que el creó han ocurrido, sólo será necesario mirar el marcador dinámico y ver si hay cambios.

6.2.9.2. Seguridad en el RSS

La idea de mostrar los títulos y ampliar la información en el momento que el usuario final lo requiera nos presentó otro gran reto en cuestión de de seguridad.

En un principio los canales RSS están pensados para ofrecer las noticias a los usuarios que se sindicalizen al canal, ya sea un periódico o cualquier medio de comunicación en la red. Estos canales ofrecen todo a todos los usuarios, sin restricciones de ningún tipo. Ya sabemos que el SGD dispone de un sistema de seguridad complejo en referencia a los permisos de acceso de cada usuario, así que la idea preconcebida del RSS de mostrar todo a todos no se adapta a nuestras necesidades. Todo y seguir trabajando en dirección al canal RSS creado con XML, se optó por generarlo con php, y así seguir fieles a toda la aplicación.

Pero empecemos por el principio: cada usuario necesita un password y un nombre de usuario para acceder a cada equipo y al navegador de Internet, de esta manera se asegura que cada trabajador acceda a su cuenta de Internet y no a otra. Si bien puede resultar farragoso tener que identificarse cada vez, asegura que un usuario no trabaje con la cuenta de otro o en el equipo de otro.

Usando esta ventaja de seguridad y aprovechando la posibilidad de personalizar la barra de herramientas, cada usuario dispondrá de su marcador dinámico en su navegador. La creación de cada marcador dinámico viene con dos variantes:

✔ El Id del usuario que lo crea.

✔ Una contraseña creada especialmente para tal fin.

Por que la contraseña si ya hemos pasado el password y el nombre de usuario del navegador y del equipo? Si nos situamos sobre el marcador dinámico y miramos sus propiedades, podemos ver los parámetros que se pasan.

Si un usuario quisiera controlar las notificaciones de otro usuario y supiera su Id, podría dirigirse al marcador, cambiar el valor de las variables y acceder a una información que no le corresponde. Para evitar esto, se crea una contraseña incodificable para cada Id de usuario, y es esta contraseña la que asegura que ningún trabajador/a intente saber aquello que no debe. Por mucho que cambie el Id también deberá crear su contraseña, una contraseña creada con MD5 y que es incodificable. Las posibilidades que el usuario pueda saber como creamos la contraseña son nulas.

Al clicar sobre el marcador es llamada una página php donde, después de comprobar que la contraseña coincida con la enviada, eso si usando el Id del usuario, genera con php la página XML. Al general el canal con php podemos controlar la consulta que realizamos a la tabla de lo que hay que notificar usando 'where' y mostrando a cada usuario aquello que quiere saber y no más de lo que puede saber.