Tips for building government websites in Panama

 In 2011, the National Authority for Government Innovation published the standards for public entities websites. The resolution can be access [here](https://www.gacetaoficial.gob.pa/pdfTemp/26749_A/32063.pdf). In this post we will give some tips and links to some of the libraries that you can use within your government website to meet these standards. ### 1. Page Structure ### AIG requires that the pages of the site be divided into three regions, upper, middle and lower and likewise each of these major regions divided in certain sub-regions having different goals. It is important to think about it when we build a site like this and how we can have dynamic structures for further use without breaking the site when they are not necessary. We at Rootstack always use a grid system to build the templates for the sites we build. This gives us the formated site by providing a guide or a set of columns, spacing, and margins that will help us position site element information in an orderly and consistent manner. We can recommend some Grid systems which we were able to work with very efficiently: * [Boostrap](http://getbootstrap.com/) * [Foundation](http://foundation.zurb.com/) * [Suzy](http://susy.oddbird.net/) ### 2. Menu "About the organization" ### This point is on page 22, paragraph 18. It is a menu for the number of items you should. It can become complicated and messy to read for the user. We recommend using libraries to collapse accordions that allow content to improve the user experience. The javascript library that works for this and is most popular would be: * [Jquery UI Accordion](https://jqueryui.com/accordion/) ### 3. Accessibility and Interoperability ### AIG requires that the site can be viewed in different browsers, the document does not specify which browsers but we can assume to be the most popular: * Internet Explorer * Google Chrome * Mozilla Firefox * Opera * Safari Building a site that looks good in different browsers can be a tedious task if the right tools and techniques are not used: * **Always do a fallback**: As we use new technologies and techniques are more likely to meet with features that may not work in all browsers, especially in the oldest, for this we must always think of a strategy to give these explorers an alternative or "fallback". The site [html5please.com](http://html5please.com/) is an example of an estrategy for HTML5 elements in browsers and without compatibility of some of its elements. * **Javascript must have behaviors only, not styles**: Sometimes we find code that assigns elements of style html from javascript, this is a bad practice, especially because if the browser has javascript disabled, it is very likely that elements receiving styles by javascript are not as they should seen. * **Use a CSS Grid Framework**: As mentioned above, but in this point also serves as an aid, as a solid and consistent basis of our development, when we find an inconsistency, if our code is well designed, should be easy to fix the problem and not having to rearrange all our styles. #### 3.1 Additional tools to help interoperability #### * **[Respond.js](https://github.com/scottjehl/Respond)**: Respond.js is a javascript library that helps develop responsive websites in browsers that do not support CSS3 Media Queries. * **[Modernizr](https://modernizr.com/)**: Modernizr is a library that helps detect the CSS and JavaScript features within the browser you are visiting the site, based on this we can make decisions as to how different elements of our website should behave. * **Polyfills as to simulate behavior**: In these browsers that certain new features of CSS, HTML or Javascript are not yet supported, we can simulate them using Pollyfils. [Examples and more information in this link](https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-browser-Polyfills). #### 3.2 Compatibility tests #### Testing the site on different browsers is just like building it, it is a tedious task, one way to make this work faster is to use tools that allow us to see a lot of the same page in many browsers at once, currently our favorite tool for this is [Browserstack](https://www.browserstack.com/). Another option to try explorers difficult to access, especially older versions of Internet Explorer is using [Modern.ie](https://developer.microsoft.com/en-us/microsoft-edge/), these are a number of virtual machines that Microsoft provides in order to test sites in different browsers. ### 4. Download speed ### As mentioned in point E.3.3 in the AIG document, this is something that we must be considered not only for government sites but also for general websites, some of our recommendations are: * **Using sprites for images**: The concept of a sprint is basically an image that contains multiple images into one and using CSS image is positioned in the right coordinate to display the desired image. This helps a lot because this way we can download all the items you need without making a request on each image you need for the site. This is used primarily for elements such as backgrounds, push buttons, borders, elements which are reusable in different parts of the site. We can see an example in the following link: [https://www.smashingmagazine.com/wp-content/uploads/2012/01/sprite-wild1.jpg](https://www.smashingmagazine.com/wp-content/uploads/2012/01/sprite-wild1.jpg) * **Compression**: If your browser supports it, it is good practice to send compressed HTML from our site, so the transfer is smaller and faster. For Apache this can be achieved using the module [mod_deflate](http://httpd.apache.org/docs/current/mod/mod_deflate.html), It can also be performed with other web servers such as [Nginx](https://www.digitalocean.com/community/tutorials/how-to-add-the-gzip-module-to-nginx-on-ubuntu-14-04). * **Cache Headers**: For items that will remain long enough in our site the same way (eg, sprites icons, backgrounds, etc.) we can use headers with high expiration time so the browser does not download every time you visit the site. * **Website Cache**: If you are developing a site with mostly static (place where no users are authenticated) content, it is good practice to use a caching system so that once the pages are visited, are the same delivered from the system cache and does not have the server do all the web page processing. Thus we save resources on the server and deliver the page faster. Examples of ways to do this is to use a reverse proxy as [Varnish Cache](https://varnish-cache.org/) or services such as [Cloudflare](https://www.cloudflare.com/). These are just some of the mechanisms, details on how to improve site performance will be in a future post. ### 5. Compliance with web standards ### This is a difficult point to accomplish, especially when we develop templates that come with many pre-built elements. Our preference when working government sites is to build templates with a solid but clean and simple basis that allow us to grow and at the same time meet the standards required by W3C and AIG. ### 6. Security ### This is one of the most important points, especially for a government website. We recently wrote a post about it Web development platforms and web applications to build our sites securely. Which is precisely the information relevant to this point.. In Rootstack we like to work with platforms that we know have a community and active security workforce that supports it, as [Drupal](http://drupal.org) and [Symfony](http://symfony.com/). We invite you to read the above to get an idea of how these platforms help us develop our sites faster and more securely. If you have questions or need information on any of these points or a government website please contact us.