A while back I wrote the Part I of how we built the Estonian Government web platform. I had all the intentions to quickly follow that up with Part 2 and 3, but as always, things got busy. The good news is, however, that all the sites are now live for several months and I can use live examples to illustrate my text here.
Part II is about some of the functionality we built and the technical solutions used for it. The development phase lasted throughout the second half of 2013 and first months of 2014 – 7 months of development means a lot of different stuff was built. Instead of trying to cover it all, I will try to focus on the parts that I feel characterize this project the best.
I already wrote about how we implemented the Google Site Search for the Government platform, which definitely was one of the big and complex parts of the project. But yet another big one was…
Integration with centralized state personnel database
Estonian Government is keeping the contact information of its employees – that is, the ministers, officials, department personnel, etc. – in a unified information system, based on SAP technologies. That is a good thing, as theoretically only a single integration is needed to show the public contact details of those people on the Government web platform sites. There was a lot of value there – over the 14 sites, that’s thousands of people, whose contact details, positions and careers within their organizations are in constant change, and keeping that information up to date would be a huge task for a lot of web editors. Instead, we were aiming to get all that data from internal systems, where it was kept up to date anyway.
But there were problems:
Different organizations had different hierarchies – ie., Government Office had two levels of departments, while the Ministry of Economics had 4 levels.
The SAP database did not contain or could not export all the information that was required to be displayed in the web.
Different Ministries had slightly different practices about how they stored the contact information in the data fields, so there were a lot of exceptions of what could be directly presented to the public and what needed manual sanitation to get a more or less unified picture across all the Ministries.
The field lock checkboxes on Contact node edit page
It was clear quite fast that there were too many exceptions and some of those could not be predicted with 100% accuracy. So we needed some sort of a combination of having 95% of contacts automatically imported, but having the possibility to manually override – and making sure that manual work can be switched back to automatic or vice versa if needed.
The technical solution was to build a “field lock” functionality. A Feeds import made a daily automatic import that created or updated Contact nodes. Each node contained about 10 different fields of data for a person, such as Name, Position, Department, Education etc. If any of those fields needed manual adjustments, the editor could do so, and then use a special checkbox for that field to lock it from automatic overrides – so that when the next automatic import happened the next day, that field was not overwritten. If the data was later corrected in the backend SAP system, the lock could be removed and Feeds would resume writing into that field.
Examples of the views displaying those semi-automatic Contacts can be seen here and here.
WYSIWYG content templates
Government sites contain a lot of content, and it can get quite overwhelming for a visitor who needs to go through and get a sense of several topics fast. So the Government Office wanted each content page to be something more than just a wall of text, to have more structure, sections, visual data and differentiation. We needed a tool that would help content editors craft pages like that themselves, without having to learn HTML and CSS for many months.
So we used the Wysiwyg API template plugin module to add a template selector functionality for CKEditor. Our frontend wizard Hannes pre-baked some 10-15 nice content templates, and content editors only had to select the correct one from a popup, replace the dummy text, and enjoy a professional-looking, rich content experience. Content templates were WCAG 2.0 AA level compatible, fully responsive, and could even be used inside one another.
Template selector popup within CKEditor
Here are some examples of pages (in beautiful Estonian) made by content editors who probably didn’t have to write a single line of CSS: Ministry of Economic Affairs and Communications is writing about energetics, Ministry of Culture describes how they use foreign resources, Government Office introduces Estonian Presidency of the Council
of the European Union 2018.
Aggregating content between the sites
One goal of the Government platform was to unify the content across different Ministries. This included several behind-the-scenes processes, but also a technical solution to aggregate content across different sites into one central source.
Each Ministry had their own page for news, weekly schedule, and contacts. These in turn had RSS feed outputs, like this and this, which could be used for news readers, open data initiatives and other machine-reading purposes, and also for aggregation.
The central information source and aggregator was to be valitsus.ee (translated, government.ee), which was also running on the Government platform and didn’t represent any physical institution per se, but the government as a whole. So weekly schedule, news, and contact search pages on the valitsus.ee site would display content from all the Ministries, pulled in over RSS. You can see “Source” filters there, in case someone would need to focus on content from just a few of the Ministries.
Unfortunately, the RSS export-import has not yet been configured for all the sites and therefore there is no active aggregation yet – I’m planning to write more about the woes of deploying 13 big sites and the importance of follow-up phases in Part 3 of this series.
Tagged: case study, Drupal 7, integrations, planet drupal
