Online data collection tool and infrastructure

The technical implementation of the LGBTIII survey
included (1) the online data col lection tool, (2) aweb-
site, which was the land ing page for the respo ndents
and provided information to them about privacy and the
conf‌identiality of d ata collection an d offered answers
to frequently asked ques tions, as well as access to the
helpdesk, an d (3) the dashboard, a n online real-time
monitoring tool p roviding information o n the progress
of the survey. The survey was accessibl e at ht t ps : // or https://www.lgbtisur
The online sur vey was hosted on highly availabl e serv-
ers in the Oracle Clo ud infrastructure and consis ted of an
Oracle database s erver for the data storage, aload bal-
ancer distributing the workload to two Oracle Weblogic
application ser vers and an Oracle back-up service. The
data centres hosting the s ervers were located with in
the EU (Frankfur t).
For the online dat a collection for the LGBT III survey,
acustom web-b ased applicatio n was designed and
developed specif‌ically by the contractor to accommo-
date the needs of this survey. These needs concern
enhanced functi onality, such as comple x branching
rules, piping an d multilingua lism, and mechan isms to
address speed, reliability, security and the respond-
ent’s privacy.
The online tool was a lightweight web-b ased applica-
tion built using Java Script and Java technologies a nd an
Oracle relational d atabase system for the data sto rage.
Performance was one of t he major concerns from the
very beginnin g of designing the sur vey. First, at the
database level, carefu l design decisions were taken to
avoid operations that sl ow down the database se rver.
At the user interface, havin g the options of Javascri pt
and AJAX technology contributed to its performance, as
this implied no refresh es of the web page and hen ce
faster operation a nd abetter user e xperience. Final ly,
the middle tier ac ted as asimple intermediate tier with
limited responsibi lity, such as f‌iltering an d protecting
HTTP (Hypertext Transfer Protocol) requests, and with-
out complex logi c, making the ap plication run fas ter.
Performance was also g uaranteed at the physical level
by powerful servers.
As far as securit y is concerned, measures we re taken
at multiple levels:
at the HTTP level with t he use of the SSL protocol,
ensuring that the com munication between res pond-
ents’ devices and the a pplication is encrypted;
Cloudflare proxy system protecting against mali-
cious attacks;
at the applicatio n level, the incorporati on of the in-
visible reCAP TCHA application prote cting from bot
attacks, as well a s the inclusion of cer tain HTTP
headers providing additional security.
At the infrastruc ture layer, the servers were conf‌igured
with high-security f‌irewalls ensuring that the survey
data are protected from unauthorised access.
4.1. Software architecture
The software was de signed with athree -tier architec-
ture model, which is a n industry-proven arch itecture
used to support en terprise-level client s erver applica-
tions. The soft ware architecture consisted of the layers
illustrated in Fig ure1.
Online data collection tool and
A long way to go for LGBTI equality — Technical report
4.1 .1 Front-end tier
This is the tier that use rs interact with, com posed of
the user interface a nd containing all t he presentation
logic; the code is responsible for rendering questions
based on their ty pe (implementing atemplating mec ha-
nism for each questio n type), getting user’s responses
from interface compon ents and preparing the submis-
sion of survey data and p aradata. The front-end is also
responsible for the coll ection of parad ata and device-
type paradat a that provide informatio n regarding the
kind of device used to compl ete the survey, such as
the type of browser, layout engi ne, operating sys-
tem, device type/model. T his information is e ntirely
extracted from t he user–agent (UA) string, aself-iden-
tifying HT TP that header browsers send when a ccessing
aweb page. A typical UA stri ng looks like this: Moz-
illa/5.0 (Macintosh; Intel Mac OSX10_14_6) AppleWeb-
Kit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130
Safari/537.36. It does not include any potentia lly iden-
tifying data su ch as IP addresses, ge ographical refer-
ences, cookies, etc.
Some of the applicat ion’s business logic, suc h as the
support of compl ex routing rules, based on awell-str uc-
tured internal representation of rules, piping mechanism
and multiling ualism, is implemented in this layer.
The front-end is written mos tly in JavaScript and HTML
(Hypertext Ma rkup Langua ge) and built upon Ang u-
larJS, one of the most p opular client-side fram eworks
for dynamic web applications.
As the interact ion with users is per formed in this tie r,
special attentio n is given to details. Th us the user
interface is carefully d esigned to have the followi ng
It is user-friendly, easy to use and perform s well.
It is responsive, so it can ada pt to different view-
ports and work we ll across browsers on desk tops,
tablets and mo bile phones. To ensure sur vey us-
ability on smal l screens, such as mobi le devices,
certain careful design steps were taken:
avoided questions in tables be cause tables do
not f‌it on smaller scree ns and require respond-
ents to zoom and scroll ho rizontally just to read
the text, e.g. matri x questions were split i nto
avoided making the respondents scroll horizon-
tally as much as possi ble; in addition to d ecom-
posing and split ting,, this involved the display of
multiple choice qu estions vertica lly as opposed
to horizontally;
avoided drag and drop questions (e.g. for rank-
ing) and developed spe cif‌ic functio nality that
enabled ranking without drag and drop;
optimised font size and navigation but tons for
usability with smartphones;
customised prompts and error mess ages to be
shown with the right font si ze, length and colour;
avoided popups (e.g. for error messages).
It is compatible with t hree major versions of th e
most popular web b rowsers (e.g. Google Chrome,
Mozilla Firefox, Opera , Safari, Internet E xplorer, Mi-
crosoft Edge), as well as embedd ed browsers wide-
ly adopted by the majori ty of social netwo rk ap-
plications (Facebook, Twitter, Inst agram, LinkedIn ,
Messenger, Pinterest, etc.). Although the applica-
tion was developed to be c ross-browser compat-
ible and tested on a wide combi nation of devices,
operating system s, browsers and browser versions,
it was almost impo ssible to verify it s proper func-
tioning in all un documented custom i n-app brows-
ers that lack the supp ort of basic web sta ndards.
That was the case with Pla netRomeo. Early i n the
survey fieldwork , users reported t hat they were
unable to answer que stions offered as drop -down
menus when accessing th e online survey usi ng the
Figure 1. Three-tier system architecture
Front-end Tier
(Tier I)
Middle Tier
(Tier II)
Data Tier
(Tier III)
Https Ojdbc

To continue reading

Request your trial

VLEX uses login cookies to provide you with a better browsing experience. If you click on 'Accept' or continue browsing this site we consider that you accept our cookie policy. ACCEPT