Archivo
Piensa en Web, pantallas ligeras y rápidas
Para aquellos equipos acostumbrados al desarrollo en entornos cliente-servidor, el paso al desarrollo de aplicaciones web no debería únicamente implicar el cambio de herramientas y tecnología a usar por parte del equipo de programación. Es tarea del equipo de analistas funcionales entender los cambios en la interficie de usuario, o a nivel transaccional que el paradigma web conlleva. Debemos tener en cuenta que un diseño funcional donde en una pantalla ponemos dos o tres relaciones maestro-detalle con multitud de ítems, si bien será implementable en web, su rendimiento será muy pobre, y además estaremos mareando al usuario llenando su navegador con una cantidad excesiva de información.
En un caso como el planteado, si realmente el usuario va a tener que rellenar toda esa información, lo más indicado sería presentarle la información en bloques (como en un wizard, con botones de “anterior” y “siguiente”; en cambio, si los datos a introducir or modificar es una parte del total, lo mejor sería que el usuario pudiera navegar a los diferentes bloques que él seleccione.
Cito un par de factores importantes que deberían ser tenidos en cuenta:
- Layout: En un entorno tipo Cliente-Servidor (como Oracle Forms) disponemos de un runtime propietario y controlado que nos permite entre otras cosas el posicionamiento absoluto de items. En cambio en el entorno web no sabemos a priori sobre qué navegador va a correr nuestra aplicación. Incluso diferentes versiones del mismo navegador (léase MS Explorer) tienen comportamientos diferentes. Debemos asegurarnos que nuestra aplicación sea capaz de mostrarse correctamente en cualquier navegador. El uso de componentes estándar de ADF 11g simplifica en gran medida este punto.
- Simplicidad: El tráfico que genera una aplicación web es significativamente mayor que el generado por una aplicación Cliente-Servidor ejecutada en un entorno de tres capas (con servidor de aplicaciones), y además la representación es más lenta (el navegador debe interpretar el código html, javascript, css, etc que le llega). Para no penalizar el rendimiento de la aplicación, es aconsejable “aligerar” al máximo las pantallas. Al mismo tiempo estaremos generando pantallas más “atómicas”, y por tanto, más fáciles de reutilizar desde diferentes puntos de la aplicación. Frameworks como ADF 11g facilitan este tipo de diseños, mediante el uso de task flows.
Prototipado con Justinmind Prototyper
Recientemente he empezado a trabajar con Justinmind Prototyper, una herramienta de prototipaje de aplicaciones, y debo decir que me parece una buena manera de reducir el coste de desarrollo, ya que permite identificar problemas de usabilidad o concepto con los usuarios antes de empezar la fase de construcción.
Se trata de una herramienta que permite adaptar los prototipos que creemos al look & feel de nuestra plataforma mediante plantillas y componentes propios. Pero más importante que eso es la facilidad con la que podemos añadir lógica de negocio, así como crear prototipos dinámicos gracias a los “data masters”, una especie de tablas de datos sobre los que podemos hacer las operaciones habituales que haríamos sobre una tabla de BD: añadir registros, borrar, modificar, filtrar, …
La posibilidad de crear pantallas a partir de “pantallazos” de una aplicación ya existente permite hacer propuestas a un Request For Change en muy poco tiempo: simplemente capturamos el formulario o página que deba ser modificada, pegamos la imagen en Prototyper, y sobre la imagen podemos añadir input texts, áreas sensibles al ratón que simulen algún comportamiento al ser clicadas, botones o enlaces que naveguen a otro módulo de la aplicación, etc.
Leer más…
ADF 11g: Simplificar invocación métodos del Application Module desde ViewController
Invocar métodos de un Application Module desde las pantallas de nuestra aplicación (por ejemplo, como respuesta a que el usuario haya pulsado un botón) es una tarea habitual en nuestras aplicaciones desarrolladas con ADF 11g.
La forma más adecuada de hacer estas llamadas es utilizando los bindings. Si esta es nuestra manera de trabajar, es posible desarrollar un par de clases auxiliares en la capa de vista para que nos faciliten las cosas.
La primera clase nos encapsula la respuesta del método, dándonos acceso a la lista de errores que se hayan producido en el método invocado, y al retorno del método (si lo hay):
Una vez tenemos esta clase, la usaremos en la llamada al Application Module para almacenar la respuesta
Leer más…
“Responder a todos” en GMail
Hace tiempo que tengo configurado GMail para que por defecto el botón de “Responder” sea realmente un botón de “Responder a todos”. Aquí os explico cómo configurarlo.
Por defecto GMail nos da la opción “Responder”, y hay que darle al desplegable para hacer un “Responder a todos”:
Vamos a Configuración y elegimos la pestaña Labs:
Buscamos la siguiente opción y la habilitamos:
A partir de este momento, ya nos aparecerá por defecto la opción que nos interesa:
Nuestra red social |
|
|
