[Serie] Enterprise 2.0: Parte 3- Que No se Retove el Usuario

 Ya  al hacer la crítica sobre el libro de Dave Platt "Por Qué el Software Apesta", comentaba que las aplicaciones que no ofrecen una buena interfaz de usuario, corren el riesgo de no ser ni siquiera olvidadas sino algo peor que eso: pueden ser ignoradas por los clientes. Al respecto hay una frase muy popular de Douglas Martin (la dijo en 1989 y mirá lo vigente que es!)

"Preguntas acerca de si diseñar es necesario o factible no están considerando bien el punto: diseñar es inevitable. La alternativa a un buen diseño es un mal diseño. No es un ‘no diseño’."
Douglas Martin, "Book Design: A Practical Introduction" (1989)

Claro: con la formación computina que todos tenemos, salida de la facu en edad adolescente (precisamente en la edad del pavo) y aterrizada en la edad adulta en los primeros años de experiencia laboral, cuando se nos empiezan a otorgar las primeras grandes responsabilidades, decime en qué momento aprendemos de cómo hacer buenos diseños de interacciones para usuarios!

Yo tengo una regla del pulgar para no hacer malos diseños de interfaz ni de experiencia de usuario: llamá a un diseñador en serio. No me estoy haciendo el chistoso, que quede claro. Hay veintiun mil aspectos (arquitectura de la información, usabilidad, familiaridad de las interfaces, navegación, …) para los cuales podremos tener cierta idoneidad pero no tenemos formación. En ese sentido, al menos yo, no quiero bastardear los pergaminos de alguien que sí de veras se formó para garantizarle al usuario una buena experiencia

En cambio sí puedo hacer mi aporte contando el estado del arte en tecnologías para la composición de buenas fachadas de aplicación que faciliten la puesta en práctica de diseños hechos por un profesional en el tema. Allá por Septiembre del 2005 había posteado sobre la dicotomía cliente delgado / cliente grueso y cómo en cada caso había algo que ganar y algo que perder. Y comentaba que con el tiempo, ambas partes de la discusión habían ido tomando del otro aquellas cosas que hacían a la diferencia, de modo tal que el usuario no acuse tanto recibo de la decisión tomada en lo que al tipo de lado cliente respecta

La cosa no se va a resolver a todo o nada, sino que cuando convenga se usará el navegador como cliente, cuando convenga se usará alguna aplicación de escritorio. La distancia entre ambos es cada vez menor en cuanto a capacidades, tecnologías usadas, etc. La diferencia fundamental cada vez más pasa por si se quiere distribuir fisicamente al cliente (de manera de aprovechar recursos locales) o si se usa como un servicio, vía la web, accediendo a datos igualmente distribuidos y por ende manteniendo una bajísima dependencia de la estación cliente

Las tecnologías que permiten hoy lograr Aplicaciones Internet Enriquecidas (Rich Internet Applications o RIA) son:

  • AJAX (Asynchronous JavaScript and XML). La historia creo que la conté varias veces: todo empezó con un agregado al Internet Explorer 5, que permitía invocar a un servidor web usando, claro, el protocolo HTTP pero para recibir a cambio una respuesta XML en lugar de HTML (en realidad, bueno, podía recibir cualquier cosa, pero lo esperable era XML). La clase capaz de hacer esa invocación se llama XMLHttpRequest y generalmente trabaja en forma asíncrona, con vos indicándole qué función JavaScript llamar cuando la respuesta HTTP esté disponible. Pero ojo, también podés indicarle a XMLHttpRequest que llame en forma sincrónica (aunque, esperablemente, el browser se va a bloquear hasta que le llegue la respuesta y en eso no va a variar de la forma tradicional, por así decir "Web 1.0", de usar la web que consistía en ir al servidor para buscar una nueva página)
     

     
    Parecen iguales pero no son!! Podemos decir que la versión de la izquierda del
    Windows Live Messenger se distribuye en la versión Software as a Service (SaaS),
    ya que no requiere instalación alguna en el equipo cliente, que accede al mismo
    a través del navegador. En cambio, la versión de la derecha está distribuida bajo
    el paradigma Software + Services, donde el puesto cliente sí aloja parte del
    software, que no obstante va a consumir servicios disponibles en la red (por
    ejemplo, recuperar la lista de usuarios conectados, enviar un mensaje a un usuario
    dado, etc). Esta segunda alternativa, claro, hace un mejor aprovechamiento de
    características locales como el envío y recepción de audio y video, entre otras
    facilidades no presentes en la versión SaaS
     

    Office Outlook Web Access (OWA). Una cuasi réplica del Outlook (incluso con la ventana
    emergente de los recordatorios) completamente lograda en el navegador
     

    Google Docs and Spreadsheets. Completamente dentro de un navegador y haciendo uso de AJAX
    puro, Google logró una aplicación SaaS que nos permite cargar formulas en celdas, aplicarles
    formato y otras propiedades mediante un click con el botón derecho del mouse; también crear
    gráficos de barras, tortas, etc. Simplemente probalo

    Lo cooooooooooool de AJAX es que, al recibir sólo un XML con datos puros (no todo el HTML que mezcla datos con la forma visual de mostrarlos), puede luego, vía DOM, alterar la página sin cargarla toda de nuevo (en la forma "Web 1.0" perdías la página actual y por ende había que hacer malabares -vía cookies, vía el manejo de tu sesión HTTP en el servidor web para no perder el contexto, el estado del caso de uso que estabas codificando -por ejemplo imaginate un wizard paso a paso de una agencia de viajes donde elegis el vuelo, el hotel en otro paso, el auto en otro paso, etc… tenés que ir arrastrando todo lo que ya venías eligiendo!-)
    En ese sentido, AJAX una masa. Ahora, tiene sus contras también. Veamos:
     
    -No está aún soportado en forma uniforme en Internet Explorer, Mozilla, Safari, Opera y otros. De hecho algunos browsers ni lo tienen soportado. Por ello, para evitar este escollo de que tu aplicación AJAX funque en algunos browsers y no en otros (lo que te diezmaría la chance de sacarle provecho a Enterprise 2.0) es que uses AJAX indirectamente a través de frameworks como la Yahoo! UI Library, el Google Web Toolkit o ASP.NET AJAX. Todos ellos le elevan el nivel de abstracción a la API básica, encapsulando así la lógica de detección de browser y posterior adaptación al mismo. El approach de Yahoo es JavaScript puro. El de Google es muy novedoso: vos programás en Java, por ejemplo con Eclipse, y el tipo te compila el Java y te deja cross-browser AJAX! En realidad, a mí personalmente no me gusta mucho el enfoque de Google (por primera vez en esta serie los voy a criticar) porque, si ya sabés Java, todo bien. Pero si tenés que aprenderlo para poder usar AJAX… estás jodido: Java es más difícil que JavaScript!! JavaScript es conocido por los que desarrollan con PHP, Ruby, .NET y la lista sigue. Cuántos de todos esos conoceran Java? No, Google, respetuosamente, ahí la chingaste. Ahora, el enfoque de Microsoft no es mucho mejor que el de Google: si programás en ASP.NET está todo bien, y si no, está todo mal. No obstante, es claro que Google y Microsoft, ponen el foco en un target de desarrollador (Java y .NET respectivamente) y le dan todo a ese público objetivo. Si lo miramos así, no se ve tan mal. Lo que sí, ASP.NET AJAX, no es homólogo al Google Web Toolkit sólo que en lugar de Eclipse es Visual Studio. ASP.NET AJAX implica ASP.NET en la lógica de lado servidor(o sea, no JavaScript) y JavaScript del lado cliente (o sea, no C# ni Visual Basic; un modelo más predecible: Google en el caso era Java a ambas márgenes -aunque se previó un mecanismo de introducción de JavaScript "as is" pero sólo para casos especiales-). Me parece que gana más el desarrollador .NET con ASP.NET AJAX que el desarrollador Java con Google Web Toolkit
    -Más contras de AJAX: JavaScript en general ejecuta lento. Si consumís demasiado XML, etc, usa mucha memoria también y lamentablemente las implementaciones actuales de los browsers más populares como Firefox o Internet Explorer a menudo pierden esta memoria (eso se llama memory leak: el sistema operativo no recibió la memoria de vuelta pero el browser tampoco la puede direccionar porque perdió los punteros a la misma). Esto se suele manifestar cambiando de una página a otra en el navegador, y cuando la memoria perdida es demasiada hay que matar el browser y reabrirlo (suena fácil decirlo, no? Te agarra en medio de la carga de datos de un caso de uso y me cache en Dié). Qué hacer ante esto? La lógica: usar AJAX razonablemente, combinando adecuadamente con lógica de ejecución de lado servidor (JSP, PHP, ASP.NET, etc)
    -La última contra de AJAX y seguimos: al hacer todo en una misma página, si en un dado momento el usuario está tan satisfecho con la info que tiene en la página que la quiere bookmarkear, la URL sigue siendo la misma del momento de cargar la página, antes de ejecutar todo el AJAX que se ejecutó. Con lo cual el bookmark no le va a permitir abrir la página en el estado que el desea. Aunque parezca un tema menor que no se va a dar… nosotros developers no conocemos bien a todos los usuarios no técnicos (que si les hacemos un mano a mano nos revientan a trompadas porque son muchos más). El usuario no sabe de AJAX ni de nada. No sabe si la URL era la del principio, la del medio, la del final, ni pretendamos que lo sepa (leé "Why Software Sucks" y lo vas a entender mejor)
     
    Un buen balanceo de lógica en el cliente y en el servidor, con AJAX, está hoy haciendo maravillas

  • Mashups. Otro mecanismo novedoso de lograr interfaces copadas es el conocido como mashup (algo así como purecito). Consiste en hacer interfaces de usuario re-usables, con su funcionalidad embebida incluído (por re-usables entendé robables en el buen sentido: lo que te contaba en Elogio del Choreo). La idea es que los que re-usen tu pedacito de página web puedan extenderla a los fines que ellos precisen (es decir, que ganen ellos porque se ahorraron de hacer todo lo que vos ya hiciste, y que ganes vos porque al usarla te terminen derivando clientes o alguna otra forma que te de la oportunidad de revenue)
    Quizás el ejemplo más exitoso de mashup lo aporta, nuevamente, Google con sus Google Maps. Google Maps es una aplicación de mapas en línea que permite obtener direcciones para ir de un sitio a otro, ver vistas satelitales, alejar, acercar, etc. Los consumidores de su mashup puede embeber la vista gráfica del mapa (mediante AJAX), añadiendole hitos, referencias señaladas en el mismo. Así, te vas a encontrar que cadenas de café, pizza, videoclubes, etc exponen en el mapa de tu localidad las ubicaciones de sus sucursales, y eventualmente te dicen (usando para eso el mashup) cómo llegar desde donde vos estás
    La versión "Web 1.0" de los mapas ciertamente es olvidable, por cuanto cada acción del usuario implicaba un requerimiento HTTP al servidor web que cargaba la página completa
     


    Antes de que surgieran los mashups, las aplicaciones que embebían mapas eran aburridas como
    chupar un clavo: cualquier desplazamiento que se quisiera aplicar al mapa implicaba cargar la
    página web completa (scrollear hasta el mapa, etc). Un embole

     

    Esta inmobiliaria española, le tirás un barrio y te muestra un mapa de la zona con las casas para
    comprar o alquilar, con sus metros cuadrados, su precio, etc. Además, cada vez que te parás
    en el mapa sobre una de las propiedades de interés, con DHTML te la destaca en un recuadro
    como el chalet de Fuentelarrena que se ve en la foto

    Los mashups vienen teniendo un éxito rotundo y es gracias a lo que se puede hacer con ellos que la Web 2.0 se ganó el mote de Web Programable, por cuanto los mashups ponen sobre la mesa todas estas tecnologías nuevas como AJAX, JSON, REST, servicios web, etc
    Existen catálogos de mashups para que revises si algo de todo eso te puede servir para chorear (y ayudar así a tu víctima del despojo)
    Un par de lugares para tener a mano
    WebMashup
    ProgramableWeb (no tan bien organizado como para encontrar rápido las cosas)
    Respecto de esta tecnología, valen los mismos comentarios que te hacía en Elogio del Choreo: al tomar algo provisto por otro corrés el riesgo de que momentaneamente no esté disponible, haciendote quedar para el traste a vos. Eventualmente, si estamos hablando de nivel "Enterprise 2.0" y no apenas "Web 2.0", te convenga tener algún acuerdo con el proveedor para salvaguardarte de eso

  • Gadgets/Widgets. Tienen cierto parentezco con los mashups pero no son exactamente eso, porque los mashups tienen la gracia de que pueden ser combinados y eventualmente mutados por el consumidor. En cambio los gadgets cuando están presentes, son más autónomos respecto de lo que los rodea
    Se trata de miniaplicacioncitas que cumplen un fin específico (decir el estado del tiempo, la cotización del dólar, quién de tus contactos del messenger está conectado, jugarte al backgammon, al space invaders… la lista es larga!)
    Los gadgets no son exclusivos de la web: los hay también para el escritorio. El precursor fue Mac OS X (el sistema operativo de las Apple) que los llamó Dashboard Widgets. Para programarlos no había que saber C, ni Java ni nada raro: con HTML, JavaScript, CSS (lo cubro en un rato), una imagen en formato PNG y alguna que otra cosita más, bastaba. Son para el escritorio pero se programan con tecnologías de la web, fabuloso!
     

     
    Gadgets de Windows Live: los elegís de una paleta disponible on line y cada vez que te logueás
    te arma la página con el collage que vos elegiste. En este ejemplo tengo un gadget que me
    presenta algunas news de MSNBC, otro que me tira el estado del tiempo en la ciudad que yo
    le configuro, otro que me pasa headlines del mundo del espectáculo y, a la derecha, un gadget
    que me trae mis correos de Hotmail!! Para tu tranquilidad: tenés que estar autentificado en
    Windows Live para que realmente entre a tu correo (ya te habías asustado eh?)

     

    Un gadget de Windows Vista (y por ende bajo el paradigma Software + Services)
    Permite elegir un idioma orígen, uno destino, cargar una frase y consume un servicio
    web que responde lo que la sentencia quiere decir en el idioma destino

     
     
    Un gadget de Spaces Live, capaz de suscribirse a un orígen de datos estilo RSS y mostrar su
    contenido. En el ejemplo, mi propio blog está haciendo eco de las 10 novedades más recientes
    de
    MSDN Architecture

    Windows Vista incorpora su versión de gadgets de escritorio (acá hay una intro interesante para desarrollarlos, que es muy similar al desarrollo de gadgets para Mac OS X)
    Así como hay catálogos de mashups, hay catálogos de gadgets pero en este caso, al revés que con los mashups, va a depender de dónde los quieras desplegar: en otras palabras, un widget de Apple Mac no te va a correr en Vista ni viceversa. Y respecto de la web, existen gadgets para Windows Live, que no se pueden usar en tu págine en Google, etc
    Echate un vistazo en
    Microsoft Gadgets (para Windows Vista y Windows Live)
    Apple Dashboard WIdgets (para Mac OS X)
    Google Desktop Gadgets (requiere un desktop que provée Google; hay una controversia que viene en aumento con ciertas facilidades que Google ofrece en este escritorio, ya que potencialmente -previa autorización del usuario que podría aprobar sin pensarlo bien- habilitaría a Google a indexar info del disco duro del usuario y subirla a sus servidores y que potencialmente quede al alcance de otros… smile_omg)

  • Cascading Style Sheets (CSS). Junto con HTML, JavaScript y DOM (Document Object Model), CSS constituye lo que se conoce como Dynamic HTML (DHTML). Puntualmente esta tecnología se creo con el propósito de ayudar a separar la estética de la semántica (o, en otras palabras, la forma del contenido). Ahora podíamos definir clases de estilo (especificando lo que queramos: color de frente, de fondo, tamaño, fuente de texto –font-, posición absoluta o relativa, características varias de los bordes de una tabla, etc). Estas clases después se asignan a los markups del <BODY> un documento HTML y voilá: el navegador aplica los estilos a estos markups y presenta el documento formateado
    El valor de hacerlo así, desacoplado, y no meter estilos directamente en los atributos de nodos interiores al <BODY> es que, mañana podríamos querer cambiar los estilos solamente, y deberíamos editarnos todos los HTML involucrados. En cambio así sólo se toca el archivo .css (vinculado adecuadamente a todos los HTML mediante un link en el <HEAD> del documento
     
    <link rel="stylesheet" type="text/css" href ="/estilos/pastel.css"/>
     
    y asunto cocinado
  • eXtensible StyLesheeT (XSLT). Originalmente se creó con la misma finalidad que CSS: para aplicar estilos a semántica pura, y de ahí el nombre. Pero en realidad esta tecnología es algo mucho más ambicioso: sirve para transformar un documento XML (de la gramática que sea), en otro (también de la gramática que sea, comunmente XHTML -un dialecto de HTML completamente compliant con XML, ya que el HTML original no era XML puro sino su antecesor: SGML-)
     

     
    Tomando como base el XML del ejemplo de REST presentado en Elogio del Choreo, en lugar de
    usar JavaScript para producir HTML podemos crear una transformación XSLT que produzca el
    mismo resultado

    El problema con XSLT es su complejidad, lo que atento en parte contra su adopción masiva: acordate lo que decía Cwalina sobre diseñar APIs fácil de entender y empezar a usar si querías adopción masiva; bueno, acá tenés un ejemplo de lo que pasa si no tenés en cuenta eso
    Ni siquiera en el uso básico, para el que había sido creado, de transformar documentos REST en XHTML con estilo, le pudo ganar a CSS

  • Otras tecnologías alternativas, que no voy a cubrir, son OpenLazlo (que habilita la creación de HTML a partir de XML y JavaScript procesado por un servlet Java); formatos de video como Flash Video (FLV) o el flamante Silverlight, eXtensible Application Markup Language (XAML, un dialecto XML que permite definir la interfaz de usuario y asignarle eventos a los controles)

 

No Pensé Que Se Trataba de Cieguitos
Para terminar el post, te quiero contar que en los tiempos que vendrán, será más y más obligatorio (quiero decir, incluso penado por la ley en caso de no cumplir) ofrecer experiencias de usuarios alternativas para personas con discapacidades (cortos de vista, ciegos del todo). Parece que exagero pero no: el Comité organizador de los Juegos Olímpicos de Sydney en 1999 desestimó un reclamo de habilitar el portal de los Juegos para lectores de pantalla (aplicaciones que interpretan lo que se está desplegando, sea para pasarselo a otro componente que lo recita verbalmente, lo presenta en paneles Braile, etc). El argumento era que proveer esta facilidad iba a costar más de dos millones de dólares (U$ 2.300.000)… Perdieron el juicio por discriminación que se comieron: tuvieron que pagar quince mil dólares de multa (U$ 15.000) más el costo de hacer todas las adaptaciones
No te esperes que haya sido un caso aislado, esto -duele decirlo pero es lo correcto- va a ser cada vez más mandatorio porque no podemos excluir a gente que tuvo menos suerte que el resto de nosotros con la Naturaleza
Afortunadamante existen un montón de técnicas y recomendaciones que ayudan a no tener que trabajar en paralelo (para videntes y no videntes): vos hacés la página para videntes en una forma tal que puede degradarse suavemente (graceful degradation, por ejemplo sustituyendo el CSS por uno más básico, sin tocar el contenido semántico) en dispositivos para gente con discapacidades y otros como el caso de los teléfonos celulares
Respecto de estos últimos: tené en cuenta que no todo el stack de tecnologías que te mencioné está masivamente disponible (AJAX, etc… fuiste)
Veamos todo esto con la lente Enterprise 2.0, no con la mera Web 2.0: la venta de teléfonos celulares y otros dispositivos móviles se dispara año sobre año. Un dato: a principios del 2006 el número de teléfonos móviles dando vueltas por el mundo era de dos mil millones (2.000.000.000), el doble de las PC conectadas a Internet. Eso sí: apenas un 28% de esos celulares se conectaba a Internet. Pero es cuestión de tiempo: vos no sabés cómo vienen los adolescentes -que mañana serán adultos- con el celular (si hasta en los colegios empezaron a prohibir el uso). Parece como una molestia, algo innecesario, desarrollar aplicaciones que degraden suavemente a teléfonos móviles, no? Pero esos celulares están prendidos todo el tiempo, seguramente más tiempo que la PC. Y andan todo el tiempo en la calle. No seas gil: no dejés plata tirada en la calle smile_wink

 

Esta serie se compone de

Esta entrada fue publicada en Software Management. Guarda el enlace permanente.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s