Skip to main content

IBUC 2016 Abstracts

 Below you will find the abstracts for the papers that will be presented at IBUC 2016.

  • Blaise on Touch-Screen Tables: the ELIPSS Example
    Matthieu Olivier and Alexandre Chevallier
    Centre de Données Socio Politiques (CDSP) – France


    Starting in 2012, the ELIPSS project is a French probability-based web panel. All panel members are equipped with a touch-screen tablet to answer, each month, a self-administered survey programmed with Blaise 4, through a pre-install app.

    This paper will describe, through some specific examples, how we had to overcome different challenges impacted by the specific technologies used, interaction between servers, and data collection.
    Most of submitted surveys did not require specific developments, but some have instead required a lot of investment to adapt our solutions to Blaise.
    We will present the solutions we found to address these problem, as for example for the development of drag & drop, clickable map, or the need to take pictures.

    Back to the overview
  • Experiences with Blaise 5 Layouts and Templates
    Sharon Johnson, Richard Squires and Michael Johnson
    Census Bureau – United States


    Moving a current Blaise 4 survey instrument to Blaise 5 involves much more than simply converting existing code to run in Blaise 5. With the emergence of touch laptops, tablets, and phones as viable interviewing devices, one must consider these different form factors and how they will impact CAPI survey data collection. The move to Blaise 5, with all of the new features, appears to be the appropriate time to redesign our CAPI data collection instruments so that they take advantage of, and work well with, touch screen devices.

    The Blaise Authoring team has been researching, learning, and testing many of the new Blaise 5 layout and template features in order to determine a reasonable approach for moving forward into Blaise 5. This paper will discuss some of the findings, issues, and challenges we have discovered in this effort. The paper will also review the latest settings we have defined for our Master Template, some of the custom templates that we have identified for our surveys, and how we implemented some of the Blaise 4 features into Blaise 5.

    Back to the overview
  • Census Setup with Blaise 5 Manipula
    Michael K. Mangiapane, Roberto Picha and Mecene Desormice
    Census Bureau – United States


    In the process of CAPI and CATI data collection at the U.S. Census Bureau, Blaise is one of a number of parts that work together to ensure we successfully collect data. Before a survey is fully deployed for data collection using Blaise, it needs the appropriate data from our control and case management systems. One of the first steps in this process is to run a Manipula “setup” script that reads a data file and uses the file’s contents to create individual Blaise databases. These Blaise databases are later loaded on an interviewer’s computer to conduct a survey.

    When Manipula became available in Blaise 5, we researched how we might use it to implement scripts that have the same functionality as our Blaise 4 scripts. We modified our setup script to run in Blaise 5 and tested its functionality versus the original Blaise 4 script. This presented some challenges since Blaise 5 creates and references databases differently than it did in Blaise 4. This paper will discuss how we overcame this challenge and others so that individual Blaise databases were produced by the setup script. We will also discuss other challenges in using Blaise 5 with the setup program and our progress in converting other Manipula scripts from Blaise 4 to Blaise 5.

    Back to the overview
  • Running Blaise 5 Instrument as “stand-alone” Environment
    Roberto Picha and Mecene Desormice
    Census Bureau – United States


    For the last two decades, the U.S. Census Bureau has used Blaise 4 software to collect CATI and CAPI survey data in a “Stand- Alone” environment, where the Blaise instruments interface with the Laptop and CATI case management systems. Our “stand-alone” (self-contained) environment involves the case management systems calling a Manipula transaction script, which in turn makes a call to the DEP via the Edit function. This script binds the metafile and local database containing a record or a single case. This process is highly integrated into the current survey systems that are currently being used at the Census Bureau. It is not an easy task to make drastic changes to this process.

    With new software and hardware technologies emerging in the data collection world, a new paradigm is presented which involves more questions than answers. What is the ideal Blaise 5 environment for interviewing with different operating systems and on different devices? It is most likely a different environment than what is currently used for our CATI/CAPI data collection. Until we can figure out the best approach for this paradigm shift and while we are still running Blaise 4 production instruments, we decided to research what it will take to implement a Blaise 5 production survey in our existing environments (i.e., stand-alone). Can we continue to run our legacy systems with a Blaise 5 instrument?

    This paper covers our experiences in attempting to run a Blaise 5 instrument in our existing control systems environment (i.e., running the DEP as stand-alone). We will share our lessons learned and experiences from this research, how the DEP can act as a service, and how to automate the process for installing of the minimum software required to deploying packages to this environment. We realize that this may not be the best approach for running Blaise 5 instruments, but it was important for us to determine what options we have for running Blaise 5 in production.

    Back to the overview
  • A Web Compatible DEP
    Maurice Martens
    CentERdata – The Netherlands


    The Survey of Health Ageing and Retirement in Europe (SHARE) is currently in its development phase for its seventh wave. This survey uses a centrally developed source questionnaire and using an online translation management environment this source version extended to 40 other country/language versions.

    In SHARE wave 7 the sample was divided into subsamples who are assigned two largely different questionnaires. The larger sample is assigned to a life history calendar questionnaire (like was done in wave3), the respondents who already did a life history calendar were assigned to do a regular interview. The Share wave 3 history calendar was developed in VB6. After some trails, it was decided that reusing this instrument was not wise. Some alternative approaches were reviewed, including using Blaise 5, but ultimately this redevelopment was done in Java, using a browser component providing the freedom to use web techniques combined with calls to the Blaise 4.8 API.

    This Java/browser approach gives us the possibility to implement web techniques in CAPI. This allows for use of jQuery, and JavaScript code for CAPI. It allows for use of interface design using stylesheets JavaScript solutions developed for CAWI mode can be reused in CAPI mode. Using this technique we were able to rapidly implement more advanced features like a history calendar, autosuggest lists, and word-recall list in a short time without major changes to the Blaise questionnaire.
    This paper discusses the route that led us to this architecture and will showcase some exiting implementations, within the context of the SHARE multi-mode, multi lingual, multi-questionnaire panel study.

    Back to the overview
  • Experiences with Collectica
    Felix Coleman
    Central Statistical Office – Ireland


    There is currently a transformation program taking place in the Social statistics environment at the Central Statistics Office. A program is under way to develop a more process orientated approach to the production of national statistics. In order to facilitate this transformation, the social statistics survey design team is utilising the DDI metadata environment to integrate the transfer of statistical metadata through its statistical production environment. The transformation is designed to develop best practice principals around the creation and storage of statistical metadata. One of the key developments in the work is the systematic mapping of survey design in DDI to the Blaise survey instrument environment and then the "carrying through" and supplementation by Blaise of additional metadata, as data exits from the data collection phase provided by Blaise. This presentation will describe the progress to date with this work and highlight some of the challenges and solutions that have been experienced with the transformation.

    Back to the overview
  • Using Audit Trail data to move from a Black Box to a Transparent Data Collection Process
    Jaqueline Hunt
    Central Statistical Office – Ireland


    CSO is currently transforming the management and administration of all its household surveys. Part of this transformation is the introduction of CATI for the LFS waves 2-5. The telephone interviewing is being outsourced and all CATI interviews are being conducted by a third party service provider. The contract negotiated by the office for the service is based on the duration of calls. Early testing with the call centre revealed using timestamps embedded in the questionnaire as a method of generating interview durations did not provide the accuracy required for contract purposes. This led us to look at an alternative method to calculate the interview durations. Our previous use of Audit Trails was limited to using the data to recreate corrupted interviews and for ad-hoc analysis to investigate incidents of unusual interviewing behaviour. The third party contract requirements led us to investigate how we could use the audit trail data to extract more accurate interview durations. As part of the design process we examined other potential uses of the Audit Trail data, such as creating key process indicators that can be used to monitor and improve the data collection process. This paper will look at our design approach and the solution that has been implemented as part of the Household Transformation project.

    Back to the overview
  • Converting a Blaise 4.8 Survey Instrument for Tablet Use
    Michelle Keniry, Caroline Donegan and Conor MacDomhnaill
    Central Statistical Office – Ireland


    In 2015 our field interviewer's laptops were reaching end of life. The dilemma we faced was to buy more laptops or look at alternative devices that were more suitable for mobile working. The focus of this paper is our experiences adapting our Blaise 4.8 survey instruments and management user interfaces to make them suitable for tablet use.
    There are three main aspects we will cover, firstly the technical challenges we faced with development and design, these include the requirement of a keyboard for text input, coding and searching in 'Browse' view and the problems encountered when system keyboards interacted with some Blaise functionality. The options and solutions implemented to cater for both right and left hand users and decisions on Font and button images. Secondly, we will look at the expectations, challenges and training issues encountered by the field interviewer and how their feedback and interactions were invaluable when determining the scale and priority of improvements required for future development. Thirdly, our request for some functionality change to CBS Blaise developers and how Blaise 4.8.5 addresses a number of the challenges we faced.

    Back to the overview
  • Blaise 5 – Is Worth the Wait
    Mark M Pierzchala
    MMP Survey Services, LLC – United States


    There are 2 ways to understand the title of this talk:
    • Blaise 5 – Is Worth the Wait?
    • Blaise 5 – Is Worth the Wait!
    In other words, is the title a question or is it a positive statement of fact?

    Blaise 5 has taken a long time to come into production. Additionally, most of the institutes that have tried Blaise 5 have struggled with its concepts, especially with devising and applying templates that work across devices and screen sizes. This paper addresses these experiences and gives some new perspectives.

    This talk will start by demonstrating the fundamental difficulties with fielding complex governmental and scientific surveys in the modern survey environment. This is a hard problem that few people or institutes truly appreciate. Governmental and scientific question types and question structures can be long, large, complex, and multi-faceted. And these days, instruments must be multicultural, multi-device, multilingual, multimodal, multinational, multi-operable, multi-platform, multi-structural, and multi-version (the ‘nine multiples’)!

    The presentation continues with explaining how Blaise 5 development has steadily been addressing these difficult needs. Indeed, new features (in Blaise 5.0.5 and 5.1) make it much easier to build instruments that address the ‘nine multiples’.

    The talk then will argue that institutes must approach specification and instrumentation in fundamentally improved ways. For example, it is not difficult to find questions that must be formulated differently across devices. Further, the testing of survey instruments is profoundly more difficult than before. It’s not only that there are so many devices out there, but that the institute no longer controls which devices will be used and by whom!

    This paper proposes solutions to these most difficult problems and shows how Blaise 5 can work for your institute. It explains how institutes must adjust their approach to instrumentation including specification, development, and testing. By the end of the talk, perhaps you will agree that Blaise 5 has been Worth the Wait.

    Back to the overview
  • The Champion Instrument Suite in Blaise 5
    Mark M Pierzchala
    MMP Survey Services, LLC – United States


    A suite of 10 demonstration and survey instruments will be part of the system distribution of Blaise 5.1. It is called the Champion series because it features polished instruments that show off Blaise 5 capabilities. Six of these are called B5 instruments. They have the names B5Basic, B5Modest, B5Complex, B5Scales, B5Cultural, and B5CodeFrame. They each show a specific range of features. For example, the B5Scales instrument shows how various kinds of scale questions can be handled.

    There are 4 survey instruments including NCSPerson, a commuter survey in 10 languages (English, Dutch, French, Spanish, Greek, Hebrew, Arabic, Hindi, Chinese, and Japanese). A Retail Trade Survey is based on a Dutch financial survey. It shows non-linear section navigation. There is a Census-like instrument for data collection on mobile devices that is in English and Spanish. Finally, there is an Annual Survey of Industry. It represents a North American survey of industries in Canada, the United States, and Mexico. It uses English, French and Spanish and it is a Blaise 4 CATI and Web survey converted to Blaise 5.

    All of the Champion instruments are multimode and all have at least 2 languages. They use a common Resource Database called Champion.blrd. The Layout Designer of each instrument has 8 Layout Sets that work for different modes on different devices. New source code features are used such as MODES, SPECIALANSWERS, SPECIALANSWERSETS, and FIELDPROPERTIES.

    The range of devices that are targeted includes smart phones, tablets, and computers; using native apps or Dep, or their browsers. The Champion.blrd Resource Database can be used out-of-the-box for your institute. You can also use it as a good start to make their own Resource Database. The Champion instruments form a test suite of instruments and questions that institutes can use in their own validation tests. There are at least 200 different question and question-structure types that have to work on all those different devices. This series of instruments gives you a ready test suite.

    Back to the overview
  • Converting a CATI Instrument from Blaise 4 to Blaise 5 for Pilot Testing
    Emily Caron and Vito Wagner
    National Agriculturatl Statistics Service – United States


    Kathleen O'Reagan
    Westat – United States


    This project was a collaboration between Westat and NASS. For an ongoing data collection we began to explore how to convert a Blaise 4.8 CATI instrument for multi-mode Blaise 5 data collection. The study involves collecting information about agricultural products. Respondents report on an annual basis so there are many complex edits between questions and a number of questions involving multiple responses and grids.

    We describe our initial approach to converting this instrument and using the default layouts available in Blaise 5. A goal of the conversion was to test the available Blaise 4 to Blaise 5 tools and determine if the code would run successfully as a connected web application as well as through an app on iOS tablets or phones. We present information about the conversion tools used and the process of creating software for a pilot test of this survey in Blaise 5.

    Back to the overview
  • Converting a Paper Collection Exercise to Collecting Data on a Tablet
    Emily Caron and Vito Wagner
    National Agriculturatl Statistics Service – United States


    Kathleen O'Reagan
    Westat – United States


    This project was a collaboration between Westat and NASS. For an ongoing data collection we began to explore how to convert a Blaise 4.8 CATI instrument for multi-mode Blaise 5 data collection. The study involves collecting information about agricultural products. Respondents report on an annual basis so there are many complex edits between questions and a number of questions involving multiple responses and grids.

    We describe our initial approach to converting this instrument and using the default layouts available in Blaise 5. A goal of the conversion was to test the available Blaise 4 to Blaise 5 tools and determine if the code would run successfully as a connected web application as well as through an app on iOS tablets or phones. We present information about the conversion tools used and the process of creating software for a pilot test of this survey in Blaise 5.

    Back to the overview
  • Blaise Instrument Extensions with Alien Routers and Manipula
    Lilia Filippenko, Chris Carson, Orin Day and Mai Nguyen
    RTI International – United States


    RTI International has conducted many studies involving field data collection on laptop computers. Most of these CAPI interviews are conducted in respondent’s homes and then data is transmitted to RTI. While collecting data for researchers, often sensitive personal information is provided by respondents. This data should be protected on the laptops and during transmission.

    There are different ways to do that and we will present one of them – using Alien Routers and Manipula to:
    • Enter sensitive data outside of Blaise interview and encrypt it, bypassing the audit trail record;
    • Call external application to electronically obtain proof of respondent consent or other information, either via electronic signature pad or digital document scanner. The completed forms are saved in encrypted files on laptop;
    • Download GPS data from a GPS-tracking device into the instrument at the end of the interview. This data is used later for verification purpose.
    The paper will describe how external applications are used and will have examples of code in Blaise instrument and Manipula.

    Back to the overview
  • Statistical surveys in households and by individuals in Slovakia – the Use of Blaise 4 / Blaise 5
    Ľudmila Hadová, Danica Tureková
    Statistical Office of the Slovak Republic


    Data collection and processing for statistical surveys has been conducted for several years by programs developed in Blaise 4. It has been used for Social Statistics, Demographics and Conjunctural Surveys. In the year 2016 this includes:
    • The Labour Force Survey (LFS)
    • The Survey on Information and Communication Technologies in Households and by Individuals (ICT)
    • The Household Budget Survey (HBS)
    • The Consumer Survey (CS)
    • Statistics on Income and Living Conditions of Households (EU SILC)
    • And more
    With respect to questionnaire content, both - wording and methodology comply with European regulations. The obtained data are sent to Eurostat, while they are also used in national statistics.

    Most of household surveys uses address based sampling. The interview process requires a special management and places heavy demands on the software. The program has to be user friendly and to conform to using Windows tablets and CAPI method for face-toface interview. We make intensive use of Blaise 4 not only to design screens, incorporating multiple checks at an early stage of collection, but also for survey progress monitoring.

    Among the many objectives, the main, and most significant, is the quality of the data. The data have to be verified and subjected to various controls and comprehensive protocols (using manipula). Checks of some surveys are extended to include the data obtained in the previous period for comparison with the new values.

    Nowadays, we are in a period of study and transformation of simple programs to Blaise 5. The big challenge for us is a fully functional transformation of our most complex EU SILC survey.

    We offer a preview of some our issues and solutions.

    Back to the overview
  • The Uses of Blaise Paradata at Statistics Canada
    Éric Joyal
    Statistics Canada


    The increasing use of computer-assisted data collection methods has provided a wide scope of ongoing and timely process data called “paradata”. The “call transaction history” file created by the Blaise system contains a record for each call made by interviewers to contact the selected units and the “audit trail” which collects each interviewer’s action during the interview process are two examples. Both files have become a tremendous source of information.
    Until recently, “paradata” were essentially used to monitor, evaluate and report survey progress using only a subset of available information. Over the last few years, many survey researchers have demonstrated the usefulness of paradata in the data collection context and have greatly improved the understanding of this complex and evolving process. In addition, paradata are used (and continue to be used) to identify strategic opportunities for data collection improvements for which active management and responsive design initiatives are good examples.
    At the same time, it is also well recognized by many survey researchers that paradata can also be of great methodological use in many other survey steps prior and after data collection, for example, questionnaire design, non-response adjustment or estimation.

    The main objective of this paper is to provide an overview of the historical use of paradata at Statistics Canada for planning, managing, monitoring, improving and assessing the survey process which includes both operational and methodological aspects.

    Back to the overview
  • From Blaise 4 to 5: Systems in Transition
    Leif Bochis Madsen
    Statistics Denmark


    For more than 15 years Statistics Denmark has used Blaise 4 as a tool for data collection for a wide range of surveys. During this period of time a lot of effort has been made to tailor systems and utilities covering Questionnaire Development, Survey Management, Sample Management, Case Management, Post Processing, etc. in order to support fast, efficient and automated processes.
    When moving to a new generation of the basic software it is important to assert that the production system supports all the necessary sub systems in order to keep productivity high, as well as considering which parts of the system that should be revised.
    This paper aims to describe the general data collection system at Statistics Denmark/Survey division and the work needed identifying, prioritizing and migrating or changing the sub processes of this system.

    Back to the overview
  • From CPI to CPIX
    Gerrit de Bolster
    Statistics Netherlands


    In order to collect data for the Consumer Price Index (CPI) a stand-alone Maniplus 4.8 application was developed in 2013. Based on a list of shops, it uses several dialogs with lookups and functionality to edit the price and weight or size (quantity) of a pre-defined set of products that can be found in the selected shop. As an experiment, this Maniplus 4.8 application was converted to a Blaise 5 questionnaire (CPIX) to be used with the data entry program (DEP.exe). The extended and powerful functionality of Blaise 5 made it possible to support more or less the same functions available in Maniplus 4.8 in a Blaise 5 questionnaire. However, the layout was adapted for Blaise 5. The paper will show how the Maniplus 4.8 functions were converted to Blaise 5 fields and rules.

    Back to the overview
  • Adventures of a Blaise 5 API Jockey
    Rod Furey
    Statistics Netherlands


    The Blaise 5 Application Programming Interface (API) can be used to access the various underlying objects of the Blaise 5 system in various programming languages. This allows us to manipulate and present these objects to our own advantage. Of interest are items such as the ability to retrieve the name and types of the fields in a datamodel for presentation and documentation purposes; the ability to retrieve and set the values of fields in a Blaise database, thereby allowing us to write our own language; the ability to retrieve information from the session database to check for recent activity; and the ability to retrieve the layout instructions, thereby allowing us to group questions for graphical display and documentation purposes. This paper discusses various cases where such Blaise 5 API calls have been used in production systems and testing tools.

    Back to the overview
  • Blaise 5 at Statistics Norway
    Trond Båshus
    Statistics Norway


    Statistics Norway has used Blaise 5 since late 2014. We decided early on to gradually replace Blaise 4 for web survey since we felt it to be increasingly outdated, especially the handling of layout and support for different devices (although we have had success with CMoto from CentERdata). Our view was then that Blaise 5 was superior for web surveys, despite of several crucial features that were still lacking.

    An important feature which was not finished in 2014 was Manipula. We overcame this by using the supplied data conversion utilities which allowed us to process data with external tools i.e. Blaise 4 Manipula or SAS. Another sorely missed feature was support for other database engines, which made access to Blaise data rather troublesome.

    For the last couple of years new features has been added to Blaise at an impressive pace, which is good, because we now have many of the tools we have missed. But this has also presented us with challenges, the most important one that it’s not advisable to upgrade a production server with active surveys without doing extensive (and expensive) testing first. Our solution to this challenge has been to set up two parallel production environments.

    Even though the setup survey layout has greatly improved in Blaise 5, it can still be a challenge. Especially if there is a need (which there often is) to make changes to the resource database. The resource database is large and be confusing, perhaps much because of the extensive dependability between elements in the database. One of the great horrors of Blaise 4 can still present problems: namely tables. In addition extensive testing with different browsers and devices is still very important.

    Blaise 5 now has many features we have waited for: Manipula, support for MySQL (for survey and audit trail data). The next step is integration with our Case management system (just around the corner), and thereafter exploration the CATI-functionality in Blaise 5.

    Back to the overview
  • Using Survey Paradata
    Gina Cheung, Andrew Piskorowski, Lisa Wood, Hueichun Peng
    University of Michigan Survey Research Center – United States


    Paradata that are captured during the survey process are a valuable source of information in helping us understand and improve the data collection process.

    One of the advantages of using Blaise for survey data collection is the rich capture of paradata that is native to the application. Paradata which are linked directly to the administration of a survey instrument are collected automatically through the Blaise software (i.e., audit trail). The ADT file from Blaise 4 has been very valuable in understanding interviewer behavior. With the advent of BlaiseIS and Blaise 5, we now are able to increase the richness of our paradata collection for understanding respondent behavior on web-SAQ (self-administered questionnaires) and/or mixed mode projects (i.e., interviewer and web-SAQ combined).

    The main focus of this paper will be to provide some practical examples to illustrate how the survey paradata can be used to inform decision making throughout the data collection process and assist in fieldwork monitoring.

    Specific practical uses include:
    • Examining question timings and survey routing (i.e., which questions were asked but not answered and which questions were not seen due to survey logic?)
    • Improving questionnaire design (including mobile survey design)
    • Recovering lost survey data
    • Identifying issues related to quality control
    • Understanding respondent and interviewer behavior within a survey
    These examples will illustrate the value of the native Blaise paradata and the supplemental survey paradata captured at the University of Michigan. Also some of the challenges/limitations of the native Blaise 5 paradata will be considered.

    Back to the overview
  • Chitwan Valley Family Study Household Registry: Paper to Computer-Assisted Interview
    Karl Dinkelmann, Stephanie Chardoul
    University of Michigan SurveyResearch Center – United States


    Bishnu Adhikari
    Institute for Social and Environmental Research – Nepal


    The Chitwan Valley Family Study (CVFS) is a longitudinal data collection effort conducted by the Institute for Social & Environmental Research – Nepal (ISER-N). The CVFS has been conducted since 1996 and includes full life histories for more than 10,000 individuals. The study investigates the influence of social contexts on population processes and the relationships between the environment and population processes (http://spe.psc.isr.umich.edu/research/cvfs.html). For more than 15 years, the ISER-N staff used complex paper questionnaires, where monthly household data were collected for individual members living, marital, pregnancy, and education status. The paper instrument included extensive hand transferring of data between forms and from wave to wave.

    In 2013, a team at the University of Michigan’s Survey Research Center began a collaborative effort with an ISER-N team to convert their CVFS Household Registry’s paper instrument to a Computer-Assisted Interview (CAI) application. This paper discusses the challenges and complexities of converting a multi-member multi-component longitudinal household registry paper instrument into a fully dynamic CAI application. This paper will include:
    • An overview of the CVFS Household Registry paper questionnaires and the advantages and disadvantages of using paper vs. moving to CAI.
    • Unique CAI features including: 13 Blaise parallel blocks with a household status tab offering the flexibility to update family composition and collect individual monthly member information seamlessly while bringing survey components online or offline as eligibility criteria are met.
    • The ability to “spawn” up to three additional Blaise data models on the fly from the main Blaise application to collect an individual’s away status, marital status, or childbirth within any given month.
    • Obstacles encountered and review of areas where efficiencies could be applied to the CAI application to aid in the administration of the CVFS.
    • Future developments based on the success of the CVFS Household Registry conversion to CAI and lessons learned from this complex multi-member and multi-component application that can be applied to future projects.


    Back to the overview
  • Blaise 5 Development at University of Michigan
    Youhong Liu
    University of Michigan Survey Research Center – United States


    We have used Blaise 5 for two survey studies at the Survey Research Center, University of Michigan since two years ago. Blaise 5 and Blaise 4.8 are similar in some ways, but are also different in many other aspects. The two studies we have developed are complex in many areas. One of them is converting a large Blaise 4.8 survey into Blaise 5. In this paper, we are going to discuss the converting steps, the challenges we have faced, and the outcome of the project. The second project is an Army Mixed Mode Survey. In order to make the survey flexible, and to present users with friendly interfaces and experiences, we have designed and implemented many different features. We will present how the mixed mode functions are achieved, and how is the challenge requirements programmed. In additional, Blaise source programming, Blaise layout setting, and resource database development will also be discussed. In web survey world, security is very important. In this paper, the user authentication method for the surveys will be presented.

    Back to the overview
  • Designing and Implementing APIs in Blaise 5: Some Technical Examples
    Max Malhotra
    University of Michigan Survey Research Center


    Using Blaise 5 for self-administrated surveys posed unique technical challenges due to the complexity of survey design and stringent requirements pertaining to response collection of self-administered web respondents. These requirements mandated the design and implementation of unique back-end APIs that needed to be concise in their delivery so that they could be quickly integrated into a survey using role text to pass parameters from the Blaise 5 data model to the API. This paper looks at how Blaise 5 capabilities and features work with the creation of the aforementioned APIs and we shall show some practical examples of how some of these functions can be best utilized. A technical discussion of issues encountered, what worked well and lessons learned.

    In particular, we will discuss:
    • Select All, Clear All (Checkbox)
    • Mutually Exclusive Response (MER) with Clear All (Checkbox)
    • Select Mutually Exclusive Response (MER)
    • Other Specify
    • Other Specify to clear out textbox
    • Single text box with single radio button
    • Multiple textboxes with single radio button
    • Single textbox with multiple radio buttons
    • Multiple dropdown menus with single radio button
    • Multiple dropdown menus with multiple radio buttons
    • Multiple dropdown menus with multiple radio buttons and with textbox
    • Disable Radio Buttons If Mask Textbox Is Zero or Empty
    • Disallowing browsers based on browser type and/or browser version
    We shall provide a demo of some of the above mentioned custom user interface functionality at the conference.

    Back to the overview
  • Data-out Experience/Challenges in Blaise 5
    Mohammad Mushtaq and April Beaule
    Panel Study of Income Dynamics, University of Michigan


    Blaise 5 web interface was used to collect data from Opt-In Pilot 2015. At the time of data collection, a limited number of data-out utilities were available. The data extraction from Blaise 5 became a challenging task. The available data-out options were flat file and xml data format and previously developed tool for Blaise 4 were not working successfully with these options. Using available data-out options in Blaise 5, the data were extracted into Blaise 4 compatible flat file. Then it was imported into SAS, the wide tables had 11664 and 11970 variables from two survey instruments V1 and V2 respectively.

    Using knowledge of core interview instruments from prior years, Blaise 4 extraction and reverse engineering method of data transformation, the wide data files were transformed in relational data structure. First, identify interview sections (Housing, Employment, etc.) and create data files by sections – this is household level file with sample id (SID) as primary key. Second, identify arrays and loops from each section and stack data by loop instance into level-one tables from each section (parent table), remove loop-one variables from parent table. Third, some sections had nested loops (loop inside of loop), therefore, data from these sections were further stacked by loop-two instance and loop-two variables were removed from loop-one table. As a result of this relational transformation, the table structure is matching with PSID 2013. Using same method, the data from All Stars 2016 can be compared with data from PSID (CATI) 2015.

    The data-out task would have been much simpler if ASCII-Relational output option in Manipula can be made available sooner so that projects like the PSID can benefit from existing data processing tools.

    A second major hurdle that we have to find a solution for with Blaise 5 is identifying questions that are ‘on the route’ but not answered versus questions ‘not on the route’. For self-administered web questionnaires where respondents may just skip a question, it is imperative for data processing that we can easily identify which questions were presented and not answered so that we can properly document the universe of each question in the codebook and generate the appropriate frequencies for valid responses.

    Back to the overview
  • Capturing Survey Paradata
    Hueichun Peng
    University of Michigan Survey Research Center – United States


    Paradata that are captured during the survey process are a valuable source of information in helping us understand and improve the data collection process.

    One of the advantages of using Blaise for survey data collection is the rich capture of paradata that is native to the application. Paradata which are linked directly to the administration of a survey instrument are collected automatically through the Blaise software (i.e., audit trail). The ADT file from Blaise 4 has been very valuable in understanding interviewer behavior. With the advent of Blaise IS and Blaise 5, we now are able to increase the richness of our paradata collection for understanding respondent behavior on web-SAQ (self-administered questionnaires) and/or mixed mode projects (i.e., interviewer and web-SAQ combined).

    The team at the University of Michigan has implemented a process to capture paradata from the client-side using JavaScript. This client-side paradata (CSP) can capture movement within a page on the respondent’s or interviewer’s device like scrolling and mouse-clicks. As research interest has been strong in using these paradata to analyze respondents’ behavior, we are working to capture more events like “loss of focus” and “geolocation”. Furthermore, as more and more respondents start to use mobile device to take web surveys, we added a new library to capture the events specific to mobile device such as tapping, orientation change, pinch-in, etc. As the University of Michigan has been investigating using tablets (mobile) for CAPI interview due to cost and efficiency consideration, the capture of mobile paradata will be crucial for analyzing interviewer’s behavior as well.

    We will share what we have learned and the challenges we have considered, with the intent that other Blaise 5 users can also supplement their paradata capture.

    Back to the overview
  • Blaise 5 Data In/ Data Out
    Andrew Piskoworski
    University of Michigan Survey Research Center – United States


    The focus of this presentation is to demonstrate various methods used to move data in and out of the Blaise 5 databases. We will show you how the team at the University of Michigan is combining custom tools with manipula to improve the process of accessing the Blaise 5 data.

    Survey Preload
    We have a windowed application that will preload a Blaise 5 data model. In addition to simplifying the preload process, this application allows for incremental updating and adding of sample rows to the project database.

    Survey Migration
    Sometimes during data collection, a new version of the survey questionnaire may need to be released. This may happen from an error in original programming, an update in question text, or a change to response options.
    This data migration (from the old version to the new version) is needed can be challenging if respondents have already started and suspended on the old version. We want to ensure that we do not lose their data from the old version, and we want to make sure that they can resume the survey where they broke off. We will demonstrate our process for this complex data migration.

    Survey Download
    We have created various processes for getting data out of Blaise 5.
    • Manipula and SAS/Metadata - We have developed automated processes for delivery of raw data from Blaise5. This includes export to a SAS database which integrates code frames and other metadata.
    • MQDS - Our latest version of MQDS also allows for the downloading of the survey question text and other metadata. This is useful in creating a survey crosswalk - a spreadsheet that maps the survey data responses to the survey questionnaire. MQDS also allows for exporting selected fields into a text file.


    Back to the overview
  • Transforming Survey Paradata
    Lisa Wood and Andrew Piskorowski
    University of Michigan Survey Research Center – United States


    Paradata that are captured during the survey process are a valuable source of information in helping us understand and improve the data collection process.

    One of the advantages of using Blaise for survey data collection is the rich capture of paradata that is native to the application. Paradata which are linked directly to the administration of a survey instrument are collected automatically through the Blaise software (i.e., audit trail). The ADT file from Blaise 4 has been very valuable in understanding interviewer behavior. With the advent of Blaise IS and Blaise 5, we now are able to increase the richness of our paradata collection for understanding respondent behavior on web-SAQ (self-administered questionnaires) and/or mixed mode projects (i.e., interviewer and web-SAQ combined).

    The main focus of this paper will be to share a process to make these sources of Blaise 5 paradata more usable for analysis and reporting. The native Blaise 5 paradata, the user agent string, and the University of Michigan’s client-side paradata (CSP) are unstructured data and very cumbersome to “untangle”. To make these data more useful for analysis, various data management techniques are applied with the following goals.
    • Parse this unstructured data (e.g., SAS, Python, SQL)
    • Calculate new measures (e.g., time on/time between page, last question seen/answered)
    • Aggregate data at various levels (e.g., page-level, session-level, respondent-level)
    In addition, reporting tools such as OLAP cubes and SSRS (SQL Server Reporting Services) are used to distribute the data to various user groups (e.g., PIs, production managers, statisticians, etc.). The resulting output is also available in a SQL database and can be accessed using other reporting and analysis tools. The transformation techniques and standard paradata reports can be implemented by any user of Blaise 5 paradata to enhance the use of this data.

    Back to the overview
  • DEP Unlimited: Solving Complex Run-Time Problems with Manipula
    Rick Dulaney and Peter Stegehuis
    Westat – United States


    The Blaise 4.8 Data Entry Program has the capability to shell out to Manipula, which allows us to solve some difficult problems during data collection.

    We will show three examples:
    1. When selecting dates, it can be desirable to use a graphical date-picker rather than the Blaise Date type. We use Manipula to establish the allowable date range, to display and manage the date-picker, and to store the resulting data in the active datamodel.
    2. There are times when it is desirable to add “off-path” data during the course of an interview. We describe some advantages of using Manipula rather than parallel blocks.
    3. The visible components and controls available in Manipula can provide a very effective tool for managing lists or rosters. In addition to displaying and selecting items from the list, we can use Manipula to allow additions and modifications to the list as well.


    Back to the overview
  • Capturing Signatures Electronically from a Blaise Instrument
    Todd Flannery and Ed Dolbow
    Westat – United States


    For a large study of adults collecting bio-specimen samples and other items, we were required to have signed consent forms from household members during a CAPI interview. In some cases up to 8 consent forms and incentive receipts were required per household. These were collected from both adults and youth in the household. It became clear during the field test that the paper management required of the field interviewer and the paper tracking required of the home office was excessive and error prone. We devised an electronic signature approach and integrated it into the Blaise instruments to solve the problem.

    We use Blaise 4.8.4 to collect data related to the consent or receipt; call a .NET application (C#) passing along the relevant data; capture the e-signature; and return key data to the Blaise instrument. In addition, we store and encrypt a PDF file containing the statement and signature associated with the participant.

    Our paper will discuss the process of having Blaise administer an electronic e-signature application for the purpose of collecting and documenting these household consents and any associated incentives, the limitations of using a shell-to-EXE application, as opposed to activation of a DLL as an alien router, and adapting the e-signature procedure to Blaise 5 for administering future surveys to this population.

    Back to the overview

 

Click here to go to the IBUC-site.

Gaining deeper understanding