Rodríguez Contreras David Ismael

Usabilidad

La usabilidad debe entenderse como un concepto global y universal,

estratégico para las empresas y responsables de un diseño web y un proyecto
e-business. No debe interpretarse y ejercitarse desde un área o departamento
más de la organización, sino dentro de todos los departamentos y a todos los
niveles de una organización, incluyendo desde el Director General hasta el
último Programador web, y mucho antes de empezar a diseñar la Web.
Este artículo trata de explicar que la usabilidad es estratégica para el
éxito on-line, por qué es esto así y cómo se debe implantar la usabilidad en una
organización si se la considera estratégica.

Responsable de usabilidad

En la actualidad poco se sabe sobre usabilidad y arquitectura de

información en Internet. Y de los que saben, pocos son capaces de implantar
una estructura metodológica que permita realmente obtener los resultados
deseados. En muchos casos esto es así simplemente por no concederle a la
usabilidad el protagonismo que se merece, y por desconocimiento del impacto
que tiene en el comercio electrónico y la imagen de marca on-line.
No obstante, a menudo nos encontramos con empresas y organizaciones que
han tomado en serio la usabilidad y han hecho algo al respecto.
Encontramos entonces departamentos de usabilidad, responsables de
usabilidad, o Directores de Contenidos. A estas personas se les asigna una
serie de tareas, entre ellas hacer que el trabajo realizado por el área de
desarrollo web cumpla con unos requisitos (muy en línea con el trabajo
realizado en un control de calidad) de usabilidad. Escenas típicas en su día a
día incluyen una lucha interna entre dicho departamento y el equipo de
desarrollo.

La usabilidad se refiere a la capacidad de un software o sistema interactivo

(una web) de ser comprendido, aprendido, usado fácilmente y ser atractivo
para un usuario, en condiciones específicas de uso. También es la efectividad,
eficiencia y satisfacción con la que un producto permite alcanzar objetivos
específicos a usuarios específicos en un contexto de uso específico.

Jugabilidad

Jugabilidad es un adjetivo calificativo que es usado en la valoración de un

videojuego. Se refiere a todas las experiencias de un jugador durante la
interacción con sistemas de juegos.
Surgiendo junto con el desarrollo de diseñadores de juegos en los años 1980,
la jugabilidad era usada solamente en el contexto de los videojuegos, aunque
ahora por su popularidad ha comenzado a verse el uso en la descripción de
otras formas de juegos más tradicionales.
Decir: "El juego tiene buena jugabilidad", se refiere a que durante el gameplay
el o los personajes se pueden controlar fluidamente, es decir sus movimientos
no serán toscos ni limitados o entrecortados, esto implica además que gozarán
de una buena animación acorde a la generación y época del juego. Y la
Rodríguez Contreras David Ismael

interacción con el medio ambiente virtual en el que se desarrolla el juego será

fluida.
Decir: "El juego tiene una mala jugabilidad", se refiere a que durante el
gameplay el o los personajes se controlarán muy limitadamente o toscamente.
Y puede no interactuar correctamente con el medio ambiente virtual. Por
ejemplo: El personaje que viene caminando por el piso y quiere agarrar una
escalera vertical para subir, si resultara que el personaje tiene que posicionarse
justo debajo de la escalera para poder subir (con presición pixel-métrica)
implica que la jugabilidad es mala.
Por el contrario, Decir: "El juego tiene buena jugabilidad", siguiendo el
ejemplo dado, se podría tomar esa misma escalera estando posicionando en
un rango cercano a la escalera y no tener que medir la posición exacta o
seguramente aun viniendo saltando también podrías tomarla.
La calidad (no la cantidad) de los movimientos que el o los personajes
puedan hacer también influye en la calificación de buena o mala jugabilidad.

Los problemas que influyen en decir que la jugabilidad es mala, son:

• Retraso (LAG) entre lo que el jugador ordena hacer y lo que se vé en el
juego.
• Que la animación (no la calidad gráfica) del personaje no sea buena
(generalmente porque usa pocos cuadros consecutivos para mostrar
cada acción), es decir en un momento dado no se pueda observar
perfectamente que está haciendo el personaje como para mantener
fluidamente el feedback en la interacción entre el jugador y el juego.
• Limitaciones del tipo: Si estoy haciendo el movimiento "A" NO pueda
pasar rápidamente al movimiento "B" salvo que primero pase por el
movimiento "C" y siendo este último movimiento una acción tal que no
concuerde con la normal dinámica que se desarrolla en el juego (por
ejemplo cuando el paso por el movimiento "C" es obligatorio debido a un
olvido del programador del juego de prever la situación de pasar del
movimiento "A" al "B" directamente).

En fin, hay un montón de pequeños detalles que hacen a una buena o mala
jugabilidad. Cabe destacar que la misma no es afectada por la generación a la
que pertenezca el juego, sino por la calidad y empeño que los programadores
hayan puesto en el código del gameplay del juego.

Motor de Juego

Un motor del juego es el componente de software de la base de un juego de la

computadora o del vídeo o el otro uso interactivo con los gráficos en tiempo
real. Proporciona las tecnologías subyacentes, simplifica el desarrollo, y
permite a menudo al juego funcionar en plataformas múltiples tales como
consolas del juego y sistemas operativos de escritorio tales como OS X de
Linux, del Mac, y Microsoft Windows. La funcionalidad de la base
proporcionada típicamente por un motor del juego incluye un motor de
representación (“renderer”) para el 2.o o los gráficos 3D, una detección del
motor de la física o de la colisión, sonido, el scripting, animación, inteligencia
artificial, establecimiento de una red, y un gráfico de la escena.
Rodríguez Contreras David Ismael

Los motores del juego proporcionan una suite de las herramientas de

desarrollo visuales además de componentes de software reutilizables. Estas
herramientas se proporcionan generalmente en un ambiente integrado del
desarrollo para permitir el desarrollo simplificado, rápido de juegos de una
manera data-driven. Estos motores de los juegos a veces se llaman
“middleware del juego” porque, como el sentido del negocio del término,
proveen de una plataforma flexible y reutilizable del software que proporcione
toda la funcionalidad de la base necesitada, derecha fuera de la caja, para
desarrollar un uso del juego mientras que reducen costes, complejidades, y
tiempo-a-mercado-todos factores críticos en la industria altamente competitiva
del juego de la computadora y del vídeo.
Como otras soluciones del middleware, los motores del juego
proporcionan generalmente la abstracción de la plataforma, permitiendo que el
mismo juego sea funcionado en varias plataformas incluyendo las consolas del
juego y los ordenadores personales con poco, os ningunos cambios realizados
al código de fuente del juego. A menudo, el middleware del juego se diseña con
una arquitectura componente-basada que permita que extiendens los sistemas
específicos en el motor sean substituidos o con componentes del middleware
especializado (y a menudo más costoso) tales como Hayok para la física,
FMOD para el sonido, o Speed Tree para rendir. Algunos motores del juego
tales como RenderWare incluso se diseñan como serie de componentes
libremente conectados del middleware que se puedan combinar selectivamente
para crear un motor de encargo, en vez del acercamiento más común de
extender o de modificar una solución para requisitos particulares integrada
flexible.
No obstante se alcanza la extensibilidad, sigue siendo una prioritaria en
los motores de los juegos debido a la variedad amplia de aplicaciones las
cuales se soliciten. A pesar de la especificidad del nombre, los motores del
juego son de uso frecuente para otras clases de usos interactivos con
requisitos gráficos en tiempo real tales como versiones parciales de programa
de la comercialización, visualizaciones arquitectónicas, simulaciones de
entrenamiento, y modelar ambientes.

Mod

En el mundo de los videojuegos un mod (del inglés modification) es una

extensión que modifica un juego original proporcionando nuevas posibilidades,
ambientaciones, personajes, diálogos, objetos, etc.
Prácticamente todos los juegos modernos incorporan herramientas y
manuales para que exista la posibilidad de modificarlos y así crear el mod.
Aunque anteriormente las comunidades de modders (creadores de
mods) eran no oficiales y no pasaban de más de un grupillo de gente,
actualmente se ve el interés de las compañías en tener una base de fans que
no sólo juegue, si no que además cree estos contenidos no oficiales para
extender la vida de los juegos durante, en algunos casos, muchos años más.
Actualmente se puede ver a las compañías dando el primer empujón a las
comunidades de modders, dándoles las herramientas, los tutoriales y el soporte
necesario para que los fans se involucren más en los juegos.
Rodríguez Contreras David Ismael

DFD

Los diagramas de flujo de datos son una herramienta de representación de flujo

de información.

Características:

• Notación gráfica
• Representan el flujo de información
• Fácilmente inteligibles
• Permiten descomposición en sub-modelos.

En un DFD aparecen elementos de los tipos siguientes:

• Flujos de datos: indica flujo de información.

• Procesos: (o actividades): transformar la información.
• Ficheros: son almacenes de información en los que está se guarda a la
espera de un procesamiento posterior.
• Entidades externas: son fuentes o sumideros de información (podría
darse el caso de alguna mixta).

Las reglas que deben respetarse en la elaboración de los DFD son:

• Los nombres deben ser unívocos, en el conjunto de diagramas de un

sistema.
• Los flujos pueden converger o divergir.
• Los procesos y ficheros no pueden poseer sólo flujos de entrada, ni
tampoco de salida. (Un elemento de estas características debería
reflejarse como entidad externa.)
• Los flujos no pueden contener información de control.

Como elaborar un DFD

• La mentalidad con que debemos abordar la realización de un DFD es la

de “interrogar a los datos”.
• Debemos preocuparnos sistemáticamente antes de los flujos de
información que de los procesos.
• Es conveniente dar nombre primero a los flujos y después a los
procesos.
• El proceso a seguir podría ser:
→ Identificar todos los flujos netos, de entrada y salida, del diagrama
y dibujarlos en su periferia.
→ Intentar conectar las entradas con las salidas, y las salidas con
las entradas, dejándose guiar por la información procedente del
usuario, intentando reflejar el flujo de información tal como es más
que preguntarse porqué es así.
→ Seguir el camino desde las entradas a las salidas, desde las
salidas a las entradas, y desde el centro a la periferia.
Rodríguez Contreras David Ismael

→ Prepararse para volver a empezar.

Denominaciones

• Dar a los flujos nombres significativos, que reflejan su contenido en

información y, si es relevante el estado de la misma.
• Habrá que poner especial esmero en la denominación de los flujos de la
interfaz del sistema.
• Un proceso bien concebido puede describirse fácilmente en términos de
sus entradas y salidas.

Diccionarios de datos DD

El diccionario de datos DD completa la información que aparece en los DFD,

aportando descripciones es:

• Flujos
• Ficheros
• Los datos que contienen unos y otros.
• Entidades externas
• Procesos que se consideren necesario especificar (todas las primitivas
funcionales y algún otro proceso cuyo DFD, que no refleja información
de control, no describa suficientemente).

La idea más importante acerca del DD es que ni esté, por sí sólo, ni el conjunto
{DFD,DD} puedan ser redundantes.