Existe en el cliente de Mail del Mac OS X (todas las versiones) lo que a mi entender es un pequeño pero grave error de diseño. Se trata de los dos iconos que representan las acciones de “Eliminar” y “Trasladar a Correo no deseado” el mensaje/mensajes que tengamos seleccionados. El problema es que los dos iconos parece que estén intercambiados, lo que genera en algunos usuarios confusión (cuanto menos a mí me pasa, pero también he visto a otros usuarios de Apple Mail claramente dubitativos frente a la duda de qué botón deben apretar). En el Apple Mail:

El botón de “Eliminar” es una señal de “Prohibido el Paso”, que obviamente nada tiene que ver con la acción de Eliminar y sí con el hecho de denegar el paso a mensajes de spam.

Por su parte, el botón de “No deseado” es una bolsa de basura convencional que, además, si nos fijamos bien veremos que es una bolsa de basura reciclable, dejando intuir que su contenido se puede reciclar (recuperar), utilizando la misma metáfora que utiliza Windos con su “Papelera de Reciclaje”.

Al ser dos iconos que parecen reflejar dos acciones que no son las que realmente realizan, esto se convierte en un fallo en la usabilidad de la aplicación, lo que en consecuencia crea a menudo errores: hay usuarios que creen prohibir el paso de e-mails de spam marcando el mensaje con la señal de Prohibido, pero en cambio lo que están haciendo es eliminarlo sin marcarlo como spam (y además legitimado el mensaje como un e-mail genuino).

Por su lado, hay usuarios que, una vez leído un e-mail legítimo de un contacto, lo quieren eliminar y por tanto trasladar a la papelera de reciclaje. Por tanto, se dejan guíar por la iconografía de la interfaz y aprietan el botón de la papelera amarilla, sin darse cuenta de que están marcando como spam ese mensaje y, por tanto, marcando también como spam los que puedan provenir en el futuro de ese remitente.

La lógica del usuario es evidente y no deja dudas: si quiero eliminar un mensaje, por qué debería apretar un botón que significa universalmente “Prohibir” y no dice nada de “Eliminar”? Con más motivo aún cuando justo al lado hay un botón con un cubo de basura, que es la metáfora más extendida en informática para la acción de “Eliminar”. El cubo de basura significa universalmente “Eliminar” y además viene reforzado por el símbolo de reciclaje, que me informa que no un eliminado definitivo, sinó que si luego quiero recuperarlo podré hacerlo (como en la Papelera de Reciclaje de Windows, o la Papelera de Mac OS X). Si por el contrario, quiero marcar como “correo no deseado” un mensaje y por tanto prohibir que no vuelva a entrar en el buzón de entrada ningún mail parecido, no debería apretar el botón de “Prohibir”???

Lógicamente, la solución radicaría en intercambiar los iconos de lugar, como se ilustra en la imagen de arriba. Pero claro, no puedes cambiar de orden dos iconos a los que la gente se ha habituado (aunque sea en una relación tormentosa con ellos) y que ahora signifiquen cosas distintas a las que han significado hasta ahora.

Por tanto, la única opción radica por realizar una alternativa completamente nueva, como por ejemplo esta propuesta que se ve en la imagen de abajo:

La ventaja de esta propuesta es que la acción de “Eliminar” queda ilustrada por un cubo de basura idéntico al que existe en el escritorio (Finder) de Mac OS X, con lo que la curva de aprendizaje, sencillamente, no existe. Los usuarios están plenamente habituados a esta metáfora. Por otro lado, el símbolo de radioactividad (aunque podría ser otro: una cucaracha, un demonio rojo, un virus, una araña…) es un símbolo universal de peligro e de infección, ideas correctamente asociadas a mensajes de spam o de virus.

Lo bueno de esto es que nadie ha hablado sobre esto antes y por tanto soy el primero que entre a explorar este territorio virgen. Con esta idea en mente y dado que tengo un esguince que me tiene impedido y no tengo nada más que hacer, voy a hacer una pequeña serie de artículos con propuestas sencillas y económicas de mejorar la usabilidad de los peajes.

En esta primera parte me centraré en exclusiva en el rotulado, que lógicamente incide en mucho en la usabilidad percibida de un sistema. En otro post intentaré escribir una pequeña crítica sobre la usabilidad de las máquinas de cobro de los peajes, que ese es un tema que merece también su propio post.

El primer problema de los peajes es la rotulación. Cuando nos aproximamos con el coche, nos encontramos con carteles de este tipo, al menos en Cataluña: MANUAL y AUTOMÁTICO.

Como todo buen profesional de la usabilidad sabe, el rotulado debe ser auto-explicativo por un lado y por el otro no llevar a confusión. Sin embargo, tanto las vías señalizadas como “MANUAL” como las de “AUTOMÁTICO” son todas manuales, no automáticas. Pagues con billetes y monedas o con tarjeta, ambos modos de pago son completamente manuales y no tienen nada de automático, en tanto en cuanto requieren que pares, que bajes la ventanilla, que pagues y que una vez se efectúe el pago se suba la barrera. No es pago automático porque no es que la máquina cobre por sí misma, quee s la definición de una máquina de pago automático. Esto viola uno de los principios más elementales de la usabilidad: la correcta rotulación a nivel semántico.

Adicionalmente, “AUTOMÁTICO” puede inducir a error a los usuarios del Teletac, que sí es un sistema de pago realmente automático en tanto en cuanto no requiere ninguna acción del conductor aparte de bajar un poco la velocidad. Un usuario del Teletac con toda la razón del mundo podría pensar que los carriles de “AUTOMÁTICO” son sus carriles, y que los de “MANUAL” son para los que no tienen de un sistema de pago automático porque manualmente, ya sea con billetes y monedas o con tarjeta.

En realidad, lo que distingue unos carriles de los otros no es otra cosa que el modo de pago. A diferencia de un supermercado en el que tanto los que pagan con billetes y monedas como los que pagan con tarjeta pasan por los mismos carriles o cajas, en los peajes se distingue a unos y otros, porque el dispositivo de cobro es diferente. Por tanto el rotulado debería expresar esto sin ambiguedades y los carteles sobre las vías deberían ser “AL CONTADO” y “TARJETA”. De este modo, se comunicaría fielmente e inequivocamente que se distingue a los conductores por cómo van a pagar.

En realidad, ésta tampoco sería buena opción, ya que en los carriles señalizados como “AL CONTADO” siempre hay un operario, y a éste se le puede pagar también con tarjeta. Por tanto, los rótulos deberían ser “AL CONTADO O TARJETA” y “TARJETA”. Lo mejor, por supuesto, es acompañar estos dos rótulos de iconos sencillos que apoyen y confirmen el mensaje para no dejar lugar a dudas. Con un sencillo icono de monedas y billetes, y otro sencillo icono de tarjeta es suficiente para acabar de comunicar que se distingue los carriles por cómo se puede pagar en ellos. Además, estos icono son necesarios para los extranjeros si el rótulo no está traducido, como es el caso aquí.

Por tanto, si antes tenían este aspecto:

Ahora tendremos éste otro:

Hemos eliminado los conceptos de “AUTOMÁTICO” y “MANUAL” porque, como hemos visto, son incorrectos y se prestan a confundir. Por otro lado, al integrar arriba los iconos de pago al contado y de pago con targeta, podemos eliminar los otros rótulos fluorescentes que están más abajo y que sólo añaden ruido visual. Las redundancias, en el caso de un sistema en el que hay pocos segundos para escoger, son negativas. También aprovechamos para quitar el rótulo verde con el icono de tarjetas que hay debajo del rótulo también verde para vehículos pesados, porque ahora es también redundante. Con lo cual la cosa nos queda así:

Pero aún hay muchas cosas que mejorar. Como bien sabe cualquier diseñador, los códigos cromáticos se suelen hacer servir para con diferentes intenciones. Pero lo que está claro es que los códigos cromáticos, si se utilizan, deben utilizarse siempre y bien. De otro modo, no sólo pierden su sentido, sino que confunden en vez de ayudar. En la imagen anterior a ésta última, hay un código cromático que identifica a los mensajes dirigidos a los vehículos pesados, el verde. El verde agrupa a 3 rótulos dirigidos a este tipo de vehículos.

Pero cualquier diseñador algo avezado en psicología humana sabrá que mucha gente, ante estos cuatro rótulos, deducirá con toda lógica que si el fondo verde se utiliza para significar “Vehículos pesados”, entonces por fuerza los fondos azul y blanco de los otros rótulos deben querer significar otros dos tipos de vehículos. Este tipo de razonamiento no es sólo completamente lógico, sino que además es también consecuencia del aprendizaje de las señales de tráfico, que son probablemente el mejor ejemplo de una señalética excelente que se basa, precisamente, en este tipo de códigos cromáticos. En el caso de las señales de tráfico, los fondos se combinan con la forma, con el borde y con iconos para expresar diferentes conceptos combinados. La gente ha aprendido a leer este tipo de códigos al estudiar para el carnet de conducir y los aplica también frente a la rotulación de los peajes.

En este peaje, parece que se ha utilizado el azul y el blanco con la intención de querer distinguir mejor un carril para pago con tarjeta y otro para pago al contado (y con tarjeta), pero es un error. En el código que estamos diseñando, los tipos de pago se comunican a través del icono y sólo a través del icono. Hacerlo de dos modos distintos, con color y con icono, como bien se sabe en usabilidad, es redundante y genera confusiones. “Dínoslo de una manera correcta, y de sólo una manera”, sería la frase.

En cambio, el color de fondo, lo estamos utilizando para identificar tipos de vehículos distintos. Verde para vehículos pesados, y por tanto el blanco o el azul, pero nunca ambos, para vehículos ligeros. En este caso prefiero utilizar el blanco, con lo cual la foto nos quedaría así:

Parece que queda más claro las dos famílias que hay, la blanca para vehículos ligeros y la verde para vehículos pesados. Pero aún queda un pequeño detalle. Dado que la redundancia es negativa como norma general en usabilidad y como norma particular cuando sólo se tienen unos cuantos segundos para tomar una decisión, como cuando uno se aproxima a un peaje, aún queda un pequeño detalle: eliminar el cartel verde con el dibujo del camión.

Finalmente, si lleváramos al extremo los principios del buen diseño y de la usabilidad, corregiríamos una asociación visual que es traicionera: el verde que identifica vehículos pesados es muy parecido al que hay en las balizas de los refugios entre carril y carril. Por supuesto, en este caso sería difícil que alguien entendiera que los vehículos pesados, identificados en verde, deben pasar por los carriles “señalizados” con balizas verdes, pero vamos a pasarnos de rosca e intentar resolver algo que no porque no nunca tendrá mayores consecuencias deja ser un error. Por tanto, cambiaremos el color verde de las balizas por uno que no se relacione en nada con los rótulos, ya que no tienen nada que ver. Hay que romper esta asociación cromática utilizando otro color.

Podríamos pintar las balizas de cualquier color excepto el blanco o el verde (ya que se asociarían con los rótulos), pero para ir a por nota, no escogeremos un color al azar, sinó que ayudaremos a distanciar más las balizas respecto de los rótulos asociando las balizas a las cabinas pintando las balizas de color azul. De este modo, ordenaremos el paisaje visual uniendo las balizas a las cabinas, comunicando por tanto que las balizas no tienen ningún significado, sino que forman parte de la estructura del peaje.

Operando estos dos cambios la cosa queda de la siguiente manera:

OK, ahora queda más claro. Lo que hemos hecho ha sido rediseñar la rotulación de este peaje, de modo que esté más ordenada, más clara, tenga menos ruido visual,  y exija menos esfuerzo para ser comprendida. Para poder comparar este resultado con lo que teníamos al principio del rediseño, recupero la imagen original:

En el caso de un peaje, una buena rotulación no es una cuestión baladí, y de hecho puede tener un impacto notable. Por un lado puede ahorrar un gran número de errores como los que todos hemos visto muchas veces de coches que tiran marcha atrás porque se han equivocado de carril, y por el otro lado puede reducir el número de maniobras de último momento que algunos conductores  hacen cuando por fin localizan el carril por el que tienen que ir. En algunos casos, este tipo de maniobras provocan accidentes.

Hasta aquí el rotulado. En el próximo capítulo, cuando pueda, me centraré en las máquinas de cobro con tarjeta de los peajes.

• Arquitectura de Información – Empieza decidiendo o planificando qué información está disponible, y dónde, cuando y bajo qué condiciones.
• Comportamientos de interfaz – A veces se requieren o son aconsejables comportamientos de interfaz específicos. Estos comportamientos suelen afectar el diseño tanto desde el punto de vista funcional como desde el visual.
• Jerarquía visual del contenido – Suele ser beneficioso para aportar pistas sobre lo que es más importante del sitio web, qué es lo siguiente en importancia, y así con el resto de elementos.
• Layout – La parrilla visual fundamental en la que se alojan los elementos mencionados anteriormente.
• Estilo – El look&feel del sitio web debe soportar y dar un aspecto a todo lo anterior y relacionar todos los elementos anteriores de una manera limpia y armónica

Cada capa es importante y, cuando se trabaja bien, contribuye a la totalidad del diseño. Olvida una de las capas y el diseño se resentirá y no alcanzará su potencial. En general, los diseños que ignoran alguna de estas capas son, simplemente, diseños pobres.

¿Por qué las aplicaciones open-source suelen tener tan mala usabilidad? He aquí algunas de mis razones:

- Hay pocos incentivos para que haya una buena usabilidad. Los fabricantes de productos comerciales tienen que ganar dinero para pagar los sueldos de los desarrolladores, y eso significa que se deben esforzar en que sus productos sean usables, para maximizar ventas. En el open-source no existe esta obligación.

- Muchas aplicaciones open-source se entregan “as it is”; no suele haber un sistema de soporte técnico que colapse ninguna centralita si el producto tiene una mala usabilidad. En cambio, en el software comercial se intenta evitar al máximo las llamadas al soporte técnico y ello significa que se cuida la facilidad de uso. En el open-source los problemas de usabilidad en una aplicación no suelen tener ningún impacto en sus desarrolladores.

- Por su propia naturaleza, las personas involucradas en el open-source suelen estar centradas en el código. Cualquier otro aspecto es secundario. Ello incluye el diseño o la usabilidad, que son aspectos que quedan relegados. El resultado son aplicaciones con interfaces bastante caóticas, sin orden, jerarquía o estructura visual.

- Cualquier producto open-source necesita diseño, pero en cambio suele haber pocos diseñadores en el software libre. Tal como está pensado el open-source, no es lugar para un diseñador. Por ejemplo, mientras que un desarrollador puede identificar un bug y contribuir un patch para solucionarlo, un diseñador que encuentre un fallo de diseño o de usabilidad no puede más que indicarlo, y esperar que alguien de mala gana lo intente arreglar.

- Al no haber muchos diseñadores, muchas decisiones de diseño y usabilidad se deciden sin el criterio necesario. Al igual que los mejores intérpretes de música suelen ser pésimos compositores, los mejores programadores suelen ser pésimos diseñadores. La ausencia de criterio propicia decisones erróneas y, en consecuencia, en el desarrollo de aplicaciones con las que trabajar no suele ser muy ergonómico. En segundo lugar, al no haber diseñadores las decisiones se toman a modo de compromiso entre las sensibilidades de todos los programadores, lo que resulta en una interfaz sin unidad, integridad y consistencia.

- Los bugs son objetivos, los fallos de diseño o usabilidad son en su mayoría subjetivos. Cuesta mucho más aceptar un error de diseño que un error de funcionamiento, porque aquél es mucho menos obvio. También cuesta mucho más que el grupo de desarrolladores se ponga de acuerdo sobre si algo es un fallo de diseño o esa una “feature” especial. Al ser los errores de diseño o usabilidad más subjetivos, es más dificil llegar a su identificación.

- Se programa antes de diseñar. El software suele ser mucho más usable si se diseña antes de programar, pero los entusiastas voluntarios de muchos proyectos open-source tienen tantas ganas de escribir código que prefieren saltarse los wireframes, los prototipos y los mockups. Sin embargo, estos elementos inciden directamente en el flujo de trabajo y uso de la aplicación, por lo que afecta al modelo de datos, a los algoritmos, al orden en que las acciones se realizan, etc. Programar antes de diseñar es cómo construir una casa sin planos.

- Al ser programadores, los desarrolladores suelen ser también power users. En consecuencia, las aplicaciones están pensadas para usuarios avanzados como ellos, para los que los problemas de usabilidad de una aplicación pueden ser superados sin mayores esfuerzos, pero eso no ocurre con los usuarios normales. Ejemplo de esta mentalidad de power-user es la ausencia casi total de asistentes o de prompts que guíen la navegación, elementos que en cambio suelen ser habituales en los programas comerciales.

- Los programadores open-source, al ser voluntarios, trabajan en aquellos proyectos que les interesan. Eso suele resultar en una falta de capacidad de abstracción. Al estar tan metidos en ese proyecto, a los desarrolladores les falta distancia y visión global, y la empatía necesaria para ponerse en el lugar de los usuarios. Los árboles no suelen dejarles ver el bosque.

- Por su propio carácter libre, el open-source facilita el intercambio de código y la reintegración de componentes, por lo que a menudo muchos módulos de diferentes orígenes se integran en una única aplicación. Ello suele resultar en inconsistencias en el diseño, en el manejo, o incluso en el léxico empleado de las aplicaciones de software libre, perjudicando por tanto la usabilidad.

- Todos los programadores voluntarios quieren que su pieza de software o la funcionalidad que han desarrollado aparezca en la aplicación, y cuánto más aparezca, mejor. Para aplacar ese deseo y asegurar la continuidad del voluntario, esa funcionalidad suele meterse donde quepa y de la mejor manera, pero a menudo sólo estorba y añade caos a la aplicación, tanto a nivel de diseño como de uso. Del mismo modo, quitar componentes de la aplicación para poder mejorar la ergonomía de la aplicación suele poner furioso al desarrollador que los hizo, con lo que a veces continúan aunque sean un estorbo o rompan completamente el uso lógico de la aplicación.

- Las aplicaciones open-source suelen competir unas con otras por el nivel de features que tienen, no por su diseño o por su facilidad de uso, mucho menos por obtener una cualificación mayor en la capacidad que tienen de ser usadas por los usuarios. Ello significa que la featuritis suele primar por encima de la experiencia de usuario. La simplicidad se ve como una carencia de features, no como una virtud.

- Los programadores no suelen distinguirse por su sensibilidad estética, por lo que muchas aplicaciones tienen un aspecto visual que ellos dan por bueno pero que a menudo horrorizan a cualquier usuario normal y corriente. Que las aplicaciones aparezcan bien es tan o más importante que el que funcionen bien. Un diseño pobre no sólo decepciona estéticamente al usuario, sino que perjudica sobremanera su usabilidad.

- Detalles como informar al usuario del progreso de una acción con una barra de progreso, explicar lo que  ocurrirá al presionar un botón determinado, rotular correctamente los botones y las secciones, redactar con propiedad la mensajería del sistema o la ayuda, ilustrar la interacción del usuario con el sistema con estados como hover o focus no suelen ser muy excitantes para los programadores, por lo que suelen faltar en las aplicaciones realizadas por voluntarios. Sin embargo, tienen un efecto crítico sobre la experiencia de uso de la aplicación.

Open source no es lo mismo que software gratis (freeware), ni que software libre. Estas razones no pueden aplicarse a todas las aplicaciones open-source (por ejemplo, hay aplicaciones open-source de pago con muy buena usabilidad), sino a muchas aplicaciones que aparte de ser open-source son también gratuitas.

Ser diseñador del iPhone: uno de los trabajos soñados para cualquier diseñador. Según se lee aquí, Apple busca un diseñador visual para el iPhone.

Según el anuncio, básicamente el candidato perfecto debe reunir estas cualidades:

- Grado en Diseño de Medios Interactivos, Diseño Gráfico, Animación o similar
- 2 años de experiencia en diseño visual de software
- Comprensión de los principios que rigen el diseño de interfaces de usuario
- Experiencia en el campo del diseño de interfaces dinámicas
- Pasión por el mejor diseño
- Capaz de comunicar sus ideas

Y se encargará de:

- Concebir, desarrollar y prototipar nuevas interacciones para varios componentes de Mac OS X
- Trabajar conjuntamente tanto con Ingeniería como con Marketing para finalizar diseños, documentar soluciones y monitorizar su implementación

Se puede enviar el CV + portfolio de diseñador a charlene@apple.com o a ljenckes@apple.com.

En los pasados años recientes, los desarrolladores debían elegir entre dos abordajes cuando construían una aplicación web.

El primer método era crear un sistema basado en pantallas con interacciones muy ricas utilizando una tecnología sofisticada y poderosa tipo Java o Flash
El método alternativo era crear un sistema basado en páginas utilizando estándares web más-fácil-de-aprender como XHTML y CSS cuyas capacidades más básicas fuerza a interacciones menos ricas.

Un nuevo abordaje tecnológico, apodado Ajax, podría ser la mezcla apropiada entre las dos.

Abordajes basados en pantallas: La opción sofisticada
Los Abordajes basados en pantallas ofrecen a los usuarios la capacidad de ingresar y manipular información en un número pequeño de pantallas que se actualizan instantáneamente con cualquier cambio enviado.
Los desarrolladores típicamente construyen esas aplicaciones, las cuales imitan la sofisticación de las aplicaciones de escritorio, con Java, Flash o una tecnología similar. La interfaz de reservas del Hotel Broadmoor, la característica Gameday de MLB.com, y la herramienta de configuración del calzado de Nike.com son algunos de buenos ejemplos del abordaje basado en pantallas.

Abordajes basados en páginas: La elección no-sofisticada
Los desarrolladores que construyen aplicaciones basadas en páginas utilizando tecnologías web estándar están forzados a lidiar con el efecto de cargar-recargar de páginas web normales. Como resultado, los usuarios que ingresan y manipular información en aplicaciones basadas en páginas deben sentarse durante el refresco de página para que esos cambios tengan lugar. La secuencia de verificación de Amazon.com, la búsqueda Google, y la secuencia de venta de eBay son ejemplos comunes del abordaje basado en página.

Si bien ambos métodos mostraron ser exitosos, cada uno tiene puntos en contra. El método basado en pantallas, por ejemplo, requiere un tiempo de desarrollo y esfuerzo significativo porque están construidos con herramientas de programación difíciles de aprender y a menudo de sistemas propietarios. Mientras que son más fáciles para construir que sus contrapartes basadas en pantallas, las metodologías basadas en página proveen una experiencia menos integrada.

Ajax: Un Abordaje A Mitad-De-Camino
Ajax esta basado es una nueva tecnología web que aúna los beneficios de los abordajes basados en pantallas y los abordajes basados en páginas. Permitiéndole más funcionalidad sofisticada utilizando estándares web fáciles-de-implementar, Ajax provee una alternativa real para crear aplicaciones web poderosas.

Jesse James Garrett de Adaptive Path acuñó el término “Ajax” en febrero de 2005, pero la tecnología que está detrás no es nueva.

Los desarrolladores que construyen interfaces Ajax aprovechan las mismas herramientas que los abordajes basados en páginas: XHTML, CSS, y JavaScript. ¿Entonces por qué Ajax repentinamente es un tópico popular?

Una razón es que varias compañías grandes incluyendo Google han creado asombrosas aplicaciones utilizando la tecnología: Google Maps, Google Gmail y Google Suggest están todos construidos utilizando Ajax.

Otra razón es la continua adopción de navegadores que cumplen con los estándares que soportan la tecnología Ajax, más notablemente Firefox, Safari, Opera e Internet Explorer 6.

Libertad de el Refresco de Página
Típicamente, cuando los usuarios ingresan información en un campo en una aplicación web basada en página, nada se hace con esa información hasta que se presiona “enviar”. Después que se presiona “enviar” la información se envía al servidor, una respuesta es devuelta, notificando al usuario el éxito o fracaso.

Durante este tiempo, el cual normalmente cambia basado en la velocidad de conexión y la cantidad de procesos que se están realizando, el usuario se sienta y espera hasta que la página se refresque.

Si bien hemos encontrado que el tiempo real de carga no conduce a la frustración del usuario por sí mismo, hemos visto que el usuario desea (y espera) una respuesta inmediata a sus consultas – recargar una página puede confundir al usuario. Por ejemplo, los usuarios a menudo encuentran difícil reconocer páginas que contienen mensajes de error, particularmente si no pueden ver dichos mensajes sin hacer avance de página.

Las aplicaciones Ajax, por otro lado, no necesitan refrescar la página completa para actualizar la información. En vez de eso, las aplicaciones Ajax pueden simplemente actualizar parte de la página en cualquier momento, dándole a los usuarios una respuesta instantánea a sus ingresos y consultas. Esto le permite a los usuarios ver continuamente con lo que están trabajando y reaccionar a cualquier cambio, error, o actualización que la interfaz les notifique.

Chequeo y guardado instantáneo del campo
Una de las características más beneficiosas que algunas veces damos por sentado en las aplicaciones de escritorio, es la capacidad para chequear instantáneamente los datos que tipeamos. En las aplicaciones de hoja de cálculo, por ejemplo, nuestro nombre ingresado en un campo numérico instantáneamente producirá un error el cual podemos solucionarlo inmediatamente.

En la web, es fácil chequear los campos en el lado del cliente utilizando Javascript. Esto produce un efecto inmediato, y replica el comportamiento de una aplicación de escritorio.
Sin embargo por razones de seguridad es necesario chequear todos los campos también del lado del servidor. Afortunadamente, Ajax permite también que esto suceda.

Interfaz De Pantalla Única
Una de las mayores razones para utilizar el abordaje basado en pantallas es la simplicidad de una interfaz de pantalla única. En el reporte del Diseño de Interfaz de Usuario de Flash, encontramos que una interfaz de pantalla única demostró ser muy útil para la gente, brindando varias ventajas sobre las aplicaciones basadas en página.

Una de las ventaja de pantallas única es que el usuario puede ver el cuadro general de la aplicación, viendo todos los pasos necesarios para completar la aplicación. Esto le da al usuario una clara idea de lo que se espera de ellos durante una transacción.

En una aplicación basada en página, ellos deberían cliquear a través de varias páginas sin saber que es lo que está más adelante

Las interfaz de pantalla única también le permite al usuario modificar y cambiar información en el orden que ellos elijan. Si quieren agregar su información de cuenta primero por ejemplo, deberían poder hacerlo. O, si quieren retroceder y cambiar algo que ya hicieron. En un interfaz de pantalla única esto es sencillo. Por otro lado, muchos abordajes basados en página fuerza a los usuarios a una secuencia específica.

Relativamente fácil de implementar
Muchos de los beneficios de Ajax refleja aquellos de las aplicaciones sofisticadas basadas en pantallas.
Sin embargo, hay un gran obstáculo para crear esas aplicaciones sofisticadas: son completos entornos de programación que requieren habilidades avanzadas de programación y un compromiso de largo plazo con tecnología propietaria. Esto hace que crear interfaces de esta forma sea caro y consuman tiempo.

Debido a que las aplicaciones Ajax están construidas utilizando nada más que estándares web actuales, ellas son relativamente sencillas de construir.

Muchos diseñadores web familiarizados con la construcción de aplicaciones basadas en página puede migrar a una interfaz a Ajax más bien rápidamente.

También, desarrolladores emprendedores de Ajax crearon bloques de construcción fáciles-de-usar que le permiten a aquello desarrolladores que no estén familiarizados con el abordaje migrar sus aplicaciones sin tener que escribir código desde cero.

Ajax: una sólida alternativa
Combinando la sofisticación de aplicaciones basadas en pantallas con la relativamente fácil-de-implementar de aplicaciones basadas en página, Ajax es un alternativa sólida para un nuevo desarrollo de interfaz.

A pesar de que nada construido con Ajax va hacer amigable para el usuario desde el comienzo, con cuidado las interfaces pueden sacar provecho de lo que nosotros sabemos y amamos de las aplicaciones de escritorio, y al mismo tiempo todavía sentír que estamos usando la maravillosa web.

Originalmente publicado: 14 de julio, 2005

por Joshua Porter
en User Interface 10 Conference como
“Using Ajax for Creating Web Applications”
UIE