Martin Montero Cristina TFG
Martin Montero Cristina TFG
Martin Montero Cristina TFG
Gracias a todas las personas que en el desarrollo de esta Trabajo Fin de Grado me han
ayudado a aprender. En primer lugar, quisiera expresar mi agradecimiento de modo
especial a la Tutora del Trabajo: Silvia Teresita Acuña Castillo, Doctora de la
Universidad Autónoma de Madrid, por sus valiosas sugerencias, su extraordinaria
capacidad de organización y por la ayuda constante recibida. Su apoyo incondicional,
ánimo e implicación durante los períodos de planteamiento y elaboración de este arduo
trabajo han sido vitales para que el esfuerzo realizado se materializase en todas estas
páginas.
Agradecer también las facilidades brindadas por el jefe del proyecto FreeMind Christian
Foltin y al jefe del proyecto OpenOffice Writer Rob Weir, que han facilitado los
recursos necesarios para realizar el trabajo y por permitir participar en sus proyectos.
No menos importante han sido la colaboración brindada por los usuarios de FreeMind y
de OpenOffice Writer, gracias por el esfuerzo que realizaron para planificar una hora de
trabajo. También agradecer a amigos y familiares por participar en este trabajo así como
a todos los estudiantes de grado y postgrado, en concreto a MSc John Wilmar Castro y
Olympia Muruzábal por su ayuda en la realización de este trabajo.
Debido al crecimiento de los usuarios de aplicaciones open source software (OSS) que
no son desarrolladores y a que las empresas y organizaciones cada vez más están usando
aplicaciones OSS, surge la necesidad y el interés por desarrollar OSS usable. Sin
embargo, hasta ahora los desarrollos de OSS no han utilizado técnicas de usabilidad y la
mayoría de ellas requieren contextos de desarrollo que la construcción de OSS no
satisface. Además, no está claro cuáles técnicas de usabilidad aplicar en cada actividad
y cómo utilizar las técnicas de usabilidad en los desarrollos OSS.
Este análisis nos permite obtener una visión integrada de cuáles son las técnicas de
usabilidad, pensadas para desarrollos tradicionales, que están siendo incorporadas por la
comunidad OSS en su proceso de desarrollo. Para el análisis de las técnicas se utiliza un
catálogo existente de técnicas recomendadas por la disciplina Interacción Persona-
Ordenador (IPO) para mejorar la usabilidad. Posteriormente, se seleccionan y aplican
cuatro de estas técnicas tanto a usuarios junior como a usuarios senior: observación
directa, observación remota, información post-test y encuesta de evaluación para
determinar el nivel de usabilidad de las herramientas FreeMind y OpenOffice Writer.
En este trabajo, las técnicas de usabilidad se han determinado para las actividades IPO
que han sido encajadas teniendo en cuenta tipos genéricos de actividades de la
disciplina Ingeniería del Software (IS): ingeniería de requisitos, diseño y evaluación.
Las técnicas de usabilidad de ingeniería de requisitos incorporadas por OSS son:
análisis competitivo, perfiles de usuario, Personas, tormenta de ideas visual, prototipos
de papel, especificaciones de usabilidad y evaluación por expertos. Las técnicas de
usabilidad de diseño incorporadas por OSS son: guía de estilo del producto y escenario
de prototipos y prototipado. Dentro de las técnicas de usabilidad de evaluación existen
tres grandes grupos de técnicas para evaluar la usabilidad: evaluación por expertos,
pruebas de usabilidad y estudios de seguimiento de los sistemas instalados. Las técnicas
de este último tipo son las más utilizadas en los proyectos OSS, es decir las técnicas que
la comunidad OSS está incorporando en su proceso de desarrollo son principalmente
técnicas para la evaluación de la usabilidad del producto software. Además, se
seleccionan algunas de estas técnicas de usabilidad utilizadas por la comunidad OSS y
se incorporan en el proceso Apache a saber perfiles de usuario, entrevistas,
cuestionarios, técnicas de prototipado, evaluación heurística y recorridos cognitivos.
Estas técnicas se asignan convenientemente a las etapas del proceso de desarrollo del
proyecto Apache.
Del mismo modo que la comunidad OSS desarrolla software siguiendo su propia
filosofía, alejándose de la manera tradicional de desarrollar software que establece la IS,
es posible incorporar la usabilidad en sus procesos de desarrollo. Es decir, una vez que
la comunidad OSS está tomando conciencia de que la usabilidad es importante, es
posible integrar técnicas de usabilidad pero adaptándolas a su cultura (por ejemplo,
discutir en comunidad los diferentes diseños alternativos de la interfaz de usuario para
una nueva funcionalidad) y al modo en que desarrollan OSS. Este hecho resulta
interesante porque las ideas generadas por la comunidad OSS pueden complementar los
aportes de los expertos en usabilidad de la IPO, integración de la que podrían también
aprovecharse los desarrollos comerciales. Dado que lo que hace un experto es dar su
opinión, en lugar de disponer de una sola opinión (aunque sea de calidad experta) en la
posible adaptación OSS hay muchas personas opinando, trabajando colaborativamente y
con mucho interés y motivación, porque ellos serán directamente los más beneficiados.
Because the number of non-developer users of open source software (OSS) applications
is growing and as companies and organizations are increasingly using OSS applications,
the need and interest in developing usable OSS is emerging. However, OSS
developments have not as yet used usability techniques, most of which require
development contexts that OSS construction does not satisfy. Furthermore, it is unclear
what usability techniques have to be applied in each activity and how to use usability
techniques in OSS development.
The objective of this research is to integrate usability techniques into the OSS
development process and determine the feasibility of applying usability techniques to
the FreeMind and OpenOffice Writer tools. To do this, this research examines the
literature in order to study the OSS development process and some usability techniques
used by the OSS community.
This analysis is useful for gaining an integrated view of which usability techniques
designed for traditional developments are being applied by the OSS community in its
development process. An existing catalogue of techniques recommended by the human-
computer interaction (HCI) discipline to improve usability is used to analyse the
techniques. Subsequently, four of these techniques were selected and applied on both
junior users and senior users: direct observation, remote monitoring, post-test
information and evaluation survey to determine the level of usability of the FreeMind
and OpenOffice Writer tools.
In this research, usability techniques were determined for HCI activities mapped to
generic software engineering (SE) activity types: requirements engineering, design and
evaluation. The requirements engineering usability techniques adopted by OSS are:
competitive analysis, user profiles, Personas, brainstorming of visual ideas, paper
prototypes, usability specification and evaluation by experts. The usability design
techniques incorporated by OSS are: product style guide and prototypes stage and
prototyping. There are three main groups of techniques for evaluating usability within
usability evaluation techniques: expert evaluation, usability testing and follow-up
studies of the installed systems. Usability evaluation techniques are the most commonly
used techniques in OSS projects, that is, the techniques that the OSS community is
adopting in its development process focus on evaluating software product usability. In
addition, some of the usability techniques used by the OSS community were selected
and adopted in the Apache process (i.e., user profiles, interviews, questionnaires,
prototyping techniques, heuristic evaluation and cognitive paths). These techniques are
assigned to the appropriate Apache project development stages.
Considering the results of applying the techniques on the FreeMind and OpenOffice
Writer tools, the findings are that usability improvements are required by both
applications depending on the user type. These improvements are related to the redesign
of the user interface for junior users and of the interaction design for senior users.
According to the results of the usability evaluation survey administered to all users, the
mean values are marginal to consider that the tools are usable. Therefore, usability
Just as the OSS community develops software according to its own philosophy, where it
moves away from the traditional way of developing software established by SE, it is
also capable of adopting usability in its development process. Now that the OSS
community is becoming aware that usability is important, it is ready to adopt usability
techniques that conform to its culture (e.g., discuss in the community the different
alternative user interface designs for a new feature) and the way it develops OSS. This
is interesting because the ideas generated by the OSS community can complement the
contributions of HCI experts to usability. Such integration could also benefit
commercial developments, because, in a possible OSS adaptation, there are many
people (even if they are non-experts) instead of a single expert doing the reviewing and
working collaboratively. Additionally, these people take a lot of interest in what they
are doing and are highly motivated because it is they who stand to benefit most.
CAPÍTULO 1.
INTRODUCCIÓN
Para ello, en este trabajo, se utiliza el método de estudio de casos. El estudio de casos
es un método de investigación que se basa en el principio de explorar algo a través de la
propia experiencia del investigador (investigación empírica), mediante la observación
sin alteración del sujeto u objeto de estudio [Runesson y Höst, 2009]. La información
que se trata en este tipo de estudio se basa en las propias experiencias del investigador.
Para llevar a cabo un estudio de casos, se deben realizar cinco pasos básicos [Runesson
y Höst, 2009]:
Con este método de evaluación del producto, lo que se pretende conseguir es que la
aplicación FreeMind y OpenOffice Writer pueda ser mejorada, a partir de las
recomendaciones dadas en este trabajo, para ser utilizada con eficiencia y satisfacción
tanto por usuarios expertos como noveles en la elaboración de mapas conceptuales y
documentos.
CAPÍTULO 2.
ESTADO DE LA CUESTIÓN
En el PDT se utiliza una variedad de modelos de ciclo de vida del software para su
construcción desde los modelos en cascada iterativos hasta los modelos incrementales
iterativos, mientras que en el PDOSS lo más frecuente es utilizar un modelo evolutivo
(el software evoluciona continuamente según las necesidades de los usuarios) [Potdar y
Chang, 2004].
Una comunidad OSS se suele construir una vez que la primera versión estable de una
aplicación es liberada por sus creadores (uno o dos desarrolladores), es instalada por los
usuarios y estos reportan errores o solicitan nuevas funcionalidades. Cuando esto
ocurre, se inicia el desarrollo distribuido y colaborativo del software mediante los
aportes de la comunidad. Por tanto, el objetivo principal de la comunidad OSS es el
soporte y mantenimiento de las funcionalidades existentes. El proceso de
mantenimiento del PDT no encaja con lo que ocurre en el PDOSS. En el PDOSS no
hay una distinción entre el desarrollo y el mantenimiento post-entrega (correctivo,
adaptativo, perfectivo o preventivo), sino el mantenimiento es evolutivo durante el
desarrollo, por ello el mantenimiento en la comunidad OSS puede ser definido como
reinvención [Castro y Acuña, 2012]. Los proyectos OSS evolucionan a través de
mejoras menores donde participan tanto usuarios como desarrolladores. En algunos
proyectos OSS hay una prioridad establecida para la construcción de las nuevas
funcionalidades, o para decidir qué errores deben resolverse primero de acuerdo a su
severidad. La corrección de errores es una tarea continua en un proyecto OSS y llevado
a cabo por personas a quienes les gustan los desafíos. El PDOSS también cuenta con
actividades análogas al PDT pero desarrolladas de manera diferente, como por ejemplo
que los usuarios pueden contribuir con ideas o con código fuente para corregir los
problemas reportados, o que cualquiera dentro de la comunidad pueda asignar
prioridades a las mejoras del sistema software.
En la actividad de pruebas (en inglés, testing) del PDOSS, los usuarios reportan
errores y actúan como beta testers [Potdar y Chang, 2004]. Cuando un usuario
encuentra un error puede o bien solucionarlo o bien reportárselo a la comunidad [Weber,
2000] para que otro usuario lo solucione. Sin embargo, el PDT utiliza service packs para
solucionar los errores.
El PDT, en general, podríamos decir que tiene un ambiente centralizado mientras que
en el PDOSS gobierna más la colaboración entre los usuarios, siendo un proceso más
descentralizado [Potdar y Chang, 2004].
En [Scacchi, 2001] se afirma que la manera de trabajar del PDOSS es más barata, más
rápida y de mayor calidad que la del PDT ya que, partiendo del principio de que los
usuarios del PDOSS trabajan en un proyecto porque quieren (la motivación juega un
papel importante aquí), no cobran nada por el trabajo (el coste del proyecto se reduce),
trabajan en paralelo y motivados ya que hacen algo que han seleccionado (esto hace que
se trabaje más rápidamente) y distribuyen el trabajo una vez está finalizado de verdad,
no tienen fechas programadas (por lo que la calidad del proyecto aumenta
considerablemente). En el PDT es todo lo contrario (aunque sus trabajadores igualmente
pueden estar motivados).
[Mockus et al., 2002] ha realizado una investigación para poder responder a ¿qué
actividades presentan los modelos de procesos de OSS. De 29 estudios analizados,
donde los proyectos más referenciados han sido FreeBSD y Apache, las actividades de
desarrollo de software tradicional más a menudo presentes en el proceso de desarrollo
OSS son: identificar las ideas o necesidades, analizar requisitos, realizar el diseño
arquitectónico, implementar el sistema, llevar a cabo revisiones y ejecutar pruebas, y
administrar las versiones de software. El mantenimiento es inherente al proceso de
desarrollo OSS y consiste en re-aplicar continuamente las actividades de desarrollo
mencionadas.
gran diversidad de técnicas donde la misma técnica puede tener distintos nombres
dependiendo del autor y pueden existir diversas variantes para una misma técnica.
Afortunadamente, algunos autores de IS ya han hecho el trabajo de compilar un
catálogo de técnicas de IPO [Ferré et al., 2002][Ferré et al., 2005]. A continuación se
especifican las técnicas de usabilidad utilizadas en el proceso de desarrollo de software
de la IPO. A partir de este catálogo de técnicas, en el siguiente capítulo, se analizan
cuáles técnicas de usabilidad son utilizadas en los desarrollos OSS.
Según [Ferré et al., 2002][Ferré et al., 2005], las actividades más representativas del
proceso de desarrollo de IPO son: especificación del contexto de uso, especificaciones
de usabilidad, desarrollo del concepto del producto, prototipado, diseño de la
interacción y evaluación de la usabilidad. Estas actividades (y sus correspondientes
técnicas asociadas) han sido asignadas a un tipo de actividad en IS. En algunos casos las
actividades IPO se integran en actividades IS existentes, como es el caso de las
especificaciones de usabilidad que se integran en la especificación de requisitos, pero en
otros casos es necesario añadir actividades adicionales que no suelen llevarse a cabo en
un desarrollo no centrado en el usuario, como por ejemplo el diseño de la interacción.
Estas actividades adicionales tendrán como nombre el mismo que reciben en IPO.
Las actividades IPO han sido encajadas teniendo en cuenta los tipos genéricos de
actividades IS: ingeniería de requisitos, diseño y evaluación. Nótese que en el catálogo,
las técnicas de IPO aparecen clasificadas según lo que significan ingeniería de
requisitos, diseño y evaluación para la IS.
Las actividades IPO que encajan en el tipo de actividad IS ingeniería de requisitos son:
especificación del contexto de uso, especificaciones de usabilidad, desarrollo del
concepto del producto y prototipado. La Tabla 2.1 recoge todas las técnicas de
usabilidad agrupadas según los tipos de actividades IS relativas a la ingeniería de
requisitos: educción, análisis, especificación y validación de requisitos.
Para cada una de las técnicas se especifica el tipo de actividad con la que se relaciona, el
nombre genérico de la técnica, el nombre dado por los diferentes autores en la literatura
y la(s) referencia(s) correspondiente(s) donde se definen o explican dichas técnicas.
Nótese que los tipos de actividades marcadas con un asterisco (*) no son propios de la
IS, sino de actividades IPO incluidas para ofrecer una visión estructurada de las técnicas
que pueden aplicarse en actividades de educción y análisis de requisitos.
En el Anexo A se describen todas las técnicas IPO para las actividades de la ingeniería
de requisitos, diseño y evaluación detalladas en las Tablas 2.1, 2.2 y 2.3.
CAPÍTULO 3.
En cuanto a los prototipos de papel, según el estudio empírico realizado por Çetin y
Göktürk [Cetýn y Göktürk, 2011], el 44,4% de los expertos en usabilidad y el 22,2% de
los desarrolladores encuestados afirmaron que lo utilizaban como un método para
evaluar la usabilidad. Las especificaciones de usabilidad han sido incorporadas en
varios proyectos OSS, entre los más conocidos se encuentran OpenOffice y Netbeans.
Estas especificaciones fueron realizadas por un grupo de expertos en usabilidad con el
objetivo de describir la interacción detallada y el diseño visual de la mayoría de las
nuevas funcionalidades [Benson et al., 2004][Müller-Prove, 2007][Terry et al., 2010].
La Tabla 3.1 presenta un resumen de todas las técnicas IPO incorporadas por la
comunidad OSS en las actividades de ingeniería de requisitos. Para cada una se
especifica el nombre genérico de la técnica, el nombre dado por los autores, la
referencia y el proyecto o los proyectos OSS donde han sido incorporadas. Cuando OSS
no ha incorporado ninguna técnica relacionada con una actividad específica, se ha
dejado la línea vacía (por ejemplo, análisis de tareas).
Del grupo de técnicas que aparece en la Tabla 2.2, OSS ha incorporado las siguientes:
guía de estilo del producto [Benson et al., 2004][Andreasen et al., 2006][Nichols y
Twidale, 2006][Terry et al., 2010][Cetýn y Göktürk, 2011], escenario de prototipos
[Terry et al., 2010] y prototipado [Osinki y Weiss, 2007][Gujrati y Vasserman, 2013].
Tabla 3.1: Técnicas IPO incorporadas en OSS relacionadas con los tipos de actividades IS
relativas a la Ingeniería de Requisitos
Las guías de estilo del producto que OSS ha incorporado son conocidas como human
interface guidelines (HIGs). Estas HIGs son un conjunto específico de reglas que siguen
los desarrolladores con el fin de crear un ‘look and feel’ para la interfaz del usuario y
garantizar su consistencia a través de toda la aplicación. Las HIGs usadas con mayor
frecuencia fueron las desarrolladas por el grupo de expertos del proyecto GNOME
[Benson et al., 2004][Andreasen et al., 2006][Nichols y Twidale, 2006][Terry et al.,
1
3DA: 3D Animation package.
2
BG: Bitmap Graphics application.
3
DTP: DeskTop Publishing application.
4
VG: Vector-based Graphics application.
5
OS: desktop Operating System.
6
WB: Web Browser.
7
CMS: Content Management System for the web.
8
DWE: Desktop Windowing Environment.
En la Tabla 3.2 se presenta un resumen de todas las técnicas IPO incorporadas por la
comunidad OSS en la actividad de diseño.
Tipo de
Uso en
Activi- Técnica IPO Nombre Dado por los Autores OSS Referencia
Proyectos OSS
dad IS
Mediante el desarrollo y la aplicación
de patrones de diseño de interfaz de [Terry et al.,
DWE
usuario 2010]
Tabla 3.2: Técnicas IPO incorporadas en OSS relacionadas con el tipo de actividad IS relativa
al Diseño
En las actividades de evaluación, según la Tabla 2.3, existen tres grandes grupos de
técnicas para evaluar la usabilidad: evaluación por expertos, pruebas de usabilidad y
estudios de seguimiento de los sistemas instalados. Las técnicas de usabilidad
pertenecientes a la evaluación por expertos que ha incorporado OSS son: evaluación por
expertos [Terry et al., 2010][Cetýn y Göktürk, 2011], inspecciones de consistencia
[Terry et al., 2010], inspecciones de conformidad con estándares [Cetýn y Göktürk,
2011], evaluación heurística [Reitmayr et al., 2006][Bodker et al., 2007][Nielsen y
Bødker, 2007][Cetýn y Göktürk, 2011][Rajanen et al., 2012], inspecciones de
9
VE: Video Editing application.
que en otros proyectos (por ejemplo, una utilidad de escritorio, un sistema operativo) ha
sido incorporada con ligeras modificaciones. La adaptación de esta técnica consiste en
que es el desarrollador y no un experto en usabilidad quien realiza la inspección. El
desarrollador inspecciona el sistema y la funcionalidad, mientras que el experto explora
el software de acuerdo a una serie de datos y acciones previamente definidos. Los
desarrolladores descubren los problemas de usabilidad mientras desarrollan o realizan
mejoras al software [Terry et al., 2010]. Con el objetivo de entender lo que hace el
software y cómo lo hace, los desarrolladores realizan una exploración y pruebas del
sistema existente y es allí donde los problemas son encontrados. En el proyecto
Roguelike esta técnica también se ha incorporado y el recorrido cognitivo ha sido
realizado por un grupo de estudiantes de IPO guiados por un experto en usabilidad
[Rajanen et al., 2012].
La Tabla 3.3 presenta un resumen de todas las técnicas IPO incorporadas por la
comunidad OSS para la evaluación de la usabilidad, relacionadas con la evaluación por
expertos.
Uso en
Técnica IPO Nombre Dado por los Autores OSS Referencias
Proyectos OSS
Tabla 3.3: Técnicas IPO incorporadas en OSS relacionadas con los tipos de Actividades IS
relativas a la Evaluación (Evaluación por Expertos)
10
DUT: Desktop UTility.
11
FE: Font Editor.
Técnicas del tipo pruebas de usabilidad han sido incorporadas en las aplicaciones
Amarok (reproductor de música), Kivio (diseñador visual) y Kget (gestor de descargas).
Todas estas aplicaciones forman parte del proyecto KDE [Cetýn y Göktürk, 2011]. Esta
técnica también ha sido incorporada en el proyecto Carrot2 [Osinki y Weiss, 2007]. En
niguno de los casos se ha especificado cuál de las técnicas del tipo pruebas de
usabilidad han sido incorporadas. En el proyecto Carrot2, los pruebas de usabilidad
fueron realizados de manera informal a la interfaz del usuario. Los participantes en estas
pruebas recibieron una explicación breve de la aplicación y del objetivo de las pruebas,
haciendo énfasis en que era la interfaz del usuario la que estaba siendo evaluada y no
sus acciones. Los participantes realizaron una serie de tareas previamente establecidas,
sin recibir ninguna clase de ayuda durante la ejecución de las mismas. Durante la
realización de estas tareas, se observaron cuidadosamente a los participantes, tomando
nota de sus interacciones con la aplicación.
En la técnica pensar en voz alta los usuarios individualmente expresan en voz alta y
libremente sus pensamientos, sentimientos y opiniones sobre cualquier aspecto (diseño,
funcionalidad, etc.), mientras que interaccionan con la aplicación en presencia de un
experto en usabilidad [Hix y Hartson, 1993]. Esta técnica ha sido incorporada en el
desarrollo de un sistema operativo de escritorio, un browser Web, una utilidad de
escritorio y en el proyecto TrueCrypt. La incorporación de esta técnica en estos
proyectos ha permitido descubrir problemas de usabilidad [Terry et al., 2010][Gujrati y
Vasserman 2013]. En el caso de la incorporación de la técnica pensar en voz alta con
ligeras modificaciones, la modificación consistió en que es un desarrollador y no un
experto en usabilidad quien está presente con el usuario mientras interacciona con la
aplicación. Tanto el desarrollador como el usuario se encuentran remotamente
[Andreasen et al., 2006].
De las técnicas para la evaluación de la usabilidad del tipo pruebas de usabilidad, los
pruebas de usabilidad en laboratorio es la técnica que menos ha sido incorporada en
los proyectos OSS debido al alto costo que supone contar con un laboratorio donde
realizar los test. Según el estudio empírico realizado por Andreasen et al. [Andreasen et
al., 2006], solo el 8% de los encuestados ha realizado prueba de usabilidad en
laboratorio. Esta técnica también ha sido incorporada con ligeras modificaciones. La
modificación consiste en que la técnica es llevada a cabo por un grupo de estudiantes de
IPO guiados por un experto en usabilidad [Rajanen et al., 2012] y no por expertos en
usabilidad como prescribe IPO.
La Tabla 3.4 presenta un resumen de todas las técnicas IPO incorporadas por la
comunidad OSS para la evaluación de la usabilidad, relacionadas con las pruebas de
usabilidad.
Uso en
Técnica IPO Nombre Dado por los Autores OSS Referencia
Proyectos OSS
[Cetýn y Göktürk,
Pruebas de Usabilidad KDE
2011]
Pruebas de
[Osinki y Weiss,
Usabilidad Pruebas de Usabilidad del Nuevo Diseño Carrot2
2007]
Pruebas de Usabilidad [Müller-Prove, 2007] OpenOffice
Vía opiniones de expertos, realizado de
Evaluación
forma remota por los miembros del [Terry et al., 2010] DWE, VE
Remota
proyecto
Grabación de Roleplaying roguelike
Grabación de Vídeo [Rajanen et al., 2012]
Vídeo game
Grabación de
Grabación de Audio Roleplaying roguelike
Audio [Rajanen et al., 2012]
game
Entrevistando a las personas de la prueba
Información Roleplaying roguelike
después de las sesiones de pruebas de [Rajanen et al., 2012]
Post-Test game
usabilidad
Mediante la Realización de Estudios de
[Terry et al., 2010] DUT, OS, WB
Pensando en Voz Alta
Pensando en Voz [Gujrati y Vasserman
Pensando en Voz Alta TrueCrypt
Alta 2013]
[Andreasen et al.,
Evaluación de Usabilidad Remoto
2006]
Mediante la Realización de Estudios de
[Terry et al., 2010] CMS, DWE, OS
Usabilidad en Entornos Controlados
Laboratorio de
[Andreasen et al.,
Pruebas de Evaluación de la Usabilidad en Laboratorio
2006]
Usabilidad
Roleplaying roguelike
Laboratorio de Pruebas de Usabilidad [Rajanen et al., 2012]
game
Tabla 3.4: Técnicas IPO incorporadas en OSS relacionadas con los tipos de actividades IS
relativas a la Evaluación (Pruebas de Usabilidad)
La técnica focus groups consiste en una serie de reuniones donde participan usuarios
finales y expertos en usabilidad. En las reuniones se discuten los problemas y las
preocupaciones de los usuarios relacionados con la interfaz de usuario [Nielsen, 1993].
Según el estudio empírico realizado por Çetin y Göktürk [Cetýn y Göktürk, 2011], la
técnica de evaluación de la usabilidad menos preferida fue focus groups. Sólo el 22% de
los proyectos la incorporaba. Esta técnica también ha sido incorporada en algunos
proyectos (por ejemplo, una aplicación de gráficos de mapa de bits), pero con una ligera
modificación. En los focus groups, un experto en usabilidad se reúne en persona o a
través de un chat con los desarrolladores. Estas reuniones se celebran con cierta
periodicidad (semanal, mensual o anualmente) y tienen como objetivo que las
aplicaciones o los diseños propuestos para una nueva funcionalidad, sean valorados por
un experto en usabilidad [Terry et al., 2010]. En este caso, son los desarrolladores OSS
los que participan en los focus groups y no los usuarios finales.
La técnica observación directa tiene como principal objetivo entender cómo los
usuarios de las aplicaciones llevan a cabo sus tareas y más concretamente conocer todas
las acciones que éstos ejecutan durante la realización de las mismas. Para ello, se visita
el lugar de trabajo donde se están llevando a cabo las actividades objeto de estudio en
las que se encuentran los usuarios representativos que serán observados [Nielsen, 1993].
Si bien la observación directa consume mucho tiempo, desempeña un rol importante en
la definición de la estrategia del producto [Müller-Prove, 2007]. Esta técnica ha sido
incorporada en los proyectos OpenOffice [Müller-Prove, 2007], GIMP (aplicación para
manipulación de imágenes) y TV-Browser (guía de TV) [Reitmayr et al., 2006]. Sin
embargo, en algunos proyectos también se ha incorporado pero con ligeras
modificaciones. En estos casos, las observaciones han sido realizadas de manera
informal cuando familiares y amigos de los desarrolladores usan la aplicación, o cuando
usuarios avanzados realizan demostraciones en conferencias. En estas observaciones no
hay un objeto de estudio previamente definido [Terry et al., 2010].
Con respecto a las técnicas foros [Terry et al., 2010], retroalimentación del usuario
[Nichols y Twidale, 2006][Hedberg et al., 2007][Terry et al., 2010] y revistas y
conferencias para usuarios [Benson et al., 2004][Terry et al., 2010] éstas han sido
incorporadas con ligeras modificaciones. Los foros permiten que los usuarios publiquen
mensajes abiertos y preguntas a los diseñadores de la interfaz [O’Mahony, 2003]. En
OSS, estos mensajes y preguntas no son solamente publicados en foros, también son
comunicados a través del chat y mailing lists. A través de estos medios de
comunicación, los usuarios no-desarrolladores participan en un diálogo permanente y
directo con los desarrolladores acerca de sus necesidades y de los problemas de
usabilidad. Los foros constituyen el principal medio para descubrir y tratar problemas
de usabilidad en la comunidad OSS [Terry et al., 2010].
La Tabla 3.5 presenta un resumen de todas las técnicas IPO incorporadas por la
comunidad OSS para la evaluación de la usabilidad, relacionadas con estudios de
seguimiento de los sistemas instalados.
Uso en
Técnica IPO Nombre Dado por los Autores OSS Referencia
Proyectos OSS
Tabla 3.5: Técnicas IPO incorporadas en OSS relacionadas con los tipos de actividades IS
relativas a la Evaluación (Estudios de Seguimiento de los Sistemas Instalados)
Uso en
Técnica IPO Nombre Dado por los Autores OSS Referencia
Proyectos OSS
[Cetýn y Göktürk,
Focus Groups (no especifica)
2011]
Focus Groups
Reuniones Anuales, Mensuales, Semanales, 3DA, BG,
[Terry et al., 2010]
o ad-hoc DWE, OS
Observaciones de los Usuarios y de la GIMP
[Reitmayr et al., 2006]
Tarea TV-Browser
Observación
Visitas al Sitio [Müller-Prove, 2007] OpenOffice
Directa
A través de Observaciones Informales de BG, DUT, VG,
[Terry et al., 2010]
Amigos y Familiares WB
3DA, BG,
Al prestar atención a lo que se pide, CMS, DTP,
Foros discutido, o solicita en chats, listas de [Terry et al., 2010] DUT, DWE,
correo y foros FE, OS, VE,
VG, WB
3DA, BG,
CMS, DTP,
A través de los Informes de Error [Terry et al., 2010] DUT, DWE,
FE, OS, VE,
VG, WB
Los usuarios Informan de los Errores [Hedberg et al., 2007] (no especifica)
Feedback de Informarles de Problemas de Usabilidad [Nichols y Twidale,
(no especifica)
Usuarios 2006]
Descripciones de los Problemas de Roleplaying
[Rajanen et al., 2012]
Usabilidad en la Wiki roguelike game
3DA, BG,
Búsqueda de la Retroalimentación de las CMS, DTP,
[Terry et al., 2010]
Maquetas, Prototipos DUT, OS, VE,
WB
Revistas y Conferencia [Benson et al., 2004] OpenOffice
Conferencias para BG, DUT, OS,
Conferencia [Terry et al., 2010]
Usuarios VG, WB
Tabla 3.5: Técnicas IPO incorporadas en OSS relacionadas con los tipos de actividades IS
relativas a la Evaluación (Estudios de Seguimiento de los Sistemas Instalados) (Continuación)
Enviar cambios al grupo AG. Los cambios son enviados a la lista para su
revisión.
La Figura 3.1 muestra una representación esquemática de las etapas dentro del proyecto
de desarrollo de Apache donde tienen cabida las técnicas seleccionadas de las
especificadas en los apartados anteriores.
En la segunda etapa, se puede hacer uso de los perfiles de usuario donde no sólo deben
quedar registrados los errores reportados por cada usuario, sino además su colaboración
en la resolución de los mismos. Esto facilitará la selección para hacerle llegar el
problema objeto de resolución a aquellos usuarios cuyo perfil haga pensar que pueden
tener más facilidades para resolverlo. Esta determinación no debe ser fija, ya que al
tratase de un proyecto de OSS, todo aquel que quiera enfrentarse al proyecto será
bienvenido, y dispondrá de información suficiente para ello.
Una vez determinado quién se encarga de resolver el problema, se proponen una serie
de técnicas muy sencillas para mejorar la usabilidad derivada de la solución. Los
prototipos de papel de las diferentes opciones consideradas es una técnica que puede
resultar de mucha utilidad. Además, su sencillez permite aceptar el diseño de distintos
prototipos facilitando la comparación de las distintas soluciones propuestas para
CAPÍTULO 4.
APLICACIÓN DE TÉCNICAS DE
USABILIDAD EN EL PROYECTO
FREEMIND
Por último, la cuarta técnica aplicada ha sido la encuesta SUS (System Usability Scale)
[Tullis y Stetson, 2004] sobre la herramienta FreeMind. El SUS es una encuesta de 10
preguntas disponible gratuitamente para su uso en estudios de usabilidad, tanto con
fines de investigación como de la industria. El único requisito previo para su uso es que
cualquier informe publicado debe reconocer la fuente utilizada. Debido a que ha sido
ampliamente utilizada, existen estudios en la literatura sobre usabilidad que han
informado de las puntuaciones del SUS para distintos productos y sistemas, incluyendo
aplicaciones de escritorio, páginas web y diversos productos de consumo [Tullis y
Stetson, 2004][Bangor et al., 2008]. A partir de estos resultados surgió la siguiente
interpretación de las puntuaciones de SUS:
Para aplicar estas cuatro técnicas se ha distinguido entre usuarios junior y usuarios
senior. Para ello cuando se contactaba con los usuarios y se les preguntaba cuántas
veces habían utilizado la aplicación. Si la respuesta era nunca o esporádicamente, se le
clasificaba como un usuario junior. Si la respuesta era a menudo, entonces era
clasificado como un usuario senior. A continuación, se muestra el número de usuarios
distintos para cada tipo a los que se les aplicó las técnicas de observación directa y de
observación remota (Figura 4.1).
Figura 4.1: Número de usuarios a los que se les aplicó cada técnica
La forma de contactar con estos usuarios fue a través de correos electrónicos con las
personas de observación remota, sacadas del foro de FreeMind, mientras que las
personas de observación directa fue, en la mayor parte, a través de contactar con
conocidos, ya sea personalmente, por teléfono o por correo electrónico. Una vez que
afirmaban querer hacer la observación se acordaba un día y una hora para proceder a la
realización de la respectiva prueba.
En las Figuras 4.2 y 4.3 se encuentran las tareas realizadas mediante el uso de FreeMind
por usuarios junior y por usuarios senior, respectivamente.
Cuando el usuario terminaba la prueba, se realizaba la encuesta SUS (Figura 4.5), donde
se comprueba cómo de usable es la aplicación para dicho usuario, a través de una serie
de 10 preguntas de forma genérica sobre el uso de la aplicación. Las encuestas
completadas se encuentran en el Anexo F.
Para la ejecución de la técnica de observación remota, una vez que se tenían ya los
usuarios separados entre junior y senior, lo primero que se hacía era pasarles, vía correo
electrónico, la encuesta SUS, las cuales se encuentran también en el Anexo F. Después
se proseguía con la realización de la prueba. Para ello concretábamos un día y una hora
con los usuarios. Una vez llegado el día de realización de la observación, se le pasaba al
usuario los ejercicios propuestos vía online y se empezaba con la prueba en el momento,
donde se rellenaban documentos con los gestos expresados y sentimientos de cada
usuario. Estos documentos se encuentran en el Anexo D. Se continuaba de forma
paralela con el documento donde se tomaba nota de los problemas que tenía cada
usuario y sí sabía hacer cada uno de los ejercicios de la prueba propuesta. Estos
documentos completados se muestran también en el Anexo D.
Esta técnica fue aplicada a todos los usuarios mediante videollamada porque los
usuarios eran personas de todo el mundo, norte de Europa, norte y centro de América.
Para poder ver la pantalla del sujeto se utilizaba la aplicación TeamViewer, la cual
permite compartir la pantalla a través de un identificador, a fin de comprobar así como
el usuario interactúa con FreeMind y ver si lo que está realizando está bien o mal.
Con estas aplicaciones y métodos fue imprescindible conexión a internet, tanto por el
observador como de la persona observada. Esto para algunos usuarios fue bastante
complicado, porque se les perdía frecuentemente la conexión y era muy difícil poder
realizar la prueba. No obstante, se superaron los problemas tecnológicos y se obtuvieron
los resultados programados.
Una vez recopilados todos los datos de los usuarios a través de las observaciones, se
prosigue con el análisis y síntesis de resultados. A partir de este análisis se combinan
todos los resultados obtenidos del conjunto de técnicas observación directa-información
post-test y observación remota-información post-test, para después finalizar con una
síntesis integrada de todos los problemas de usabilidad recogidos con ambos conjuntos
de técnicas sobre la aplicación FreeMind.
Hay que destacar que la mayoría de los problemas de usabilidad encontrados tanto para
la técnica de observación directa como para la remota han sido obtenidos de los
resultados recogidos a través de la entrevista de la información post-test, que es donde
el usuario expone exactamente los problemas más significativos que ha ido teniendo
durante la prueba, así como también los problemas de usabilidad de la aplicación que le
han ido surgiendo.
Para finalizar el análisis y síntesis de todos los resultados, se integraron a su vez los
resultados anteriores, recopilando todos los problemas de usabilidad de la herramienta
FreeMind. Estos resultados conjuntos se encuentran en el apartado 4.3.1.
Una vez realizadas las encuestas SUS, se transcriben las respuestas de cada participante
en forma de hoja de Excel y se obtiene el promedio correspondiente y el promedio total
(Tabla 4.1), separada cada hoja de cálculo por usuarios junior, usuarios senior, y
combinados, para poder comprobar así la usabilidad de la aplicación FreeMind por
perfiles de usuarios y en conjunto.
Según el resultado que se puede apreciar en la Tabla 4.2, el valor promedio es de 71,2,
es decir para el tipo de usuarios senior la aplicación es aceptable en usabilidad, ya que
este valor es mayor que 70. Por lo tanto, para usuarios de tipo senior utilizando la
aplicación no habría que realizar mejoras, a no ser que estas fueran de prioridad alta, ya
que así se garantizaría una mejor usabilidad de la aplicación para este tipo de sujetos.
Para finalizar el procesamiento de las encuentas SUS, se combinan los resultados de los
usuarios junior (Tabla 4.1) y senior (Tabla 4.2) para comprobar la usabilidad de la
herramienta en forma conjunta (Tabla 4.3).
Los problemas más destacados por los usuarios se diferencian para usuarios junior y
usuarios senior, junto con sus respectivas mejoras. También se analizarán las clases de
mejoras que los usuarios creen convenientes incorporar en la aplicación.
En la Tabla 4.4 se muestran los problemas descritos por los usuarios junior, cuya
observación se realizó de forma directa, ordenados por relevancia. Como se puede
apreciar, hay problemas que coinciden con varios usuarios, y las mejoras han sido dadas
tanto por los usuarios como a partir de mi observación.
Número de Nivel de
Problema Mejoras
Personas Relevancia
No se ve fácilmente insertar un 1 Alto Poner más visible las
nodo hijo opciones relacionadas con
insertar y eliminar nodos
Símbolo familia con el botón 1 Alto Poder acceder a todos los
derecho no sale símbolos a través del
botón derecho
La imagen sale muy grande 1 Alto Redimensionamiento de la
imagen
Imagen quita el texto del nodo 1 Alto Mismo nodo con una
imagen y texto
No se ve fácilmente insertar un 2 Alto Poner más visible las
nodo nuevo opciones relacionadas con
insertar y eliminar nodos
Dificultad para encontrar los 2 Alto Clasificación de los iconos
símbolos por categorías
Botón de eliminar y mover nodos, 2 Alto Poner más visible las
bastante escondido opciones relacionadas con
insertar, eliminar y mover
nodos
Pide guardar a la hora de meter 3 Alto No pedir guardar cuando
una imagen se inserta una imagen
Usabilidad de toda la aplicación 3 Alto Cambiar parte de la
usabilidad, pensando en
principiantes
Los símbolos son muy pequeños 4 Alto Poner los símbolos en la
barra de herramientas y
modificar el tamaño de
estos
No se pueden mover los nodos 1 Medio Movimiento de cualquier
nodo del mapa
No se encuentra eliminar nodo 1 Medio Poner más visible las
opciones relacionadas con
insertar y eliminar nodos o
poner un símbolo
Eliminar un icono 2 Medio Opción más visible y más
explicativa
Eliminar un icono, cuando hay 2 Medio Poder eliminar cualquier
más de uno icono, sin ser el último
El símbolo familia es muy 4 Medio Modificar el símbolo de
parecido a grupo familia
Número de Nivel de
Problema Mejoras
Personas Relevancia
No se ve fácilmente donde está el 1 Bajo Organización de los
símbolo ! iconos en la barra de
herramientas y por
categorías
Seleccionar un nodo, modifica el 1 Bajo Seleccionar un nodo, sin
texto que salte la modificación
del texto
Nodo hijo y nodo padre tienen la 1 Bajo Cambiar la forma del nodo
misma forma hijo con respecto al padre
Mover el diagrama del nodo 1 Bajo Poder mover el diagrama
principal desde cualquier parte del
mapa
Número de Nivel de
Problema Mejoras
Personas Relevancia
Encontrar el símbolo de familia 1 Alto Poder acceder a todos los
con botón derecho símbolos a través del botón
derecho
Poca flexibilidad y poca intuitiva 1 Alto Cambiar parte de la
interfaz, pensando en
principiantes
No se sabe si se ha seleccionado 1 Alto Sombrear un nodo cuando
un nodo es seleccionado
Los símbolos son muy pequeños 1 Alto Poner los símbolos en la
barra de herramientas y
modificar el tamaño de
estos
Deficiente la forma de operar 1 Alto Operaciones de forma
homogénea entre todas las
opciones que se pueden
realizar
El símbolo guardar no interactúa 1 Alto Interactividad para el
símbolo de guardar el mapa
conceptual
Guardar al meter la imagen 1 Alto No pedir guardar cuando se
mete una imagen
Color fondo del nodo no aparece 1 Alto Cambio del color de nodo
cuando se cambia de modo automático
cuando se selecciona el
color
No se ve fácilmente insertar nodo 1 Alto Poner más visible las
hermano opciones relacionadas con
insertar y eliminar nodos
Opción “Color nodo” no se sabe 1 Alto Especificar para qué es
si es para la fuente o el fondo “Color del nodo”, fuente o
fondo
Número de Nivel de
Problema Mejoras
Personas Relevancia
Barra de herramientas en un 1 Alto Mismo lenguaje para los
mismo lenguaje menús de la barra de
herramientas
Imagen muy grande 2 Alto Redimensionamiento de la
imagen
Eliminar un icono cuando hay 3 Alto Poder eliminar cualquier
más de uno icono, sin ser el último
Símbolos desordenados 4 Alto Organización de los iconos
en la barra de herramientas
y por categorías
Eliminar nodo de una hoja 1 Medio Preguntar solo si la hoja
pregunta si quieres borrar tiene hijos, sino no
Menús poco homogéneos 1 Medio Variar cada funcionalidad
de los menús según la
función que realicen
Selección de varios nodos 1 Medio Poder seleccionar varios
nodos a través de un
cuadrado de selección
Símbolo familia muy igual al de 1 Medio Modificar el símbolo de la
grupo familia
No se puede mover los nodos 1 Medio Movimiento de cualquier
nodo del mapa
Diferencia entre nodo hijo y 1 Medio Cambiar la forma del nodo
hermano en el nodo raíz hijo y del nodo hermano
con respecto al raíz
Símbolos de la barra de 2 Medio Cambiar los símbolos por
herramientas iguales y hacen otros
cosas diferentes
Apariencia poco agradable 1 Bajo Poner una interfaz con más
colorido y agradable
visualmente
Cambiar el color del fondo de la 1 Bajo Cambiar el color de la nube
nube si no se pulsa bien el nodo desde cualquier nodo
dentro de la nube, y no solo
desde el nodo padre
Actualización de la herramienta 1 Bajo Avisar al usuario de nuevas
con versiones versiones
Mayor variedad de símbolos y 1 Bajo Opción para poder añadir
poder añadir iconos iconos, y mayor variedad
de ellos
Apariencia en nodos y ramas muy 3 Bajo Cambiar la forma de los
seria nodos y poner colores a las
diferentes ramas
En la Tabla 4.6 se muestran las mejoras dadas por los usuarios tanto junior como senior
sobre la interacción de la aplicación y su interfaz. Para dar valor a la columna prioridad,
se ha seguido el mismo criterio que para calificar el nivel de relevancia de las tablas de
problemas identificados pero en este caso en relación con las mejoras propuestas.
Los problemas más destacados por los usuarios se diferencian para usuarios junior y
usuarios senior, junto con sus respectivas mejoras. También se analizarán las clases de
mejoras que los usuarios creen convenientes incorporar en la aplicación.
En la Tabla 4.7 se muestran los problemas descritos por los usuarios junior, cuya
observación se realizó de forma remota, ordenados por relevancia. Como se puede
apreciar, hay problemas que coinciden con varios usuarios, y las mejoras han sido dadas
tanto por los usuarios como a partir de mi observación.
En la Tabla 4.9 se muestran las mejores dadas por los usuarios tanto junior como senior
sobre la interacción de la aplicación y su interfaz. Para dar valor a la columna prioridad,
se ha seguido el mismo criterio que para calificar el nivel de relevancia de las tablas de
problemas identificados pero en este caso respecto a las mejoras propuestas.
Como la mayoría de los problemas y de las mejoras para cada tipo de observación ha
sido obtenido de la entrevista post-test realizada a los usuarios tanto junior como senior,
no se va a realizar un informe de la técnica de observación post-test porque su contenido
sería el mismo que las tablas descritas en este apartado.
Para tener una visión global de todos los problemas de usabilidad encontrados por los
usuarios, en el Tabla 4.10 se muestra la unión de los resultados obtenidos en las tablas
de observación directa e información post-test y de observación remota e información
post-test, sin repetidos. Las tablas originales se encuentran en el Anexo G y en el Anexo
H, respectivamente. En la Tabla 4.10 se muestran: el problema, el tipo de técnica que
permitió tal descubrimiento, el número de usuarios que lo han mencionado, la mejora
propuesta y el autor de la mejora.
Los problemas de la aplicación de las técnicas que han ido surgiendo son diferentes
según la técnica aplicada (observación directa, observación remota, información post-
test y encuesta) y según el tipo de participación del usuario (presencial o remota). A
continuación, se describirán para cada una de las técnicas los problemas encontrados al
aplicarlas.
Para la técnica observación directa, el problema encontrado al aplicarla con los usuarios
de la herramienta FreeMind ha sido, principalmente, la disponibilidad del usuario. Esto
debido a que muchos de los usuarios tenían un horario bastante difícil de coordinar para
llevar a cabo el desarrollo de la prueba. Es importante mencionar que durante la
aplicación de la técnica no ha surgido ningún problema con respecto al funcionamiento
de FreeMind que entorpeciese la prueba, es decir, la herramienta desempeñaba toda su
funcionalidad de forma correcta.
Para la técnica encuesta, los problemas encontrados durante su aplicación han sido dos.
Primero, muchos de los usuarios no tenían instalado Microsoft Excel, por lo tanto no
podían abrir la encuesta. Para solucionar este problema fue necesario cambiar la
encuesta a un formato común para que cualquier hoja de cálculo pudiera abrirla.
Segundo, como las encuestas fueron enviadas por correo electrónico a los usuarios que
participaron de manera remota para que las completaran cuando fuera posible, a unos
pocos usuarios se les olvidaba y no contestaban el correo electrónico. Sin embargo,
estos problemas no ocurrían con los usuarios que participaban presencialmente, porque
la encuesta estaba impresa y la completaban al final de la aplicación de las técnicas.
Además de estos problemas descritos, también hay que destacar que a la hora de
seleccionar a los participantes, el director del proyecto FreeMind, Christian Foltin, no
contaba con una lista de usuarios, ni con una clasificación de los mismos, por lo tanto
tuve que buscar a dichos usuarios por los foros y posteriormente clasificarlos a través de
un cuestionario para diferenciar entre junior y senior según el uso que hacían de la
herramienta.
CAPÍTULO 5.
APLICACIÓN DE TÉCNICAS DE
USABILIDAD EN EL PROYECTO
OPENOFFICE WRITER
OpenOffice es uno de los proyectos OSS más populares que existen ahora mismo.
Siempre que se habla de proyectos OSS exitosos, OpenOffice encabeza la lista.
OpenOffice es un proyecto OSS muy grande que está bien organizado y estructurado y
cuenta con una gran comunidad de usuarios [OpenOffice, 2014].
La versión actual es la 4.0.1. Si bien la versión antigua estable 1.1.5, no tenía gran
atractivo en cuanto a apariencia, la versiones 2.x (también descargables desde su página
web) han mejorado, respecto a sus versiones anteriores, su interfaz, compatibilidad con
otros formatos de archivo y la sencillez de su uso.
Puede proteger documentos con contraseña, guardar versiones del mismo documento,
insertar imágenes, objetos OLE, admite firmas digitales, símbolos, fórmulas, tablas de
cálculo, gráficos, hiperenlaces, marcadores, formularios, etc.
Writer es también un potente editor HTML tan fácil de usar como un documento de
texto. Sólo con entrar en el menú Ver y seleccionar “Diseño para internet” cambia el
formato del cuadro de texto, asemejándose a una página web, que se puede editar de la
misma forma que si fuera un procesador de textos. Con él también se pueden hacer
etiquetas, así como tarjetas de presentación fácilmente, sin tener que modificar el
formato de un documento de texto para ello. Además tiene una galería de imágenes,
texturas y botones.
Por último, la cuarta técnica aplicada ha sido la encuesta SUS (System Usability Scale)
[Tullis y Stetson, 2004] sobre la herramienta OpenOffice Writer. El SUS es una
encuesta de 10 preguntas disponible gratuitamente para su uso en estudios de
usabilidad, tanto con fines de investigación como de la industria. El único requisito
previo para su uso es que cualquier informe publicado debe reconocer la fuente
utilizada. Debido a que ha sido ampliamente utilizada, existen estudios en la literatura
sobre usabilidad que han informado de las puntuaciones del SUS para distintos
productos y sistemas, incluyendo aplicaciones de escritorio, páginas web y diversos
productos de consumo [Tullis y Stetson, 2004][Bangor et al., 2008]. A partir de estos
resultados surgió la siguiente interpretación de las puntuaciones de SUS:
Para aplicar estas cuatro técnicas se ha distinguido entre usuarios junior y usuarios
senior. Para ello cuando se contactaba con los usuarios y se les preguntaba cuántas
veces habían utilizado la aplicación. Si la respuesta era nunca o esporádicamente, se le
clasificaba como un usuario junior. Si la respuesta era a menudo, entonces era
clasificado como un usuario senior. A continuación, se muestra el número de usuarios
distintos para cada tipo a los que se les aplicó las técnicas de observación directa y de
observación remota (Figura 5.1).
Figura 5.1: Número de usuarios a los que se les aplicó cada técnica
La forma de contactar con estos usuarios fue a través de correos electrónicos con las
personas de observación remota, sacadas del foro de OpenOffice, mientras que las
personas de observación directa fue, en la mayor parte, a través de contactar con
conocidos, ya sea personalmente, por teléfono o por correo electrónico. Una vez que
afirmaban querer hacer la observación se acordaba un día y una hora para proceder a la
realización de la respectiva prueba.
En las Figuras 5.2 y 5.3 se encuentran las tareas realizadas mediante el uso de
OpenOffice Writer por usuarios junior y por usuarios senior, respectivamente.
Cuando el usuario terminaba la prueba, se realizaba la encuesta SUS (Figura 5.5), donde
se comprueba cómo de usable es la aplicación para dicho usuario, a través de una serie
de 10 preguntas de forma genérica sobre el uso de la aplicación. Las encuestas
completadas se encuentran en el Anexo O.
Para la ejecución de la técnica de observación remota, una vez que se tenían ya los
usuarios separados entre junior y senior, lo primero que se hacía era pasarles, vía correo
electrónico, la encuesta SUS, las cuales se encuentran también en el Anexo O. Después
se proseguía con la realización de la prueba. Para ello concretábamos un día y una hora
con los usuarios. Una vez llegado el día de realización de la observación, se le pasaba al
usuario los ejercicios propuestos vía online y se empezaba con la prueba en el momento,
donde se rellenaban documentos con los gestos expresados y sentimientos de cada
usuario. Estos documentos se encuentran en el Anexo M. Se continuaba de forma
paralela con el documento donde se tomaba nota de los problemas que tenía cada
usuario y sí sabía hacer cada uno de los ejercicios de la prueba propuesta. Estos
documentos completados se muestran también en el Anexo M.
Esta técnica fue aplicada a todos los usuarios mediante videollamada porque los
usuarios eran personas de todo el mundo, norte de Europa, norte y centro de América.
Para poder ver la pantalla del sujeto se utilizaba la aplicación TeamViewer, la cual
permite compartir la pantalla a través de un identificador, a fin de comprobar así como
el usuario interactúa con OpenOffice Writer y ver si lo que está realizando está bien o
mal.
Con estas aplicaciones y métodos fue imprescindible conexión a internet, tanto por el
observador como de la persona observada. Esto para algunos usuarios fue bastante
complicado, porque se les perdía frecuentemente la conexión y era muy difícil poder
realizar la prueba. No obstante, se superaron los problemas tecnológicos y se obtuvieron
los resultados programados.
Una vez recopilados todos los datos de los usuarios a través de las observaciones, se
prosigue con el análisis y síntesis de resultados. A partir de este análisis se combinan
todos los resultados obtenidos del conjunto de técnicas observación directa-información
post-test y observación remota-información post-test, para después finalizar con una
síntesis integrada de todos los problemas de usabilidad recogidos con ambos conjuntos
de técnicas sobre la aplicación OpenOffice Writer.
Hay que destacar que la mayoría de los problemas de usabilidad encontrados tanto para
la técnica de observación directa como para la remota han sido obtenidos de los
resultados recogidos a través de la entrevista de la información post-test, que es donde
el usuario expone exactamente los problemas más significativos que ha ido teniendo
durante la prueba, así como también los problemas de usabilidad de la aplicación que le
han ido surgiendo.
Para finalizar el análisis y síntesis de todos los resultados, se integraron a su vez los
resultados anteriores, recopilando todos los problemas de usabilidad de la herramienta
OpenOffice Writer. Estos resultados conjuntos se encuentran en el apartado 5.3.1.
Una vez realizadas las encuestas SUS, se transcriben las respuestas de cada participante
en forma de hoja de Excel y se obtiene el promedio correspondiente y el promedio total
(Tabla 5.1), separada cada hoja de cálculo por usuarios junior, usuarios senior, y
combinados, para poder comprobar así la usabilidad de la aplicación OpenOffice Writer
por perfiles de usuarios y en conjunto.
Los problemas más destacados por los usuarios se diferencian para usuarios junior y
usuarios senior, junto con sus respectivas mejoras. También se analizarán las clases de
mejoras que los usuarios creen convenientes incorporar en la aplicación.
En la Tabla 5.4 se muestran los problemas descritos por los usuarios junior, cuya
observación se realizó de forma directa, ordenados por relevancia. Como se puede
apreciar, hay problemas que coinciden con varios usuarios, y las mejoras han sido dadas
tanto por los usuarios como a partir de mi observación.
Número de Nivel de
Problema Mejoras
Personas Relevancia
Número de página no sale en la 2 Alto Número de página
parte inferior automático en la parte
inferior
Opciones escondidas en el menú 3 Alto Mayor visibilidad en
opciones básicas
Insertar una imagen de la Galería, 3 Alto Poner la opción de Galería
no está en Insertar en el menú de Insertar
Tipo de letra con el botón derecho 5 Alto Todos los tipos de letras a
través del botón derecho
Cambiar el margen izquierdo es 1 Medio Opción más visible a la
poco intuitivo hora de diseñar la página
Autoformato de la tabla, no se ve 1 Medio Poder cambiar el
con facilidad y solo se hace al autoformato una vez
crearla creada la tabla
Encontrar la opción de número de 1 Medio Mayor visibilidad en
página opciones básicas
Encontrar la opción de nota al pie 1 Bajo Mayor visibilidad en
opciones básicas
Arrastrar la imagen de la galería 1 Bajo Pinchar la imagen para
que aparezca
Quitar las opciones y botones que 1 Bajo Resaltar los botones y
no se usen a menudo opciones que más se
utilicen
Quitar el panel izquierdo 1 Bajo Poner el panel en la barra
de herramientas
Interfaz complicada o pésima 1 Bajo Interfaz más intuitiva y
fácil de usar
Tabla 5.4: Problemas encontrados por los usuarios junior
En la Tabla 5.5 se especifican los problemas descritos por los usuarios senior, cuya
observación se realizó de forma directa, ordenados por relevancia. Como se puede
apreciar, hay problemas que coinciden con varios usuarios, y las mejoras han sido dadas
tanto por los usuarios como a partir de mi observación.
Número de Nivel de
Problema Mejoras
Personas Relevancia
Insertar una imagen de la Galería, 1 Alto Poner la opción de Galería
no está en Insertar en el menú de Insertar
Tipo de letra con el botón derecho 2 Alto Todos los tipos de letras a
través del botón derecho
Número de página no sale en la 2 Alto Número de página
parte inferior y tiene que ir con automático en la parte
pie de página inferior
Vincular la imagen al documento 1 Medio Mayor facilidad para esta
opción
Menús poco intuitivos, como 2 Medio Poner nombres a los menús
Campos y Carácter más claros e intuitivos
Ordenar la tabla no se puede 1 Bajo Poder ordenar cogiendo
coger el encabezamiento toda la tabla y decir porqué
fila/columna ordenar
La galería si se abre con 1 Bajo Cerrar la galería una vez
Herramientas, se queda abierta, si seleccionada la imagen
no se quita el tick, y el panel
derecho también se queda abierto
En las Tablas 5.4 y 5.5, los valores de la columna nivel de relevancia se han dado de
acuerdo a las siguientes pautas: nivel alto se ha considerado a aquellos problemas que
tengan una gran importancia sobre la realización de documentos, así como también con
la usabilidad básica que se espera de la aplicación y si un problema ha sido nombrado
por varios usuarios. Nivel medio se ha dado a los problemas que no tengan mucha
importancia en la realización de los documentos pero que estén relacionados en alguna
medida con la usabilidad. Nivel bajo se ha asignado a los problemas que son poco
importantes, ya que si no se solucionan la aplicación puede seguir funcionando sin ser
un gran obstáculo para el usuario.
En la Tabla 5.6 se muestran las mejoras dadas por los usuarios tanto junior como senior
sobre la interacción de la aplicación y su interfaz. Para dar valor a la columna prioridad,
se ha seguido el mismo criterio que para calificar el nivel de relevancia de las tablas de
problemas identificados pero en este caso respecto a las mejoras propuestas.
Estas tablas han sido elaboradas a partir del informe final de observación directa y de
información post-test, que se encuentra en el Anexo R.
Los problemas más destacados por los usuarios se diferencian para usuarios junior y
usuarios senior, junto con sus respectivas mejoras. También se analizarán las clases de
mejoras que los usuarios creen convenientes incorporar en la aplicación.
En la Tabla 5.7 se muestran los problemas descritos por los usuarios junior, cuya
observación se realizó de forma remota, ordenados por relevancia. Como se puede
apreciar, hay problemas que coinciden con varios usuarios, y las mejoras han sido dadas
tanto por los usuarios como a partir de mi observación.
En la Tabla 5.9 se muestran las mejores dadas por los usuarios tanto junior como senior
sobre la interacción de la aplicación y su interfaz. Para dar valor a la columna prioridad,
se ha seguido el mismo criterio que para calificar el nivel de relevancia de las tablas de
problemas identificados pero en este caso en relación con las mejoras propuestas.
Estas tablas han sido elaboradas a partir del informe final de observación remota y de
información post-test, que se encuentra en el Anexo S.
Como la mayoría de los problemas y de las mejoras para cada tipo de observación ha
sido obtenido de la entrevista post-test realizada a los usuarios tanto junior como senior,
no se va a realizar un informe de la técnica de observación post-test porque su contenido
sería el mismo que las tablas descritas en este apartado.
Para tener una visión global de todos los problemas de usabilidad encontrados por los
usuarios, en el Tabla 5.10 se muestra la unión de los resultados obtenidos en las tablas
de observación directa e información post-test y de observación remota e información
post-test, sin repetidos. Las tablas originales se encuentran en el Anexo P y en el Anexo
Q, respectivamente. En la Tabla 5.10 se muestran: el problema, el tipo de técnica que
permitió tal descubrimiento, el número de usuarios que lo han mencionado, la mejora
propuesta y el autor de la mejora.
Los problemas de la aplicación de las técnicas que han ido surgiendo son diferentes
según la técnica aplicada (observación directa, observación remota, información post-
test y encuesta) y según el tipo de participación del usuario (presencial o remota). A
continuación, se describirán para cada una de las técnicas los problemas encontrados al
aplicarlas.
Para la técnica observación directa, el problema encontrado al aplicarla con los usuarios
de la herramienta FreeMind ha sido, principalmente, la disponibilidad del usuario. Esto
debido a que muchos de los usuarios tenían un horario bastante difícil de coordinar para
llevar a cabo el desarrollo de la prueba. Es importante mencionar que durante la
aplicación de la técnica no ha surgido ningún problema con respecto al funcionamiento
de FreeMind que entorpeciese la prueba, es decir, la herramienta desempeñaba toda su
funcionalidad de forma correcta.
Para la técnica encuesta, los problemas encontrados durante su aplicación han sido dos.
Primero, muchos de los usuarios no tenían instalado Microsoft Excel, por lo tanto no
podían abrir la encuesta. Para solucionar este problema fue necesario cambiar la
encuesta a un formato común para que cualquier hoja de cálculo pudiera abrirla.
Segundo, como las encuestas fueron enviadas por correo electrónico a los usuarios que
participaron de manera remota para que las completaran cuando fuera posible, a unos
pocos usuarios se les olvidaba y no contestaban el correo electrónico. Sin embargo,
estos problemas no ocurrían con los usuarios que participaban presencialmente, porque
la encuesta estaba impresa y la completaban al final de la aplicación de las técnicas.
Además de estos problemas descritos, también hay que destacar que a la hora de
seleccionar a los participantes, el director del proyecto OpenOffice Writer, Rob Weir,
contaba con una lista de usuarios, pero estos usuarios no estaban clasificados, es decir,
no se sabían los usuarios representativos de la aplicación, por lo tanto tuve que
clasificarlos a través de un cuestionario para diferenciar entre junior y senior según el
uso que hacían de la herramienta.
CAPÍTULO 6.
Además, a medida que los usuarios de la comunidad OSS han crecido más allá de los
desarrolladores de software, se ha incrementado el interés por la usabilidad y se han
aplicado técnicas de usabilidad adaptadas de la IPO. En este trabajo, estas técnicas se
han determinado para las actividades IPO que han sido encajadas teniendo en cuenta
tipos genéricos de actividades de IS: ingeniería de requisitos, diseño y evaluación.
Del mismo modo que la comunidad OSS desarrolla software siguiendo su propia
filosofía, alejándose de la manera tradicional de desarrollar software que establece la IS,
está incorporando la usabilidad en sus procesos de desarrollo. Es decir, una vez que la
REFERENCIAS
Acuña, S.T., Castro, J.W., Dieste, O., Juristo, N. (2012). A Systematic Mapping Study
on the Open Source Software Development Process. Proceedings of the 16th
International Conference on Evaluation & Assessment in Software Engineering
(EASE’12), Ciudad Real, Spain, pp. 42-46.
Andreasen, M.S., Nielsen, H.V., Schroder, S.O., Stage, J. (2006). Usability in Open
Source Software Development: Opinions and Practice. Information Technology and
Control, 35(3A): pp. 303-312.
Bangor, A., Kortum, P., Miller, J.A. (2008). The System Usability Scale (SUS): An
Empirical Evaluation. International Journal of Human-Computer Interaction, 24(6): pp.
574-594.
Benson, C., Müller-Prove, M., Mzourek, J. (2004). Professional Usability in Open
Source Projects: GNOME, OpenOffice.org, NetBeans. Proceedings of the CHI 2004,
Vienna, Austria, pp. 1083-1084.
Bødker, M., Nielsen, L., Orngreen, R.N. (2007). Enabling User Centered Design
Processes in Open Source Communities. In Aykin, N. (Ed.): Usability and
Internationalization, Part I, IPOI 2007, LNCS 4559, Springer-Verlag, pp. 10-18.
Castro, J.W., Acuña, S.T. (2012). Differences between Traditional and Open Source
Development Activities. Proceedings of the 13th International Conference on Product-
Focused Software Development and Process Involvement (PROFES’12), Madrid,
Spain, pp. 131-144.
Castro, J.W., Acuña, S.T. (2011). Comparativa de Selección de Estudios Primarios en
una Revisión Sistemática sobre el Proceso de Desarrollo de Open Source Software.
Actas de las XVI Jornadas de Ingeniería del Software y Bases de Datos (JISBD’11),
Madrid, España, pp. 319-332.
Çetýn, G., Göktürk, M. (2011). Assessing Usability Readiness of Collaborative
Projects. International Journal of Computer Systems Science & Engineering, 26(4): pp.
259-274.
Çetýn, G., Göktürk, M. (2009). Collaboration in Open Source Domains. International
Journal of Open Source Software and Processes, 1(3): pp. 17-28.
Çetýn, G., Göktürk, M. (2008). A Measurement Based Framework for Assessment of
Usability-Centricness of Open Source Software Projects. Proceedings of the IEEE
International Conference in Signal Image Technology and Internet Based Systems
(SITIS'08), pp. 585-592.
Chrusch, M. (2000). Seven Great Myths of Usability. Interactions, pp. 13-16.
Constantine, L.L., Lockwood, L.A.D. (1999). Software for Use: A Practical Guide to
the Models and Methods of Usage-Centered Design. Third Edition. Addison-Wesley.
Cooper, A., Reimann, R., Cronin, D. (2007). About Face 3.0: The Essentials of
Interaction Design. Wiley Publishing.
Dinh-Trong, T., Bieman, J.M. (2005). The FreeBSD Project: A Replication Case Study
of Open Source Development. IEEE Transactions on Software Engineering, pp. 481-
494.
Donahue, G.M. (2001). Usability and the Bottom Line. IEEE Software, 18(1): pp. 22-
30.
Ferré, X., Juristo, N., Moreno, A.M. (2005). Framework for Integrating Usability
Practices into the Software Process. Proceedings of the 6th International Conference in
Product Focused Software Process Improvement (PROFES'05). Lecture Notes in
Computer Science. Vol. 3547. pp. 202-215.
Ferré, X., Juristo, N., Moreno, A.M. (2002). Deliverable D5.2 Specification of the
Software Process with Integrated Usability Techniques. STATUS Project.
http://is.ls.fi.upm.es/status/results/STATUS_D5.2_v1.0.PDF.
Ferré, X., Juristo, N., Windl, H., Constantine, L. (2001). Usability Basics for Software
Developers. IEEE Software, pp. 22-29.
FreeMind (2014): http://FreeMind.sourceforge.net/Wiki/index.php/Main_Page
[Accessed: 13-05-2014].
Frishberg, N., Dirks, A.M., Benson, C., Nickell, S., Smith, S. (2002). Getting to Know
You: Open Source Development Meets Usability. Extended Abstracts of the CHI 2002,
Minneapolis, MI, pp. 932-933. Online: ACM Press,
http://doi.acm.org/10.1145/506443.506666.
Gujrati, S., Vasserman, E. (2013). The Usability of Truecrypt, or How I Learned to Stop
Whining and Fix an Interface. Proceedings of the 3rd ACM Conference on Data and
Application Security and Privacy (CODASPY’13), San Antonio, Texas, USA, pp. 83-
93.
Herdberg, H., Livari, N., Rajanen, M., Harjumaa, L. (2007). Assuring Quality and
Usability in Open Soruce Software Development. Proceedings of the First International
Workshop on Emerging Trends in FLOSS Research and Development (FLOSS'07),
IEEE Computer Society, pp. 1-5.
Hix, D., Hartson, H.R. (1993). Developing User Interfaces: Ensuring Usability through
Product and Process. John Wiley and Sons.
ISO Std. (1998). Ergonomic Requirements for Office Work with Visual Display
Terminals. Part 11: Guidance on Usability, ISO 9241-11.
Johnson, K. (2001). A Descriptive Process Model for Open-Source Software
Development. Master. Thesis in Computer Science. Department of Computer Science.
University of Calgary, pp. 131-144.
Mayhew, D.J. (1999). The Usability Engineering Lifecycle. Morgan Kaufmann.
Mockus, A., Fielding, R.T., Herbsleb, J. (2002). Two Case Studies of Open Source
Software Development: Apache and Mozilla. ACM Transactions on Software
Engineering and Methodology, pp. 309-346.
Müller-Prove, M. (2007). User Experience for OpenOffice.org. BCS Interfaces
Magazine 71, pp. 47-48.
Nichols, D.M., Twidale, M.B. (2006). Usability Processes in Open Source Projects.
Software Process Improvement and Practice, 11(2): pp. 149-162.
Scacchi, W. (2001). Is Open Source Software Development Faster, Better and Cheaper
than Software Engineering? Proceedings of the 23rd International Conference on
Software Engineering, Toronto, Ontario, Canada, pp. 119-124.
Senyard, A., Michlmayr, M. (2004). How to Have a Successful Free Software Project.
Proceedings of the 11th Asia-Pacific Software Engineering Conference (APSEC 2004),
IEEE Computer Society, pp. 84-91.
Shneiderman, B. (1998). Designing the User Interface: Strategies for Effective Human-
Computer Interaction. Addison-Wesley.
Terry, M., Kay, M., Lafreniere, B. (2010). Perceptions and Practices of Usability in the
Free/Open Source Software (FoSS) Community. Proceedings of the 28th Conference on
Human Factors in Computing Systems, (CHI’10), Atlanta, Georgia, USA, pp. 999-
1008.
Thomas, M.P. (2008). Why Free Software Has Poor Usability, and How to Improve it.
Online] Available: http://www.oreillynet.com/onlamp/blog/2008/08/
atthew_paul_thomas_why_free_s_1.html [Accessed: 13-05-2014].
Trudelle, P. (2002). Shall We Dance? Ten Lessons Learned from Netscape’s Flirtation
with Open Source UI Development. Proceedings of the CHI 2002. Presented at the
Open Source Meets Usability Workshop, Conference on Human Factors in Computer
Systems.
Tullis, T.S., Stetson, I.N. (2004). A Comparison of Questionnaires for Assessing
Website Usability. Proceedings of the Usability Professionals Association (UPA) 2004
Conference, Minneapolis, USA, pp. 7-11.
Vixie, P. (1999). Software Engineering. In: de DiBona, C., Ockman, S., Stone, M.
(Eds.): Open Sources: Voices from the Open Source Revolution”, O'Reilly Press, pp.
131-144.
Weber, S. (2000). The Political Economy of Open Source Software. BRIE Working
Paper, Nº 140: http://e-conomy.berkeley.edu/publications/wp/wp140.pdf [Accessed: 13-
05-2014].
ANEXOS
Las técnicas IPO especificadas en el apartado 2.2 del Capítulo 2, Estado de la Cuestión,
se describen a continuación.
modelo del dominio que tiene el usuario en la cabeza. Cada concepto se escribe en una
tarjeta, y se pide al usuario que organice las tarjetas en pilas. [Nielsen, 1993].
Casos de Uso Esenciales: A un nivel más alto de abstracción, los casos de uso se
definen en términos de las intenciones de los usuarios y las responsabilidades del
sistema, manteniendo un enfoque libre de tecnología e independiente de la
implementación. Pueden utilizarse para trabajar con casos de uso al principio del
proceso de desarrollo, sin tener que tomar demasiadas decisiones sobre los detalles de
la interfaz de usuario. El mapa de casos de uso particiona la funcionalidad total del
sistema en una colección de casos de uso esenciales interrelacionados. Nótese que
esencial se refiere al foco abstracto utilizado para la descripción de casos de uso, no
para especificar detalles de la interfaz de usuario, y es aplicable a todos los casos de uso,
no se refiere a un conjunto particular de casos de uso especialmente importantes.
[Constantine y Lockwood, 1999].
Contenido del Modelo de Interfaz: Es una representación abstracta de los contenidos
de los distintos espacios de interacción de un sistema. El contenido se puede modelar
por medio de papel (una hoja por cada espacio de interacción) y post-its que representan
las herramientas y materiales que se van a ofrecer al usuario. [Constantine y Lockwood,
1999].
Cuestionarios: Se trata de métodos indirectos de estudio de la interfaz de usuario,
porque proporcionan al equipo de desarrollo las opiniones del usuario, pero no
información directa de la interfaz de usuario. Son especialmente apropiadas para
obtener la satisfacción subjetiva del usuario. Los cuestionarios pueden ser distribuidos
por correo, correo electrónico o directamente con el software. [Nielsen, 1993].
Cuestionarios y Encuestas: Hay dos tipos de preguntas: cerradas (se pide al
encuestado que seleccione una respuesta entre un conjunto de respuestas alternativas) y
abiertas (el encuestado puede dar libremente su propia respuesta). Las preguntas
cerradas normalmente tienen algún tipo de escala de valoración. Tres de estas escalas
son: una escala de valoración multipunto, la escala Likert y la diferencial semántica. En
ocasiones se emplea un cuestionario antes y después de los estudios de rendimiento de
usuarios. Estos se conocen como pre- y post-cuestionarios. [Preece et al., 1994].
Cuestionarios de Perfiles de Usuarios: Los perfiles de usuarios describen a los
usuarios previstos del sistema, según las siguientes características:
o Características psicológicas (por ejemplo, actitud, motivación).
o Conocimiento y experiencia (por ejemplo, velocidad de mecanografiado,
experiencia en la tarea).
o Características del puesto y de las tareas (por ejemplo, frecuencia de uso,
estructura de tareas).
o Características físicas (por ejemplo, daltonismo).
Para cada usuario se incluye una descripción general, una descripción de las
características de los usuarios, y un apartado sobre los requisitos de usabilidad para ese
tipo de usuario. [Mayhew, 1999].
Diagramas de Afinidad: Esta técnica se propone para el caso de tener que organizar las
notas obtenidas de una serie de entrevistas contextuales, realizadas por varios
observadores en distintas sesiones. La técnica consiste en que cada observador anota en
un post-it cada una de las observaciones que va recogiendo de la observación de los
usuarios en su entorno habitual de trabajo. Cuando se reúnen todos los observadores,
van poniendo sus notas en una pared blanca grande, de una en una, agrupando juntas las
notas que parecen estar relacionadas. Según se van añadiendo notas, el grupo va
reagrupando las notas según criterios en los que esté de acuerdo todo el grupo. Se
presenta como paso de organización de ideas, previo a sesiones tipo tormenta de ideas
(brainstorming). [Mayhew, 1999].
Diagramas de Estado Harel: Este tipo de diagrama de estados permite agrupar
estados, para factorizar transiciones comunes, y pueden extenderse con especificaciones
de flujo de datos y de restricciones. Representan mejor que los diagramas de transición
la concurrencia y la sincronización. [O’ Mahony, 2003].
Diagramas de Transición de Estados de la Interfaz: En este tipo de diagramas los
nodos representan estados de la interfaz o pantallas, y los arcos representan transiciones
de estado basadas en las entradas. Estos diagramas pueden usarse para complementar
las representaciones UAN, indicando secuenciamiento e información de estado o modo.
[Ferré et al., 2005].
Diseño Integrado (both-and design): Se trata de una técnica para la ingeniería creativa
de interfaces. La manera de pensar both-and busca una síntesis creativa de ideas
aparentemente opuestas o alternativas supuestamente exclusivas. Más que un
compromiso, busca incorporar lo mejor de ambos mundos y satisfacer metas
conflictivas simultáneamente. Los autores describen un proceso para ayudar a encontrar
soluciones de este tipo. [Constantine y Lockwood, 1999].
Diseño Paralelo: Varios diseñadores distintos trabajan en diseños preliminares
(trabajando independientemente). Una variante se denomina Diseño Paralelo
Diversificado, en el que se pide a cada diseñador que se centre en diferentes aspectos
del problema de diseño. [Nielsen, 1993].
Encuestas: Las encuestas escritas de usuarios son un complemento familiar, barato y
generalmente aceptable para las pruebas de usabilidad y las revisiones por expertos. [O’
Mahony, 2003].
Entrevista Contextual: Tras reunir toda la información relacionada con el trabajo a
realizar (especificaciones de requisitos, reunión con miembros del equipo, reunión con
usuarios), y haber identificado los actores y casos de uso clave, se realizan las
observaciones o entrevistas contextuales propiamente dichas. En las entrevistas el
usuario realiza sus tareas habituales, y el entrevistador le interroga sobre el por qué de
sus decisiones y acciones. [Mayhew, 1999].
Entrevistas: Llevar a cabo entrevistas para obtener las reacciones subjetivas de los
usuarios. [Nielsen, 1993].
Entrevistas Estructuradas: En forma de entrevista post-experimento, el evaluador
pregunta a cada participante una serie de cuestiones preplanificadas [Ferré et al., 2005].
Entrevistas Flexibles: Generalmente se tiene un conjunto de temas establecidos, pero
una secuencia fija, y en este caso, el entrevistador es libre de seguir las respuestas de los
entrevistados para obtener mayor información de sus actitudes personales. [Preece et al.,
1994].
Escenario de Prototipos: Son prototipos que están limitados en dos sentidos: por una
parte reducen el número de funciones que ofrece el sistema, y por otra el usuario no
puede interactuar usando datos reales. Representan una sesión de interacción única, por
lo que sólo simulan la interfaz de usuario mientras el usuario siga un camino
previamente definido. Se trata de un tipo especialmente poco costoso de prototipos, y
pueden ser tanto prototipos de papel como prototipos ejecutables elaborados por una
herramienta de prototipado. [Nielsen, 1993].
Escenarios: Para sistemas que sufrirán cambios sustanciales (como en el caso de la
reingeniería de procesos) o cuando una aplicación novedosa se plantea, normalmente no
existen datos fiables acerca del rango y distribución de frecuencias de tareas y
secuencias. Una forma temprana y fácil de describir un sistema novedoso consiste en
escribir escenarios de uso y entonces, si es posible, llevarlos a cabo como si fuera teatro.
[Shneiderman, 1998].
Escenarios de Tareas: Los escenarios de tareas son instancias de casos de uso que
representan las tareas del trabajo en la vida real. Se elaboran estos escenarios para las
tareas más representativas de cada tipo de usuario. No hace falta que correspondan
exactamente con una tarea concreta que se haya observado en las entrevistas
contextuales, pues un escenario puede incorporar los aspectos más interesantes de varias
tareas reales combinados. [Mayhew, 1999].
Escenarios e Instantáneas de la Pantalla: Un escenario es una historia de ficción,
personalizada con personajes, eventos, productos y entornos. Las instantáneas son
imágenes visuales individuales (normalmente tipo cómic), que capturan una posible
acción significativa. [Preece, 1994][Ferré et al., 2005].
Escenarios y Storyboards: Un escenario es una historia de ficción, personalizada con
personajes, eventos, productos y entornos. Los storyboards son secuencias de
instantáneas que se centran en las principales acciones en una posible situación.
[Constantine y Lockwood, 1999].
Especificaciones de Usabilidad: Son objetivos de usabilidad cuantitativos, que se
utilizan como guía para conocer cuándo una interfaz es suficientemente buena. Pueden
basarse en medidas objetivas o subjetivas. Las Medidas Objetivas se asocian
normalmente con una tarea concreta de referencia, mientas que las Medidas Subjetivas
se asocian habitualmente con un cuestionario para usuarios. [Hix y Hartson, 1993].
Etnográfico: Es un método tradicional utilizado en Antropología. Los investigadores
etnográficos procuran sumergirse en la situación sobre la cual quieren aprender algo.
[Preece et al, 1994].
Evaluación Heurística: Se lleva a cabo observando una interfaz e intentando obtener
una opinión acerca de lo bueno y malo de la interfaz. [Nielsen, 1993][Ferré et al., 2005].
Es mejor tener a varios evaluadores que revisen el mismo diseño de forma
independiente, puesto que descubren muchos más errores que un único evaluador. Lo
ideal es que lo realicen especialistas en usabilidad. Un tipo de evaluación heurística
particular es el recorrido pluralístico:
o Recorrido Pluralístico: Esta Evaluación Heurística se lleva a cabo por
usuarios representativos, desarrolladores del producto y especialistas en
usabilidad. [Nielsen, 1993].
Evaluación por Expertos: Los revisores son expertos en la aplicación o en el dominio
de la interfaz de usuario. Dependiendo del centro de atención de la revisión, hay
diferentes tipos de revisiones [Shneiderman, 1998][Hix y Hartson, 1993]:
o Evaluación Heurística: Los revisores expertos critican una
interfaz para determinar la conformidad con una lista corta de
heurísticas de diseño.
o Revisión de Guías: Se comprueba la conformidad de la interfaz
con el documento de guías organizacional u otros.
o Inspección de Consistencia: Los expertos verifican la
consistencia a lo largo de una familia de interfaces, comprobando
la consistencia de terminología, color, disposición, formatos de
entrada/salida, etc.
o Recorrido Cognitivo: Los expertos mantienen una reunión tipo
juicio, con un moderador o juez, para presentar la interfaz y
discutir sus méritos y debilidades.
lógica que ha motivado dichas decisiones para permitir futuros cambios. [Hix y
Hartson, 1993].
HTA (Hierarchical Task Analysis): Se trata de un método clásico de análisis de tareas,
según los autores es uno de los más conocidos. Implica un proceso iterativo de
identificación, categorización y descomposición de tareas en subtareas, junto con la
comprobación de la precisión de tal descomposición. Se divide en tres etapas: inicio,
progreso y finalización. Para la representación gráfica de la descomposición utiliza los
diagramas de estructuras. Estos diagramas muestran la secuencia de actividades
ordenándolas de izquierda a derecha; las actividades que se pueden repetir se marcan
con un asterisco dentro de la caja, y cuando hay una elección entre un número de
actividades éstas se marcan con un pequeño círculo dentro de la caja. [Preece et al.,
1994].
Información Post-Test: La mayor parte de planes de test incluyen una entrevista post-
test con cada sujeto. Normalmente se agradece a los sujetos por su participación y se les
reafirma acerca de su rendimiento. [Constantine y Lockwood, 1999].
Inspección de Consistencia: Equipos de diseñadores, al menos uno de cada proyecto,
que se reúnen para inspeccionar un conjunto de interfaces para una familia de
productos. [Preece et al., 1994][Hixy, Hartson, 1993].
Inspecciones de Colaboración: Se trata de un examen sistemático de un producto
finalizado o un prototipo, desde el punto de vista de su usabilidad última por los
usuarios previstos. El proceso de revisión es un esfuerzo de equipo que incluye
desarrolladores software, usuarios finales, expertos de la aplicación o del dominio y
especialistas en usabilidad, colaborando para realizar una inspección completa y
eficiente. [Constantine y Lockwood, 1999].
Inspecciones de Conformidad: En las inspecciones de conformidad, el objetivo es
identificar desviaciones de los estándares de interfaz de usuario o de las guías de estilo
en vigor en la organización. Todos los participantes deben estar familiarizados con los
estándares o guías de estilo aplicables, y no se suele incluir a usuarios. [Constantine y
Lockwood, 1999].
Instantáneas, Escenarios y Storyboards: Un escenario es una historia de ficción,
personalizada con personajes, eventos, productos y entornos. Las instantáneas son
imágenes visuales individuales (normalmente tipo cómic), que capturan una posible
acción significativa. Los storyboards son secuencias de instantáneas que se centran en
las principales acciones en una posible situación. [Preece et al., 1994].
Instrumentación Interna de la Interfaz: Esta técnica consiste en la programación de
registros internos de las acciones que se realizan sobre la interfaz. [Ferré et al., 2005].
Interacción Constructiva: Implica tener a dos usuarios de test utilizando el sistema
juntos. Se denomina también Aprendizaje de Codescubrimiento. Se basa en el hecho de
que las personas acostumbran a verbalizar cuando están intentando resolver un
problema de forma conjunta. [Nielsen, 1993].
Investigación Contextual: Es una forma de educción que puede usarse para
evaluación. Los usuarios e investigadores participan para identificar y comprender los
problemas de usabilidad en el entorno habitual de trabajo del usuario. [Preece et al.,
1994].
JEM (Joint Essential Modeling): Es un proceso estructurado para colaborar con
usuarios para desarrollar especificaciones de requisitos centrados en el uso mediante el
modelado concurrente. Se parece de alguna forma a su antecesor JAD (Joint
Application Design). Las actividades que incluye JEM son las siguientes [Constantine y
Lockwood, 1999]:
1. Premodelado y consolidación
2. Modelado de roles
3. Modelado de tareas
4. Evaluación de modelos
5. Asignación de funcionalidades.
Laboratorio de Pruebas de Usabilidad: Los test de usabilidad tienen un número
menos de sujetos que los experimentos controlados, y el resultado es un informe con
cambios recomendados. [O’Mahony, 2003].
Laboratorio de Usabilidad: Se trata de instalaciones especialmente dedicadas a test de
usabilidad. Suelen tener espejos de una sola vía y cámaras de vídeo. [Nielsen, 1993].
Mapa de Navegación del Contexto: Representa la arquitectura general de la interfaz
de usuario modelando las relaciones entre contextos de interacción. Cada contexto se
representa con un rectángulo y las flechas que los conectan representan posibles
transiciones entre un espacio de interacción y otro. [Constantine y Lockwood, 1999].
Mapa de Roles de Usuario: Los roles de usuarios y sus relaciones se representan por
medio de un Mapa de Roles de Usuario. Captura la visión general de los usuarios del
sistema. Las relaciones que se representan pueden ser de afinidad, clasificación o de
composición. [Constantine y Lockwood, 1999].
Métricas de Rendimiento: Cuantifican importantes aspectos del uso real, bien en un
entorno controlado de laboratorio, bien en el entorno habitual de trabajo. [Constantine y
Lockwood, 1999].
Método del Conductor: El experimentador (o “entrenador”) lleva al usuario en la
dirección adecuada cuando éste está usando el sistema. El usuario puede preguntar al
experimentador, y las preguntas pueden mostrar problemas de usabilidad que
permanecerían ocultos de otro modo. El experimentador contestará en base a su
conocimiento del sistema. [Nielsen, 1993].
Modelado Operacional: El modelo operacional es una colección de varias influencias
operacionales y contextuales que pueden jugar un rol en usabilidad. Estas colecciones se
refieren como perfiles. Los factores operacionales que pueden afectar a la arquitectura y
detalles de la interfaz de usuario son: características de los usuarios y roles de usuario,
aspectos del entorno físico de trabajo, características y limitaciones del equipo y de los
dispositivos de interfaz, y factores operacionales de riesgo genéricos y específicos.
[Constantine y Lockwood, 1999].
Modelo Estructurado de Roles: Un modelo de roles es una lista de roles de usuarios
que va a soportar por un sistema, que describe cada rol en términos de sus necesidades,
intereses, expectativas, comportamientos y responsabilidades que caracterizan y
distinguen ese rol. Algunos roles se destacan como roles focales, y son los que se juzgan
como los más comunes o típicos o que se consideran particularmente importantes desde
una perspectiva de negocio o desde el punto de vista del riesgo o de algún otro
contenido técnico. El modelo estructurado de roles ofrece una forma metódica de
capturar el máximo posible de información relevante sobre la relaciones de los usuarios
del sistema. Se organiza en una serie de perfiles como descripción (incumbents),
habilidad (proficiency), interacción, información, criterios de usabilidad o soporte
funcional. [Constantine y Lockwood, 1999].
Objetivos de Usabilidad: Los objetivos de usabilidad se establecen al comienzo de un
proyecto con el fin de que dirijan todas las posteriores decisiones de diseño [Mayhew,
1999]. Pueden ser de varios tipos:
o Objetivos Cualitativos: Este tipo de objetivos o requisitos describen
metas no cuantificables. Son útiles para guiar los esfuerzos iniciales de
diseño.
Toma de Incidentes Críticas: Esta técnica consiste en registrar tanto los incidentes
negativos (signos de frustración, bien a través de comentarios, bien con acciones), como
los incidentes positivos (expresiones de satisfacción y terminación). Los incidentes
negativos ayudan a identificar los principales problemas de usabilidad, mientras que los
positivos ayudan a identificar metáforas o detalles a utilizar más a fondo en la interfaz
de usuario debido a su éxito. [Ferré et al., 2005].
UAN (User Action Notation): UAN es una técnica para representar el diseño de la
interacción con el usuario desde un punto de vista comportamental. UAN aborda el acto
mental creativo que supone la resolución de problemas (por ejemplo, al crear nuevos
diseños), y el acto físico de documentar una representación del diseño. La abstracción
primaria en UAN es la tarea del usuario. Una interfaz se representa como una estructura
casi-jerárquica de tareas asíncronas, siendo independiente el secuenciamiento dentro de
cada tarea del de otras tareas. Las acciones de los usuarios, la correspondiente reacción
de la interfaz, y la información de cambio de estado son representadas al nivel más
detallado. [Ferré et al., 2005].
Uso de Registro Real: Registrar el uso implica tener al ordenador recogiendo
automáticamente estadísticas acerca del uso detallado del sistema. Normalmente es una
forma de conseguir información acerca del uso de campo de un sistema tras su
lanzamiento, pero puede utilizarse como un método suplementario en test de usabilidad.
[Nielsen, 1993].
Observación Directa
Número de Nivel de
Problema Mejoras
Personas Relevancia
No se ve fácilmente insertar 2 Alto Poner más visible las
un nodo nuevo opciones relacionadas
con insertar y eliminar
nodos
No se ve fácilmente insertar 1 Alto Poner más visible las
un nodo hijo opciones relacionadas
con insertar y eliminar
nodos
No se ve fácilmente donde 1 Bajo Organización de los
está el símbolo! iconos en la barra de
herramientas y por
categorías
El símbolo familia es muy 4 Medio Modificar el símbolo de
parecido a grupo familia
Figura I.1: Resultados de la Aplicación de la Técnica Observación Directa
Número de Nivel de
Problema Mejoras
Personas Relevancia
Pide guardar a la hora de 3 Alto No pedir guardar
meter una imagen cuando se inserta una
imagen
Los símbolos son muy 4 Alto Poner los símbolos en la
pequeños barra de herramientas y
modificar el tamaño de
estos
Botón de eliminar y mover 2 Alto Poner más visible las
nodos, bastante escondido opciones relacionadas
con insertar, eliminar y
mover nodos
Usabilidad de toda la 3 Alto Cambiar parte de la
aplicación usabilidad, pensando en
principiantes
Eliminar un icono 2 Medio Opción más visible y
más explicativa
Eliminar un icono, cuando hay 2 Medio Poder eliminar
más de uno cualquier icono, sin ser
el último
Símbolo familia con el botón 1 Alto Poder acceder a todos
derecho no sale los símbolos a través del
botón derecho
La imagen sale muy grande 1 Alto Redimensionamiento de
la imagen
Dificultad para encontrar los 2 Alto Clasificación de los
símbolos iconos por categorías
Seleccionar un nodo, modifica 1 Bajo Seleccionar un nodo, sin
el texto que salte la
modificación del texto
No se pueden mover los nodos 1 Medio Movimiento de
cualquier nodo del
mapa
Imagen quita el texto del nodo 1 Alto Mismo nodo con una
imagen y texto
Nodo hijo y nodo padre tienen 1 Bajo Cambiar la forma del
la misma forma nodo hijo con respecto
al padre
Mover el diagrama del nodo 1 Bajo Poder mover el
principal diagrama desde
cualquier parte del
mapa
No se encuentra eliminar nodo 1 Medio Poner más visible las
opciones relacionadas
con insertar y eliminar
nodos o poner un
símbolo
Figura I.1: Resultados de la Aplicación de la Técnica Observación Directa (Continuación)
Nivel de
Problema Número Mejoras
Relevancia
Encontrar el símbolo de 1 Alto Poder acceder a todos los
familia con botón derecho símbolos a través del
botón derecho
Símbolos desordenados 4 Alto Organización de los
iconos en la barra de
herramientas y por
categorías
Poca flexibilidad y poca 1 Alto Cambiar parte de la
intuitiva interfaz, pensando en
principiantes
Eliminar nodo de una hoja 1 Medio Preguntar solo si la hoja
pregunta si quieres borrar tiene hijos, sino no
Eliminar un icono cuando hay 3 Alto Poder eliminar cualquier
más de uno icono, sin ser el último
No se sabe si se ha 1 Alto Sombrear un nodo
seleccionado un nodo cuando es seleccionado
Los símbolos son muy 1 Alto Poner los símbolos en la
pequeños barra de herramientas y
modificar el tamaño de
estos
Apariencia en nodos y ramas 3 Bajo Cambiar la forma de los
muy seria nodos y poner colores a
las diferentes ramas
Menús poco homogéneos 1 Medio Variar cada
funcionalidad de los
menús según la función
que realicen
Apariencia poco agradable 1 Bajo Poner una interfaz con
más colorido y agradable
visualmente
Deficiente la forma de operar 1 Alto Operaciones de forma
homogénea entre todas
las opciones que se
pueden realizar
El símbolo guardar no 1 Alto Interactividad para el
interactúa símbolo de guardar el
mapa conceptual
Selección de varios nodos 1 Medio Poder seleccionar varios
nodos a través de un
cuadrado de selección
Imagen muy grande 2 Alto Redimensionamiento de
la imagen
Cambiar el color del fondo de 1 Bajo Cambiar el color de la
la nube si no se pulsa bien el nube desde cualquier
nodo nodo dentro de la nube, y
no solo desde el nodo
padre
Figura I.1: Resultados de la Aplicación de la Técnica Observación Directa (Continuación)
Número de Nivel de
Problema Mejoras
Personas Relevancia
Guardar al meter la imagen 1 Alto No pedir guardar cuando
se mete una imagen
Color fondo del nodo no 1 Alto Cambio del color de
aparece cuando se cambia nodo sea automático
cuando se selecciona el
color
Símbolos de la barra de 2 Medio Cambiar los símbolo por
herramientas iguales y hacen otros
cosas diferentes
Símbolo familia muy igual al 1 Medio Modificar el símbolo de
de grupo la familia
No se ve fácilmente insertar 1 Alto Poner más visible las
nodo hermano opciones relacionadas
con insertar y eliminar
nodos
No se puede mover los nodos 1 Medio Movimiento de cualquier
nodo del mapa
Diferencia entre nodo hijo y 1 Medio Cambiar la forma del
hermano en el nodo raíz nodo hijo y del nodo
hermano con respecto al
raíz
Opción “Color nodo” no se 1 Alto Especificar para que es
sabe si es para a fuente o el “Color del nodo”, fuente
fondo o fondo
Actualización de la 1 Bajo Avisar al usuario de
herramienta con versiones nuevas versiones
Barra de herramientas en un 1 Alto Mismo lenguaje para los
mismo lenguaje menús de la barra de
herramientas
Mayor variedad de símbolos y 1 Bajo Opción para poder añadir
poder añadir iconos, y mayor variedad
de ellos
3. Recomendaciones
Mejoras Prioridad
Apariencia más visible con colores y formas diferentes Medio
Documentación más amplia para mayor formación Alto
Innecesario guardar el documento para meter una imagen Alto
Agrupación de los iconos según categoría de funcionalidad Alto
Redimensionamiento de la imagen Alto
Mayor distinción del símbolo familia con el grupo Alto
Poner más visible las opciones de insertar nodo, nodo hermano y nodo hijo Alto
Actualizar la herramienta con versiones Bajo
Mejoras Prioridad
Mismo lenguaje para la barra de herramientas Alto
Mayor variedad de icono y poder añadir más Bajo
Iconos más grandes Medio
Poner un botón de papelera y otro para mover, en el barra de herramientas Medio
Aplicación más intuitiva Alto
Retocar la interfaz para facilitar el manejo del sistema Medio
Poner los iconos en un lugar más visible Alto
Selección de un nodo sin que se modifique el texto Alto
Permitir el movimiento de los nodos Alto
Poder tener una imagen y un texto en un mismo nodo Alto
Formas diferentes para los nodos hijos Bajo
Poder mover el diagrama pinchando en un hueco en blanco Medio
Cambiar “Eliminar último icono” por “Eliminar último icono introducido” Medio
Observación Remota
3. Recomendaciones
Mejoras Prioridad
Iconos menos ocultos con el botón derecho Medio
Redimensionar los iconos Alto
Redimensionar la imagen Alto
Usuarios principiantes, información de donde y como hacer las cosas Bajo
Diseño de la interfaz más moderna Medio
Agrupación de los iconos Alto
Mover los nodos Alto
Ver color del fondo del nodo de forma automática Alto
Al hacer click derecho que no desaparezcan nodo hermano e hijo Alto
Click derecho tenga las mismas opciones que la barra de herramientas Medio
Nodo principal donde se quiera, no solo en el centro Medio
Barras laterales para poder mover el mapa Medio
Quitar la parte de debajo de la interfaz Bajo
Borrar y papelera en la barra de herramientas, no donde lo iconos Medio
Selección de iconos más importantes Medio
Lista de iconos más pequeña Bajo
Ramas más bonitas Bajo
Fondo detrás del mapa Bajo
Ajustar la resolución de la pantalla Bajo
Mejor acceso al menú de filtros Medio
Añadir iconos de fuera de la herramienta Bajo
Usar más el teclado, comandos rápidos Medio
Modificar FreeMind a FreePlane Bajo
Opción de vista preliminar de todo el mapa Medio
Lista de opciones al nodo marcado Medio
Remarcar los botones de la barra de herramientas cuando se pase el ratón por Medio
encima
Figura J.1: Resultados de la Aplicación de la Técnica Observación Remota (Continuación)
3. Recomendaciones
Mejoras Prioridad
Poner un ayudante virtual Bajo
La interfaz gráfica debería ser sin el panel derecho Medio
Resaltar los botones y opciones que más se utilicen y quitar las que no se Bajo
utilicen a menudo
Diseño para los encabezados Medio
Poner en cada pestaña las opciones de cada herramienta relacionada con Alto
ello
La paginación tiene que ir con el encabezamiento o pie de página, tendría Alto
que preguntar dónde meterlo
Ordenar la tabla sin quitar el encabezado de esta Bajo
Mejorar los nombre del menú Campos y Carácter, porque no son Alto
intuitivos
La opción Herramientas/Galería tendría que ser Insertar/Imagen/Galería Alto
Sacar el desplegable del menú Campos y ponerlos dentro de las opciones Medio
de Insertar, separadas de las otras opciones
Cerrar la galería una vez seleccionada la imagen ya sea de Herramientas o Medio
del panel derecho
Desmarcar de forma automática la opción de vincular la imagen, cuando Medio
se sale de la ventana
Valor por defecto de forma automática la opción de calidad de Medio
compresión, cuando se sale de la ventana
3. Recomendaciones
Mejoras Prioridad
La aplicación debe ser más intuitiva como Kingsoff Office, ya que es más Medio
fácil de manipular
Iconos más estéticos Medio
Barra de herramientas que ocupen más espacio para que sean fácilmente Alto
identificables
A la interfaz le falta algo más de color y de diseño minimalista Bajo
Posicionar la imagen porque no hay un wizard para ponerla con opciones Alto