viernes, 25 de mayo de 2012

Mucho que aprender sobre navegación

La Internet está llena de aplicaciones con esquemas de navegación
diferentes. Muchos buenos, otros no tanto.
Al final no hay una única manera de hacerlo bien, pero si hay un conocimiento
sobre Navegación que manejan los Arquitectos de los sitios exitosos.
Siempre nos encontramos personas “tímidas” que nos detienen para comentarnos o preguntarnos en forma privada sobre los temas que abordamos en los post que escribimos para Hiperbibliotecas. Muchas veces nuestro siguiente post nace de una de estas conversaciones que se originan en un pasillo, un café o un correo electrónico, donde nos damos cuenta que hay algo que vale la pena explicar. Hemos aprendido que ni a todas las personas les gusta comentar en público, ni siempre se tiene ánimo para ello. El punto concreto esta vez es que recientemente comenzamos a hablar sobre Navegación y ha sido interesante lo que nos ha llegado en la realimentación de cafés. Una pregunta nos llamó la atención ¿Es posible sistematizar lecciones de Navegación universales que todo desarrollador de un sitio Web debe conocer? La respuesta es si. Hay mucho que aprender sobre Navegación y por eso ella ocupa un lugar privilegiado en nuestros talleres de Arquitectura de Información. Enumeramos a continuación algunos de los tópicos interesantes sobre el conocimiento de Navegación que tienen los buenos Arquitectos de los sitios exitosos de la Internet.

Las enunciamos en forma ilustrativa. Es claro que por razones de espacio no los podemos desarrollar en un único post, pero podemos hacerlo en los próximos:

1. Las áreas básicas de la salida
Hay patrones regulares y áreas típicas en las salidas de los sistemas disponibles en la Web. Hay estándares y hay variantes interesantes sobre ellos. Así como cuando abordamos la Funcionalidad vimos que hay tipos de salidas y cuando abordamos la Estructura vimos que hay tipos de objetos de información al hablar de Navegación es bueno saber que hay área básicas en la salida y que entender su uso es clave en el diseño de una buena experiencia de Navegación. Esto en Google y en muchos sitios exitosos se conoce bien.

2. Los cinco menús modernos
Vimos en días pasados que ya no se usan los menús tradicionales ni se desarrollan sistemas basados en una navegación a través de un simple menú de opciones. Pero esto no significa que los menús están muertos. Por el contrario, los buenos sitios usan muchas veces un esquema de navegación donde se usan hasta cinco tipos de menús: Menú institucional, Menú de Opciones principales del contexto, Menú de contexto de la región, Menú de opciones complementarias, Menú del pie.

3. Errores frecuentes en la navegación
Hay errores de principiantes en la navegación. Errores que ningún profesional de la Arquitectura de información cometería pero que cientos de nuevos profesionales inexpertos cometen a diario en todas partes del mundo. En parte porque los tópicos de Navegación o de Arquitectura de Información muchas veces no son atendidos por las actividades de formación tradicional en sus carreras de Ciencias o de Tecnologías de la Información. El tema es muy interesante y nos hemos dado cuenta que en nuestros talleres, el abordaje de los errores típicos de navegación siempre despierta interés.

4. El buen uso del cursor y del ratón
Mucha de la buena práctica de Navegación está en aprender a usar el cursor y el ratón. El consorcio de la WWW lo reconoció cuando agregó el parámetro de "title" entre las opciones del HTML y el "overmouse" para ejecutar código javascript. Sin embargo hay evoluciones en el camino y el "title" y cursor del ratón pierden importancia en los estilos de Navegación que se usan en los nuevos dispositivos móviles.

5. Dispositivos móviles y navegación
Un tema muy interesante y de mucha actualidad es el de cuáles son las características de la Navegación que es importante tomar en cuenta cuando se trabaja con dispositivos móviles. Esta navegación es diferente, por varias razones.

viernes, 18 de mayo de 2012

El mensaje de cero registros


Ejemplo de una respuesta inteligente a una consulta de cero registros en Amazon:
 "ventana xxx innovación"
La respuesta con Arquitectura de información elimina la palabra que produce la condición de
cero registros y obtiene "Una ventana a la innovación". Presenta adicionalmente otros libros
del mismo autor en los que el usuario que consulta podría estar interesado.
La semana pasada hablamos de la Navegación, la tercera de las dimensiones con las que trabaja regularmente el Arquitecto de Información. Esta semana queremos, manteniéndonos dentro de ese área de diseño, conversar acerca de algo puntual que puede ser, sin embargo, un ejemplo ilustrativo de lo que se toma en cuenta en el trabajo moderno de definir la navegación. Se trata de la situación frecuente en que hacemos una consulta y, al explorar la base de información que subyace debajo del sistema, éste encuentra que no hay registros que cumplan con la búsqueda planteada. ¿Cuál debe ser la respuesta? ¿Un mensaje de cero registros? ¿Algo más?

Si una pregunta de un usuario genera una respuesta con varios registros es fácil intuir que una navegación adecuada proporciona, de un modo natural, una pantalla de salida con enlaces que permiten solicitar el detalle de cualquiera de los registros que cumplieron la condición de búsqueda. Pero el caso de cero registros que trabajamos hoy es diferente y menos intuitivo, por lo que nos detendremos en el.

En efecto, este es un punto concreto donde la Arquitectura de Información (AI) ha evolucionado y plantea análisis y tareas diferentes a los que se hacían tradicionalmente. Anteriormente los ingenieros desarrollaban sistemas donde ante las situaciones en las que no se encontraban datos de respuesta a la pregunta realizada por los usuarios simplemente se respondía con una pantalla vacía o con un mensaje parco que indicaba que estábamos en una situación de cero registros en la base de datos.

¿Por qué aún siendo “correcto” un mensaje de que en efecto, no se obtuvo ningún dato como respuesta a la consulta, es una salida inadecuada para el Arquitecto de información? La respuesta radica en el hecho de que este profesional debe estar siempre pensando en el contexto en el que se produce cada consulta y cada salida y en cómo facilitar la navegación, es decir, los próximos pasos de los usuarios a partir de los mensajes de salida que les damos a través del sistema que se está implementando.

Hay dos preguntas que debemos hacernos los desarrolladores para el caso de uso de cero registros. La primera es la posibilidad de algún error simple, quizá de transcripción, en la escritura de la pregunta. En ese caso la mejor respuesta es una facilidad para ver el contenido de la pregunta que hicimos, corregir sobre ella y volver a preguntar. Como vemos, se trata de, incluso en este caso, dar una respuesta con navegación.

La segunda pregunta es qué debería hacer el usuario si efectivamente no hubo error en la transcripción y la pregunta fue escrita correctamente. ¿Qué alternativas deben proporcionarse? El punto de vista de un sistema desarrollado con criterios de AI es facilitar las siguientes acciones del usuario ante el contexto. Recordemos que en días pasados precisamente presentamos que la AI podía ser vista como usuarios+contenidos+contexto (ver). Así, por ejemplo, si se considera que el obtener cero registros es debido frecuentemente a que el usuario no conoce el vocabulario interno de los contenidos almacenados en el servicio de información, una respuesta adecuada, asertiva, es proporcionar un mensaje con facilidades de exploración para que la persona que consulta pueda conocer términos que si son válidos.

En los grandes sistemas comerciales, exitosos en la Internet, podemos apreciar variantes adecuadas de este tipo. Por ejemplo, Google, cuando la respuesta a una pregunta es de cero registros o incluso de relativamente pocos, responde señalando: “Quizá quiso decir...” y presenta una solución más alineada con los contenidos almacenados (lo que a su vez le da contexto al usuario). Puede notarse que muchas veces esta respuesta es un próximo paso acertado y cuando no lo es, estorba poco, por lo que se convierte en una respuesta arquitectónicamente correcta.

Si la probabilidad de que el usuario elija una alternativa diferente es alta, quizá conviene presentar directamente la respuesta a la pregunta no solicitada. Si no satisface al usuario pero éste puede continuar navegando, la salida presentada no le hace daño. Pero si le satisface, ganamos tiempo a su favor.

Una solución diferente a la de Google es la de Amazon cuando hacemos una búsqueda y el sistema se da cuenta que algunas de las palabras buscadas son la que causan el problema en la respuesta (Ver imagen arriba). El sistema decide suprimirlas explícitamente, pero continuar. ¿Por qué se hace esto? Porque en este caso la navegación es mejor y con mucha probabilidad se ahorra tiempo al usuario.

Como vemos lo acertado no es dar una respuesta matemáticamente correcta. Eso es lo que se hacía antes. Ahora lo que se busca es proporcionar un contenido con contexto que, en todo lo posible, le facilite al usuario el próximo paso, es decir, la navegación. ¡Incluso si no se obtuvieron registros!

viernes, 11 de mayo de 2012

La Navegación, la Tercera dimensión de la Arquitectura de Información


Una página de www.w3schools.com, un sitio de tutoriales sobre tecnologías
de Intenet que sin duda puede considerarse un buen ejemplo de
una Navegación bien lograda

El desarrollo de la Navegación es una de las actividades cruciales del trabajo de los Arquitectos de Información. Un sitio Web puede ser funcionalmente correcto y estéticamente hermoso, puede estar basado en una estructura de información correctamente diseñada y tener presente todo lo referente al acceso abierto o cerrado para cada audiencia que atiende y, sin embargo, ser prácticamente inusable por una Navegación mal diseñada. En efecto, la Navegación es la tercera de cinco dimensiones de la Arquitectura de información. Las otras cuatro son la Estructura, la Funcionalidad, la Seguridad y la Estética. Como hemos hablado de estas otras en anteriores oportunidades nos concentraremos hoy en la Navegación.

La Navegación es un tema que aunque parece fácil de enunciar, en la práctica resulta muy difícil de obtener una solución realmente satisfactoria. Anteriormente los desarrolladores de sistemas tenían una aproximación que, a los ojos que tenemos hoy, en su mejor expresión sólo llegaba a ser medianamente satisfactoria: colocaban un menú de opciones, los menús llevaban a otros submenús que abrían el abanico de opciones y así sucesivamente. Se esperaba que el usuario usara un manual donde se explicaban las distintos submenús y opciones y el énfasis del diseño se hacía en la completitud de las opciones y en la funcionalidad correcta de las mismas. La navegación en el modo en que hoy la conocemos era muy poco evolucionada.

¿Cuál es el problema con la navegación? El problema es que las facilidades y las posibilidades y la cultura de los usuarios son mayores.

En efecto, los tiempos cambiaron. Con la Web los contenidos se hicieron hipertextuales y por ello hay facilidades para colocar enlaces en cada sitio donde estos pudieran requerirse. Esto, de entrada, significa que existe una navegación posible sin necesidad de los menús tradicionales. Por otro lado, las font, los colores, las imágenes, las pestañas y la diagramación aportan nuevas alternativas para atraer la mirada, jerarquizar los contenidos, presentar alternativas y generar así múltiples posibilidades hipertextuales. Ya no tiene sentido pensar en una interacción basada en listas de opciones como las que usaban los menús de los antiguos sistemas y hoy día sería un error diseñar soluciones de procesamiento de esta manera.

Las posibilidades computacionales modernas también son mayores y esto ha traído consigo un aumento de la complejidad en los sistemas. Hay un incremento de la cantidad de alternativas consideradas en cada solución por lo que el número de opciones de un sistema moderno suele ser muy grande y las soluciones son, por lo tanto, prácticamente inmanejables con los menús tradicionales.

Por otro lado, como ha sido señalado, las audiencias son mucho mas variadas que las antiguas audiencias corporativas o institucionales (ver) y, por si fuera poco, con la popularización de la Internet la cultura de los usuarios es otra: Muchos de ellos han navegado y han probado en algún momento sistemas con una buena usabilidad y una buena encontrabilidad (ver) por lo que tienden a ser más exigentes en sus expectativas y más duros en juicios sobre la navegación inadecuada.

Finalmente, hay una dimensión subjetiva extra. Con la navegación ocurre como con la comida y el arte. Es difícil complacer todos los gustos. Siempre habrán personas a las que le parece difícil, incómodo o inapropiado lo que para otros está muy bien, resulta práctico y es agradable.

Sin embargo, es interesante presentar un ejemplo ilustrativo de una navegación excelente, sencilla, práctica, donde cada nuevo paso está al alcance de la mano, bien ubicado, próximo adonde se le necesita, al alcance de la vista en una diagramación que aprovecha y se equilibra en toda la pantalla. Nos referimos a w3schools.com, un sitio web de tutoriales en línea que proporciona a sus usuarios una manera fácil de aprender HTML, CSS, XML, JavaScript, SQL y muchas cosas más.

viernes, 4 de mayo de 2012

A veces menos es más



Un caso de menos puede ser más:
¿Por qué los blogs pudieron resolver
el problema de la publicación masiva
y las soluciones anteriores no?
No son pocos los casos en que menos es más. Claro, en todos ellos siempre que se dice “menos” se hace referido a una percepción de que disminuyendo la cantidad y concentrándose en otros aspectos, se puede obtener foco en parámetros de calidad, con un consecuente resultado más confortable, apropiado y práctico. Ocurre en muchas áreas de la creación humana. Por ejemplo, una diagramación atiborrada de elementos distrae, pierde sentido y deja de verse bien. Pasa en la estética y de allí el gusto que muchas veces nos da la expresión minimalista en el arte. Ocurre también así en Arquitectura de Información y en los sistemas informáticos. A veces se realizan diseños que nos agobian por la cantidad de alternativas y preferimos algo con menos funcionalidad pero más simple, comprensible y directo. En este post queremos dar un ejemplo de una de estas situaciones, usando algunos de los conceptos con los que hemos venido trabajando recientemente: tipos de salida, y tipos de objetos.

Hemos visto algunas semanas atrás como en los tipos de salida todos los sistemas se parecen (Ver). Esto significa que a pesar de la idea de heterogeneidad que tenemos, hay un nivel de abstracción donde podemos apreciar la homogeneidad, las características comunes que tienen muchos sistemas.

Hemos visto también la noción de objetos de información (Ver 1, 2, 3), entidades que tienen connotaciones naturales en el dominio de la información, una de las ideas claves para que los arquitectos de información puedan simplificar el diseño de la gestión de información y manejar un lenguaje común entre los usuarios, los desarrolladores de soluciones y los gerentes. En efecto, un objeto de información es algo natural, cercano a la aplicación y por tanto al mundo real. Algo muy diferente a la data, contenidos atomizados que son articulados en tablas y relaciones de bases de datos, como la trabajan usualmente los informáticos.

Hemos visto que al comenzar a analizar un problema de gestión de información lo primero que hacemos es obtener el mapa de objetos de información, para a partir de allí, comenzar a entender la funcionalidad asociada. Todo objeto de información tiene una salida de múltiples registros  típica (Ver) que se presenta en un orden típico. Eso no quiere decir que en un sistema no se requieran otros tipos de salidas, sino que en la mayoría de los casos la salida típica en el orden típico es suficiente.

Veamos ahora un ejemplo sencillo e ilustrativo de los conceptos de Arquitectura de información simplificando y ayudando a elaborar diseños del tipo “menos es más”. Hace unos años la aproximación para la colocación de contenidos en la Web por el amplio público venía experimentando con distintas aproximaciones. El problema es que las soluciones llegaban desde la complejidad. La simplificación se intentaba en el uso de herramientas que daban un feedback inmediato en el sentido de que “lo que ves es lo que obtienes”. Con ellas era, sin duda, más fácil hacer páginas Web que colocando en un editor de texto etiquetas de HTML. Sin embargo, nunca se resolvió el problema de la publicación Web por el amplio público hasta que llegaron los blogs. La pregunta pertinente es: ¿Por qué?

Los blogs cambiaron la historia. Facilitaron claramente la publicación de contenidos al punto que en muy poco tiempo empezamos a tener millones de ellos con millones de usuarios leyéndolos. ¿Qué pasó allí? Pues, un ejemplo de la lógica “menos es más” que señalábamos al comienzo, en el primer párrafo de este post.

¿Qué era un blog? Una creación magistral de Arquitectura de Información. Veamos: Un problema que se resuelve con un mapa hiper sencillo un único tipo de objeto de información: el post. El post a su vez es un tipo de objeto muy sencillo en su estructura. Sólo unos poquísimos campos. Un título, un contenido, un campo de clasificación temática y una fecha implícita: la de subida a la Web. La salida típica era también simple: una lista de salidas de contenido con metadatos implícitos. En ella se entiende qué es título, qué es contenido y cuáles son las palabras de clasificación por el contexto diagramado. Es decir, la dimensión estética es transversal e independiente, no está metida en la estructura como lo hacían las herramientas anteriores a los blogs. ¿Qué más? Un orden típico, desde lo más reciente a lo más viejo. Esto era suficiente para obtener una solución de publicación para el amplio público…

Cómo vemos, el problema de una solución de publicación masiva no era informático. Era de Arquitectura de Información…