El Tamaño es Relativo: Ems

General

En una nota anterior comenté sobre las unidades de medida para fuentes en CSS. En esta oportunidad profundizaremos el tema refiriéndonos particularmente a una unidad, tal vez la menos conocida del grupo: ems.

Cuando se plantea el tema de cómo definir los tamaños del texto usando CSS varias cosas entran en juego. En primer lugar las consideraciones de usabilidad, en relación a la legibilidad del texto y la posibilidad de los usuarios de controlar el tamaño de despliegue para ajustarlo a sus necesidades. Por otro lado, el control sobre el diseño y presentación del sitio, normalmente defendido a dentelladas por los diseñadores.

Poniendo las cosas en perspectiva, lo primero que debemos entender, es que las necesidades del usuario son un requerimiento y no un elemento optativo en el desarrollo de un sitio. La usabilidad y accesibilidad son demandas del usuario y nosotros debemos oirlas.

El diseño debe estar al servicio de estos requerimientos. Punto.

Estas dos perspectivas no son necesariamente contradictorias, y es posible crear sitios accesibles, usables y estéticamente agradables. En esto el control y conocimiento de las herramientas disponibles ayuda mucho, y CSS juega una parte importante.

Con CSS podemos lograr textos con tamaños relativos, es decir, no fijos, modificables por los usuarios utilizando los controles normales del browser (las opciones Text Zoom o Text Size dependiendo del browser). Para ello contamos con tres unidades de medida definidas como relativas:

em
En la práctica, el tamaño por omisión definido en las preferencias del browser. La definición real de un em es el ancho del caracter m según el tamaño de texto actualmente en uso (activo). Esto normalmente se refiere al tamaño del elemento padre, el que contiene a aquél al que nos estamos refiriendo.
ex
ex se refiere a la altura del caracter x respecto al tamaño de texto activo.
px
Para sorpresa de muchos, se considera al píxel como una unidad de medida relativa, esto respecto a diversos dispositivos de visualización. Por ejemplo, un píxel en un PC de escritorio no será del mismo tamaño que en una Palm. Incluso será de tamaño diverso en distintos tipos de monitores.
%
Pese a no estar directamente asociado a los elementos anteriores como unidad de medida, el porcentaje se relaciona siempre con otros valores, como por ejemplo, píxeles. Al definir un porcentaje, se necesita conocer un valor de referencia, por ejemplo, el 10% de 125 píxeles.

Lo que hace especial a em lo podemos resumir en la siguiente lista:

  • se trata de una unidad relativa, que se escala proporcionalmente
  • que no depende directamente de otros elementos, como los porcentajes
  • que no es exclusivo para uso en un medio particular, como pt o px
  • que permite un total control al usuario

El problema sobre el control del diseño persistirá si insistimos en desarrollar diseños que requieran de precisión absoluta. La solución es diseñar tomando en cuenta estos factores, y teniendo consciencia de que finalmente y en condiciones más o menos extremas, para un usuario (y para nosotros como responsables de un sitio) es preferible ser capaces de acceder a un contenido, que de ver un diseño agradable, pero quedar impedido de leer la información a la que supuestamente sirve.

Texto y Unidades de Medida en CSS

General

Juan Carlos escribe una nota bien documentada, como es usual, sobre tipografía en el web. Su objetivo es tratar de entender las razones detrás del uso de fuentes con o sin serif, pero un comentario secundario capturó mi atención y no puedo evitar el entrar en detalles sobre esto.

De momento, aunque con poca base científica detrás, yo sigo recomendando escribir el cuerpo de los textos más o menos largos en letra sans serif, preferiblemente Verdana o Arial, y en un tamaño de 12 puntos (mejor puntos que pixels, pues los puntos permiten al usuario modificar fácilmente el tamaño del texto).

Evidentemente lo que ha hecho que mis alarmas suenen es la recomendación de usar puntos por sobre otras unidades de medida. Desde hace bastante tiempo que el tema de las unidades de medida para textos se viene discutiendo con bastante pasión en los círculos de die-hards de CSS. En resumen este asunto se puede resumir en lo siguiente, al menos desde mi perspectiva:

  • pt (puntos) es una unidad de medida eminentemente (tipo)gráfica, sin embargo no es apropiada para la pantalla, por varias razones, entre ellas el hecho de que no es proporcional, pese a que browsers modernos realicen un escalamiento proporcional (Mozilla, Opera). Adicionalmente, un punto no siempre es exactamente equivalente a un píxel: en Windows un punto se traduce a 1.3 píxeles y en Mac el equivalente es uno a uno, por lo que los resultados en diversas plataformas son imprecisos. En conclusión, es mejor utilizar esta unidad de medida para especificar hojas de estilo especiales para impresión.
  • px (píxeles) es una unidad de medida absoluta y mapeada directamente a la resolución del monitor. Si bien es posible (y aconsejable) escalarla, IE no es capaz de hacerlo, al menos hasta la versión 6.
  • em es una medida inherentemente tipográfica y proporcional, y es la más apropiada para la pantalla.
  • % (porcentaje) es una unidad de medida relativa que se ajusta perfectamente al uso en monitor, pero que puede llevar a ciertas impresiciones conceptuales. Prefiero utilizar porcentajes para especificar bloques en lugar de textos.

Para sostener estos argumentos y comprobar cómo se tratan las distintas unidades de medida de texto he publicado una página de prueba con texto en puntos, píxeles, ems y porcentajes. Para nadie será sorpresa que Mozilla maneja las unidades de medida de manera formidable, escalando cada una de ellas de modo apropiado. En IE, en cambio, puntos y pixeles no son escalables.

Modelos Mentales y Aplicaciones Web

General

modelomentalweb

Ventana de diálogo para guardar archivos en Mozilla luego de presionar Control+S. Atrás, formulario de edición de contenidos de WordPress.

Indefectiblemente cada vez que estoy concentrado editando o generando contenido en alguna aplicación web como el CMS que soporta este sitio, WordPress,o cualquier otro, tengo el reflejo natural de presionarControl+S para guardar los contenidos. Naturalmente esto activa la función Guardar Página del navegador (Mozilla en mi caso) en lugar de guardar aquéllo que estoy elaborando. Este es un condicionamiento producto de años de trabajo digital, en que he aprendido por la fuerza a proteger mi trabajo de potenciales problemas que terminen en la pérdida de horas de dedicación. Creo que a todos nos ha pasado.

El problema es que el modelo mental que formamos para trabajar en las aplicaciones tradicionales de escritorio, con interfaces bastante estandarizadas, no se aplican al entorno web. Sin embargo, necesitamos guardar o registrar nuestro trabajo o las selecciones que hayamos realizado, la configuración que hemos modificado, etc. Aquí, no obstante, el modelo es otro: debo recordar que estoy trabajando en un formulario web y que cualquier acción debe ser procesada por un script en el servidor, llamado mediante botones más o menos reconocibles, dependiendo del diseño único de cada aplicación web.

Aquí quedan expuestos claramente dos problemas que debemos tener muy claros al desarrollar interacciones en la plataforma que nos ofrece el web:

  1. Necesitamos dejar muy en claro, de modo explícito, que este es un medio diferente, con reglas propias.
  2. Debemos ser claros, consistentes y establecer un modelo que resulte en un aprendizaje rápido y fácil para el usuario: no debemos inducir a errores al usuario.

Esto que acabo de plantear no es algo nuevo, pero me comenzó a dar vueltas en la cabeza desde que comencé a publicar este weblog y me ha hecho replantear o repensar algunas cosas que daba por sentado. Y si me sucede a mí, de seguro que no soy el único. El asunto de fondo es, en consecuencia, cómo resolver la ambigüedad y partucularidad del formato que nos ofrece el web para realizar tareas que en el contexto familiar de las aplicaciones de escritorio nos resulta a esta altura natural.

No pretendo tener una respuesta, pero tengo la pregunta. Volveré al tema en la medida que lo elabore un poco más.

Diseño de las Cosas Cotidianas

General

Desde hace un par de meses que estaba en la lista de espera de mis lecturas el libro de Donald Norman The Design of Everyday Things. Finalmente comencé a leerlo y la espera no ha sido en vano. Ya desde el principio me encontré con una anécdota que vale mencionar.

design-of-everyday-things-book-cover

Portada de El Diseño de las Cosas Cotidianas con su título actual.

Cuenta Norman que originalmente el libro se llamó La Psicología de las Cosas Cotidianas, pero su editor le hizo notar que la palabra psicología hacía que en las librerías y bibliotecas éste se catalogara junto a los libros de psicología en lugar de aquéllos relacionados con interacción humano/máquina. Norman se dedicó a conversar con bibliotecarios y personal de librerías y comprobó la situación.

La anécdota de esto es que incluso él, que había escrito un libro sobre el diseño centrado en el usuario, había cometido un error considerable: no pensar en sus lectores, sino en sus colegas académicos, a quienes el título evidentemente complacía. Fue entonces que decidió cambiar el nombre en futuras ediciones a El Diseño de las Cosas Cotidianas.

Para sumar a la anécdota, es posible encontrar copias de ambas ediciones en Amazon: la primera versión, La Psicología de las Cosas Cotidianas y la segunda, El Diseño de las Cosas Cotidianas.

Cito la anécdota de Norman no como un acto de autoindulgencia sino, por el contrario, como algo a tener en cuenta, un recordatorio de que hasta en las cosas más simples, no debemos olvidar al usuario o destinatario final.

Más comentarios sobre el libro en cuanto avance la lectura.

Diseño Centrado en el Usuario

Diseño Centrado en el Usuario

Considerando que el propio nombre de este weblog, El Factor Humano, está inspirado en el Diseño Centrado en el Usuario, es curioso que ésta sea la primera vez que escribo directamente sobre el tema.

ucd.foto

Las técnicas de Diseño Centrado en el Usuario involucran al usuario desde las primeras etapas del proyecto.

¿De qué trata el Diseño Centrado en el Usuario? Simplemente de diseñar, en término amplio, con el usuario final permanentemente en el centro de la atención. Cada etapa del proceso de diseño y desarrollo de un proyecto Web debería considerar al usuario final ya sea mediante actividades que lo involucren directamente o utilizando técnicas que nos permitan tener una clara percepción de sus necesidades y preferencias.

Hay muchas metodologías que utilizan un enfoque de UCD (o DCU), normalmente vinculadas al procesos de desarrollo de software pero por sobre todas ellas existe una serie de técnicas que podemos utilizar en un rango amplio de proyectos. Del mismo modo son varias las disciplinas que pueden sacar provecho de ellas: Arquitectura de Información, Diseño de Interacción, Usabilidad, Diseño Gráfico.

Los beneficios de utilizar el enfoque de UCD son evidentes: optimización de la experiencia de usuario, mejoras de usabilidad, incremento de la accesibilidad, etc. En la práctica, sitios y aplicaciones que se ajustan al usuario, cumplen sus expectativas y satisfacen sus necesidades.

Lo mejor del caso es que esto no significa necesariamente un encarecimiento del presupuesto del proyecto, considerando que podemos utilizar diversas herramientas dependiendo de las características de cada proyecto y del presupuesto disponible. La clave radica en incorporar las herramientas de diseño centrado en el usuario desde el principio del proyecto, desde la etapa de diseño. Esto, y una selección apropiada de las herramientas que utilizaremos os darán una ventaja significativa..

Entre las herramientas más comúnmente utilizadas podemos destacar:

Escenarios

Existen varias técnicas para el desarrollo de escenarios, pero fundamentalmente consiste en la exploración de las necesidades del usuario mediante un grupo reducido de preguntas dirigidas.

Personas

Consiste en la definición de un grupo de personas o personajes ficticios, basados en los perfiles de un grupo definido de usuarios. Este personaje se crea a un nivel de detalle que nos permite (casi) darle vida y reconocer necesidades y preferencias específicas.

Definición de Usuarios

A diferencia de la técnica de definición de personas, en este caso definimos características comunes de grupos relevantes de usuarios, pero sin llegar a individualizarlos.

Evaluaciones en Linea y Directas

Existen diversas técnicas de evaluación que resultan apropiadas a varios fines, entre ellas la evaluación de usabilidad remota, evaluación de prototios, evaluación de accesibilidad, etc. En concreto se trata de comprobar determinadas características mediante verificaciones automáticas, con usuarios, presencial o remotamente.

Encuestas y Cuestionarios en Linea y Directas

Los cuestionarios son una herramienta económica y apropiada para varios fines. Disponemos de una amplia variedad de tipos de encuestas, desde encuestas en línea que miden la percepción de los usuarios respecto a un sitio en marcha, hasta cuestionarios dirigidos a identificar problemas específicos.

Prototipos

La elaboración de prototipos permite establecer un vínculo temprano con los usuarios, antes incluso de que se comience a escribir la primera linea de código. Podemos desarrollar prototipos de baja fidelidad utilizando papel y lápiz para evaluar una interfaz, hasta herremientas más sofisticadas para simular la navegación de elementos concretos.

Análisis de Tareas

Esto considera la evaluación y análisis del desarrollo de tareas específicas en un sitio o aplicación, lo que nos permite evaluar la usabilidad y efectividad de los mecanismos de interacción entre otros aspectos.

Ordenamiento de Cartas

Esta técnica, básicamente perteneciente a la Arquitectura de Información consiste en poner a disposición de un grupo de sujetos de prueba un set de cartas con los nombres de secciones o categorías para que ellos las ordenen de la manera que les parece más lógica o cómoda.

La clave de estas técnicas reside en que involucremos a los usuarios desde el principio del proyecto, cuando su aporte puede ser efectivo e influir positivamente. Si tratamos de considerar a los usuarios sólo como sujetos de prueba una vez que hemos finalizado un proyecto, de seguro su aporte será marginal, porque cualquier cambio en esta etapa resulta considerablemente más caro por la redundancia que esto implica.

Citas en HTML

General

HTML provee de un conjunto de elementos estructurales para definir citas. Una cita, según su acepción como mención es:

Recuerdo o memoria que se hace de una persona o cosa, nombrándola, contándola o refiriéndola.

Estructuralmente podemos definir tres tipos de citas:

  • Un bloque extenso de texto referido desde algún texto, publicación o cualquier otra fuente externa
  • Una referencia breve de un contenido de una fuente externa
  • Una referencia a otras fuentes, sin citar necesariamente contenidos específicos

Estos tres tipos de referencia tienen su representación en HTML en los elementos blockquote, q y cite respectivamente.

Uno de los aspectos interesantes de estos elementos es el hecho de que el contenido que definen gana un valor semántico importante: cualquier procesador automatizado o cualquier persona que lea el código reconoce que estas estructuras se refieren a un contenido que está siendo referenciado. Es decir, reconoce el sentido y relación de este contenido respecto al documento.

Más aún, podemos utilizar el atributo cite para blockquote y q para indicar la fuente de destino en la forma de una URI. Es importante no confundir el atributo cite, propio de los elementos blockquote y q, con el elemento cite.

El ejemplo de la definición de la palabra cita que aparece poco más arriba, utiliza blockquote junto con el atributo cite para indicar la definición en el sitio de la RAE.

Una distinción más sutil es la que marca la diferencia entre los elementos q y cite. q, así como blockquote definen un contenido extraído de una fuente externa, sólo que en el primero se trata de un texto breve, contenido dentro de un párrafo u otro elemento de bloque. cite, en tanto, tiene como objetivo el definir una referencia, o más bien la fuente de una referencia. Un ejemplo de esto es:

El elemento cite está definido en la sección de Texto Estructurado de la Especificación de HTML 4.01.

Estos elementos permiten enriquecer el valor semántico de los contenidos, en tanto que al identificarlos según su estructura podemos presentarlos apropiadamente usando CSS.

Estructura y Contenido

General

¿Cuál es el objetivo de validar un documento (X)HTML? ¿Es acaso el comprobar que cumplimos 100% con la sintaxis del tipo de decumento, independientemente de la estructura de contenidos que éste tenga? ¿Vale la pena tener un documento que pase las pruebas automatizadas de validación independientemente de la estructura interna?

Yo creo que no . No creo que el espíritu de un estándar sea el que los documentos cumplan sólo formalmente con su sintaxis. En un post anterior planteé algunos aspectos de mi forma de enfrentar los temas de estándares y validación. Lo importante no es cumplir formalmente, sino utilizar la estructura que HTML o XHTML nos proveen para organizar y dar cuerpo a los contenidos.

Progresivamente podemos observar una proliferación de sitios utilizando correctamente DOCTYPE para definir los tipos de documentos, e incluso muchos utilizando XHTML. Esto es en parte debido al soporte de las herramientas de desarrollo así como también porque el tema está en el aire. Pero muchos de esos documentos que se declaran como XHTML utilizan una diagramación basada en tablas. Técnicamente es posible y el (X)HTML puede validar pero la estructura de los documentos es pobre y no describe realmente la jerarquía y relaciones internas del contenido.

¿A qué me refiero? El validador de HTML del W3 genera un outline que utiliza los encabezados del documento (los elementos h1 al h6) para representar la estructura de contenidos. Este tipo de análisis se basa en el reconocimiento de la estructura de los contenidos, que es relativamente fácil de extraer de un documento bien organizado.

Los elementos h1, h2, h3, h4 , h5 y h6 deben representar la estructura de un documento mediante la jerarquización de los contenidos. h1 es el título principal, por lo tanto su contenido es relevante para determinar de qué trata un documento. Por lo mismo, h2 determinará un contenido secundario, pero de mayor relevancia o peso que el contenido de h3. Evidentemente ningún analizador automatizado podrá extraer la estructura real de un documento que no use apropiadamente los encabezados.

Otros beneficiados del uso de elementos estructurales de XHTML son los buscadores. Para un robot indexador tiene mucho sentido reconocer la estructura de un documento mediante sus encabezados y otorgará un mejor ranking a aquellos contenidos que declaren su estructura explícitamente.

Tampoco es muy razonable utilizar recursos como <div id="titulo"> porque no representan realmente a la estructura.

Del mismo modo otros elementos determinan estructura dentro de un documento, un p es un párrafo, es decir, un conjunto ordenado de ideas relacionadas que termina en un punto aparte. Los contenidos de una tabla utilizada para contenidos tabulares reflejan una relación basada en los cruces de filas y columnas: una celda pertenece a una fila y una columna, esta relación le confiere un sentido especial.

Así, formalmente un documento puede pasar una validación automatizada, pero eso no significa que la sintaxis esté utilizada de modo apropiado para reflejar la estructura de los contenidos.

Estándares y Validación

General

Desde hace ya varios años que me dedico a promover el uso de buenas prácticas en el Web y a incentivar el uso de estándares como XHTML y CSS. Los beneficios de utilizar los estándares son muchos y seguramente escribiré más adelante acerca de ellos. No obstante, mencionaré algunas ideas al rspecto. Estándares como CSS y XHTML además establecer un lenguaje común en el que todos nos podemos comunicar, en el que podemos confiar (poco más o menos) que los navegadores modernos respetarán de un modo razonable y que de paso facilita el trabajo a agentes de indexación (los robots) y otros procedimientos automatizados, nos permiten separar eficientemente el contenido y la presentación, el diseño visual.

Pero estas herramientas, que nos deberían simplificar la vida están implementadas y adoptadas de modo direferente y no somos nosotros (normalmente) los que controlamos el amplio universo en el que publicamos nuestros productos, léase contenidos, sitios, documentos, etc.

Es por esto que en momentos, en la vida real, aunque tengamos un compromiso grande con el respeto a los estándares, tenemos que tomar decisones que bajo cierta óptica pueden ser cuestionables. En efh yo puedo darme el lujo de ser estricto y controlar muchos aspectos, tomar desiciones autónomas y determinar qué técnicas utilizo, pero la vida no simepre es así. La idea es tener en el horizonte y como objetivo que el estándar es tal y las cosas deben ser así, y lo haremos en la medida que esto sea factible.

Cito un ejemplo: en una de las CSS de la Guía Web hay una propiedad, white-space a la que agregamos el valor pre-wrap, que es una definición propia de Microsoft para Explorer, por lo tanto no valida, para asegurar que este navegador desplegara correctamente lo que nosotros necesitábamos. El valor real, estándar es pre y lo agregamos mediante un hack sólo para los browsers estándar.

p.code {
white-space: pre-wrap;
}

h t m l >body p.code {
white-space: pre;
}

Todo el mundo recibe lo que quiere, sin que eso signifique un perjuicio muy grande. Ese es el único error de validación, es conciente y por razones concretas. Los browsers estándar reciben una versión estándar, Explorer recibe lo que necesita.

Podría citar otros ejemplos, pero creo que esto ilustra mi punto: lo importante es hacer el mejor esfuerzo de lograr la conformidad con los estándares, pero hasta que los navegadores sean 100% compatibles, tendremos que recurrir a trucos como esos. La idea es que sean los menos.

No quiero ser malinterpretado, yo soy tremendamente exigente respecto a estos temas, este sitio valida 100% sin errores y además es WAI-AAA (tengo algunos ajustes que hacer a este respecto, pero están en la lista de to-dos). Quienes me conocen lo saben, pero no soy integrista.

Moraleja: construye tus sitios considerando y respetando los estándares, pero no creas que el objetivo final es el estándar. Éste es sólo un medio, y en tanto el soporte real de los navegadores no sea el apropiado, habrá que procurar soluciones que se ajusten a la realidad.

Presentación de la Guía Web

General

Desde hace ya algún tiempo está al aire la Guía para el Desarrollo de Sitios Web de Gobierno. La iniciativa del Gobierno de Chile fue un esfuerzo que se basó en las conclusiones y experiencias de la primera versión del Premio Web. Su objetivo es el reunir una serie de buenas prácticas y recomendaciones que los sitios del Estado deben cumplir para asegurar un óptimo servicio a los ciudadanos.

Pese a que aún no ha sido presentada oficialmente, la Guía está disponibla para consulta y su recepción ha sido importante.

El Coordinador del proyecto fue Paulo Saavedra y el responsable de la edición Juan Carlos Camus. Mi papel en este proyecto fue construir el sitio de la Guía, que por su naturaleza debía cumplir con todas las recomendaciones del documento y ser muy respetuoso de los estándares, considerando entre otras cosas, accesibilidad. En este aspecto el sitio cumple con todas las guías de verificación automáticas y con una serie de los puntos de chequeo manual.

Nota: actualmente el sitio presenta un problema de validación en la portada producto del código de certificación de Certifica, que es un elemento ajeno al sitio. Esto se solucionaría próximamante.

Uno de los aspectos más interesantes de la construcción del sitio, al menos para mí que soy un maniático declarado de los estándares, es el uso meditado y cuidadoso de cada elemento o tag de XHTML. Los invito a anlaizar la estructura de los documentos que, naturalmente, confían la presentación a CSS. Una página en particular que me dió mucha satisfacción es el Glosario. Observen el cuidadoso uso de las listas de definición DL y de la lista de navegación alfabética al principio de la página.

Quedan otras cosas por revisar del sitio, pero la verdad es que necesitaré otro post completo para eso. Por ahora los dejo con la presentación, prometo una visita más detallada de los detalles de la construcción y las decisiones que fue necesario tomar respecto a estructura, presentación, estándares, etc.

Buscar Mientras Escribes

General

Una de las funcionalidades que me resultan más cómodas en Mozilla es la llamada Find As You Type. Consiste básicamente en que el usuario puede escribir aquéllo que desea encontrar en una página, con el foco en el documento, sin necesidad de abrir una ventana de buscador y Mozilla buscará y destacará en el contenido del documento lo que uno está ingresando.

findasyoutype.01

 

Find As You Type, o Encuentra Mientras Escribes en acción en Mozilla.

Por otro lado todos hemos observado el comportamiento de la barra de ubicación en los browsers que tratan de hacer cincidir la URL que uno ingresa con aquéllas registradas en el historial. Incluso en los entornos de desarrollo IDE las funciones de autocompletación de código proveen una utiidad similar.

livesearch.01

Livesearch al momento de comenzar a escribir el término deseado.

OK, pero todo eso en aplicaciones de escritorio no es algo demasiado impresionante, sin menospreciar su utilidad. Lo destacable es implementarlo en entorno Web. Es por esto que me detengo nuevamente en el caso de Livesearch que mencionara en un post anterior.

livesearch.02

Livesearch mientras se completa la escritura del término buscado.

La búsqueda dinámica implica que se están realizando una serie de conexiones y queries en el servidor, y me pregunto cuánto afectará esto al rendimiento y cuántos recursos adicionales utilizará. Aparentemente esto está resuelto de modo bastante apropiado en Livesearch, observando su comportamiento aparentemente las búsquedas se realizan sobre los títulos de los posts en el sitio y no sobre los contenidos completos y es posible que una vez realizada una conexión para obtener los datos de, por ejemplo, Li si ingreso luego Livesearch se puedan filtrar los contenidos localmente vía JavaScript sin necesidad de realizar nuevas comunicaciones con el servidor.

Estoy especulando, habrá que ver con más detalle su implementación, pero el punto destacable es el hecho de ser una aplicación inteligente de tecnologías combinadas al servicio del mejoramiento de la experiencia de uso.