ACM / Crossroads / Espanol / Xrds12-2 / 

 

Cuando las noticias son más de lo que aparece en los titulares

por Kayre Hylton, Mary Beth Rosson, John Carroll and Craig Ganoe

Traducido por Pier Paolo Guillén Hernández

Introducción:

Para que un ambiente de colaboración tenga éxito, los implicados en esta colaboración deben mantener un cierto nivel de conciencia sobre cómo avanza el proyecto en el que están participando y sobre sus compañeros colaboradores. A esta conciencia se le denomina Conciencia de Actividad (Activity Awareness [3]). Esto implica responder a la interrogante de la conciencia social (¿Quién está alrededor?) como también la de la conciencia de acción (¿Qué está pasando?).

El problema de mantener conciencia en un ambiente de colaboración ha sido tratado frecuentemente, y distintos estilos de sistemas de notificación han sido desarrollados para lograr este propósito. Se ha puesto mucho énfasis en el diseño de la  interfaz. McCrickard et al. [7] describen una interfaz de sistema de notificación basada en el balance de la interrupción de tareas primarias, reacción al aviso, y comprensión de la información recibida. ¿Se debe presentar la información como una diapositiva de Microsoft? [2] ¿Debe ser transparente? [6] ¿Las interrupciones son benéficas o dañinas? ¿Cuándo y cómo deben ocurrir las interrupciones, y cómo debe responder el usuario a ellas? [4, 8].

En lugar de estar preocupado sólo en cómo se muestra la información relativa a la actividad, en esta publicación nos enfocamos en el contenido de esta información. ¿Qué tipo de información necesitan conocer los colaboradores sobre los diferentes tipos de objetos? Exploramos mandando diferentes tipos de información acerca de actividades a colaboradores a través del uso de una fuente RSS. RSS (que es acrónimo de "RDF Site Summary", Resumen de sitio RDF) es una tecnología existente utilizada para mandar información en ítems. La fuente puede estar compuesta por varios ítems, en la cual cada ítem contiene información como puede ser el título, una breve descripción textual, y la fecha asociada con este. La fuente puede también contener un enlace al objeto real al que el ítem representa. Los usuarios pueden suscribirse a una fuente RSS y obtener información periódica sobre actualizaciones de ítems nuevos o modificados. También pueden suscribirse a través de una variedad diversa de clientes RSS, cada uno con su estilo de interfase e identificación única. Este procedimiento puede parecer similar a un sistema avanzado de listas de correos pero en realidad es superior ya que evita el costo de tener un moderador y facilita agregar información dentro y a través de transmisiones [5].

La tecnología RSS es utilizada principalmente para mandar y recibir titulares con los enlaces a la noticia relacionada. Creemos que esta tecnología no está siendo utilizada en todo su potencial, y exploramos el uso de RSS como un sistema de notificación para mantener una conciencia de actividad. Utilizamos RSS 1.0 para investigar. [1].

Panorama:

Recursos Básicos para Grupos Distribuidos de Ambientes Integrados (BRIDGE, por sus siglas en inglés) es un conjunto de herramientas que facilitan el trabajo en colaboración. El Centro de Interacción Hombre - Computadora del Tecnológico de Virginia (CHCI) fue el creador original de BRIDGE, y el laboratorio de Colaboración y Aprendizaje Asistido por Computadora (CSCL) del departamento de Ciencias y Tecnología de la Información (IST) del estado de Pennsylvania continuó con el desarrollo de este. BRIDGE contiene muchos objetos tales como páginas Web, calendarios, carpetas, foros de discusión, gráficas, mapas, y listas de usuarios. Muchos de los proyectos en desarrollo del ambiente BRIDGE hacen uso de las distintas combinaciones de los objetos enlistados en conjunto con otros.

Uno de los proyectos en desarrollo en ambientes BRIDGE por parte del laboratorio CSCL es el de las Visualizaciones de Geo-Colaboración desde Múltiples Perspectivas para la creación de Equipos de Trabajo en Campos Comunes. El proyecto involucra colaboradores locales y remotos, así como el uso de visualizaciones de colaboración para brindar apoyo a equipos sincronizados y distribuidos en la planeación de tareas geo-espaciales. Este tipo de esfuerzos intensos de colaboración se podrían beneficiar del uso de un sistema de notificación. Con uno de estos sistemas, los miembros de un grupo, si quisieran mantener conciencia de sus colaboradores y del progreso del proyecto, no requerirían estar dentro de sesión en el ambiente BRIDGE, revisar manualmente cada objeto para determinar que cambios ha sufrido, y terminar revisando la lista de usuarios para saber quien está disponible y activo en el ambiente.

Nos volveremos a referir a este panorama una vez que hayamos discutido en detalle las metas y el diseño para crear y distribuir contenido a través de nuestro sistema de notificación basado en RSS.

Metas:

La meta de nuestro sistema de notificación basado en RSS es doble. La primera meta es proveer un resumen de actividades. A través de contenido conciso y significativo, esperamos incrementar la conciencia del usuario del estado general del proyecto. Con esto, los usuarios podrán obtener información valiosa de alto nivel sobre las actividades. Además, nuestro sistema debe facilitar la inspección de cambios. El contenido entregado deberá ser suficiente para poder indicar al usuario si el cambio al objeto es de su interés. El usuario deberá ser capaz de acceder a cualquiera de estos objetos y poder investigar con facilidad y a detalle cualquier cambio.

Diseño:

Para el prototipo inicial de este proyecto, decidimos enfocarnos en tres objetivos primordiales de BRIDGE: 1) la Lista de Usuarios, 2) el Calendario y 3) la Página Web. Una Lista de Usuarios BRIDGE muestra la información de acuerdo a los usuarios que estén en sesión, en que momento se encuentran en sesión, si están activos o no en el ambiente BRIDGE, cuánto tiempo han estado inactivos, y cualquier mensaje de estado que pudieran haber incluido para indicar su actividad o localización. Los Calendarios incluyen ítems de calendario, los cuales pueden ser parte de meses, listas de ítems recurrentes, o listas de trabajos por hacer. Las Páginas Web pueden contener datos textuales, etiquetas convencionales de HTML, enlaces a otras páginas, y mensajes con objetos autocontenidos (internos o externos a BRIDGE). Escogimos estos tres objetos porque son ampliamente utilizados dentro de BRIDGE y porque su naturaleza dista mucho una de otra. Proveer a los usuarios con información respecto a la Lista de Usuarios contribuye a una conciencia social, mientras que se puede contribuir a la conciencia de acción con conocimiento de los eventos del Calendario y de los cambios hechos a las representaciones visuales de la información en las Páginas Web.

Listas de Usuarios

Tuvimos que considerar la información que el usuario desea obtener cuando busca en una Lista de Usuarios, y como se puede representar la información de forma condensada y textual. Los usuarios necesitan saber con quienes pueden colaborar y quien está disponible en ese momento para colaborar con otros o contribuir al proyecto. Por lo tanto, llegamos a la conclusión que para nuestro diseño inicial, incluir información tal como si un usuario se encuentra en estado activo deberá tener más relevancia que cuando el usuario entró en sesión. Aun así, algún tipo de indicador que indique el tiempo que lleva el usuario activo o inactivo puede resultar útil. Un usuario podría deducir en cuanta actividad ha participado un usuario comparado con otros, o que tan probable sea que el usuario esté disponible a corto plazo.

La descripción para el ítem que representa la Lista de Usuarios incluye una lista de usuarios activos, en la cual los usuarios que llevan más tiempo en sesión aparecen primero, seguida por una lista de usuario inactivos, en la cual los usuarios que han estado activos más recientemente o con un tiempo menor de inactividad aparecen primero.

Calendarios

Para los objetos que se enfrentan a una conciencia social, tal como la Lista de Usuarios, simplemente representando algunos aspectos de su estado puede llegar a ser suficiente, pero para una colección de eventos como un Calendario, debemos dar más información para que sea útil. Enlistar todos los ítems en un Calendario puede llegar a ser demasiado largo y abrumador para el usuario. La lista puede llegar a contener demasiada información, obligando al usuario a buscar de entre todos los ítems los que son relevantes para él. Una lista de ítems reciente despliega lo que interesa al usuario, en lugar de todo el estado del calendario.

Si los usuarios desean estar conscientes de ítems recientes, ¿desean conocer los últimos ítems que han sido modificados en el Calendario? ¿O desean conocer sobre los cambios que se han hecho en los últimos días? Si lo reciente está basado en el número de cambios, como en el primer caso, tenemos la ventaja de siempre estar conscientes de cuándo y cómo fue cambiado el Calendario, sin importar quién ni cuándo fueron hechos los cambios. Si lo reciente está basado en una cantidad específica de tiempo, tenemos la ventaja de poder atrapar cualquier cambio si por alguna razón hubo una sucesión rápida de estos. Pero corremos el riesgo de reportar mucha o muy poca información porque no estamos especificando un número particular de ítems.

Para resolver este problema con respecto a la información, decidimos utilizar los cambios en los últimos días ya que nos percatamos que la preocupación principal de los usuarios corresponde a la situación actual. Si un Calendario no es actualizado con la suficiente frecuencia, el primer método podría dar demasiada información y volver complicada la lectura. Usuarios potenciales comentaron que les gustaba el hecho de que este método indica explícitamente si ha habido cambios en un período determinado de tiempo. La cantidad óptima de tiempo a utilizar en el Calendario depende del ambiente en cuestión, y basados en el BRIDGE que utilizamos en nuestro laboratorio, optamos por usar los últimos siete días.

El siguiente problema a resolver es precisamente saber qué información es la que el usuario podría querer conocer sobre ítems recientes. Decidimos que el título del ítem es suficientemente descriptivo y podría ser la característica más útil que puede conocer el usuario. Como una actividad involucra tanto personas como acciones, también incluimos qué usuario estuvo involucrado en la creación o modificación del ítem.

Dar una fecha asociada con el ítem también podría resultar útil para ofrecer al usuario una sensación de la actividad que se desarrolló durante el tiempo. Para esto escogimos la fecha de creación o ultima modificación del archivo. Creemos que poder conocer cuáles ítems han sido modificados o creados, y cuándo y por quién fueron añadidos o modificados estos ítems da suficiente información para tener una panorámica global de la actividad. Después de hablar con usuarios potenciales, decidimos también incluir la fecha en la que el evento fue agendado porque los eventos pueden ser programados con antelación, y sólo conocer la fecha del evento puede hacer que sea difícil de localizar en el Calendario. Sin embargo, decidimos mantener el campo de la fecha como la fecha en la que el Calendario fue modificado por última vez, esto significa que un evento es agregado a la descripción y un ítem para un Calendario se informa como actualizado sólo cuando el evento es creado o cambiado, no cuando el evento ocurre; nuestra preocupación principal es la actividad hecha al Calendario y no la actividad que el contenido del Calendario engendra.

Páginas Web

Representar sólo una parte del estado actual de una Página Web, como se hizo con la Lista de Usuarios, no sería muy útil por razones similares a las del Calendario. Aunque las Páginas Web se pueden comparar más con los Calendarios que con las Listas de Usuarios, ya que el conocimiento de los cambios hechos a las páginas contribuye más explícitamente a la conciencia de acción, no podemos representar cambios recientes con los mismos métodos que se utilizaron con el Calendario. Aunque los dos pueden ser muy parecidos en algunos aspectos, son muy diferentes en lo que representan y deben ser tratados de maneras diferentes. Un Calendario es básicamente una colección de ítems. Para saber si un Calendario ha cambiado, significa que uno de estos ítems ha sido creado o (en menor medida) modificado. El cambio es, en esencia, el ítem. Una Página Web, por el otro lado, no es un simple contenedor de subpartes. La Página Web posee contenido que puede ser modificado de formas no triviales. Decir que una Página Web ha cambiado equivale a decir que se ha agregado, quitado o modificado una o todas las partes de información del contenido. El cambio puede ser mínimo, así como enorme.

Por lo tanto, cambios recientes no pueden ser resumidos y agregados; debemos describir sólo un cambio a la vez. Este método tiene más sentido cuando se piensa en la forma en que estos objetos son editados. Para editar un Calendario, un usuario necesita poco más de un minuto para agregar un ítem. Para editar una Página Web, un usuario puede escribir por minutos o incluso horas. Cada edición puede contener varios cambios. Estos cambios son los que interesan a los usuarios además de ser más informativos.

Entonces, nuestra tarea fue determinar que partes principales pueden cambiar en una Página Web y como afectan al documento. La parte más obvia es el texto. Conocer cuánto texto ha sido agregado, removido, o cambiado es de gran utilidad para representar cuánto ha cambiado la Página Web. La parte menos obvia fue determinar el método a usar para medir cambios dentro del texto que tengan sentido para el usuario.

Usar páginas o líneas como unidades de medición sería algo con lo que los usuarios podrían identificarse, ya que la mayoría de las veces nos referimos a los documentos en términos que cuántas páginas o líneas contienen. El problema es que una página o una línea no tiene significado dentro de una Página Web ya que distintas resoluciones de monitor y tamaños de las ventanas del navegador hacen que medir páginas y líneas se vuelva complicado. Utilizar párrafos puede ser también problemático ya que pueden diferir grandemente en tamaños, y saber que un párrafo fue cambiado no nos da una idea de cuánta información fue cambiada, lo que puede llevar a que la información pase desapercibida. Utilizar los caracteres como unidad no daría pie a ambigüedad y permitiría hacer cálculos como porcentaje de cambio, pero este método es de muy bajo nivel como para ser significativo para la mayoría de las personas. El porcentaje de cambio por si solo puede causar confusión porque si una página es lo suficientemente grande, un cambio que puede ser significativo no sería tomado en cuenta ya que representaría un porcentaje muy pequeño de la Página Web.

Decidimos utilizar oraciones como unidades, segmentando al documento con caracteres de fin de oración, como pueden ser los puntos, signos de interrogación, signos de exclamación, y cambios de línea. Esta técnica es la más clara para darnos una idea de cuánta información fue cambiada pero tiene el problema de que ciertos caracteres de fin de oración pueden llegar a utilizarse en otros lugares que no son el fin de una oración. También nos dimos cuenta que las oraciones reflejan más el modelo mental que la mayoría de la personas utiliza al crear datos textuales. Junto con el número de oraciones cambiadas, los primeros cambios se incluyen con la intención de dar una indicación de la naturaleza del conjunto de cambios y sirve como referencia a los usuarios cuando quieren buscar los cambios realizados en la Página Web en cuestión.

Un problema que surge frecuentemente con Páginas Web es que en ocasiones cambian con demasiada frecuencia sin que sufran cambios significativos. Los usuarios tienden a revisar el documento para hacer cambios menores, como lo son arreglar problemas de mayúsculas, agregar signos de puntación o quitar espacios. No sentimos que estos sean contribuciones significantes a la actividad, y avisar al usuario cada vez que uno de estos cambios es efectuado puede llegar a molestar en lugar de mantener un estado de conciencia.

A pesar de que podemos implementar distintos casos a ignorar con los signos de puntuación y los espacios, ¿qué hay de los errores de mecanografiado? Consideramos tener un umbral mínimo para el cambio, con lo cual una página no sería reportada como modificada a menos de que cumpla con un número mínimo de palabras u oraciones. Esta idea no fue implementada porque el tamaño del cambio no siempre es proporcional a su importancia. Unas pocas palabras pueden cambiar completamente el significado de una oración, párrafo o idea, pero no pueden ser distinguidos de arreglar algunos errores de mecanografiado o un cambio pequeño de palabras que no modifiquen el significado. También consideramos utilizar un umbral de tiempo, donde los cambios hechos en un intervalo pequeño no fueran considerados. Decidimos no implementar esta idea ya que puede tomar solo unos segundos borrar una gran parte del contenido de la página o pegar un pedazo grande de información.

Para los ítems que representan los objetos del Calendario o de la Página Web, hicimos uso del campo "creador" que las especificaciones RSS permiten. Con esto insertamos el nombre del usuario que modificó por última vez el objeto. Aunque no todos los lectores RSS tienen soporte para desplegar esta propiedad, sentimos que sería útil para los usuarios si pudieran ver quién hizo el cambio antes de escoger revisarlo. Este método también permite a los usuarios ordenar los ítems de acuerdo con quién fue el autor del cambio.

También trabajamos con algunos usuarios potenciales en el formato de la descripción de modo que la información relevante sea evidente. Para hacer las descripciones fáciles de leer, las organizamos con técnicas como la medida de cambio de las Páginas Web y los nombres de los ítems agregados o modificados para los Calendarios.

Para medir si el diseño para nuestro sistema de notificación RSS estaba alcanzando las metas propuestas, pedimos información de nuevas cuentas de usuarios potenciales. La mayoría consideró que las descripciones eran un indicador razonablemente de alto nivel de cuánto había cambiado el objeto. Para las Páginas Web, las medidas cuantitativas de texto, enlaces, y objetos cambiados resultaron ser útiles para la mayoría de los usuarios. También indicaron que la información en las descripciones era suficiente como para determinar si necesitaban ver el objeto real en detalle. Algunos usuarios se apoyaron en el número de oraciones, enlaces y objetos autocontenidos que fueron cambiados, mientras que otros lo hicieron más en los primeros cambios para tomar la decisión. También encontraron útil saber si una página era nueva o simplemente modificada para determinar el significado del cambio. Algunos de los usuarios potenciales con los que platicamos sintieron que las descripciones les ayudaron a encontrar los cambios en las Páginas Web. Encontraron que conocer dónde comenzaron los cambios y una estimación de cuantos cambios habían sido realizados les resultaba útil. Una usuaria mencionó que las Páginas Web tienden a estar organizadas por secciones con títulos y listas. También mencionó que conocer el número exacto de líneas que cambiaron la ayudaban a encontrar la sección correcta. La mayoría de los usuarios, sin embargo, sintieron que conocer cuales fueron los cambios no los ayudaba a encontrarlos. De notar, fue que uno de estos usuarios utilizó el buscador del navegador para encontrar los cambios, por lo que en realidad si tuvo que utilizarlos. Sentimos que en la práctica, estar familiarizados con una Página Web en particular facilitará a los usuarios encontrar los cambios.

Implementación:

Implementamos nuestro sistema de notificación RSS y creamos una fuente de transmisión RSS para reportar cambios en los objetos relacionados con el proyecto del Visualizador de Geo-Colaboración mencionado en el panorama. La imagen muestra como los cambios en Páginas Web y Calendarios aparecen en la transmisión utilizando el lector RSS que tiene incluido Safari. La primera descripción muestra los cambios hechos al Calendario en los últimos siete días. Se muestra cada cambio en el título del ítem, la fecha en la que el evento está programado, la fecha en la que cada cambio fue realizado, y el usuario que hizo el cambio. La segunda descripción muestra los cambios hechos a la Página Web. Incluye el número de oraciones que han sido agregadas, quitadas, o cambiadas y las primeras tres oraciones distintas. El número de enlaces y objetos autocontenidos agregados, removidos, o cambiados (no se muestra en la imagen) también se incluye, seguidos por el usuario que hizo los cambios.

Imagen 1: Items representando objetos BRIDGE en una fuente RSS, como se muestra en el lector RSS incluido en Safari.

Surgieron algunos problemas adicionales que no previmos en el diseño original de nuestro sistema de notificación. En la práctica, notamos que algunas veces cuando se realizaba una junta, un usuario se registraba en sesión, pero otro (o varios más) era el que realizaba los cambios. La fuente RSS obtiene la información de BRIDGE, el cual registra como editor del objeto a quién se registró en sesión. No podemos editar la fuente para que actúe de forma diferente, pero quizás BRIDGE podría ser cambiado para aceptar el registro de una sesión con varios usuarios. Una solución simple podría ser crear cuentas de usuario para grupos.

Otro problema que se presentó fue la utilidad de las descripciones de las Listas de Usuarios. Saber quién se encuentra conectado podría indicar productividad o por lo menos interés si supiéramos que están viendo objetos relacionados con el proyecto. La Lista de Usuarios muestra usuarios que se encuentran en sesión en cualquier parte de BRIDGE. Quizás este acomodo podría ser cambiado de tal manera que pudiéramos determinar si el usuario está viendo alguno de los archivos que nuestra fuente de RSS está viendo.

Muchos usuarios dijeron que les gustaría tener la posibilidad de ir a una Página Web y ver todos los cambios marcados. Esta función se encuentra presente en otras aplicaciones de software con las cuales el usuario puede estar familiarizado, por ejemplo MS Word. Esta función sin lugar a dudas es útil, pero va más allá del alcance de este proyecto. Quizás la forma en que BRIDGE funciona podría ser cambiada para permitir esta función, ya que sería útil su uso de manera conjunta a la tecnología RSS.

Conclusión:

A través de la implementación y los comentarios de los usuarios, encontramos que nuestro sistema de notificación RSS tuvo cierto éxito al cumplir las metas para las que fue creado. El sistema probó ser muy útil como un resumen de actividades y permite a los usuarios conocer de un vistazo cuáles objetos han sido cambiado y saber aproximadamente qué tan grande ha sido el cambio. Este sistema es particularmente útil para usuarios en posiciones de supervisión, ya que su preocupación principal son los niveles de actividad y no los cambios específicos. El sistema puede resultar más limitado en ayudar a inspeccionar los cambios. Las medidas cuantitativas de cambio fueron indicadores valiosos para determinar si el cambio a un objeto era significativo y valía la pena inspeccionarlo. Tener un enlace directo al objeto en cuestión fue útil a la vez que ayudaba a ahorrar tiempo. Sin embargo, la fuente RSS no siempre fue útil cuando se buscaban los cambios hecho en una página.

Mientras el uso de RSS se incremente, esperamos que más personas tomen ventaja de sus capacidades de hacer mucho más que sólo reportar titulares. Debido al hecho de que la naturaleza de nuestro uso propuesto, reportar cambios a objetos que contienen datos, difiere mucho de reportar nuevos artículos, para llegar a ser más eficientes, el sistema de notificación RSS podría ser utilizado junto con otros sistemas de notificación, como los son los que marcan los cambios hechos a los documentos.

Agradecimientos:

Quisiéramos agradecer al Comité de la Asociación de Investigación en Computación en el Status de Mujeres en Investigación Computacional por apoyar a Kayre Hylton en su investigación en la Universidad Estatal de Pennsylvania durante el verano del 2005 a través de su Proyecto de Mentores Distribuidos.

Referencias:

1

Beged-Dov, G., D. Brickley, R. Dornfest, I. Davis, L. Dodds, J. Eisenzopf, David Galbraith, R.V. Guha, Ken MacLeod, Eric Miller, Aaron Swartz, and Eric van der Vlist. RSS 1.0 specification: RSS-DEV Group, 2000.

2

Cadiz, J.J., Venolia, G.D., Jancke, G., and Gupta, A. Designing and deploying an information awareness interface. In Proceedings of the 2002 ACM Conference on Computer Supported Cooperative Work (CSCW 2002), (Nov. 16-20, Luiziana, EUA) 2002, pp. 314-323.

3

Carroll, J.M., Neale, D.C., Isenhour, P.L., Rosson, M.B. and McCrickard, D.S. Notification and Awareness: Synchronizing task-oriented collaborative activity. International Journal of Human-Computer Studies. 58, 5 (2003), 605-632.

4

Cutrell, E., Czerwinski, M. and Horvitz, E. Notification, Disruption, and Memory: Effects of Messaging Interruptions on Memory and Performance. In Proceedings of IFIP Conference on Human-Computer Interaction (INTERACT 2001) (July 9-13, Tokyo, Japan) 2001, pp. 263-269.

5

Gordon, T. F. An Open, Scalable and Distributed Platform for Public Discourse. Informatik. 2 (2003), 232-234.

6

Harrison, B., Ishii, H., Vicente, K., and Buxton, W. Transparent Layered User Interfaces: An Evaluation of a Display Design to Enhance Focused and Divided Attention. In Proceedings of the ACM Conference on Human Factors in Computing Systems (CHI 1995), (May 9-11, Denver, CO.)1995, pp. 317-324.

7

McCrickard, D.S., Catrambone, R., Chewar, C. M., and Stasko, J.T. (2003). Establishing Tradeoffs that Leverage Attention for Utility: Empirically Evaluating Information Display in Notification Systems. International Journal of Human-Computer Studies. 8, 5 (2003) 547­582.

8

McFarlane, D.C. (1999). Coordinating the interruption of people in human-computer interaction. In Proceedings of IFIP Conference on Human-Computer Interaction (INTERACT 1999) (Aug. 30- Sept. 3, Edinburgh, Scotland) 1999, pp. 295-303.

Biografías:

Kayre Hylton (khylton@andrew.cmu.edu) obtuvo su Licenciatura en Ciencias de la Computación por parte del Instituto Tecnológico de Georgia, y se encuentra realizando una Maestría en Interacción Hombre Computadora por la Universidad de Carnegie Mellon. En el verano, entre sus estudios, realizó una investigación en la Universidad Estatal de Pennsylvania, en el Laboratorio de Ciencias y Tecnología de la Información, para el Aprendizaje y Colaboración asistido por Computadoras.

Mary Beth Rosson (mrosson@ist.psu.edu) es profesora de Ciencias y Tecnología de la Información en la Universidad Estatal de Pennsylvania. Es codirectora del Laboratorio de Ciencias y Tecnología de la Información, para el Aprendizaje y Colaboración asistido por Computadoras.

John Carroll (jcarroll@ist.psu.edu) es el profesor de Ciencias y Tecnología de la Información de la cátedra Edward M. Frymoyer en la Universidad Estatal de Pennsylvania. Es el otro codirector de la escuela del Laboratorio de Ciencias y Tecnología de la Información, para el Aprendizaje y Colaboración asistido por Computadoras.

Craig Ganoe (cganoe@psu.edu) está en su último año como Investigador Asociado en la Universidad Estatal de Pennsylvania, en el Laboratorio de Ciencias y Tecnología de la Información, para el Aprendizaje y Colaboración asistido por Computadoras.

Traductor

Pier Paolo Guillén Hernández (pier@nibbo.net) está trabajando actualmente en su tesis de grado de Ingeniería Electrónica en la Universidad Bonaterra. Es también Programming Director y cofundador de Nibbo Studios, una empresa mexicana de desarrollo de videojuegos.

Nota: Se usó la frase castellana "fuente RSS" por la inglesa "RSS feed"; se aceptan sugerencias.