Recomendaciones a la hora de construir sitios gubernamentales para Panamá

June 18, 2021

Share

Table of contents

Quick Access

![enter image description here](https://cms.rootstack.comhttps://cms.rootstack.com/sites/default/files/blog/img/layer-3_2.png) En el 2011, la Autoridad Nacional para la Innovación Gubernamental publicó los estándares para sitio web en las entidades públicas. La resolución se puede ver en [este enlace](https://www.gacetaoficial.gob.pa/pdfTemp/26749_A/32063.pdf). En este post vamos a dar algunos tips y enlaces algunas de las librerías que puede usar dentro de su sitio web gubernamental para cumplir con estos estándares. ### 1. Estructura de la página ### La AIG requiere que la páginas del sitio estén divididas en 3 regiones, Superior, medio e inferior y así mismo cada una de estas regiones principales divididas en ciertas sub-regiones que tienen diferentes objetivos. Es importante pensar cuando construimos un sitio de este tipo cómo podemos hacer para tener estructuras dinámicas para usarlas a medida que las necesitemos sin romper el sitio en el momento que no sean necesarias. Nosotros en Rootstack siempre utilizamos un sistema de grid para construir las plantillas de los sitios que construimos. Esto nos facilita el maquetado de un sitio al proveer una guía o un sistema de columnas, espacios y márgenes que nos ayudan a posicionar la información de los elementos del sitio de manera ordenada y consistente. Podemos recomendar algunos sistemas de Grids con los que hemos podido trabajar de un modo muy eficiente: * [Boostrap](http://getbootstrap.com/) * [Foundation](http://foundation.zurb.com/) * [Suzy](http://susy.oddbird.net/) ### 2. Menú "Sobre la entidad" ### Este punto se encuentra en la página 22, el punto 18. Es un menú que por la cantidad de elementos que debe tener puede volverse complicado y enredado de leer para el usuario. Recomendamos usar librerías para hacer acordeones que permitan colapsar el contenido, para así mejorar la experiencia de usuario. La librería de javascript más popular que funciona para esto es: * [Jquery UI Accordion](https://jqueryui.com/accordion/) ### 3. Accesibilidad e Interoperabilidad ### La AIG requiere que el sitio pueda ser visto en diferentes navegadores, el documento no específica que versiones y que navegadores, pero podemos asumir que deben ser los más populares: * Internet Explorer * Google Chrome * Mozilla Firefox * Opera * Safari Construir para que un sitio se vea bien en varios navegadores puede ser una tarea tediosa si no se utilizan las herramientas y técnicas adecuadas: * **Siempre hacer un fallback**: A medida que utilizamos nuevas tecnologías y técnicas estamos más propensos a encontrarnos con funcionalidades que no funcionen en todos los exploradores, sobretodo en los viejos, para esto siempre debemos pensar en una estrategia para brindar a estos exploradores una alternativa o "fallback". La el sitio [html5please.com](http://html5please.com/) es un ejemplo de estrategias para elementos de HTML5 en exploradores sin compatibilidad de algunos de sus elementos. * **Javascript solo debe tener comportamientos, no estilos**: Algunas veces nos hemos encontrado con código que asigna elementos de estilo al html desde el javascript, esto es una mala práctica, sobre todo porque si el explorador tiene javascript inhabilitado, es muy probable que los elementos que reciben estilos por javascript no se vean como deberían de verse. * **Utilizar un CSS Grid Framework**: Ya lo mencioné anteriormente, pero dentro de este punto también nos sirve de ayuda, como una base sólida y consistente de nuestro desarrollo, en el momento que encontremos una incompatibilidad, si nuestro código está bien diseñado, debe de ser sencillo arreglar el problema y no tener que hacer arreglos en todo nuestros estilos. #### 3.1 Herramientas adicionales para ayudar a la interoperabilidad #### * **[Respond.js](https://github.com/scottjehl/Respond)**: Respond.js es una librería de javascript que ayuda a desarrollar sitios web responsivos en exploradores que no soportan Media Queries de CSS3. * **[Modernizr](https://modernizr.com/)**: Modernizr es una librería que ayuda a detectar que características de CSS y Javascript tiene el explorador que está visitando al sitio, en base a esto podemos tomar decisiones en cuanto a como deben comportarse diferentes elementos de nuestro sitio web. * **Polyfills para simular comportamientos**: En estos exploradores que ciertas funcionalidades nuevas de CSS, HTML o Javascript todavía no son soportadas, podemos simularlas utilizando Pollyfils. [Ejemplos y más información en este enlace](https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-browser-Polyfills). #### 3.2 Pruebas de compatibilidad #### Probar en diferentes exploradores al igual que construir, es una tarea tediosa, una forma de hacer este trabajo más rápido es utilizar herramientas que nos permitan ver muchos la misma página en muchos exploradores a la vez, actualmente nuestra herramienta favorita para esto es [Browserstack](https://www.browserstack.com/). Otra opción para probar exploradores de difícil acceso, sobre todo versiones viejas de Internet explorer es utilizar [Modern.ie](https://developer.microsoft.com/en-us/microsoft-edge/), estas son una serie de máquinas virtuales que provee Microsoft para probar páginas en sus diferentes exploradores. ### 4. Velocidad de descarga ### Mencionado en el punto E.3.3 el documento de la AIG, esto es algo que debe de ser considerado no sólo para sitios gubernamentales sino también para sitios web en general, algunas de nuestras recomendaciones son: * **Utilización de sprites para imágenes**: El concepto de un sprint es básicamente una imagen que contiene múltiples imágenes en una sola y con ayuda de CSS la imagen es posicionada en la coordenada correcta para mostrar la imagen deseada. Esto ayuda bastante porque de este modo podemos descargar todos los elementos que necesite el la página sin necesidad de hacer una petición sobre cada imagen que necesite el sitio. Esto es utilizado principalmente para los elementos como fondos, botonería, bordes, elementos que sean reutilizables en diferentes partes del sitio. Podemos ver un ejemplo de ello en el siguiente enlace: [https://www.smashingmagazine.com/wp-content/uploads/2012/01/sprite-wild1.jpg](https://www.smashingmagazine.com/wp-content/uploads/2012/01/sprite-wild1.jpg) * **Compresión**: Si el explorador lo soporta, es buena práctica enviar el HTML de nuestro sitio comprimido, así la transferencia es menor y más rápida. En el caso de apache esto se puede lograr utilizando el módulo [mod_deflate](http://httpd.apache.org/docs/current/mod/mod_deflate.html), también puede ser realizado con otros servidores web como [Nginx](https://www.digitalocean.com/community/tutorials/how-to-add-the-gzip-module-to-nginx-on-ubuntu-14-04). * **Headers de cache**: Para elementos que van a permanecer bastante tiempo en nuestro sitio del mismo modo (ejemplo, los sprites con iconos, fondos, etc.) podemos utilizar headers con tiempo de expiración altas para que el explorador no los descargue cada vez que visitamos el sitio. * **Cache de sitio web**: Si estamos desarrollando una página con contenido mayormente estático (sitio donde no se autentican usuarios), es buena práctica utilizar algún sistema de cache para que una vez se visiten las páginas, sean las mismas entregadas desde el sistema de cache y no tenga que el servidor web hacer todo el procesamiento de la página. De este modo ahorramos recursos en el servidor y entregamos la página de un modo más rápido. Ejemplos de modos de hacer esto es utilizando un reverse proxy como [Varnish Cache](https://varnish-cache.org/) o servicios como [Cloudflare](https://www.cloudflare.com/). Estos son solo algunos de los mecanismos, más detalles sobre como mejorar el rendimiento del sitio daremos en otro post. ### 5. Cumplimiento de estándares web ### Este es un punto difícil de cumplir, sobre todo cuando desarrollamos con plantillas que vienen ya con muchos elementos preconstruidos. Nuestra preferencia cuando trabajamos sitios gubernamentales es construir las plantillas con una base sólida pero limpia y sencilla que nos permita crecer y a la vez cumplir con los estándares de la W3C requeridos por la AIG. ### 6. Seguridad ### Este es uno de los puntos más importantes, sobretodo para un sitio web gubernamental. Recientemente escribimos un post sobre Plataformas de desarrollo web a la hora de construir nuestros sitios y aplicaciones web de forma segura. Que es justamente la información relevante a este punto. En Rootstack nos gusta trabajar con plataformas que sepamos que tienen una comunidad y equipo de seguridad activo que respalde la misma, como [Drupal](http://drupal.org) y [Symfony](http://symfony.com/). Los invitamos a leer el enlace anteriormente mencionado para tener una idea de como estas plataformas nos ayudan a desarrollar nuestros sitios de una forma mas rápida y segura. Si tiene alguna duda o necesita información sobre alguno de estos puntos o su sitio web gubernamental no dude en contactarnos.