Navegación

Introducción

La navegación es un subconcepto de una incumbencia más general de nuestra aplicación, y en particular de nuestra interfaz de usuario: la interacción. Toda acción del usuario sobre la interfaz es una interacción. Navegación se refiere en particular a esas interacciones que el usuario realizará para poder llevar acabo diferentes tareas. En general serán todas las interacciones relacionadas con el ciclo de vida de una tarea:
  • cómo iniciar una tarea
  • cómo terminar una tarea:
    • exitósamente
    • cancelándola
  • será posible realizar tareas en simultaneo ?
  • podrá el usuario anidar tareas (realizar una subtarea mientras aún sigue con la tarea más general) ?
Cómo verán aquí, tanto nombrar el concepto de tarea les dará la idea de que es un concepto importante, ya que la navegación se define en base a ella.
Pero entonces bajémoslo a algo concreto, qué sería una tarea ?

Tareas / Caso de Uso

Nos referimos a tarea aquí como una unidad de trabajo que comienza y realiza un usuario sobre el dominio.
Por ejemplo:
  • En un sistema de gestión de un videoclub:
    • Crear un nuevo usuario
    • Alquilar una película
    • Buscar un usuario
    • Eliminar un usuario
    • Crear una nueva película
    • Buscar una película
    • etc.
Esta definición tiene cierta similitud con la idea de caso de uso del análisis de requerimientos. Por eso a veces se utilizan ambos términos intercambiáblemente.

Pero entonces, ¿cómo se relacionan las tareas con la UI?

Relación entre una Tarea y los elementos de una Interfaz de Usuario

La relación entre las tareas y la UI es justamente la navegación.  Esta navegación, o su implementación va a depender de varios factores:
  • La arquitectura: por ejemplo,
    • Aplicación standalone de escritorio
    • Aplicación distribuída web
    • Aplicación de escritorio distribuída
  • Los dispositivos:
    • PC
    • Handhelds: PDA; Palm, Windows Mobile
    • Mobile: android
    • Dispositivos dedicados o de ciertas industrias particulares
  • La tecnología que estemos usando: léase el framework que estemos usando. Las capacidades que nos brinde y sus limitaciones. 
    • Por ejemplo, arena no les permite (actualmente) crear nuevos componentes fácilmente. Tampoco les permite acceder a los controles propiamente dichos (ejemplo, acceder al texto actual de un TextBox).
  • Los requerimientos de usuario:
    • La interfaz de usuario es un elemento más de nuestro sistema, y como todo el usuario/cliente puede tener una idea preconcebida de lo que quiere de ella. De hecho, la interfaz es uno de los puntos centrales ya que es justamente la cara visible para el usuario.
Así como hemos visto previamente cómo vincular nuestro dominio con la interfaz de usuario (a través de bindings, por citar un ejemplo), la manera de implementar una tarea  y su navegación va a depender de todos estos factores que nombramos.

A continuación vamos a mostrar solo un ejemplo de cómo esto afecta a la navegación.

Factor Arquitectura: navegación web (1.0) vs escritorio

Sí bien en las siguientes unidades vamos a desarrollar el tema de la programación web, su comparación con las aplicaciones de escritorio es un buen ejemplo de dos tipos de navegación bien distintas.

Aplicaciones de Escritorio: son aquellas como las que venimos haciendo/mostrando en arena. Que corren en la máquina del usuario final, sobre un sistema operativo, como un programa propiamente dicho.

En una arquitectura web, no codificamos un programa que va a correr en la máquina del cliente, sino que utilizamos un programa ya existente, un navegador web. Como firefox, internet explorer, etc. Luego, este navegador, se conecta a diversos servidores que son los que le proveen contenido.

La arquitectura web (al menos la parte que vamos a ver en esta materia, es decir las páginas web o HTTP+HTML) nace con la idea de compartir documentos. Y no con la idea de construir aplicaciones. Esto es importante porque afecta a la navegación.
Estos documentos llamados páginas html pueden tener vínculos entre ellos, que le permite al usuario navegar entre ellos.

Entonces, decimos que la metáfora de las interfaces web es la página. Y lo que el usuario puede hacer es moverse entre estas páginas.
Puede además ingresar datos, en la forma de formulario. Y luego submitearlo (publicar/despachar?) al servidor. Lo cual nuevamente resultará en una página como respuesta.

Además la página nos da la idea de algo estático, cómo la página de un libro, fue impresa y no va a cambiar (salvo que tengan un Amazon Kindle, en fín...)

Por el otro lado, en aplicaciones de escritorio, la metáfora no es tán rígida, pero podríamos pensar en ventanas, paneles, controles, etc, que están vivos. El usuario está interactuando diréctamente con estos elementos, y ellos responden e interactúan de vuelta con él.

Entonces bajemos esto a un ejemplo concreto.

Videoclub: Buscar un socio

En una arquitectura web, como todo son páginas, y las interacciones del usuario con la aplicación son las de pedir nuevas páginas (enviando información de ser necesario). Deberíamos pensar en al menos dos pasos para esto:
  • Página de ingreso de datos para la búsqueda
  • Página de resultado de la búsqueda
Las interacciones serían:
  • El ususario pide la página de búsqueda. La aplicación le presenta la pantall con los posibles datos a buscar
  • El usuario ingresa un valor en "Nombre:" por ejemplo
  • Luego, debe clickear en un botón "Buscar" o "Enviar", para enviar la información a la aplicación (recuerden que en la programación web la aplicación y el usuario no estan conectados continuamente).
  • Luego se recibe la respuesta con los resultados de la búsqueda.
En una aplicación de escritorio, usuario y aplicacion estan conectados e interactúan directa y constantemente. Entonces podríamos pensar en una interacción que no requiera pasos discretos sino que sea más fluida. Solo por dar un ejemplo:
  • Controles para el ingreso de datos de la búsqueda y controles para mostrar los resultados podrían estar en una mísma ventana. Sin necesidad de transicionar de una a otra.
  • Podríamos pensar en evitar la interacción de apretar un botón para enviar los datos. No hay donde "enviar" los datos, porque ya se está interactuando con la aplicación diréctamente. Entonces eliminamos el botón, y a medida de que el usuario ingresa el nombre, la aplicación va buscando y mostrando los resultados.

Tipos de navegación

ABM (Alta, Baja y Modificación)

También conocida como CRUD de las siglas en inglés: Create, Retrieve, Update y Delete.
Es el tipo de navegación más básica y tradicional, donde existe una página o pantalla de nuestra aplicación para cada una de estas tareas básicas, y además esto por cada entidad del dominio.
Por ejemplo en nuestro videoclub tendríamos:
  • Socio:
    • Búsqueda de socio
    • Alta de socio
    • Modificación de socio
    • (el borrado se puede hacer desde la modificación, o la búsqueda)
  • Película:
    • idem a socio
  • Alquiler:
    • idem

Generalmente estas aplicaciones se estructuran con una página/pantalla de inicio (home) que dará acceso a los casos de uso de cada entidad. Por ejemplo esto podría hacerse con una menú.

Ventajas

  • Como las pantallas son similares entre las distintas entidades de nuestro dominio, facilita la reutilización de código de UI.
  • Podría tener generación automática (como hacen varios frameworks hoy en día).
  • En principio parece la interfaz de usuario más "intuitiva" y simple para el desarrollador (ojo acá, dejamos bien en claro que es para el programador, ver desventajas).

Desventajas

  • Lo que es más simple e intuitivo para el desarrollador, no necesariamente será para el usuario final.
  • Interfaz pensada desde el punto de vista del desarrollador y no del usuario.
  • Incómodo y poco ágil para el usuario:
    • Ej: para crear una nueva factura en mi dominio tal vez deba dar de alta primero al cliente, y al producto. Entonces el usuario debe tener en cuenta este orden.

Draft

  • Relación con user experience
    • Consistencia
    • Intuitividad
    • Ágilidad
    • Dependencia con el dominio / aplicación
      • más dificil que pensar
  • MVC
    • Lógica = dominio + navegación
  • Relación con la arquitectura
    • Transacciones
      • Simultáneas y aisladas
      • Anidadas
      • Wizards
    • Modelado de Application Models
    • Arquitecturas alternativas
      • ABMs
      • Single Page
      • Direct Manipulation (Naked objects / squeak)
  • Implementaciones:
    • Arena
      • Listeners de diálogos
Comments