Lineamientos

Lineamientos tecnológicos para los sitios web turísticos, las aplicaciones móviles orientadas al turista y los sistemas de información del sector

Los lineamientos tienen como objetivo definir las pautas básicas y elementales a ser consideradas al momento de diseñar, desarrollar e implementar sitios web, aplicaciones móviles y proyectos de innovación tecnológica orientados al turista, independientemente que se realicen desde el Estado o por un proveedor.

Con los siguientes estándares, se busca aumentar la calidad de los desarrollos tecnológicos de los destinos turísticos, para facilitar la comprensión y utilización de los mismos, primando la interoperabilidad, usabilidad, la accesibilidad y la experiencia. Asimismo, se busca facilitar la disponibilidad y socialización de la oferta turística.

1. Sitios web


1.1 Principios


1.1.1 Priorizar las necesidades de los turistas: cualquier desarrollo debe apuntar a solucionar esas necesidades.
1.1.2 Diseñar a partir de los datos: las decisiones de diseño basadas en la recolección y análisis de parámetros objetivos, incluyendo métricas de uso, de usabilidad e indicadores de performance.
1.1.3 Entender los canales de cada servicio: el uso de un servicio se puede dar a través de diversos canales, se debe diseñar pensando en la experiencia completa del turista.
1.1.4 Los servicios digitales diseñados para el turista deben ser simples de usar: cada servicio debe tener una experiencia de uso fácil, aun cuando los procesos y sistemas sean complejos.
1.1.5 Los servicios digitales que se desarrollen deben ser accesibles: es necesario cuidar que la calidad de los servicios sea igual para todos los turistas, compensando dificultades visuales, auditivas, físicas, cognitivas, neurológicas y del habla.
1.1.6 Los servicios digitales deben poder ser utilizados desde cualquier dispositivo apto.
1.1.7 Todos los servicios y desarrollos que se realicen deben considerar la interoperabilidad con otros sistemas turísticos, ya sean locales, regionales o nacionales.
1.1.8 Se deberá trabajar en ciclos cortos y progresivos: se deberá planificar el trabajo sobre los servicios en iteraciones pequeñas para sumar funciones o cambiar existentes de manera gradual. De esa manera se deberán mostrar los resultados frecuentemente para producir una retroalimentación y mejorar los servicios y productos creados para el turista.

1.2 Usabilidad


1.2.1 Diseñar para todas las resoluciones de pantalla de computadoras, tablets y celulares posibles.
1.2.2 Usar convenciones de estética y funcionamiento de cada plataforma o sistema operativo.
1.2.3 Entender qué funcionalidades son las más usadas (en base a medición de analíticas y pruebas de usabilidad), para hacerlas más fácil de acceder en futuras versiones.
1.2.4 Mostrar al usuario el estado del sistema en todo momento. Dónde está, lo que está haciendo y de qué se trata (títulos y descripciones), cuál es su progreso (indicadores de carga y barras de progreso, etc.).
1.2.5 Brindar una respuesta inmediata a cada interacción (un cambio visual, un mensaje de carga, etc.).
1.2.6 Los elementos interactivos deben tener un estilo para cuando está:
1.2.6.1 En estado normal
1.2.6.2 En foco
1.2.6.3 Over (mouse sobre del elemento)
1.2.6.4 Activo (cuando se está haciendo clic o tap)
1.2.6.5 Visitado (para enlaces dentro de un párrafo).
1.2.7 Los botones o áreas interactivas deben ser grandes como para no necesitar precisión al hacer clic o tap. Esta necesidad está basada en la ley de Fitts. En aplicaciones móviles el mínimo de un área interactiva debe ser 44x44pts.
1.2.8 Los campos de formularios deben mostrar su etiqueta al estar completos.

1.3 Accesibilidad


1.3.1 Los textos deben cumplir las 5 reglas de legibilidad:
1.3.1.1 El contraste mínimo del texto debe ser 4,5:1.
1.3.1.2 El cuerpo de texto mínimo para sitios web es de 14px/pts para párrafos y 12px/pts para anotaciones.
1.3.1.3 Usar interlineado de párrafos de 1,5 a 2 veces el cuerpo de texto.
1.3.1.4 La separación entre párrafos debe ser 1,5 veces el interlineado.
1.3.1.5 No usar párrafos con texto justificado.
1.3.2 Usar subrayado para los enlaces (a menos que sea un menú o botón).
1.3.3 Las fotos deben tener un texto alternativo descriptivo.
1.3.4 No usar texto que en vez de ser texto es una imagen.
1.3.5 Incluir una vista de impresión, ya sea usando una hoja de estilos o una página aparte, para que todo contenido se vea bien al imprimir.
1.3.6 Usar subtítulos para videos.
1.3.7 En web, permitir el uso de un teclado sin necesidad de mouse.

1.4 Seguridad


1.4.1 La comunicación con los servicios web debe ser encriptada usando un certificado SSL/TLS
1.4.2 Todas las URL que lanza una aplicación deben ser https.
1.4.3 Se deben mantener actualizados los frameworks de desarrollo, librerías y demás componentes de software, como así también la infraestructura tecnológica de base para evitar vulnerabilidades de seguridad.

1.5 Contenidos


1.5.1 Información clave y orden de los temas: cuando el usuario entra al sitio, tiene que poder acceder a un pantallazo general de lo que va a encontrar en la página, a modo de orientación. Esto, teniendo en cuenta que el primer filtro que aplica es: “¿Estoy donde/quiero/ necesito estar?”
1.5.2 Estructura del texto: El esquema tripartito de título, encabezado y cuerpo, permite redactar de manera clara un texto. Para lo cual se deberá usar el menor número de palabras posible para expresar un concepto
1.5.3 Lenguaje claro, sencillo, preciso: La claridad y sencillez son rasgos esenciales para que un texto no presente ambigüedades ni dé lugar a múltiples interpretaciones.
1.5.4 Recursos:
1.5.4.1 Negrita: resaltan las palabras clave de un párrafo. Se recomienda un uso máximo de 2 resaltados por párrafo, para evitar que el texto resulte ilegible o sature visualmente. Nunca se usan en el título o la bajada/copete.
1.5.4.2 Bastardilla, cursiva o itálica: siempre se utilizan para destacar vocablos en otros idiomas, como smartphone o startup.
1.5.4.3 Mayúsculas: nunca se utilizan para destacar conceptos, ya que el texto pierde legibilidad. Solo se usan al comienzo de oración y de nombres de personas, instituciones o cargos. Se aceptan en siglas.
1.5.4.4 Viñetas: cuando se presentan una serie de elementos sin orden que puede hacer confuso el texto.
1.5.4.5 Listado numérico: cuando se presenta una serie de elementos ordenados como pasos de un proceso
1.5.5 Extensiones orientativas

    Título: 8-10 palabras [70 caracteres con espacios]
    Volanta o indicador de sección: 8 palabras, idealmente 4 [60 caracteres con espacios]
    Copete o bajada: 15-20 palabras [120-160 caracteres con espacios] 
    Oración: 15-20 palabras [120-160 caracteres con espacios]
    Párrafo: 40- 70 palabras [320-560 caracteres con espacios] 
    Cuerpo del texto: 350 palabras [2.150 caracteres con espacios] 
    Epígrafe de foto: 15 palabras [120 caracteres con espacios] 
    Etiquetas: Hasta 8 palabras [60 caracteres con espacios]

2. Aplicaciones móviles


2.1 Desarrollo


2.1.1 Las aplicaciones deben soportar las distintas resoluciones de los distintos tipos de dispositivos.
2.1.2 No embeber imágenes y videos como contenido estático que hagan que los archivos de las aplicaciones sean más pesados.
2.1.3 Las aplicaciones existentes deben estar actualizadas. Si la aplicación no estará más en funcionamiento (o con soporte), se debería remover de las tiendas, para evitar inconvenientes de seguridad.
2.1.4 El código fuente de las aplicaciones deberá ser fácil de comprender, documentado, escalable, flexible y deberá ser acompañado de la documentación necesaria para poder asegurar su continuidad soportando un futuro cambio de proveedor o integrantes del equipo interno.
2.1.5 Generar y proveer los manuales de uso necesarios para el turista que utiliza la aplicación móvil.
2.1.6 Control de Versiones:
2.1.8.1 versión v 0.0.1: Resolución de bugs de versiones actuales.
2.1.8.2 versión v.0.1.0: Nueva funcionalidad dentro de la versión actual.
2.1.8.3 versión v.1.0.0: Representan un cambio sustancial respecto de la funcionalidad o de la estética actual del sitio.
2.1.7 Las aplicaciones con sistemas de registración y autenticación deben procurar un sistema homogéneo para los turistas.
2.1.8 Todo contenido que muestra la aplicación debe ser consumido mediante una API, con el objeto de permitir actualizar el contenido de forma dinámica sin necesidad de generar una nueva versión de la aplicación.
2.1.9 La aplicación debe brindar la posibilidad de operar en forma total o parcial en modo offline (sin conexión). La sincronización y actualización de contenidos se llevarán a cabo una vez que el dispositivo se encuentre nuevamente en modo online. Esto permitirá evitar el tráfico de datos innecesarios para el turista y brindar la posibilidad de usar la aplicación aun cuando no se cuenta con una conexión a Internet.
2.1.10 El desarrollo se realizará para que sea compatible con la última versión más estable del sistema operativo y contemplando las versiones previas que aún siguen siendo populares.
2.1.11 El diseño de las estructuras de datos debe priorizar el uso eficiente, tanto internamente como en el consumo de servicios web e interoperabilidad mediante APIs.

2.2 Diseño


2.2.1 Como estética se sugiere utilizar un sistema visual minimalista en donde predomine el diseño del contenido evitando el uso de ornamentos que distraigan.
2.2.2 Se recomienda el uso de fotografías como parte del contenido, ya que hace más amena la lectura, ayuda a la comunicación y resulta más atractiva para la promoción de productos y servicios turísticos.

2.3 Usabilidad


2.3.1 Diseñar para la mayor cantidad posible de resoluciones de pantalla de computadora, tablet, celular, smartwatch, smartTV y otros dispositivos.
2.3.2 Usar convenciones de estética y funcionamiento de cada plataforma o sistema operativo.
2.3.3 Entender qué funcionalidades son las más usadas (sobre la base de la medición de analíticas y pruebas de usabilidad) para hacerlas más fácil de acceder en futuras versiones.
2.3.4 Brindar una respuesta inmediata a cada interacción (un cambio visual, un mensaje de carga, etc.).
2.3.5 Los elementos interactivos deben tener un estilo para cuando está:
2.3.5.1 En estado normal
2.3.5.2 En foco
2.3.5.3 Activo (cuando se está haciendo clic o tap)
2.3.5.4 Visitado (para enlaces dentro de un párrafo).
2.3.6 Los botones o áreas interactivas deben ser grandes como para no necesitar precisión al hacer click o tap. Esta necesidad está basada en la ley de Fitts. En aplicaciones móviles el mínimo de un área interactiva debe ser 44x44pts.
2.3.7 Los campos de formularios deben mostrar su etiqueta al estar completos.

2.4 Seguridad


2.4.1 La comunicación con los servicios web debe ser encriptada usando un certificado SSL/TLS
2.4.2 Todas las URL que lanza una aplicación deben ser https.
2.4.3 Solo se deben pedir al usuario los permisos mínimos y estrictamente los que son necesarios.
2.4.4 Los datos de los usuarios usados en la registración deben ser guardados con seguridad.
2.4.5 Limitar cantidad de intentos de ingresos al sistema.
2.4.6 Se deben actualizar los frameworks de desarrollo para evitar vulnerabilidades de seguridad.

2.5 Métricas


2.5.1 Se deben identificar las principales métricas y utilizar sistemas que permitan el seguimiento diario de las mismas.
2.5.2 Las aplicaciones deben incorporar registros de errores y fallas. Lo que permitirá registrar, identificar y rastrear las fallas que se generan dentro de las aplicaciones, y poder resolverlos para mantener la mejora continua de las aplicaciones y ofrecer una mejor experiencia de uso al turista.

2.6 Publicación


2.6.1 Las aplicaciones las firmará el organismo oficial de turismo con la firma y certificados propietaria. De esta manera se logrará mantener la continuidad del producto sin importar el desarrollador o tercero.
2.6.2 Es importante que los organismos trabajen con sus propios
repositorios para lograr mantener la continuidad del producto sin importar el desarrollador o tercero.
2.6.3 Los identificadores de cada aplicación deben ser únicos para cada dispositivo
2.6.3.1 Permite tener homogeneidad en los identificadores de todas las aplicaciones.
2.6.3.2 Permite que exista una única aplicación instalada dentro del dispositivo.
2.6.3.3 Una vez publicadas las aplicaciones en las tiendas, los identificadores no pueden ser cambiados ni removidos porque sino se considera una nueva aplicación, completamente distinta de la anterior y no una nueva versión del mismo.

3. Sistemas y plataformas de información turística


3.1 Lineamientos


3.1.1 Diseñar el sistema de forma modular y escalable.
3.1.2 Generar servicios web que puedan ser utilizados desde diversos dispositivos y plataformas.
3.1.3 Utilizar perfiles de metadatos orientados a la información turística, con el objeto de facilitar la interoperabilidad entre plataformas.
3.1.4 Diseñar el sistema considerando las buenas prácticas de ingeniería de software, de la tecnología subyacente y patrones de diseño.
3.1.5 Utilizar JSON como formato para el intercambio de datos mediante servicios web.
3.1.6 Contemplar distintos niveles de acceso a la información y las responsabilidades en la gestión de los datos.
3.1.7 Diseñar el sistema contemplando la normativa en relación a los datos personales, propiedad intelectual de los recursos incluidos, existencia de registros de prestadores turísticos y otras normativas complementarias.
3.1.8 Habilitar mediante servicios web toda la oferta turística disponible incluyendo, pero no limitándose a alojamientos, agencias de viajes, empresas de turismo, guías de turismo, otros prestadores de servicios turísticos. En todos los casos se deben incluir aquellos que han cumplido con la normativa legal vigente.
3.1.9 Incluir sistemas de alerta que permitan notificar cambios en los datos a otras plataformas que utilizan los servicios web.

4. API


4.1 Lineamientos


4.1.1 Incluir el número de versión de la API en la URL.
4.1.1 No traducir al español lo que se utiliza en inglés por cuestiones de costumbre, buenas prácticas o restricciones de la tecnología subyacente.
4.1.2 Generar la documentación que incluya al menos la especificación y ejemplos de implementación.
4.1.3 Diseñar considerando la menor cantidad de consultas y estructuras de datos eficientes, para evitar tráfico de datos innecesarios.
4.1.4 Se recomienda la utilización de HATEOAS.

4.2 RESTful URLs


4.2.1 Una URL identifica un recurso.
4.2.2 Las URLs deben incluir sustantivos, no verbos.
4.2.3 Use sustantivos en plural solamente para consistencia (no sustantivos en singular).
4.2.4 Use los verbos HTTP (GET, POST, PUT, DELETE) para funcionar en las colecciones y elementos.
4.2.5 No necesita ir más allá de resource/identifier/resource
4.2.6 Ponga el número de versión en la URL, por ejemplo: http://ejemplo.tur.ar/v1/path/to/resource
4.2.7 Especificar campos opcionales como una lista separada por coma.
4.2.8 El formato DEBE ser: api/v2/resource/{id}.json

4.3 Verbos HTTP


4.3.1 Los verbos HTTP, o métodos, se deben utilizar en el cumplimiento de sus definiciones de la norma 1.1 / HTTP.

4.4 Soporte JSON


4.4.1 Las respuestas deben ser un objeto JSON. No utilizar un array para retornar resultados porque limita la escalabilidad de las soluciones.
4.4.2 No usar claves impredecibles.
4.4.3 Usa guión_bajo para las claves. Diferentes lenguajes usan diferentes convenciones. JSON usa guión_bajo, no camelCase.

4.5 Respuestas


4.5.1 No incluir valores en las claves. Las claves deben ser los nombres de atributos, no el valor en sí mismo.
4.5.2 La metadata solamente debe contener propiedades directas a la respuesta, no propiedades relacionadas a la información de la respuesta.
4.5.3 Ejemplo válido
No incluir valores en claves:

"tags": 
    [
        {"id": "234", "name": "Turista"},
        {"id": "752", "name": "Viajero"}
    ]

Ejemplo no válido Valores en claves:
"tags": 
    [
        {"234": " Turista "},
        {"752": " Viajero "}
    ]

4.6 Formato de fecha


4.6.1 Usar formato ISO 8601, en UTC.
4.6.2 Para representar únicamente fechas, el formato debe ser año(cuatro dígitos)-mes(dos dígitos)-día(dos dígitos), como por ejemplo: 2016-09- 27.
4.6.3 Para representar fecha y hora, el formato debe ser 2016-01- 27T10:00:00Z.

    2016-01-27T10:00:00Z
    año, mes, día
    hora, minutos, segundos UTC

4.7 Manejo de errores


4.7.1 Las respuestas de errores deben incluir los códigos de estados HTTP, mensaje para el desarrollador, mensaje para el usuario final, código de error interno, enlaces con más información para los desarrolladores. Por ejemplo:

{
    "status" : 400,
    "developerMessage" : "Detallar una descripción clara del problema.
    Proveer a los desarrolladores sugerencias de cómo resolver sus problemas.",
    "userMessage" : "Este es el mensaje para el usuario final.", "errorCode" : "123",
    "moreInfo" : "http://www.tur.ar/dev/path/to/help/for/123"
}
4.7.2 Use estos 3 simples códigos de respuesta indicando (1) éxito, (2) fallo debido a un problema del cliente, (3) fallo debido a un problema del servidor:
    200 - OK
    400 - Bad Request
    500 - Internal Server Error


4.8 Usar UTF-8


4.8.1 Esperar caracteres acentuados o comillas en la salida de la API, aun cuando no se espere.
4.8.2 Una API debe informar a los clientes de esperar UTF-8 mediante la inclusión de una notación de caracteres en la cabecera Content-Type para las respuestas.
4.8.3 Una API que retorna JSON debe usar: Content-Type: application/json; charset=utf-8

4.9 Versiones


4.9.1 Nunca libere la versión de una API sin su número de versión.
4.9.2 Las versiones deben ser enteros, no decimales, con el prefijo ‘v’. Por ejemplo:

    Válido: v1, v2, v3
    No válido: v-1.1, v1.2, 1.3
4.9.3 Dar soporte al menos una versión anterior a la actual.

4.10 Límite de registros


4.10.1 Si el límite no está especificado, retornar resultados con un valor por defecto.
4.10.2 Para obtener un rango de registros se recomienda utilizar filtros, como por ejemplo:
http://ejemplo.gob/articulos?limit=25&offset=50 offset=50 significa, ‘evitar los primeros 50 registros’ limit=25 significa, ‘retornar un máximo de 25 registros’
4.10.3 La información sobre los límites de registros y totales disponibles deben ser incluidos en la respuesta. Por ejemplo:

{
"metadata": 
    {
        "resultset": {
            "count": 227,
            "offset": 25,
            "limit": 25
        }
    },
    "results": []
}

4.11 Seguridad


4.11.1 Siempre usar HTTPS
4.11.2 Cualquier API que se cree debe usar HTTPS encryption (TLS/SSL). HTTPS provee:
Seguridad. El contenido de las peticiones están encriptadas a través de Internet.
Autenticidad. Una garantía más fuerte de que un cliente se comunica con el API real.
Privacidad. Privacidad mejorada para las aplicaciones y usuarios que usan la API. Las cabeceras HTTP y los parámetros query string (entre otras cosas) serán encriptadas.
Compatibilidad. Más amplia compatibilidad del lado del cliente. Para solicitudes CORS a la API para trabajar en los sitios web HTTPS - para no ser bloqueado en forma de contenido mixto - esas peticiones deben ser a través de HTTPS.
4.11.3 HTTPS debe estar configurado aplicando las mejores prácticas, incluyendo cifrado que soporte forward secrecy y Seguridad de transporte HTTP estricta (HTTP Strict Transport Security).
4.11.4 Para APIs existentes que corren sobre HTTP, el primer paso es agregar soporte HTTPS y actualizar la documentación aclarando que es la configuración por defecto, usarlo en los ejemplos, etc.
4.11.5 Luego, evaluar la posibilidad de deshabilitar o redireccionar a peticiones HTTP.

4.12 Claves API


4.12.1 Es importante que las APIs tengan la forma de poder identificar qué aplicación quiere acceder a los recursos. Para esto se utiliza una clave que va junto con la petición.
4.12.2 Estas claves deben poder ser gestionadas.

5. Datos abiertos


5.1 Lineamientos


5.1.1 Para ser considerados datos abiertos, estos deberán cumplir con las siguientes características:
Completos: que reflejen la totalidad del tema y descritos con detalle.
Públicos: de interés general y carácter público, protegiendo la privacidad.
Primarios: que provienen de la fuente original y tienen el máximo nivel de desagregación posible.
En tiempo: siendo oportunos y actualizados tan pronto sea posible.
De libre acceso: disponibles de manera conveniente, sin restricciones de acceso ni discriminación.
Procesable por máquina: estructurados de tal forma que permita el procesamiento automático.
En formatos abiertos: que utilicen estándares abiertos, procesables por máquinas y pueden ser descargables y operados con los requerimientos tecnológicos mínimos.
Con licencia de libre uso: que define claramente la libertad y certeza de ser utilizados como insumo para cualquier fin, requiriendo a lo mucho, atribución.
Permanentes: para habilitar la capacidad de encontrar la información publicada a perpetuidad; y para que toda información hecha pública, permanezcan así, siempre con identificadores adecuados respecto a versiones y archivado en el tiempo.
Costos de utilización: que deberán ser justos -preferentemente nulos-, para evitar barreras al uso por parte de los ciudadanos.
5.1.2 Se debe crear un catálogo de datos abiertos con las principales entidades de información del sector turístico.


Fuentes

https://github.com/argob/estandares
https://github.com/argob/accesibilidad-web
http://paquete-apertura-datos.readthedocs.io/es/stable/
https://www.gov.uk/design-principles
https://playbook.cio.gov/