EEA is mandated to provide high quality information to support the environmental policy process and sustainable development, and raise public awareness. One of its main tasks includes providing that information to a very wide range of target groups. The Internet is a perfect tool for this type of mission. EEA products displayed online should provide the best experience, be accessible to the largest possible number of users, across a wide range of computing equipment, operating systems and/or browser software. Online products should, in that perspective, not only be user-friendly, but be designed for unexpected usage.
Due to history and technological constraints, EEA's software development work fall into five technological areas:
The aim of these guidelines is to provide guidance for the implementation of high quality products meant to be part of EEA's online communication in the Eionet and EEA public sphere.
The purpose of this document is to map the road of EEA's software development with a three year horizon. Compared with earlier versions of this document, EEA now has a large investment in existing infrastructure that it wishes to build on and protect.
These standards shall be used by all projects that build shared infrastructure or common software tools for EEA in the relevant technological areas. It is not always possible for a project to determine the wider implications of their choices. Therefore, any project that starts software development shall do any of the following:
If there is no standard in a particular area, the choice is open. However, it is still a good practice to inform EEA's IT Team.
The standard systems listed herein are supported by EEA's IT Team and by the Eionet Network Management Centre. They are or can be installed to all systems upon request.
All new software must be developed with products listed.
Must use:
Must use one or more of following:
Must use one or more of following:
Should use:
Websites should be able to interface with a reverse proxy for load distribution and caching.
Those that work well in connection with the above Internet and database services
Note that a website that only uses non-HTML technologies on the client side is not acceptable, as it very effectively prevents search engines from indexing the site.
Most development projects follow the iterative model. The project is assigned one or more technical supervisors from EEA. Their job is to ensure the product fits into EEA's system and has the required functionality. The technical supervisor will be available on Email and Instant Messaging, currently XMPP (Jabber).
EEA uses Subversion (SVN) for version control. We want you to use our version control system rather than your own or none at all. This is for our benefit and your protection as it allows us to document the progress in the project easily via the commit log and to differentiate between what you (as a contractor) have delivered and what other people have done to the code.
The software must come with complete instructions on how to install it and what prerequisites there are. The instructions must be bundled with the source code. Also, write down the engineering specifications, so that other folks can figure out how to extend and enhance the product.
Source code is defined as the files and file formats a programmer uses to create a computer program. For example .java files, Flash source, Photoshop files, and image files before text is written on them.
If a company has received the contract to create a new independent piece of software, it is guaranteed that the contractor will be the only party to make modifications to the code until such time when the product is delivered and accepted. The delivery is considered to be the base release.
There will usually be a period of warranty where the contractor is obliged to fix bugs free of charge. Though the software can have been modified in the meantime, the contractor is only obliged to fix bugs that exists in the base release.
If a company has received the contract to add functionality to an already existing product a baseline will be established upon which the modifications are created. The company is guaranteed that nobody but that company modifies code in that particular branch.
When the modification has been delivered and accepted to work with the base line it must be merged with the main branch in the development tree. Here we again establish a base line of the main branch and merge with it. Hopefully there were no additions to the main branch in the meantime otherwise we do the cycle again.
After a product has been delivered it goes into maintenance mode. It will stay here until the product is scrapped. The purpose of maintenance is to adjust the product to a changing environment, add new functionality and fix bugs. To keep track of it we use an issue tracking system such as Trac. Again, this is also to document progress.
EEA reserves the right to decide under what terms copies of the source of a software product will be released under. This will usually be the Mozilla Public License or the GNU Public License. The contractor must respect the copyright of other parties, whose software has been integrated into the product. The contractor must not integrate software with a license that is incompatible with the product's license. All source files must include a copyright statement referencing the licence terms.
EEA exists to handle information. Much of that information is freely available according to Regulation (EC) No 1049/2001 and the Aarhus Convention. To support retrieval, all representations of resources (webpages) must have a persistent URL. The URL should not change when access restrictions to the resource change or if underlying technology changes.
On 25 September 2001 the Commission adopted the Communication eEurope 2002: Accessibility of Public Web Sites and their Content and follows W3C's accessibility guidelines. Contractors must comply with WAI-A (single-A), and should comply with WAI-AA (double-A) specifications.
All websites must follow the EEA/Eionet look and feel. Authors must use semantically correct HTML markup and CSS for styling.
New websites must be authored in XHTML 1.1. When a page uses frames, popups or opens new browser windows, the format is XHTML 1.0 Transitional. All pages must validate against the W3C HTML validator.
EEA lives in a multilingual world. We handle three alphabets - sometimes on the same webpage. To avoid a painful cleanup, all pages must be written in UNICODE - and this usually means served to the webbrowser in UTF-8.
Preference should be given to development tools that eases localisation of navigation and content. See also the Best Practices for multilinguality document.
Webpages must look the same in Internet Explorer 7 and Firefox 3. The same pages should be usable in older browsers as well as handheld devices, unless the nature of the webpage makes it unnecessary. In a world of browser security bugs and popup blockers, the contractor shall not rely on Javascript and the ability to open new browser windows.
All websites in need of authentication must use the Eionet site directory - an LDAP service.
Eionet has developed an authorisation design that is derived from DCE and adapted to persistent URI principles. In short, for a database record, a globally unique resource identifier is constructed from the host, table and primary key. I.e. http://<host.eionet.europa.eu>/<table>/<key>. To each object is associated a set of permissions, which can be set or unset for users and groups. It is not required to control access on record level. This depends on the nature of the application.
User associations to groups are available from the site directory, but is usually maintained locally within each application.
Should use:
Microsoft Internet Explorer 5.0 and Netscape Communicator 4.51 or later. JavaScript versions that function under these browsers
Document last modified: 2017/04/13 . Content in this portal is modified daily by a community of providers.
Disclaimer.
Copyright: