Artículo:
Challenges for Ubicomp Evaluation
Autores: Scott Carter and Jennifer Mankoff
Introducción
La tecnología ubicua de diferentes maneras esta presente en cualquier parte del mundo. El estudio de la computación ubicua (Ubicomp) tiene que ver con permitir que las aplicaciones más útiles de esta tecnología sean factibles de construir y agradable de usar.
Pero es necesario evaluar si estas tecnologías son de verdad útiles o no, si sin utilizables o si son lo que la gente en realidad necesita, todos estos cuestionamientos son en particular difíciles de poder evaluar en las primeras etapas de diseño.
En este trabajo se muestran un estudio de caso de tres diferentes sistemas de Ubicomp que fueron evaluados en varias etapas de diseño y se describe brevemente su aplicación y la evaluación que utilizaron para poder aprender mejor cómo las técnicas de evaluación deben de estar evolucionando para el dominio de Ubicomp, y se sugieren cuatro desafíos para la evaluación.
Incluso en el laboratorio, es difícil llevar a cabo una evaluación controlada de un Ubicomp, porque las aplicaciones Ubicomp están generalmente diseñadas para ser integradas en las aplicaciones y tareas complejas. Esto significa que, en ausencia de técnicas de evaluación que no dependan de los sistemas completos, de trabajo, actualmente se debe realizar un esfuerzo importante en una aplicación antes de probarla. La velocidad y el costo fueron calificados como dos de las tres principales razones para utilizar estas técnicas que enseguida se mencionaran.
Tres casos de estudio
Aqui se presentan tres casos de estudio de evaluaciones que se hicieron de sistemas ubicuos. El primero "PALplates" fue desarrollado en 1997. El segundo es un sistema de "asesoramiento nutricional", que se encuentra en fase de desarrollo. Y el tercero "Hebb" que ha sido desarrollado y evaluado desde el 2002 hasta el 2004. Se muestran estos tres casos con el objetivo de ver las dificultades que se interponen en la evaluación de los sistemas ubicuos.
PALplates
Este sistema esta destinado a apoyar a los trabajadores de oficina en hacer las tareas cotidianas mediante la presentación de información clave y los servicios en los lugares donde eran más necesarios.
La evaluación de PALplates tomó la forma de un prototipo de papel. Los prototipos de papel se realizan tradicionalmente esbozando todos los cuadros de diálogo, pantallas y otros elementos interactivos de una interfaz gráfica de usuario en papel. Un hombre simula entonces las reacciones de un equipo como los usuarios al ejecutar tareas predefinidas utilizando el papel interfaz. Esta técnica es eficaz, y tan rápida, una de las razones es tan rápida es que no requiere ningún desarrollo de código, pero es capaz de proporcionar información temprana sobre las ideas de diseño. También se puede utilizar para implicar a los usuarios finales en el diseño.
Se publicaron las interfaces de papel en los lugares de interés (puertas de las oficinas, salas comunes y de conferencias) alrededor de un lugar de oficina. La gente podría escribir notas, o hacer pedidos. También pueden hacer sugerencias y reservas y ver las noticias locales.
Dos veces al día, un miembro voluntario de la red, visitaría cada pantalla y ejecutaría las solicitudes.
Por ejemplo, una nota puede ser recogida y se entrega en la pantalla para la que fue dirigida.
Se encontró que a pesar de que al PALplates le faltaba características importantes que estarían presentes en una completa solicitud hecha y derecha, la gente lo utilizaba. PALplate en diferentes lugares se utilizaba para diferentes tareas. Por ejemplo, en la pantalla situada en la cocina se utiliza sobre todo para ordenar utensilios de cocina.
Lecciones aprendidas
No escalar en el tiempo-falta de capacidad de respuesta. A pesar del éxito con PALplates, se cree que la creación de un prototipo de papel tiene algunas limitaciones graves. En particular, en su forma actual, prototipo en papel falla en manejar adecuadamente la escala. Por ejemplo, en PALplates sólo podía actualizar las pantallas dos veces al día. Y no se pudo simular un control más preciso, como actualizar el estado de la impresora cada vez que un trabajo se inició o se terminó, o la actualización de un mapa que muestra la ubicación actual de todos en la construcción.
Los errores rara vez ocurrieron. Con "agentes" humanos era difícil demostrar los errores reales en el proyecto de PALplates. Dado el número de voluntarios necesarios para ejecutar el sistema, algo más sofisticada habría requerido mucho entrenamiento. Además, los participantes sabían los seres humanos fueron involucrados, y se espera un comportamiento muy preciso y consistente.
Seguimiento nutricional
Este sistema esta hecho para ayudar a reducir la obesidad y diferentes problemas de salud. Mucha gente no conoce cuanto hay que comer de frutas, granos, vegetales y grasas para hacer la dieta. 7 de 10 personas americanas creen que eso es complicado. Y tener la ayuda de la computadora parece complicado, existen soluciones que pueden ayudar a comer sanamente. Entonces este sistema es una aplicación no muy cara, que recopila datos sobre lo que los miembros del hogar están comprando y consumiendo, y utiliza simple y persuasivas técnicas para sugerir posibles cambios.
Lo primero que se hiso fueron encuestas y entrevistas para guiar las primeras etapas del diseño. También se desarrollaron y probaron prototipos en papel de esta solicitud. Se ha iterado en esta interfaz basada en una serie de estudios informales en las que se le pidió a la gente a comentar diseños esbozados.
Se siguió durante tres semanas en las casas de los tres participantes. En la implementación una de dos semanas se reunieron datos, seguido por tres semanas de uso en el campo, seguido por entrevistas.
Los resultados fueron mixtos. Aunque se han estudiado usuarios, se habló con ellos, y se trató de interconectar con ellos en el papel, no fue hasta la implementación que se puedieron enterar de lo mal que la interfaz cumplió con sus necesidades. La cantidad de esfuerzo de desarrollo, y los altos costos del estudio están totalmente fuera de proporción con una primera iteración. Y los sujetos que usaron el sistema dijeron que tres semanas era apenas el tiempo suficiente para que se sientan cómodos con el sistema.
Lecciones aprendidas
No se puede medir la capacidad de integrar discretamente La lección más importante que se aprendió del proyecto de seguimiento de la nutrición fue la dificultad de evaluar con precisión los problemas y el potencial de un sistema que se debe integrar discretamente en una actividad de la vida diaria. El prototipo de papel no se alerta que el sistema no se integran bien en los patrones de compra.
No escalar a través de los datos - no se pudo hacer la prueba de seguimiento de las recomendaciones nutricionales El papel prototipo también no pudo ayudar para la evaluación de la calidad de las recomendaciones.
No se puede medir el impacto de los errores del sistema de alimentación estaba plagado de ambigüedades y errores. la información más útil fue enterarse que no eran las recomendaciones de la calidad suficiente. Sin embargo, hasta que el sistema no estuviera en uso fácilmente no se podía decir cuál era el nivel de ambigüedad para los usuarios.
hebb
Hebb es un sistema Ubicomp diseñado para capturar y transmitir los intereses compartidos. Este sistema surgió de una serie de entrevistas que se llevaron a cabo con miembros de seis grupos de trabajo pequeños. A partir de estas entrevistas, se encontró que los beneficios de la función de proximidad a menudo no se extienden más allá del grupo. Intereses compartidos con grupos cercanos o personas con intereses similares pasan desapercibidos, lo que limita las posibilidades de comunicación y colaboración. En respuesta a este problema, se ha diseñado un sistema que detecta los intereses de los miembros del grupo a través del correo electrónico software de análisis y muestra las relaciones entre los miembros de las demostraciones públicas y privadas para fomentar la conversación sobre esos temas.
El sistema hebb incluye sensores de presencia y exhibiciones públicas y privadas. Cada componente registra con otros componentes para recibir datos etiquetados semánticamente.
El sensor de interés genera eventos de imagen, nombre y la palabra clave, correspondiente a una imagen del usuario del sensor de interés, el nombre del usuario, palabras clave (generado a partir del algoritmo descrito en la siguiente sección) así como los datos del documento completo cifrados (para su uso en PDAs personales).
Se reclutaron varios grupos diferentes de para utilizar el sistema, y se desplegaron dos centros de investigación en el mismo departamento. Se ha sido capaz de instalar el sistema con un grupo inmediato, pero la instalación con el otro grupo se detuvo. Algunos grupos rechazaron el sistema en absoluto, porque sería "aumentar el correo basura", y que las demostraciones públicas sería "terminar por mostrar anuncios al azar". Entrevistas con estos grupos demostraron que estas respuestas parecen reflejar más una ideología aceptada sobre la tecnología de experiencias particulares. Cabe señalar que muchos de estos grupos tienen poca experiencia con las nuevas tecnologías. Las entrevistas revelaron que estos grupos compartían una gran cantidad de experiencias prácticas de trabajo, pero sin embargo no se comunican uno al otro. Por lo tanto, los dos grupos parecían un buen partido para el sistema de hebb.
Lecciones aprendidas
Adaptar a los usuarios En particular, se encontró que las actitudes de los usuarios hacia el sistema se hizo menos notable y más discreta. Por ejemplo, durante la etapa de desarrollo y al comienzo de las implementaciones, las actitudes del usuario hacia el Sensor de interés fueron negativas por escépticos. Sin embargo, su actitud cambió significativamente durante el curso del desarrollo de la prueba.
La percepción de la privacidad y la utilidad evolucionan Se encontró que el equilibrio entre la privacidad y utilidad fue siempre en constante cambio durante el estudio. En un primer momento, se encontró que el hecho de que las pantallas mostraron poca información al público mitigaría los problemas de privacidad. Pero en realidad los usuarios estaban tan preocupados con la minería de datos realizada por el sensor de interés que la exposición pública no era importante. Esto cambió todo el estudio, sin embargo, y como se mencionó anteriormente algunos usuarios comenzaron a discutir una mayor fidelidad contenido personal que deberá aparecer en demostraciones públicas hacia el final de la implementación.
Cambios en general
Muchas de las lecciones aprendidas de la evaluación de los tres estudios de casos se superponen. En particular, los problemas de escala aparecieron en las tres evaluaciones. Las cuestiones relativas a la aceptabilidad y la ocurrencia de errores y la ambigüedad apareció también en todas las evaluaciones. Las cuestiones relativas a la integración en la vida cotidiana se presentó en dos evaluaciones. Estas observaciones llevan a sugerir desafíos para Evaluación Ubicomp.
Reto # 1 - Aplicación de las métricas
Las aplicaciones ubicuas pueden no tener los mismos objetivos que otras tecnologías y por lo tanto pueden requerir la medición de diferentes parámetros de éxito. Se han identificado varios indicadores importantes para la evaluación Ubicomp, y también para señalar que las cifras pueden variar de adecuación por el sistema que está siendo evaluado. El análisis de los estudios de caso reveló varios importantes indicadores de evaluación que no se han probado originalmente, como la comodidad, la intimidad, la previsibilidad, la precisión, la adopción y la adaptabilidad. Pero la idoneidad de cada métrica varía entre los estudios. Por ejemplo, una mejor medición a priori del valor de la adopción del sistema de seguimiento de la nutrición para un usuario específico habría llevado a los datos más útiles. Por el contrario, PALPlates podrían haber beneficiado más de las medidas de control de usuario y personalización. También, debido a la transferencia implícita de la información personal, la privacidad era un indicador mucho más importante para Hebb que para los otros estudios. Dado el gran número de indicadores que se podrían medir en la evaluación de un sistema Ubicomp sería difícil medir a todos y por lo tanto más trabajo que hay que hacer para entender bajo qué condiciones cada métrica es apropiado.
Reto # 2 - Escala
Los sistemas Ubicomp normalmente deben manejar los problemas de escala que no se enfrentan los sistemas de escritorio, que funciona a través de múltiples dispositivos, ubicaciones o durante largos períodos de tiempo o entre varios usuarios. Un sistema Ubicomp temprana desplegado en un aula, eClass, incluido múltiples pantallas proyectadas para el instructor, una pizarra, retro-proyección en pantalla grande, pen tablets para estudiantes, videos y grabaciones de audio, y el acceso basado en web a los datos registrados en un momento posterior.
Mirando hacia atrás en las lecciones aprendidas, los problemas de escala surgieron una y otra vez. Por ejemplo los prototipos tenían problemas de escala a través del tiempo y la cantidad de datos. Otras técnicas de etapa temprana como evaluación heurística se enfrentaría a problemas similares en escala a través del número de dispositivos y escenarios para los que Sistemas Ubicomp se pueden diseñar. En el desarrollo pareció difícil de escalar el número de dispositivos y los usuarios debido a los muchos retos de mantenimiento y apoyo de nuestro sistema. Se aprendió también a la fase de despliegue que se puede ayudar a acelerar la aceptación y ayudar a mitigar el tiempo dedicado al sistema.
Reto # 3 - La ambigüedad
En los estudios de casos anteriores se muestra que la ambigüedad y los errores son problemas serios e importantes para determinar el éxito del sistema y problemas de usabilidad comprensión. Cuando los sistemas Ubicomp dependen de reconocimiento, aprendizaje automático, u otros componentes que propician ambigüedad propensa a las técnicas de evaluación deben proporcionar información sobre los niveles aceptables de exactitud. Esta información también es necesaria para entender la recuperación de errores.
Durante la implementación, se necesita ayuda para mitigar los inevitables errores y malentendidos. Si la ambigüedad no ha sido perfeccionado a un nivel aceptable, es probable que los usuarios decidan rápidamente que un sistema no vale la pena utilizar.
Conclusiones
En este trabajo se puede ver que la evaluación es un problema para el desarrollo de aplicaciones de computación ubicua, en particular en las primeras etapas de diseño. Debido a la escasez de técnicas disponibles, los desarrolladores de aplicaciones Ubicomp raramente cambian sus diseños debido a las evaluaciones. Desde una perspectiva de desarrollo, este hace más difícil el desarrollo de aplicaciones que realmente satisfagan las necesidades de sus usuarios finales. La contribución de este trabajo es un estudio de los problemas que surgieron en la evaluación de tres sistemas Ubicomp diferentes en diferentes etapas del diseño y los retos derivados de la evaluación Ubicomp que surgió de esas cuestiones.
Estos son claramente problemas a los que un desarrollador se enfrenta al crear sistemas ubicuos, ya que la usabilidad de ellos se analiza y se hace de diferente manera a cualquier sistema de escritorio.
