En busca del “área de administración” perfecta

El entorno

En toda mi vida como programador, mi principal preocupación han sido las áreas de administración.
Programar entornos Web es relativamente simple. Un modulo de administración de usuarios por aquí, una de edición de noticias por allá. Incluso cuando los sitios dejan de ser principalmente “escaparates de información”, y se convierten en intranets más complejas, con estudio de las estadísticas de la página, gestión de proyectos, CRM, mensajería interna, calendarios de eventos compartidos, encuestas, etc. Incluso entonces la programación se reduce a introducir modelos de datos y procesarlos, y con los debidos conocimientos, estudios y experiencia siempre se llega a buen término.

El problema con las áreas de administración de intranets o sitios Web es más complejo.
Entran en juego requerimientos especiales que hacen útil la herramienta. Es fácil en un área pública, accesible a navegantes de Internet, no introducir programación cliente sin redundarla con programación servidor. Normalmente se reduce en todos los proyectos “estándar” a uno o dos formularios de registro y contacto. Siempre nos aseguramos de que exista una comprobación por parte del ordenador cliente, y en caso de que esta no exista, una comprobación servidor.
Obviamente no estamos en posición de olvidar las ‘buenas maneras’ del desarrollador Web una vez que están tan repetidas últimamente.

Proveer al visitante de un sitio Web de:

• Un entorno claro e intuitivo,
• Un sistema eficaz que muestre al usuario, de manera transparente, el resultado de sus acciones.
• Las mismas funcionalidades, independientemente de los requerimientos tecnológicos recomendados.
• Posibilidad de ser “participe” del contenido de la pagina Web.

Estas son algunas de las básicas a tener en cuenta por el programador. Herramientas para llevarlo a buen termino hay muchas: cualquier lenguaje de programación de servidor, ajax, librerias javascript de mejora de experiencia (prototype + scriptaculous, mootools, jqery…), y seguro que un largo etc en producción o no tan famosas.

Sin embargo todas estas prácticas se complican cuando se llevan a cabo en un área de administración.

El análisis

Un área de administración se distingue principalmente del área pública, de acceso a los visitantes de la web en que el usuario que la maneja requiere un mayor control. Incluso cuando se trata de una intranet, el administrador suele ser el más necesitado en lo que respecta a control de la herramienta.

Un pequeño análisis de las necesidades de un “administrador Web” sería:

• Gestión sobre los contenidos del sitio Web.
  • Los administradores han de poder por ejemplo crear noticias, publicarlas y editarlas. Gestionar las secciones de las que dispone su Web, añadir, editar y eliminar.
  • Crear productos para una zona de “tienda online”, publicarlos, definir ofertas…
• Control sobre las herramientas de que disponen los usuarios de su web.
  • Un ejemplo seria la creación de encuestas personalizadas para sus visitantes, conocer sus resultados… Por ejemplo también tener la posibilidad de cambiar su sección de contacto, de modo que las solicitudes recibidas vayan a tal o cual email, o se almacenen en una base de datos.
• Gestionar el tipo de usuarios que tienen acceso a su sitio Web.
  • Puede disponer de varios tipos de usuarios. Los visitantes de la web que deben o no estar registrados para realizar ciertas acciones, los administradores del contenido de su Web, los administradores de foros de discusión, etc.
• Control sobre el análisis de uso de su sitio Web.
  • No basta con poder ver el numero de visitas del usuario a las distintas secciones. Herramientas de servidor como Webstats realizan esta función magníficamente.
  • El administrador querrá ver si durante un mes en particular uno de sus productos se ha vendido más o si una oferta ha tenido especial repercusión.
  • Querrá conocer si una encuesta ha sido mas votada o que opinión tienen los usuarios de su sitio.

Posibilidades hay muchas, tantas como intereses distintos puedan tener los administradores de las webs. ¿Como dar tantas posibilidades de uso a un administrador web sin requerirle un mínimo de tecnologías, ya sea un navegador en particular, javascript integrado o una resolución mínima?

El resultado

Un área de administrador, de gestión de contenidos o de intranet puede realizarse de infinitas formas.
Yo plantearía los siguiente pasos en este orden, basandonos en un sistema del lado de servidor en 3 capas MVC.

1. El modelo de datos.

El diseño de la base de datos acorde con las necesidades del proyecto.

2. El controlador.

La programación de las acciones que realizará el sistema, tanto para alimentar los modelos de datos como para extraer información de ellos.
Idealmente este proceso no debería depender en exceso de la capa de presentación, pero no hay otro remedio.
Tenemos que tomar decisiones en lo que respecta al uso de javascript – AJAX, por ejemplo cuando tratamos de .net o jsp (a lo mejor no queremos que estos sistemas realicen acciones postback por cliente), a lo mejor queremos usar URIs para tratar las direcciones del área de administración y para ello nos vemos obligados a usar el método GET de envió de datos al servidor, o quizás queremos usar POST.
Para ello normalmente el controlador se pone al servicio del modelo de vista que es el que decidirá como se realizaran las acciones en su más alto nivel (de interacción con el usuario).

3. El layout.

Es conveniente realizar un pequeño diseño del área de administración antes de ponerse a la tarea con ella. Hay geniales artículos sobre desarrollo de interfaces en Internet.
Lo mas divertido es separarse por un momento del ordenador y tirar de lápiz y papel.

En aliamultimedia solemos usar un layout que nos da buen resultado, esquemáticamente es algo asi:

Cabecera
Buscador Formularios | Listado Formularios
Pie

El resultado varía en función de los sitios Web, pero tiene un aspecto final como en la figura (sin los difuminados queda mucho más mono):

La ventaja principal de este layout es que nos permite tener el listado de los datos y el formulario de edición, creación, borrado en una sola pagina.
También nos da la posibilidad de usar cualquier tipo de petición al servidor. Mas adelante hablaré de ello.

Aspectos a tomar en cuenta:

• - Como se realizarán las peticiones al servidor.
• - Existirán peticiones ajax o solo POST y GET
• - Habrá animaciones realizadas en cliente o será un área sobria en cuanto a efectos.

Mediante el layout anterior tenemos todas las posibilidades. Enumero a continuación las ventajas que yo le veo:

1. Los botones disponen de eventos onclick que disparan peticiones ajax y también peticiones estándar a servidor por el método GET. De este modo si el usuario no dispone de javascript o lo tiene desactivado podrá también realizar las gestiones necesarias. Mediante este layout disponemos de todo lo necesario para la gestión en una sola página, lo que nos permite hacer un uso más efectivo de ajax.

   Los listados, así como los formularios están siempre disponibles. Con el uso de ajax incluso no tiene que esperar a la recarga de la pagina. Al pulsar en editar el formulario de creación se convierte en el de edición con los datos en el.

2. Los mensajes de errores, guardado correcto, observaciones, etc pueden mostrarse en la propia pagina sin necesidad de enviar variables al servidor para el cambio de paginas. Para ello usamos javascript (y un método redundante por servidor), que nos permite mostrarle al usuario un “overlay” que puede cerrar en cualquier momento con un clic.
3. El usuario dispone de filtros de información, ventanas plegables y ayudas mediante tooltips en cualquier sección.
4. No existen secciones “ocultas” al usuario. Cada sección dispone de su botón y no hay enlaces dentro de los enlaces o paginas que lleven a otras no disponibles mediante el menú.
5. Los datos se subministran “en el aire” cuando el usuario los pide. La disposición de la página y los elementos en ella permiten la inclusión de todos los datos “disponibles” a petición del usuario. Al igual que con otras zonas existe disponibilidad por servidor, sin requerir por parte del ordenador cliente módulos, plugins o javascript integrado.
6. 6. – El layout actual nos permite también incluir efectos gráficos útiles:
   • Posibilidad de plegar y desplegar las secciones.
   • Ayudas emergentes con efectos de aparición y desaparición que llamen la atención sobre ellas.
   • Relojes de tiempo que indiquen que se está realizando alguna acción o que está en proceso.

Conclusión

En lo que respecta a áreas de administración, en Alia nos sentimos muy orgullosos de nuestro enfoque (prueba de ello es que he escrito este articulo para presumir :) ).
Aunque en cada desarrollo personalizado que hacemos buscamos nuevos métodos. A mi sin embargo este es el que mas me convence.

Existen otros muchos métodos, principalmente distinguidos por el layout que utilizan:

• Formularios de edición – creación arriba y listado abajo con su buscador.

• Secciones que son listados y formularios accesibles solo desde estos, sin enlaces directos y en otra pagina.

• Secciones con listados y formularios pero con demasiados efectos especiales innecesarios

• ….

Desde luego, aceptamos ideas para discutir las ventajas y desventajas.

Aunque extenso aquí no se han nombrado las peculiaridades de todos estos desarrollos. Tampoco he hablado de sistemas de administración populares como el wordpress, joomla, drupal, kentico, los predefinidos de typo3, etc..
Así que, con tantas cosas en el tintero no dudéis de que me veréis mas por estos lares.
Un saludo desde Alia multimedia