• 5 segundos para que aparezca algo visible en la pantalla • 10 segundos para que aparezca algo legible en la pantalla • 30 segundos hasta hacer un click hacia otra parte del sitio o hacia otro sitio Nota: El rendimiento de una conexión a Internet nunca es del 100%. Hay que tener en cuenta que en estos tipos de conexiones (Módem analógico, RDSI, ADSL) se utilizan diversos protocolos (PPP, TCP/IP) que ocupan ancho de banda (entre un 2% y un 20% del 100% total, según el tipo de conexión y protocolo utilizado), con lo que se reduce el ancho de banda útil para la descarga de datos. El resultado que se muestra en las pruebas de velocidad de conexión existentes (por ejemplo en http://testacceso.es.tdatacenter.com/) corresponde al ancho de banda útil, esto es, equivale a la velocidad de transferencia de información, y no a la velocidad de acceso. Adicionalmente, existen otros factores que no pueden ser medidos y que contribuyen a reducir la velocidad de la conexión, como son la congestión en la red, interferencias electromagnéticas, etc., que también afectan al resultado final.
2. Diagramación de las Páginas Aunque existen nuevas tecnologías para la diagramación de las páginas web (como las Hojas de Cascadas de Estilo o CSS), lo habitual es que los contenidos que se muestran se dispongan en tablas con el fin de que cada elemento ocupe el lugar que se le ha asignado dentro de la página.
Al respecto se recomienda construir una estructura de presentación de los contenidos que se pueda fragmentar en varias tablas.
De esa manera, cuando el sitio se presente en el programa visualizador del cliente, siempre mostrará la primera tabla (que normalmente llevará el logotipo y la identificación del sitio) de manera rápida, dando al usuario la sensación de haber llegado al destino elegido. Luego en las siguientes tablas se van poniendo los restantes elementos del sitio.
En la figura 1 se puede ver que el sitio está construido en tres tablas, de acuerdo al siguiente orden:
Tabla 1: Muestra el logotipo de la institución, la fecha y el menú del sitio.
Tabla 2: Muestra las Secciones del Sitio más los contenidos de diferente nivel.
Tabla 3: Muestra el pie de la página con la identificación corporativa de la institución.
Hay que recordar que los estudios sobre acceso a Sitios Web indican que el usuario espera que al primer segundo después de haber hecho clic sobre un enlace o haber ingresado una dirección en un programa visualizador, ya quiere ver alguna reacción y notar que algo está ocurriendo.
Por lo anterior se debe evitar a todo lugar las tablas generales que incluyen en sí mismas a otras (tablas anidadas), ya que el programa visualizador usará una parte del tiempo en calcular esa relación de dependencia entre las tablas, antes de mostrar algo útil en la pantalla.
En la figura 2 se puede ver que el sitio está construido en tres tablas interiores, que son agrupadas por una tabla general; también en la zona de Contenido 1 se dispuso una tabla que permite incluir una foto junto al contenido:
3. Uso de Presentaciones en Flash Si se desea hacer una presentación en tecnología Flash de Macromedia para la portada del sitio, se recomienda no hacerlo directamente en la portada. Un ejemplo concreto de hacerlo se muestra en la siguiente imagen:
La razón para evitar el uso de Flash en la portada es que su uso recarga la presentación del sitio y si la presentación no está bien hecha, puede impedir el acceso de los robots de búsqueda al interior del mismo. Si eso ocurre, los contenidos del sitio no serán indexados en los buscadores que emplearán los usuarios para buscar información sobre los temas que la institución desea comunicar.
La buena práctica en este sentido es ofrecer una portada con la identificación de la institución y dos enlaces: uno para ver la presentación y otro para ingresar directamente al sitio. Adicionalmente se debe ofrecer la información que sea necesaria para que los usuarios puedan ver el contenido sin experimentar problemas; dentro de esto se cuenta un enlace para obtener el plug-in necesario.
Dado lo anterior y como pocos usuarios estarán dispuestos a ver repetidamente la presentación, se recomienda utilizar esos recursos en el interior del sitio, para mostrar con una tecnología de animación aquellos contenidos en los que desee poner énfasis o para explicar procesos que gráficamente resulten atractivos y que en texto sea difícil dar a conocer.
4. Uso de Marcos o «Frames» La tecnología de marcos o «frames» consiste en agrupar varios archivos para que se desplieguen de manera simultánea, permitiendo a los usuarios ver varios contenidos al mismo tiempo.
En el ejemplo siguiente se puede ver gráficamente cómo se hace el despliegue de dichos archivos:
Esta tecnología tiene aspectos positivos y negativos, que detallamos brevemente:
Positivos:
• Permite tener ciertos contenidos presentes todo el tiempo, como un cabezal o menú.
• Facilita la navegación ya que el usuario nunca pierde de vista dónde se encuentra.
Negativos:
• Impide que el usuario pueda marcar una página como «favorita» (bookmark) porque nunca se le muestra cuál es su dirección web.
• Cuando un usuario llega a un contenido desde un enlace provisto por un buscador, verá el sitio sin los otros marcos y no sabrá cómo navegar en él.
• La existencia de varios archivos en uno genera una carga mayor para el usuario que llega al sitio; eso lo obliga a esperar a que aparezcan todos los contenidos de los archivos para poder usarlo.
Debido a lo anterior y salvo que sea muy necesario, esta forma de organizar los sitios web debe desecharse para pasar a sitios de interfaz contenida en un solo archivo.
5. Uso de Imágenes de «background» Una tecnología muy popular que se puso de moda en el año 1996 cuando el software Netscape Navigator lo implementó, fue el uso de imágenes como fondos o «backgrounds» de las páginas web.
Salvo casos en que sea estrictamente necesario, esta práctica debe ser dejada de lado porque su único efecto es el de agregar un paso excesivo a los sitios, afectando el tiempo de descarga y acceso a la información.
6. Uso de «meta tags» Adecuados Los «meta tags» son marcas en lenguaje html que van en la parte superior del código fuente de cada página, a través de las cuales se entrega a los sistemas de indexación y búsqueda, la información mínima para hacer una correcta indexación del contenido que incluye.
Los «meta tags» son un conjunto de elementos que obedecen a un estándar definido por el World Wide Web Consortium (http://www.w3c.org) por lo que su uso está regulado y mediante los cuales redescribe información concreta sobre la página, tal como título, autor, descripción, idioma y otros. Los más importantes, aunque no los únicos, son los siguientes:
Adicionalmente sobre este tema se ha dado en los últimos años un trabajo de estandarización muy importante a través del grupo «Dublín Core» que ha definido los elementos «meta tags» a usar y que deben ser consultados en http://www.dublincore.org.
> Normas para Incorporar Elementos Gráficos y Multimediales Cuando en un Sitio Web se incorporan elementos gráficos y multimediales, se deben seguir normas muy concretas para evitar que su peso afecte el desempeño de la página cuando sea solicitada por los usuarios del Sitio Web.
A continuación entregamos algunas recomendaciones tendientes a asegurar la correcta inclusión de dichos elementos:
• Optimizar el peso de las imágenes: se debe bajar al máximo posible el peso de las imágenes; cuando esto no sea posible hacerlo por su tamaño, se debe reducir el número de colores disponibles y la resolución (72 dpi es la norma).
• Elegir el formato adecuado: ante un mismo tamaño de imagen, el peso varía dependiendo de si son procesadas para desplegarse en formato GIF respecto del formato JPG. Normalmente una imagen con colores planos (como un icono) tendrá un peso menor si se guarda en GIF respecto de si es guardada en JPG. Lo contrario ocurrirá con una imagen con muchos colores diversos (como una foto). Se recomienda probar ambos formatos para determinar el óptimo.
• Ubicación de imágenes: se recomienda usar un solo directorio para almacenar las imágenes repetidas, tales como los iconos y otros elementos gráficos que son utilizados en diferentes páginas del sitio. Al ubicarlos en un directorio único se puede aprovechar la función de caché del programa visualizador para mejorar el rendimiento de las páginas. Para efectos de seguridad, se recomienda impedir que un programa visualizador pueda ver el contenido de dicho directorio o cualquier otro dentro del sitio.
• Usar el atributo ALT en imágenes: en el código HTML se debe usar el atributo ALT (texto alterno) en las imágenes para que éste se despliegue antes que las imágenes y facilite de esta forma la comprensión del contenido a los usuarios.
• Imágenes con alto y ancho: las imágenes (dibujos, fotos, iconos, botones) deben tener tamaño para el ancho y el alto, para que el programa visualizador pueda dejar reservado el espacio para dicho contenido antes de que se realice su despliegue visual.
• Ofrecer plug-ins: cuando se utilizan archivos multimediales que requieren el uso de plug- ins (programas visualizadores especiales) para revisarlos, se recomienda poner el programa para ser bajado u ofrecer un enlace a lugares donde obtenerlo. Esto es especialmente válido en sitios que ofrecen presentaciones de portada en tecnología Flash, las cuales deben ser anunciadas para que el usuario tenga la opción de verlas o avanzar directo al sitio.
• Indicar el peso de los archivos: cuando se ofrecen elementos gráficos o audiovisuales para que sean bajados al computador personal por el usuario (especialmente en Video, Audio, Flash u otros), se recomienda indicar el peso de los mismos, con el objeto de ofrecerle información útil para efectuar la operación.
> Interoperabilidad Dado que los sitios web pueden ser accedidos sin problemas desde computadores que utilizan diferentes sistemas operativos, en un sitio de Gobierno Electrónico se debe cuidar ese aspecto de la diversidad. Para ello se debe asegurar de que desde la mayor parte de ellos las páginas pueden verse sin mayores contratiempos.
Para asegurar esto, las recomendaciones son las siguientes:
• Utilizar código html estándar, no mejorado para un visualizador en especial • Probar el sitio con las versiones para diferentes sistemas operativos de diversos visualizadores de páginas (browsers); especialmente hacerlo con versiones de Microsoft Internet Explorer, Netscape Communicator, Mozilla, Opera y Safari.
• Asegurarse de que el sitio puede ser visualizado de alguna forma cuando no se cumplen ciertas condiciones mínimas, por ejemplo, cuando se usan versiones antiguas de un programa visualizador que no soporta las nuevas características del lenguaje html (por ejemplo Netscape Navigator versión 4.6).
Estándares Internacionales Además de las buenas prácticas basadas en la experiencia, la tecnología web cuenta con un conjunto de estándares que deben ser respetados para obtener la certificación que acredita al sitio respecto de su conformidad con ellos.
La entidad encargada del tema es el Word Wide Web Consortium (http://www.w3c.org/) que se encarga de velar por las mejoras en la tecnología y por hacer avanzar los estándares y que los programas visualizadores cumplan efectivamente con mostrar lo que el lenguaje HTML permite construir.
Dentro de los estándares que más interesa cumplir, se cuentan dos que tienen que ver con la forma de hacer la presentación de contenidos en un Sitio Web y que se detallan a continuación:
Validación de HTML Es un sistema basado en Internet y presentado en el propio sitio del W3C (http:/ /validator.w3.org/) y que permite detectar errores en la forma de utilizar el lenguaje HTML y XML en la construcción de un Sitio Web. Lo interesante del programa es que muestra en detalle los errores del código en la página que se pruebe, con lo cual se puede llegar a una directa corrección de los problemas que se hayan detectado.
La importancia de tener un código correctamente validado es que se asegura, a partir de esa certificación, que la página web puede ser vista sin problemas, desde cualquier programa visualizador que cumpla con los estándares internacionales en la materia.
Validación de CSS Es un sistema basado en Internet y presentado en el propio sitio del W3C (http:// jigsaw.w3.org/css-validator/) mediante el cual se puede validar la sintaxis de una Hoja de Estilo en Cascada (Cascade Style Sheet o CSS, en inglés), mediante la cual se describe la forma de presentar contenidos en una página web.
Este programa muestra en detalle los errores del CSS en la página que se pruebe, con lo cual se pueden aislar los problemas y hacer la corrección correspondiente. Cabe indicar que la ventaja de usar la tecnología CSS es que facilita la mantención de un sitio mediante la separación de la presentación (diseño) del contenido.
Diseño para la Accesibilidad La accesibilidad de un Sitio Web se refiere a su capacidad para presentar contenidos a personas que cuentan con discapacidades físicas, que les impiden usar la información disponible de una manera tradicional y por ello emplean ayudas técnicas.
Un ejemplo de esto son el uso de un lector de voz o un magnificador de pantalla en el caso de los discapacitados visuales, que les permiten interpretar el texto que se muestra en la pantalla.
La accesibilidad corresponde a una de las tendencias que se ha impuesto con mucha fuerza en los últimos dos años, gracias especialmente a los avances conseguidos en los sitios del Gobierno de Estados Unidos (país que promulgó la Act 508 para reglamentar esta forma de mostrar los contenidos).
Esta tendencia se ha asociado mundialmente a la actividad de los sitios web de Gobierno Electrónico, debido a que, por el hecho de pertenecer a instituciones públicas, deben asegurarse de que todos los ciudadanos accedan a la información que se les ofrece por esta vía, sin que existan barreras para ello.
Para comprobar que un Sitio Web cumple con las normas de accesibilidad, la iniciativa WAI (Web Accesibility Initiative) de la W3C (World Wide Web Consortium) propone la realización de las siguientes pruebas:
• Verificar la accesibilidad con herramientas automáticas y revisión humana. Los métodos automáticos son generalmente rápidos y convenientes, pero no pueden identificar todos los problemas de accesibilidad. La revisión humana puede ayudar a garantizar la claridad del lenguaje y la facilidad de navegación.
• Utilizar los métodos de validación desde las primeras etapas del desarrollo. Los problemas de accesibilidad que se identifican temprano son fáciles de corregir y de evitar. Entre dichos métodos de validación, se cuentan los siguientes:
• Utilizar una herramienta automatizada de validación de la accesibilidad y la navegación. Se debe tener en cuenta que las herramientas o programas de revisión no contemplan todos los problemas de accesibilidad, como lo comprensible que puede ser un enlace de texto, o el contenido de un texto alterno, etc.
• Validar la sintaxis de programación de las páginas con las herramientas ofrecidas por el W3c; de esta manera se determinará si se utiliza apropiadamente el lenguaje que se haya elegido (Ej., HTML, XML, etc.).
• Validar las hojas de estilo (Ej., CSS).
• Utilizar un emulador o navegador solo-texto.
– Utilizar varios navegadores gráficos, con:
– sonidos y gráficos cargados – gráficos no cargados – sonidos no cargados – sin mouse – marcos, scripts, hojas de estilo, y applets sin cargar.
• Utilizar varios navegadores, antiguos y nuevos.
• Utilizar un navegador con conversión texto-voz, un lector de pantalla, un programa de magnificación, una pantalla pequeña, etc. Varios de esos software se pueden obtener desde el Sitio Web de Fonadis (http://www.fonadis.cl/ index.php?seccion=25) • Utilizar un revisor gramatical y ortográfico. Una persona que lee una página con un sintetizador de voz puede no ser capaz de descifrar la pronunciación que emite ese dispositivo de una palabra que tiene un error ortográfico. Eliminando los problemas gramaticales se aumenta la comprensión.
• Revisar el documento en cuanto a su claridad y simplicidad. Las estadísticas de legibilidad, como las que generan algunos procesadores de texto, pueden ser útiles indicadores de la claridad y simplicidad. Mejor aún, consulte con un editor (humano) experimentado para revisar el contenido escrito en cuanto a su claridad. Los editores pueden también mejorar la usabilidad de los documentos, al identificar problemas potenciales de sensibilidad cultural que pueden presentarse, debido al uso del lenguaje o de los iconos.
• Invitar a personas con discapacidad a revisar los documentos. Los usuarios con discapacidad, noveles o expertos, proporcionan valiosa información sobre la existencia de problemas de accesibilidad o usabilidad y la seriedad de la falla.
Más información del tema en:
• W3c.org: http://www.w3.org/TR/WAI-WEBCONTENT/ • Sidar.org (España): http://www.sidar.org/recur/desdi/wai/index.php • Fonadis (Chile): http://www.fonadis.cl/index.php?seccion=25 Buenas Prácticas Las buenas prácticas en el tema de la accesibilidad consisten en aplicar las «Directrices o Pautas de Accesibilidad para el Contenido de la Web», a través de las cuales es posible garantizar que se están cumpliendo las normas correspondientes, las cuales se explican en los siguientes títulos.
> Estándares Técnicos Recomendados Las normas a cumplir para conseguir la Accesibilidad de un sitio, y por lo tanto atender a este tipo de audiencias, están separadas en tres áreas a las que se les asigna diferente nivel de Prioridad. Estas son consecutivas y pueden certificarse individualmente.
Prioridad 1:
los puntos de verificación de esta prioridad tienen que ser satisfechos, porque, de lo contrario, uno o más grupos de usuarios encontrarán imposible acceder a la información del documento. Satisfacer este punto de verificación es un requerimiento básico para que algunos grupos puedan usar estos documentos Web.
Prioridad 2:
los puntos de verificación de esta prioridad deben ser satisfechos, porque, de lo contrario, uno o más grupos tendrán dificultades en el acceso a la información del documento. Satisfacer este punto de verificación eliminará importantes barreras de acceso a los documentos Web.
Prioridad 3:
los puntos de verificación de esta prioridad pueden ser satisfechos, porque, de lo contrario, uno o más grupos de usuarios encontrarán alguna dificultad para acceder a la información del documento. Satisfacer este punto de verificación mejorará la accesibilidad de los documentos Web.
Como se ve en la descripción anterior, cada una de las prioridades lleva asociado un tipo de obligación, siendo la primera la más perentoria de todas.
Para revisar los elementos contenidos en cada una de las Prioridades, ver Anexo I – Estándares técnicos de Accesibilidad.
> Estándares Internacionales Con el fin de validar el cumplimiento de los estándares internacionales de accesibilidad reseñados previamente, en Internet existe una serie de sitios que permiten validar el cumplimiento de éstos. Dentro de ellos recomendamos usar los siguientes:
Bobby Es un revisor de accesibilidad desarrollado por el Centro de Tecnología Especial Aplicada (Center for Applied Special Technology – CAST), ejecuta un test automático «on-line» de muchos de los puntos de verificación que forman parte de las «Pautas de Accesibilidad al Contenido en la Web 1.0». Visitar en http:// bobby.watchfire.com/bobby/html/en/index.jsp TAW Es la primera herramienta de verificación de la accesibilidad de las páginas Web en castellano. Se trata del Test de Accesibilidad a la Web TAW, desarrollado por el Fondo Formación Asturias para el Centro Estatal de Autonomía Personal y Ayudas Técnica (CEAPAT) del Instituto de Migraciones y Servicios Sociales (IMSERSO) de España. Visitar en http://www.tawdis.net.
Diseño de la Experiencia del Usuario En forma paralela al desarrollo de las interfaces, todo proyecto web debe tener en cuenta la experiencia que vivirá el usuario al navegar por sus páginas. A ese concepto se le denomina «experiencia» del usuario y el objetivo siempre será el de que cada persona que visite el sitio encuentre lo que está buscando de manera simple, de tal manera que regrese al sitio y le cuente a otros sobre su contenido y funcionalidades.
Para conseguir lo anterior, es necesario hacer un trabajo muy acabado en lo que se refiere a la planificación y organización de los contenidos, como también definir cómo se van a mostrar y operar las funcionalidades. Sólo de esa manera habrá certeza de las operaciones que se pueden realizar en el sitio y los efectos administrativos que ello generará en la institución.
> Desarrollo de Diagrama de Interacción Una de las metodologías más concretas para asegurar que la experiencia del usuario se está resguardando adecuadamente, es la generación los «diagramas de interacción» mediante los cuales se representan gráficamente las posibilidades de acción que tiene un usuario enfrentado a tomar una decisión en un Sitio Web.
Por ejemplo, el siguiente diagrama muestra las posibilidades de reacción que tiene un Sitio Web ante el ingreso de un usuario registrado en un sitio:
Como se puede apreciar, aparecen muy bien definidas en este esquema las acciones que pueda realizar un usuario que accede a un sitio y la forma en que el sistema reaccionará ante su presencia. Lo anterior conduce a preocuparse de manera concreta de las pantallas a desarrollar y los elementos que hacen falta para atender adecuadamente a dicho usuario.
De allí que la existencia de estos diagramas, acompañados de las respectivas pantallas mediante las cuales se pueda describir gráficamente lo que se espera que ocurra en un sitio, son herramientas muy valiosas al momento de desarrollar los elementos de interacción que se pretende abordar en un sitio.
> Principales Actividades a Desarrollar en el Sitio Es importante considerar que de acuerdo al Instructivo Presidencial de Gobierno Electrónico (2001), los sitios tienen un ciclo de vida que va enfatizando en su interactividad, de acuerdo al siguiente desglose:
• Presencia: en esta fase se provee básicamente información del Servicio al ciudadano.
• Interacción: considera comunicaciones simples entre el Servicio y el ciudadano y la incorporación de esquemas de búsqueda básicas.
• Transacción: incluye provisión de transacciones electrónicas al ciudadano por parte del Servicio, en forma alternativa a la atención presencial en las dependencias del órgano.
• Transformación: considera cambios en los Servicios para proveer aquellas prestaciones que componen su misión crítica en forma electrónica, y la introducción de aplicaciones que administran la entrega de prestaciones a los ciudadanos.
Lo anterior implica que cada Sitio Web que desee avanzar en su vida útil, como parte de la política de Gobierno Electrónico, tiene que ofrecer capacidades de interacción que sean cada vez más importantes para el grupo de usuarios hacia los cuales se dirige.
En este sentido, los sitios web deben ir incrementando su complejidad para ir haciéndose cargo de las necesidades de comunicación primero, y luego de las de atención, con el fin de brindar a los usuarios la posibilidad de eliminar etapas burocráticas en su relación con los servicios.
Las etapas que pueden ir marcando el avance de un Sitio Web podrían ser las siguientes:
• Comunicaciones: corresponde al estado de «Presencia» y consiste en que el sitio ofrezca la posibilidad de que los usuarios envíen correos electrónicos desde el sitio; al principio, con el uso del software de correo que tenga el computador; posteriormente desde formularios del sitio; finalmente, conectando los formularios con algún sistema de gestión para hacer seguimiento a las respuestas que se envíen a los usuarios.
• Trámites: corresponde al estado de «Interacción» y consiste en que el sitio ofrezca la posibilidad de que los usuarios puedan obtener información y realizar trámites del servicio a través del computador; al principio, recibiendo sólo información para hacer los trámites; finalmente, con la realización de la transacción mediante el sistema.
• Compras y Pagos: corresponde al estado de «Transacción» y consiste en que el sitio cumpla actividades transaccionales, que permitan a los ciudadanos ahorrar tiempo y dinero para realizar acciones ante los servicios.
Dado lo anterior, los sitios web de las instituciones públicas deben tener metas muy concretas a desarrollar en sus planes de trabajo anuales y esto debe estar expresado en el presupuesto de la institución, de tal manera que cuenten con los recursos necesarios para llevarlos adelante y darle sustentabilidad a la vida del proyecto.
> Pruebas de Sistemas e Interfaces Cuando se han generado las interfaces de un Sitio Web y antes de hacer la puesta en marcha del mismo, es muy conveniente hacer una serie de pruebas que permita asegurarse, antes de la construcción del código, que los usuarios van a entender la forma en que está organizada la información y los contenidos y funcionalidades que se están ofreciendo a través del Sitio Web. Para ello, se cuenta con dos tipos de prueba, que se describen a continuación y que son:
• Pruebas Heurísticas: consisten en análisis hechos por expertos respecto de las pantallas que se están ofreciendo en el sitio.
• Pruebas de Usabilidad: revisan una serie de factores con el fin de establecer si cumplen con las necesidades de los usuarios del sitio.
Con esta información, es posible rehacer partes del sitio antes de la construcción o desarrollo de las piezas de software que lo integran, facilitando de esa forma la siguiente etapa de trabajo.
Pruebas Heurísticas Originalmente desarrolladas por Jakob Nielsen (http://www.useit.com/), las diez pruebas que se incluyen dentro de la heurística han sido aplicadas universalmente y se entienden como el conjunto más adecuado para medir las características de un Sitio Web.
La pauta de evaluación es la siguiente:
• Visibilidad del estado del sistema: la prueba mide si el usuario siempre sabe qué está haciendo el sistema. Se revisa si existen los diferentes elementos que ayudan a esto:
– Indicación gráfica de donde se encuentra (ruta de acceso desde portada) – Indicación de que ha visto (marcar los enlaces visitados) – Indicción de que hay un proceso en marcha (anunciando estado de avance…) – Indicación de cuántos pasos faltan para terminar (como en el caso de que ya a un proceso de registro en el Sitio Web) • Similitud entre el sistema y el mundo real: la prueba mide si el sitio se expresa de una manera comprensible para el usuario. Para ello se revisa si se emplean las convenciones habituales y que le permiten operar en el Sitio Web.
• Control y libertad del usuario: la prueba mide si los usuarios que se equivocan al hacer algo tienen forma de recuperarse de esos errores. Se revisa si existen formas de hacerlo. Por ejemplo: ¿Se puede deshacer una operación? ¿Se puede rehacer una operación? • Consistencia y cumplimiento de estándares: la prueba mide si se cumplen los estándares que se usan en la Internet en el Sitio Web. Para ello se debe validar y revisar el sitio con las herramientas que se ofrecen en http://www.w3c.org para HTML y CSS.
• Prevención de errores: la prueba permite validar si se cuenta con mecanismos que aseguren que el ingreso de cualquier información, por parte del usuario, permite evitarle errores. Para ello, se verifica si en las áreas en que los usuarios deben interactuar con el sistema, se les explica claramente lo que se espera de ellos. Por ejemplo:
– Uso de Javascript para validar formularios: para que todos los campos obligatorios sean llenados, para que el número de RUT sea ingresado correctamente, etc.
– Uso de elementos destacados en los formularios: indicar los campos obligatorios con asteriscos (*) o, bien, campos obligatorios marcados con color.
• Preferencia al reconocimiento que a la memorización: la prueba permite revisar si el Sitio Web ayuda al usuario a recordar cómo se hacía una operación, o bien le obliga a aprenderse los pasos cada vez que ingresa. Para conseguir este objetivo se verifica la existencia de una línea gráfica uniforme en todo el Sitio Web (mediante la cual el usuario entiende lo que se le ofrece con sólo mirarlos) y si se cuenta con un sistema de navegación coherente.
• Flexibilidad y eficiencia de uso: la prueba permite revisar si se ofrecen soluciones diferentes de acceso a los contenidos, a los usuarios novatos respecto de los expertos. Por ejemplo, se puede contar con botones para los primeros y atajos de teclado para el experto. También es importante medir en esta prueba la carga rápida de los sitios mediante una buena construcción del código.
• Estética y diseño minimalista: la prueba pide que los elementos que se ofrezcan en la pantalla tengan una buena razón para estar presentes. Se verifica la existencia de elementos irrelevantes (texto, sonido e imagen), que no aportan ni ayudan a que el usuario distinga lo importante de lo superfluo. Para ello se verifica la existencia de:
– Jerarquías visuales: que permiten determinar lo importante con una sola mirada.
– Tamaño de imágenes: que no afectan la visión general de la información del Sitio Web; se verifica tanto tamaño como peso.
• Ayuda ante errores: se verifica que el usuario sepa cómo enfrentar problemas en una página tanto online como offline; entre los elementos que se miden se cuentan:
– Mensaje 404 personalizado, con el fin de ofrecer una información y navegación alternativa cuando una página no es encontrada.
– Mensaje de falla ofrece una alternativa offline (teléfono, mesa de ayuda) que permite que el usuario mantenga su confianza en la institución.
• Ayuda y documentación: se revisa que el Sitio Web ofrezca ayuda relevante de acuerdo al lugar en que el usuario esté visitando; también se revisa la existencia de sistemas de búsqueda que permiten al usuario encontrar los elementos de ayuda que sean relevantes de ofrecer (preguntas frecuentes; páginas de ayuda).
Pruebas de Usabilidad Se trata de pruebas efectuadas con usuarios, con el objetivo de determinar si la organización de los contenidos y las funcionalidades que se ofrecen desde el Sitio Web son entendidas y utilizadas por los usuarios de manera simple y directa.
Las pruebas tradicionales son:
• Prueba Inicial: para ver cómo funciona la organización de contenidos y elementos iniciales de diseño (botones, interfaces). El material con que se prueba es una imagen dibujada del Sitio Web.
• Prueba de Boceto Web: para ver si se entiende la navegación, si se pueden cumplir tareas y si el usuario entiende todos los elementos que se le ofrecen. El material con que se prueba es una maqueta web semi funcional En ambos casos la prueba consiste en mostrar a un grupo de personas el Sitio Web y hacerles preguntas sobre lo que ellos imaginan existe allí. Hay que recordar que en esta etapa del desarrollo las funcionalidades no existen como tales, aunque están definidas. Por lo mismo, todo el trabajo tiene que ver con los aspectos visuales y de organización de los contenidos.
Los resultados de cada una de esas etapas permitirán adecuar los elementos con los que se esté trabajando en esos momentos, con el fin de atender a los usuarios y ofrecerles una experiencia a la altura de sus expectativas.
Es importante enfatizar en estas pruebas, ya que generan insumos que serán muy útiles y permitirán darse cuenta a tiempo de errores conceptuales en la entrega de la información, que puedan ser remediados de manera temprana y sin afectar el desarrollo total del proyecto.
Cómo Atender a los Usuarios Dado que la interacción y la comunicación de los usuarios a través del Sitio Web de la institución están entre los objetivos más importantes de un Sitio Web del Gobierno, se ha diseñado esta sección para tratar directamente el tema.
En ese sentido hay que indicar que la tecnología web está orientada a generar niveles de comunicación muy avanzados, de los cuales se espera respuestas rápidas e interacción permanente. Se puede indicar incluso que el uso del computador permite establecer nuevas formas de atender la relación entre personas.
Por lo anterior, es importante reconocer los diversos sistemas que puede utilizar un Sitio Web para recibir «feedback» o retroalimentación de parte del usuario, de las cuales nombramos a continuación las principales.
• Sistemas de Correo Electrónico • Sistemas de Encuestas o Votaciones • Sistemas de Foros • Sistemas de Chat • Sistemas de Simulación Es importante considerar que cada uno de ellos genera más información y conocimiento de la audiencia que visita el Sitio Web, por lo que siempre será interesante ver cómo reaccionan a los temas que se les planteen y, asimismo, administrar positivamente el mayor flujo de trabajo que pueden generar en un Sitio Web muy participativo.
> Sistemas para Generar Feedback Como se planteó antes, un Sitio Web tiene diversos sistemas para recibir feedback o retroalimentación de parte del usuario, entre los que destacamos:
• Sistemas de Correo Electrónico: permite enviar mensajes a los encargados del sitio sobre temas puntuales. La premisa básica es que todo correo que llegue a la institución debe ser respondido adecuadamente y en el menor plazo posible, evitándose sólo las respuestas automáticas. En estos sistemas se debe asegurar el funcionamiento de los servidores de correo electrónico asociado, con el fin de que los mensajes sean enviados exitosamente.
• Sistemas de Encuestas o Votaciones: permite hacer sondeos rápidos entre los usuarios del sitio acerca de temas simples. En el caso de este sistema, la validación obligatoria que requiere debe permitir que los usuarios voten sólo una vez; que la pregunta y sus respuestas no contravengan disposiciones legales ni que generen una controversia, dado el carácter público del sitio. Asimismo se debe aclarar que las respuestas sólo representan a quienes participaron y no tienen validez estadística.
• Sistemas de Foros: permite a los usuarios entregar opiniones sobre temas concretos en modo asincrónico. En el caso de este sistema se debe tener especial cuidado con los contenidos que generen los usuarios, puesto que en muchos casos el uso de interfaces computacionales relajan la responsabilidad de quienes escriben en lo referido a formas de expresarse y contenidos vertidos en este tipo de programas. Se aconseja, por lo mismo, mantener un seguimiento constante de las expresiones registradas en el sistema, recomendándose en todo caso el uso de software de foros que permitan moderar el contenido e impidan la publicación de imágenes.
• Sistemas de Chat: permite establecer conversaciones escritas en tiempo real con otros usuarios o con los encargados del sitio. En el caso de este sistema se debe cuidar la generación de contenidos por parte de los usuarios, porque tal como en el caso de los Foros se puede llegar a hacer un mal uso de este tipo de sistemas. En el caso de los chats, se aconseja utilizar las herramientas que ofrece este tipo de sistemas para evitar la participación de usuarios que tengan malos hábitos de comunicación. Asimismo se recomienda su uso para Mesas de Ayuda que permitan apoyar a los usuarios de modo directo mientras visitan el sitio.
• Sistemas de Simulación: permite entender los escenarios que se pueden dar ante determinadas situaciones, sin necesidad de acceder a ellos. Habitualmente este tipo de sistemas es agregado a los Sitios Web como aplicaciones especiales, por lo que sólo se debe asegurar su correcta operación funcional.
• Sistemas de Búsqueda: estos sistemas proveen una forma interesante de obtener feedback de los usuarios. Al incorporar mecanismos de bitácora para las búsquedas que hacen en el Sitio Web (en la medida que se cuente con un sistema buscador), se irá registrando lo que ellos andan buscando; al revisar en forma periódica y obtener estadísticas de uso del sistema, se podrá avanzar en comprender las necesidades del usuario y de esa manera enfatizar en la información más buscada por ellos. Adicionalmente, el control de búsquedas fallidas a su vez permite identificar ya sea errores de organización de contenidos o, simplemente, detectar el tipo de información que el usuario espera encontrar en el sitio.
> Formularios del Sitio En la creación de los formularios para la generación de comunicaciones del Sitio Web, es muy relevante cumplir con ciertas prácticas de usabilidad, que hagan más sencilla la operación de los formularios. Como ejemplos de buenas prácticas podemos mencionar:
• Validación del RUT: se refiere a incorporar la programación adecuada para que se valide inmediatamente el ingreso del Rol Único Tributario, de tal manera que tras escribir los datos en el campo el usuario pueda saber si está bien o no ingresado.
• Validación de campos obligatorios: se refiere a que todos los campos en que sea obligatorio poner datos (que no serán todos los de formularios), estén marcados de alguna forma (puede ser un asterisco o señalar esos campos con un color diferente) de tal manera que los usuarios cumplan con ingresar los datos correspondientes. Adicionalmente, al pulsar el botón de acción al final del formulario, se debe indicar un alerta si llegaran a faltar datos de ese tipo.
• Validación del e-mail: se refiere a usar la programación adecuada para validar que los datos que se ingresen en este campo, cumpla con la formalidad de estructura de un correo electrónico (existencia del signo @ por ejemplo).
• Valores por omisión: se refiere a que si hay campos con menú drop-down para elegir una, entre muchas opciones, siempre se ponga en el primer lugar aquella que vaya a ser la más usada. Por ejemplo, si es el campo País, el primer registro debe ser para Chile.
• Ejemplos de ingreso de contenidos: se refiere a que, al lado de donde el usuario deba ingresar la información, debe aparecer escrita la forma en que se debe hacerse.
Por ejemplo, al lado del campo RUT escribir un número de ejemplo, para que el usuario sepa si debe escribirlo con puntos y guión, sin puntos y guión o sin puntos ni guión.
• Claridad de botones: los botones de acción al final de los formularios deben tener una palabra clara, que no deje lugar a dudas sobre la acción a realizar. Si es un formulario para Enviar información, debería tener la palabra «Enviar». Si es para suscribirse a un servicio, deber decir «Suscribirse». Asimismo, si se pone un botón para borrar el formulario, debe quedar clara su función con un texto adecuado que indique esa acción. Se debe indicar «Borrar Formulario» y evitar palabras ambiguas para esta función, tales como «Limpiar», «Cancelar», «Eliminar» o similares.
> Boletines de Noticias y Novedades Cuando se empleen sistemas de suscripción a boletines de noticias o difusión de novedades, se debe dejar muy clara cuál será la política de suscripción, envío y eliminación de la base de datos de nombres.
En este sentido, hay que poner siempre cerca de los formularios de suscripción un enlace a la Política de Privacidad en la que se deje clara la información relativa a como realizar esas acciones.
Hay que recordar que el artículo 12 de la Ley N° 19.628, del 28 de agosto de 1999, «Sobre Protección de la Vida Privada» plantea las obligaciones que existen para quienes guarden datos de terceros.
En el inciso tercero del artículo 12 se refiere al envío de e- mails y al derecho de cualquier persona de ser eliminado de una base de datos. Indica: «Igual exigencia de eliminación, o la de bloqueo de los datos, en su caso, podrá hacer cuando haya proporcionado voluntariamente sus datos personales o ellos se usen para comunicaciones comerciales y no desee continuar figurando en el registro respectivo, sea de modo definitivo o temporal».
Ver texto de la Ley N° 19.628
Protección de Datos Personales
www.sernac.cl/derechos/pdf/Ley19628.pdf
> Sistemas para Recibir y Administrar Mensajes de Usuarios Cuando se generan sistemas para que los usuarios envíen información, es imprescindible que exista un procedimiento administrativo que le dé tanta validez a un mensaje enviado por esta vía, respecto de otro enviado por una vía tradicional (carta, fax, etc.).
Adicionalmente hay que recordar que la ley de Silencio Administrativo (Ley N° 19.880) requiere que se dé respuesta a determinadas presentaciones en plazos concretos, con el objetivo de acelerar procesos.
Para ello, una buena práctica sería contar con un sistema de seguimiento de mensajes, que permita ir registrando las comunicaciones que llegan desde los formularios de contacto y ayuda del sitio en Internet. En éste se pueden asignar los siguientes estados a dichos mensajes, de acuerdo a la tramitación que se le otorgue:
• Estado Pendiente: lo tiene todo mensaje que llegue al sitio y para el que sólo se haya enviado una respuesta de Acuse de recibo.
• Estado En trámite: cuando se deriva el mensaje a terceros en busca de la respuesta en alguna repartición de la institución.
• Estado Respondido: cuando se envía la información solicitada al usuario final.
• Estado Archivado: estado final para permitir el manejo de grandes cantidades de información.
Es importante considerar que para hacer este tipo de seguimiento no se requiere necesariamente un sistema computacional, puesto que también se puede hacer con los recursos tradicionales y una buena organización.
En el siguiente diagrama se puede ver un escenario posible de manejo o flujo de actividad en torno a un mensaje electrónico por parte de una Oficina de Informaciones, Reclamos y Sugerencias (OIRS).
Como se puede apreciar, la generación de este tipo de gráficas permite revisar todos los estados posibles y asignar las responsabilidades que correspondan a cada una de las áreas de trabajo involucradas.
A continuación se revisa la actividad posible con cada una de las áreas de la institución que atienden público:
Oficina de Información, Reclamos y Sugerencias (OIRS) Debe hacer la recepción, mantención y seguimiento de todas las comunicaciones que lleguen por el Sitio Web, asignándole a cada una de ellas el mismo valor que un mensaje llegado en formato tradicional. Su preocupación debe ir desde la recepción a la respuesta, por lo que, de contar con un sistema de gestión como el indicado en títulos anteriores, debería ser su responsabilidad la operación del mismo.
Se sugiere incluso que cualquier mensaje de correo electrónico, que llegue por otra vía distinta a los formularios del sitio, pueda ser atendido por esta oficina para contar con un único punto de acceso y salida.
Oficina de Partes Al igual que la OIRS debe hacer la recepción, mantención y seguimiento de todas las comunicaciones que lleguen por vías tradicionales y apoyar el trabajo de la OIRS. Tradicionalmente en estas oficinas se concentra un gran conocimiento de la institución, por lo que será vital su apoyo en la derivación de comunicaciones y en la atención de mensajes.
Área de Comunicaciones El área de Comunicaciones debe mantener el discurso público de la institución, por lo que es importante que pueda entregar a la OIRS la información adecuada de cómo atender y responder a las consultas que lleguen, validar los formatos de respuesta y opinar cuando la respuesta esté relacionada con su propia área.
Área de Informática El área de Informática debe ser un facilitador tecnológico para la OIRS como para cualquier componente del equipo que tiene a cargo el desarrollo del Sitio Web, de manera que siempre reciban información adecuada y a tiempo.
Es necesario que el Área de Informática esté coordinada y pueda actuar permanentemente coordinada como contraparte técnica de cualquier proyecto de este tipo.
4 Capítulo IV
Puesta en marcha del sitio web
Resumen En este capítulo se revisan los pasos que se deben dar al terminar el desarrollo de un Sitio Web y efectuar su presentación a los usuarios, incluyendo desde criterios técnicos para hacer pruebas sobre el sitio construido, hasta la forma de efectuar la comunicación de sus características, para dar a conocer a la comunidad el trabajo realizado.
Desarrollo de un Plan de Pruebas Una vez que el sitio se ha construido, es necesario hacerlo pasar por una serie de pruebas antes de y entrar a la fase de producción. Mediante dichas pruebas, se medirá su reacción integral frente a diversas acciones que realizarán los usuarios desde sus páginas.
Entre otros aspectos será necesario probar el desempeño computacional de la plataforma tecnológica usada; seguridad ante intentos de ataque y exactitud; corrección de su contenido y su despliegue en los diferentes programas visualizadores, entre otros aspectos.
Errores en la Etapa de Pruebas Antes de entrar de lleno en el capítulo, se debe hacer una prevención inicial sobre el funcionamiento de los sistemas y sus características, en la etapa que va entre el fin del desarrollo y el comienzo de su uso.
En este sentido, hay que anotar que los errores serán de común ocurrencia y no situaciones aisladas, por lo que hay que utilizar diversas metodologías para llevar un recuento de ellos y hacer un seguimiento ordenado de la forma en que son abordados y corregidos.
Si la metodología de desarrollo ha sido bien aplicada, en esta etapa podrían ocurrir problemas con el funcionamiento de las aplicaciones por diversas condiciones de borde (tipo de programa visualizador usado, enlaces no encontrados, etc.), pero no deberían producirse problemas relacionados con que el sistema ejecute acciones diferentes a las que se hubieran solicitado a través de sus formularios, sistemas de búsqueda u otros.
Para evitar lo anterior, es muy importante la precisión de las descripciones que se realizan en los Términos de Referencia, a los cuales se hace referencia en el Capítulo 1.
Dado que los errores serán comunes, se debe preparar a los usuarios que harán las pruebas para este tipo de ambiente, explicándoles que las situaciones de error en esta etapa serán lo normal y que gradualmente éstas irán desapareciendo para dar lugar al funcionamiento normal de las aplicaciones probadas. Pero, lo relevante en este caso, será hacerles hincapié en la necesidad de que ellos vayan registrando e informando adecuadamente sus hallazgos, con el fin de contribuir al proceso de corrección de los errores.
Cómo y Qué Probar Con el fin de probar las diferentes capacidades de un Sitio Web, es necesario dividir el trabajo en cinco áreas, que son:
• Pruebas de Interfaces y Contenidos • Pruebas de Funcionalidades y Operación • Pruebas de Carga • Pruebas de Seguridad • Pruebas de Respaldo y Recuperación Por cada una de ellas hay actividades específicas a realizar, de las cuales se entrega un detalle a continuación.
> Pruebas de Interfaces y Contenidos Las actividades de esta etapa consisten en hacer revisiones precisas de la forma en que se despliegan las páginas del sitio y ver si cumplen con los «Términos de Referencia» en estos temas y, además, si cumplen con los estándares mínimos que se hayan definido como meta a ser cumplida (ver Capítulo 3, sobre Usabilidad y Accesibilidad).
Las acciones de prueba sugeridas para realizar en esta etapa son las siguientes:
• Verificación de Contenidos: es una prueba básica para revisar si el Sitio Web desarrollado incluye todos los contenidos que se han especificado en los «Términos de Referencia» o los que se hayan definido en el marco del plan de desarrollo. Se puede hacer en forma manual o automática, de acuerdo a las siguientes orientaciones:
• Sistema Manual: se refiere a hacer una revisión manual de los contenidos del Sitio Web a través de la navegación de sus páginas. Para ello se recomienda primero construir un índice de contenidos y luego verificar la existencia de cada uno de los ítemes que contiene, a través de hacer un recorrido exhaustivo del sitio. Los elementos que deben probarse obligatoriamente son:
• Verificación de ortografía y redacción • Verificación de enlaces principales • Verificación de imágenes en páginas • Verificación de existencia de Archivos adjuntos • Verificación de la Lista de Chequeo de Accesibilidad (ver Capítulo3) • Sistema Automático: especialmente orientado a la verificación de enlaces rotos, lo cual se puede hacer utilizando sistemas basados en Internet o, bien, software especializado.
• Sistemas Basados en Internet: se recomienda usar el servicio del W3C «Check Link» (http://validator.w3.org/checklink); • Software: se recomienda bajar y usar desde su computador el software gratuito Xenu (http://home.snafu.de/tilman/xenulink.html). De igual manera, los actuales software de creación de sitios WEB permiten manejar en forma controlada los enlaces internos; un error común de este tipo es que una foto se vea normalmente en el computador de desarrollo, pero no en el Sitio Web, Esto ocurre porque es referida en forma absoluta desde una ubicación en un disco duro local o en red, en lugar de un directorio de imágenes del Sitio Web.
Nota: se recomienda hacer estas pruebas en ambientes controlados diferentes a los usados para el desarrollo (diferentes redes y computadores), para que los resultados sean confiables.
• Sitio en Construcción: se debe verificar que el Sitio Web no contenga espacios vacíos o que tenga el título de «en construcción». No es adecuado, bajo ningún sentido, usar espacios con dicha leyenda; en tal caso es preferible eliminar esa zona y volver a incluirla cuando exista el contenido correspondiente en el sitio.
• Verificación de Meta Tags: los «meta tags» son marcas en lenguaje html que van en la parte superior de cada página, a través de las cuales se entrega a los sistemas de indexación y búsqueda (como Google, Yahoo! y otros), la información mínima que se debe tener en cuenta para hacer una correcta indexación del contenido que incluye. Los «meta tags» son elementos que obedecen a un estándar definido por el World Wide Web Consortium (http://www.w3c.org) por lo que su uso está regulado. Para verificar que dichas marcas cumplen con los elementos mínimos requeridos por los buscadores, existen herramientas en Internet que permiten hacer tal prueba y ofrecen recomendaciones para mejorar la información ingresada en dicha área. Se recomienda en ese sentido utilizar las aplicación existente en el Sitio Web SearchMechanics.com (http://www.searchmechanics.com/prepare/index.htm) que cuenta con una aplicación en idioma español para hacer dicha comprobación.
• Verificación de Estándares: aunque los sitios web pueden ser construidos a partir de diferentes lenguajes, todos deben cumplir ciertas normas de organización de su código fuente (sintaxis), que permitan su visualización por software equivalente en diferentes plataformas. Dicha sintaxis está estandarizada y puede ser probada a través de herramientas públicas que están disponibles en Internet. Las dos más importantes son:
• Validación de HTML: la realiza el World Wide Web Consortium (http://validator.w3.org) e indica si el código usado en la página es correcto. Como resultado entrega un reporte con los eventuales errores para ayudar a su reparación.
• Validación de CSS: la realiza el World Wide Web Consortium (http://jigsaw.w3.org/css- validator) e indica si la Hoja de Cascada de Estilo (Cascade Style Sheet) cumple con la sintaxis estándar y por lo tanto podrá ser visualizada correctamente en todos los sistemas.
• Verificaciones de Interfaces: mediante esta prueba se revisan aspectos gráficos del Sitio Web, para determinar si su despliegue en las páginas es correcto. Dentro de los elementos más importantes a ser verificados, se incluyen los siguientes:
• Plug-ins necesarios: cuando se utilicen elementos audiovisuales o interactivos que requieran de algún software incrustado para funcionar (plug-ins), se debe ofrecer un enlace para que los usuarios que no lo tengan instalado, puedan bajarlo y hacer el proceso de instalación. En el caso del uso de la tecnología Flash, las últimas actualizaciones del producto permiten que el software pueda ser bajado en forma automática por los programas visualizadores, si se cuenta con la codificación adecuada. Por lo anterior, es necesario hacer la prueba desde un computador que carezca de dicho software, para comprobar que efectivamente hace dicha operación.
• Consistencia de la Diagramación: cada una de las páginas del sitio debe tener elementos consistentes, con el fin de ofrecer al usuario una experiencia similar en cualquier área del Sitio Web; por nombrar sólo tres aspectos, lo anterior implica que los menús deben aparecer siempre en el mismo lugar; que los listados deben estar diseñados de similar manera en todo el sitio y que los colores y formas de uso de las interfaces deben ser similares a lo largo de las páginas.
• Ancho de la Diagramación: si la diagramación del sitio se ha realizado para un ancho determinado (por ejemplo, 800 pixeles de ancho), en esta etapa se debe probar si ello se cumple. Asimismo, se debe probar en una pantalla configurada con una menor dimensión (por ejemplo 640 x 480 pixeles), cuál es el área visible del sitio y cómo afecta eso a la navegación por el mismo. Otra prueba del mismo estilo, se refiere a usar un programa visualizador orientado sólo a texto como Lynx (http://www.delorie.com/web/ lynxview.html), para obtener visiones alternativas de la manera en que los usuarios están accediendo a la información que se les ofrece.
En este aspecto, en caso de existir, es de interés contar con un estudio del «log» del servidor que muestre la forma en que los usuarios están accediendo a las páginas, porque de esa manera se podrá determinar hacia qué configuración de pantalla se debe atender con mayor prioridad. La norma en este aspecto es que sin importar las características técnicas que tenga el computador del usuario que accede al Sitio Web, éste siempre se vea ordenado y legible.
• Diagramación vs. Browsers: aunque la codificación en los lenguajes soportados por los programas visualizadores (browsers) puede apegarse a los estándares, no todos muestran de la misma manera los sitios web. Dado esto, es necesario revisar el sitio en diferentes tipos de programas, especialmente en aquellos que conforman la minoría, al momento de escribir este Manual. Es decir, las pruebas al menos deberían hacerse en Microsoft Internet Explorer (http://www.microsoft.com/explorer), Opera (http://www.opera.com) y Mozilla (http://www.mozilla.org), ya que con ellos se cubrirá un amplio espectro. Lo que se debe revisar en este caso es el despliegue de todos los elementos que se muestran en la pantalla, para asegurar de que aparecen en las posiciones que se les han asignado en el diseño.
• Diagramación vs. Sistema Operativo: tal como se explicó en el caso anterior, los diferentes sistemas operativos pueden establecer diferencias en la forma en que se muestran los sitios web. Por ello, es importante conocer cuáles son los sistemas operativos utilizados por la audiencia a la que se desea llegar y revisar el despliegue del sitio en ellos. Hay que recordar que, además de Microsoft Windows, los usuarios pueden estar visualizando el sitio desde computadores equipados con Apple Macintosh o diferentes versiones del sistema operativos Unix.
• Imágenes Escaladas: se debe verificar que las imágenes que aparezcan en el sitio no estén siendo mostradas en tamaño reducido artificialmente; es decir, que se tome una imagen de grandes dimensiones y por programación se muestre en un tamaño menor. El efecto de eso es que las páginas con ese tipo de imágenes serán muy pesadas y harán que el acceso a ellas sea lento. Para comprobarlo, se debe solicitar las «Propiedades» de la imagen; en la ventana que se muestra se indica el peso de la imagen, que no debería sobrepasar los 5Kb para las de tamaño pequeño (iconos y thumbnails) y los 25 Kb, para los de tamaño mediano (fotografías en noticias). Es importante considerar que, además de estas verificaciones individuales de peso de imágenes, el límite de peso para una página es de 100Kb, incluyendo todos sus elementos.
• Imágenes Sin Atributo ALT: para cumplir con las normas de accesibilidad es necesario que todas las imágenes que se usen en un Sitio Web, tengan una descripción utilizando el atributo ALT (para texto alterno) del lenguaje HTML. Para comprobarlo, basta situar el mouse sobre una imagen, para que se despliegue una leyenda en texto en una etiqueta amarilla que flota sobre la foto; si eso no ocurre, el atributo no está siendo usado y debe ser corregido e incluido.
> Pruebas de Funcionalidades y Operación Las actividades de esta etapa se refieren a hacer chequeos completos respecto de las funcionalidades y aplicaciones que ofrece el sitio, ya sean de aplicaciones simples como formularios hasta más complejas, como consultas y modificaciones de registros en base de datos.
En este sentido, las pruebas se deben hacer sobre diferentes elementos, siendo algunos de los más importantes los siguientes:
• Validación de Formularios: si el Sitio Web tiene formularios para el envío o ingreso de datos, se debe utilizar sistemas de validación del ingreso de datos para asegurar que éstos sean bien ingresados. En este aspecto, algunas de las validaciones más importantes deben ser las siguientes:
• Campos Obligatorios: se debe validar que en los formularios sean ingresados todos aquellos campos que sean necesarios; éstos deben ser marcados de alguna manera (usualmente con un asterisco) que permita a los usuarios entender la obligatoriedad de ingresar información en ellos; adicionalmente, debe indicarse tal condición en forma explícita • Validaciones Locales: para reducir la carga de validaciones en el servidor, se recomienda incorporar la mayor cantidad de éstas en el computador del cliente, utilizando en forma estándar el lenguaje Javascript para hacerlas.
• Sintaxis de Ingreso: se debe validar que, en algunos casos, los campos sean ingresados con datos válidos; el mejor ejemplo es el caso del ingreso del número de RUT o Cédula de Identidad, cuyos números tienen un algoritmo conocido para ser validado.
• Suscripción a Servicios: se debe validar que cada vez que se realice la suscripción a un servicio que ofrezca el Sitio Web, se envíe un e-mail al usuario (para lo cual se debe necesariamente solicitar su dirección de correo electrónico) en el que se le informe sobre el resultado de lo realizado. Quien pruebe el sistema debe validar que el sistema esté enviando correctamente los e-mails y que dicho e-mail llegó a la dirección correspondiente; en este caso se recomienda probar con una dirección de recepción externa a la institución desde la cual se prueba.
• Ingreso de Datos: si se cuenta con un sistema que permita el ingreso de información hacia una base de datos, se debe revisar en la tabla de destino que efectivamente se estén enviando los datos de la manera que se ha previsto.
• Reingreso y Corrección de Datos: para mejorar la interacción del Sitio Web, cuando tras el ingreso y envío de los datos de un formulario (después de la validación local del formulario) el usuario presiona el botón «Back» de su programa visualizador para volver atrás y modificar algún campo, se le deben presentar todos los datos que hayan sido ingresados. De esta manera se aprovecha la información ingresada previamente, evitando la frustración del usuario por tener que escribir nuevamente el contenido completo del formulario.
• Elementos de Interfaz: al usar elementos del lenguaje HTML para la creación de las pantallas (input boxes, combo boxes, list boxes, radio y check buttons, etc.), se recomienda no modificar radicalmente sus atributos de despliegue (colores, formas) y comportamientos tradicionales, para lograr que el usuario sepa intuitivamente cómo usarlo y no deba aprender de nuevo su operación.
• Multiplataforma: se debe comprobar que los formularios funcionan en diferentes versiones de programas visualizadores (browsers), de sistemas operativos y de tipos de conexión a Internet (conmutado, banda ancha y dedicado).
• Botones de Interacción: si se cuenta con botones interactivos que permiten imprimir, enviar una página a un amigo, etc. se debe validar que estén realizando correctamente la acción indicada.
permitan encontrar documentos existentes en el sitio; en este sentido se deben ingresar documentos específicos y luego buscarlos de manera de asegurarse que la funcionalidad está operando adecuadamente. Si el sistema de búsqueda tiene una versión de «búsqueda avanzada», se debe asegurar de que las opciones ofrecidas encuentren los documentos de la manera en que se ofrezca. El formulario para hacer la búsqueda debe ser intuitivo, evitándose el lenguaje técnico y específico que impida entender su funcionamiento entre usuarios con menores conocimientos de los temas abordados en la institución.
• Sistemas de Feedback: si se cuenta con sistemas de envío de preguntas o reclamos (al estilo de los indicados para la Oficina de Informaciones, Reclamos y Sugerencias, OIRS), se debe asegurar de que se está completando el ciclo de vida de la consulta. En este sentido se debe validar que el sitio realiza la consulta y que ésta es recibida por el funcionario encargado de atenderla. De otra manera, la funcionalidad podría operar computacionalmente pero no en términos de tramitación.
• Sistemas de Compra: si se cuenta con sistemas de pago en línea, se debe revisar cuidadosamente el flujo de trabajo de la aplicación y asegurarse de que en cada uno de los pasos se está asegurando la calidad y seguridad de la transacción.
• Administración del Error 404: cuando se ingresa una dirección equivocada, el software del servidor web muestra una pantalla de error anunciando el número de código del problema (Error 404). No obstante, dicho software puede ser configurado para que muestre una página diferente, en la que se explique a los usuarios las probables razones del error. Es importante incluir, en dicha página, un enlace al Mapa del Sitio y un Buscador, de tal manera que el usuario tenga más herramientas para resolver la inexistencia del contenido que buscaba. Se recomienda, además, que el Administrador de Sistemas de la institución entregue un reporte semanal basado en los «logs» del servidor, que permita ver qué es lo que más buscan los usuarios y de qué manera el Sitio Web les está respondiendo sus consultas.
> Pruebas de Carga La carga de trabajo se refiere a la capacidad máxima que tiene un servidor web (hardware y software), para atender a un conjunto de usuarios de manera simultánea. Por ello, las actividades de esta etapa tienen relación con comprobar, de manera anticipada, el funcionamiento que tendrá el servidor del Sitio Web cuando esté en plena operación.
Las pruebas en este caso consisten en simular una carga de trabajo similar y superior a la que tendrá cuando el sitio esté funcionando, con el fin de detectar si el software instalado (programas y aplicaciones) cumple con los requerimientos de muchos usuarios simultáneos y también si el hardware (servidor y el equipamiento computacional de redes y enlace que lo conecta a Internet) es capaz de soportar la cantidad de visitas esperadas.
Es importante considerar que si el servidor está en las dependencias de un tercero que entrega el servicio de alojamiento del Sitio Web (hosting), se le debe solicitar a dicho proveedor un informe en que dé a conocer las características de carga de la solución de hardware y software sobre la cual funciona el Sitio Web de la institución.
Hay diversos software en el mercado que están orientados a este tipo de simulaciones, todos los cuales ofrecen características similares. Entre los datos más relevantes que es posible obtener se cuenta:
• Tiempo de acceso de los usuarios a los datos • Volumen de datos y ancho de banda utilizado • Archivos solicitados y tiempos usados en transferencia de datos • Tiempo de espera de los usuarios tras hacer un clic • Tiempo de respuesta a clicks de usuarios • Niveles de error existentes tras clicks de usuarios Como se puede apreciar del listado anterior, los reportes que se obtienen a través de esta vía se refieren a tiempos de acceso que tienen los usuarios que acceden al Sitio Web y la degradación que ocurre en los ser vicios cuando aumenta el volumen de visitantes concurrentes.
Un ejemplo de las pruebas que se pueden realizar en este tema se puede ver en este gráfico que muestra los tiempos que demora en atender los requerimientos por las direcciones solicitadas tras un click de usuarios.
Cada una de las líneas representa un valor importante de tener en cuenta:
Click time: demorad el sitio en entregar los datos tras el primer click.
Time to First Byte: tiempo que se demora tras el click, en enviar el primer byte de datos. Time to Connect: tiempo de demora tras enviar el click, en establecer la conexión entre servidor y cliente.
Time for DNS: tiempo de demora para resolver la dirección solicitada en el click.
sistemas, con el fin de hacer las optimizaciones que aparezcan como necesarias. Asimismo, se debe tener en cuenta que será normal la existencia de situaciones excepcionales que harán que los servicios no funcionen adecuadamente.
> Pruebas de Seguridad Las actividades que se pueden realizar para hacer las pruebas de seguridad son diversas y se orientan a varios ámbitos, como se describe a continuación. Los temas a tratar son los siguientes:
• Manejo de DNS • Protección de Estructura Interna del Sitio Web • Protección contra Robots • Manejo de Privacidad • Canales seguros • Mecanismos de Control de Acceso • Protección de Programas • Hosting vs. Sitio Propio • Roles Mínimos a asegurar A continuación se entrega información para cada uno de ellos.
Manejo de DNS Un aspecto que se debe cuidar es el de utilizar un nombre de dominio adecuado y relacionado con la identidad y misión de la institución. No obstante, gracias a la forma de operación del Domain Name Service (DNS o Servicio de Nombre de Dominio) es posible asignar más de un nombre de dominio a un mismo Sitio Web. De esta manera es posible incorporar otras denominaciones, bajo el dominio .CL u otro, que permitan generar «alias» adicionales para el sitio y así permitir utilizar las denominaciones más coloquiales con la cual la institución es conocida por los ciudadanos.
No obstante, sin importar cuántos alias tenga un sitio, se recomienda que todos los dominios sean redirigidos para que la primera pantalla, en cualquier caso, corresponda a la portada «oficial» del Sitio Web.
Recuerde que sobre los nombres de dominio existe una normativa obligatoria definida en el Oficio No. 485, del 10 de noviembre de 2000, en relación con el Decreto Supremo No. 5996, donde se especifica claramente que los sitios del Estado deben registrar su dominio bajo la denominación .GOB.CL y .GOV.CL. Adicionalmente pueden hacerlo bajo el dominio .CL en forma directa.
Dicha operación, en cuanto a procedimientos y alcance, está definida en su totalidad en el sitio http://nic.gob.cl y mayores referencias se pueden encontrar en http://nic.gob.cl/normativa.htm.
Protección de la Estructura Interna del Sitio Web Uno de los mecanismos que permite proteger la estructura interna del sitio (especialmente para casos de intentos de ataques externos y/o intentos de violación de confidencialidad), es disminuir la cantidad de información contenida en las URL que se muestran en el programa visualizador. Esto es importante respecto de directorios y nombres de programas, pero especialmente en lo que se refiere a la entrega de parámetros de sesión, datos de usuario u otro mecanismo de transferencia de información entre páginas y/o secciones de código.
Se recomienda que los mecanismos de traspaso de información entre páginas sea a nivel de objetos del servidor, asociados a la sesión, sin que la interacción con el lado cliente deba hacerse responsable de la transferencia de datos y/o información entre sesiones de ejecución del servidor.
De igual forma, se recomienda evitar que el acceso a elementos del servidor web esté asociado a «direccionamientos relativos por sesión» o asociados al UserId o SessionId; esto se debe a que mediante simples pasos se puede conocer «token» de sesión y gracias a eso simular que es el mismo usuario que regresa al sitio. Para evitar el problema se recomienda incorporar protecciones de dirección relativas a la Dirección IP de origen.
Otro método de protección de estructura interna consiste en deshabilitar (excepto para casos excepcionales, como repositorios públicos de archivos) la navegación sobre directorios mediante el servidor web. Esta protección se hace para todos los directorios desde la configuración del software del servidor web. Otra forma de hacerlo consiste en incorporar un archivo por omisión del servidor web en todos los directorios, aun cuando no sea directamente referenciado por otras páginas para que se muestre su contenido cuando un usuario intente revisar el contenido existente en el directorio. En el caso de habilitar la navegación sobre directorios, se debe evitar el acceso a ciertos directorios protegidos.
Junto con estas protecciones de lectura, se r ecomienda r ealizar periódicamente una revisión de los esquemas de permisos otorgados a directorios y archivos. Las permanentes actualizaciones del software de un servidor web, generalmente provocan un problema de control del acceso a nivel de archivos, lo cual requiere procedimientos claros de supervisión.
Protección Contra «Robots» No todos los directorios del sitio deben estar disponibles para que los robots de búsqueda (conocidos más popularmente como «arañas» o «spiders» de los buscadores) entren en ellos. Para impedirlo, se debe utilizar el archivo «robots.txt» o las instrucciones específicas en los «meta-tags» de la página de inicio, para impedir su ingreso.
El archivo «robots.txt» es un archivo de texto plano (no de html) ubicado en directorios el servidor web que contiene instrucciones precisas respecto de qué hacer en ellos. Cada vez que un robot visita un sitio, primero revisa si existe ese archivo.
Si no lo encuentra, indexa la página en el sistema buscador que lo haya enviado; si lo encuentra, analiza su contenido buscando la siguiente información:
User-agent: * disallow: / La primera línea «User-agent» indica que es válida para todos los robots que lleguen (porque tiene un asterisco; puede restringirse a un robot, indicando su nombre), mientras que la segunda indica con «disallow» que no está permitido avanzar por los enlaces de la página al uras % hace referencia a la raíz del sitio.
En otro caso, si se quiere evitar el acceso de todos los robots a un directorio determinado (por ejemplo cgi-bin, donde están los archivos más sensibles), se puede indicar esa información de la siguiente manera:
User-agent: * disallow: /cgi-bin/ Adicionalmente se puede usar el commando «allow» que permite incluir directorios específicos, gracias a lo cual ciertos contenidos sí son indexados. Por ejemplo:
User-agent: * disallow: /imagenes/ allow: /imagenes/logotipo-institucion.jpg En este caso la segunda línea indica con «disallow» que no está permitido ingresar al directorio de Imágenes, pero que sí se puede indexar un archivo específico, que corresponde al Logotipo institucional.
Otra forma de impedir el acceso de un robot es poniendo marcadores específicos en los «meta-tags» de las páginas. No obstante, este mecanismo no es soportado por todos los robots, por lo que su alcance es más limitado.
La forma precisa de incluir dicho «meta-tag» es la siguiente:
…Las cuatro posibles combinaciones de este «meta-tag» son las siguientes:
• – Indica que la página puede ser indexada y sus enlaces seguidos • – Indica que la página puede ser indexada, pero sus enlaces no pueden ser seguidos • – Indica que la página no puede ser indexada, pero sus enlaces pueden ser seguidos • – I ndica que la página no puede ser indexada ni sus enlaces seguidos Manejo de Privacidad Mantener la privacidad de los usuarios debe ser un objetivo permanente del sitio. Para ello se requiere de contar con una Política de Privacidad formal y explícita en el sitio y, además, deben existir mecanismos de seguridad concretos para proteger los datos de sus usuarios.
Entre estos, se debe contar con protecciones físicas y lógicas sobre dicha información.
Más información en :
http://www.robotstxt.org/wc/robots.html http://www.robotstxt.org/wc/norobots.html En el caso de disponer de arquitecturas multicapas reales, se recomienda proteger la información de clientes en servidores físicos distintos de almacenamiento de datos, incluyendo interfaces idealmente separadas de consulta de datos. Además, incorporar mecanismos de encriptación de los datos para información sensible.
Se recomienda que la información, si es almacenada para efectos de que los usuarios la recuperen desde el Sitio Web, sea encriptada con claves administradas por ellos mismos (por ejemplo, su clave de autenticación frente al sitio).
Una decisión de arquitectura que disminuye el riesgo de robo de información de clientes o cuentas de acceso, consiste en evitar que desde la Base de Datos sea posible generar parejas UserId/Clave que permitan autenticarse frente al sitio. La forma de hacerlo es incorporar mecanismos que almacenen un valor de índice de la clave en la Base de Datos, en vez de almacenar la clave propiamente tal. Gracias a esto, cuando un cliente se autentica frente al sitio, la comparación de claves se realiza sobre los valores de índice y se evita conocer directamente esa información.
Es importante destacar además que un buen diseño de los mecanismos de autenticación junto con mecanismos de auditoría, almacenamiento y recuperación posterior, son adecuados para la implementación de la Firma Electrónica Simple, requisito definido como suficiente para múltiples interacciones del Estado, de acuerdo con la Ley 19.799 y su reglamento (analizar recomendaciones asociadas al Uso del Documento y Firma Electrónica al interior del Sector Público).
Finalmente, se recomienda un control particular de todos los procesos de respaldo, recargas, manejo de medios removibles y generación de copias de información, por ser mecanismos internos de fugas o compromiso de confidencialidad de la información.
Canales Seguros Es importante incorporar mecanismos de encriptación del canal de comunicaciones (como el protocolo Secure Socket Layer o SSL), para la transferencia de información privada entre los usuarios y el Sitio Web, a través de la red Internet. Hacerlo no requiere de programación adicional a las funcionalidades de interacción, y asegura la protección de toda la información intercambiada entre el servidor y los usuarios.
Desde un punto de vista de desempeño, si bien el inicio («hand shaking») del proceso de establecimiento del canal SSL puede significar un pequeño retardo en la conexión inicial, posteriormente no provoca un aumento significativo del ancho de banda utilizado en la conexión, ni tampoco obliga a un aumento significativo de recursos del servidor.
Es importante considerar que la seguridad asignada a un Sitio Web debe ser correspondiente con la inversión y la importancia de los datos almacenados, siendo estas capacidades obligatorias para el caso de los sitios transaccionales.
Mecanismos de Control de Acceso Otro aspecto que genera mejoras en la protección de la privacidad de los usuarios y de la información contenida en el Sitio Web, es la incorporación de mecanismos modernos de generación de claves y autenticación, como los que se plantean a continuación.
• Firma Electrónica Simple y Avanzada: es un sistema que identifica al usuario cuando realiza trámites a través de Internet o redes cerradas. Existe una ley y el correspondiente reglamento que la regula y empresas que las ofrecen en el mercado (más información en http://www.entidadacreditadora.cl). Ambas firmas constituyen las bases legales para que ciudadanos y empresas puedan identificarse virtualmente y de esa manera enviar comunicación y hacer negocios de manera más segura y confiable. Se trata de un mecanismo de complejidad media, aunque incluye funcionalidades de seguridad y criptografía. No obstante, la incorporación de este mecanismo en forma única dependerá del control absoluto que se tenga de la comunidad de usuarios de la solución. Para comunidades abiertas es preferible establecer dos mecanismos de autenticación: uno fuerte, mediante Firma Electrónica (usando certificados digitales) y otro, mediante autenticación de Usuario y Clave. Por otro lado, la Firma Electrónica Simple podría ser usada para las comunicaciones oficiales enviadas por la institución a sus usuarios. El uso de la Firma Electrónica debe definirse al momento de determinar la arquitectura de solución del Sitio Web.
• Autenticación con par Usuario y Clave: si se emplea esta solución, debe existir un procedimiento concreto para los casos en que un usuario pierda o no recuerde su clave. Se recomienda ofrecer mecanismos de «regeneración de clave», mediante la entrega de respuestas a preguntas predefinidas por los usuarios, en lugar de hacer el «envío de la clave por e-mail». En el caso de contar con mecanismos de Ayuda, se debe ofrecer apoyo para la regeneración de las claves, sin que el personal de la institución tenga acceso a la información de seguridad del cliente. Se debe evitar el uso de mecanismos de autenticación administrados por terceros, en caso de que puedan comprometer la confidencialidad o la suplantación del usuario.
• Sistemas de Hardware para Autentificación: para sistemas de seguridad que requieren una autenticación absoluta del usuario, es preferible considerar mecanismos de autenticación fuerte. Para ello, se deben incorporar mecanismos que incluyan elementos de hardware que deben estar en posición del usuario, tales como tarjetas u otros similares (security token) que permiten el acceso a las áreas de autenticación. Allí el usuario debe ingresar su identificación de Usuario (security challenge response) y se le genera una clave de sesión que al ser digitada en pantalla, le permite acceder al sistema. Dicha clave cambia frecuentemente para aumentar la seguridad de acceso.
Protección de Programas Es fundamental proteger los códigos y programas internos del servidor web, particularmente evitando la transferencia de parámetros o información a través de la dirección de acceso a las páginas (por ejemplo, al usar el método GET para la entrega de parámetros), los cuales son mecanismos frecuentes de «hackeo» o robo de información.
De igual forma, se debe evitar la lectura de ejecutables desde los directorios del servidor, controlando los permisos adecuados de acceso a éstos, con el fin de evitar desensamblaje y/o ingeniería reversa para analizar accesos internos.
En cuanto a los «scripts» ubicados en el lado del cliente, en caso de ser críticos, se recomienda utilizar compactadores de código y eliminar documentación de apoyo que permita su fácil comprensión a partir de la lectura del código.
Es importante que estas medidas sean incluidas junto a las acciones de seguridad informática normales de la institución.
Hosting Externo vs. Sitio Propio Sin entrar en profundidad en cuanto al detalle de los elementos a considerar para esta decisión, la principal recomendación es hacer una evaluación objetiva basada en los siguientes aspectos:
• Evaluar las reales capacidades disponibles para la operación permanente del sitio, desde un punto de vista técnico.
• Evaluar los requerimientos de control y seguridad necesarios.
• Evaluar el nivel de soporte efectivo que el personal técnico del servicio puede realizar sobre los servidores.
Con estos parámetros se debe definir la mejor opción, no sólo desde el punto de vista del interés de las áreas técnicas, sino que mediante una evaluación de impacto global de la decisión asociada.
La amplia oferta disponible permite realizar combinaciones de servicios e infraestructura de muy diversos tipos, lo cual facilita configurar una solución óptima en términos del costo– beneficio asociado (por ejemplo, hosting compartido, dedicado, collocation, housing, red administrada, monitoreo de seguridad, administración de seguridad perimetral, control de aplicaciones, fulfillment, etc.).
En caso de que se decida externalizar esta área, es importante contar con altos estándares de parte del proveedor en todo lo referido a tiempo de desempeño («uptime»), respaldos y recuperación, actualizaciones de software, etc.
Roles Mínimos a Asegurar Un último aspecto considerado en esta área de recomendaciones, consiste en definir los diversos roles profesionales dentro de la definición y diseño de un Sitio Web para una institución.
Desde un punto de vista exclusivamente técnico, es fundamental considerar al menos los siguientes roles, identificando tanto sus responsabilidades como el personal más competente que pueda cumplirlos.
Si bien más de uno de estos roles funcionales puede ser desarrollado simultáneamente por una persona o área de la organización, es importante que dichas áreas sean cubiertas no sólo durante la puesta en marcha de la solución sino también durante su etapa de producción.
– Arquitecto: encargado de hacer las configuraciones de trabajo de los servidores y aplicaciones.
 Página anterior | Volver al principio del trabajo | Página siguiente  |