Online data collection tool and infrastructure

• Pages: 21-37

21

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 : //

lgbtisurvey.eu/ or https://www.lgbtisur vey.eu/.

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

infrastructure

A long way to go for LGBTI equality — Technical report

22

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

characteristics.

•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

sub-questions;

− 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

Users