The package comes with an interactive application to quickly and easily collect your own occupation data and possibly conduct your own survey.
This application can be started by just calling the function
app()
.
The flow of the app and its questions can be quite complicated, as we tried to optimise the rate of successful codings.
We created the flow diagram below to illustrate how a participant will be guided through the app, depending on their responses. None of the complexity is visible to users and the flow is completely handled within the app.
There are multiple ways of changing the behaviour and contents of the
app. These are split into two main sections: You can change the
information / contents of the app and what is shown, by using a
different questionnaire
or you can adjust general settings
of the app, such as data saving options by modifying the
app_settings
.
The toolbox comes with different ready-made questionnaires, such as the
questionnaire_web_survey()
for
self-administered online surveys,questionnaire_interviewer_administered()
for interviews
conducted by an interviewer, orquestionnaire_demo()
for a version of the app that
includes explanations for how the app works behind the scenes.If you need more flexibility, you can also modify existing
questionnaires or create your own ones from scratch. To do this refer to
the more detailed explanations available in
vignette("app-questionnaire")
.
There are multiple settings available to the app to change how it
behaves, where data is saved and much more. These settings need to be
passed to the app under the parameter app_settings
and are
created using create_app_settings()
. You can read about all
options in the function’s helpfile ?create_app_settings()
.
If you’re specifically looking to save data into a database, you can
find a detailed explanation in
vignette("app-database")
.
library(occupationMeasurement)
app(
# Use the questionnaire for interviewer-administered interviews
questionnaire = questionnaire_interviewer_administered(),
app_settings = create_app_settings(
# ... specify your custom settings here:
# Collect an interview_id, so that you can merge data from your questionnaire
# and from the app after data collection
require_respondent_id = TRUE,
# Skip follow-up questions related to ISCO skill level
# or ISCO supervisory/managment occupations
# (in case similar questions are already included in your questionnaire)
skip_followup_types = c("anforderungsniveau", "aufsicht")
# ...
)
)
Some settings can also be varied between individual sessions / interviews, e.g., if they were to depend on a previous question or input from an external questionnaire. To modify these “session”-settings you pass them as query parameters:
# Ask questions in past tense
https://{url-to-my-interactive-app}/?tense=past
# Use full range of supported session parameters
https://{url-to-my-interactive-app}/?respondent_id=<your_unique_id>&tense=past&extra_instructions=off&num_suggestions=10
Here is a list of all supported query parameters:
respondent_id
: Identify users (see the section below
for more details)tense
: We may not always want to ask for the current
job (e.g. if someone is retired). You can switch between asking for a
current or prior job, by switching this between present
and
past
.extra_instructions
: Is conversational interviewing
turned on? Then some additional instructions for the interviwer will be
shown. Can be on
or off
.num_suggestions
: How many suggestions (maximally) to
show to participants. Can be any full number / integer. A common default
is 5
.Most of these settings are also described in the help page
?create_app_settings
, as their defaults are set in the
app_settings
.
If you want to match your data with an external source or embed the
interactive app within another survey, you will probably want to pass a
unique interview or user identifier, called the
respondent_id
.
This can be done adding a query parameter named
respondent_id
to the URL, i.e.,
https://{url-to-my-interactive-app}/?respondent_id=<your_unique_id>
(with {url-to-my-interactive-app} corresponding to the URL your
application is running at and
If you want to make sure that a respondent_id
is always
supplied, you can enforce this by setting
require_respondent_id = TRUE
in the
app_settings
.
The app will keep track of data for you and will, by default,
automatically save data in multiple CSV files. These are saved to the
response_output_dir
(if save_to_file
is
TRUE
), which can be configured in the
app_settings
(see the section above for more information).
To quickly read the most important data from CSV files, the convenience
function get_responses()
is available.
Currently there are 5-6 different formats of data
that
are being saved, see below. These are differentiated by different
table_name
s. You can see these table_name
s in
the filenames of the data files, although the filenames typically also
have some extra information besides the table_name
to
differentiate between files from different sessions/interviews.
If you plan to save data into a database, you can find a detailed
explanation of how to do this in
vignette("app-database")
.
The five different kinds of data, i.e. “tables”, that are being saved right now are outlined below.
The user’s answers themselves, with one row per question/item. These
are saved, whenever a page gets submitted and therefore multiple times
per participant. The unique key is made from variables
session_id
, page_id
, start
and
item_id
.
A combined version of the user’s answers and information about the
user themselves. These are saved at the end of the questionnaire and
therefore only once per participation. session_id
is the
unique key here. Note that respondent_id
is not necessarily
unique (although it should be) because the same
respondent_id
can be passed multiple times via the URL.
answers
for additional information).The list of suggestions shown to the user. These are saved at the
moment when suggestions are generated and therefore typically
once per participation, but not necessarily. The unique key is made from
variables session_id
, start
, id
,
and auxco_id
.
This list also includes “other” response options, such as “No response” or “Other”.
At the moment these are only saved when the
suggestion_type
is auxco-1.2.x
.
response_id
corresponding with
this option. Use to also identify “other” response options than
suggested occupations.Information on when and which suggestions were clicked to be expanded
(or closed) by a participant. The unique key is made from variables
session_id
and time
.
Information on all sessions, saved whenever a session is ended (after
a timeout, upon leaving the app or when stopping the server). The unique
key is session_id
.
This is mainly useful for understanding whether some users may start multiple sessions in the app.
1-
indicates that the session was
ended on or before the first page was shown. 1-3-7
indicates that three pages were shown and the session ended on page 7.
When the previous
button is pressed, this page is not saved
here.session_info
-record got saved.If you want to deploy the interactive app to an actual server for use
in a production environment you can find detailed instructions in
vignette("app-deployment")
.