Diary Entry App for Researchers

Sachin Kumarswamy, Darshan Sangal Ramesh, Ankit Kulshrestha

Goal

The aim of the application is to help researchers who are willing to collect data using diary study. The application will serve as stand-alone material, which is configurable according to the needs of the researcher. The desktop-application can be used to configure the questions and tasks to be completed by the participant and the application will be used to update the diary by the users/participants. This way, the report can be pulled directly from the database to have a smooth, less-nosy way (than already it is) of collecting data from the participants.

Introduction

Diary study is one of the frequent ways of gathering data for a research. In a diary study, participants are asked to record their daily activities on a preprinted log form. The activities are initially recorded using the participant’s own description, i.e., “had dinner with Kelly,” or, “dentist — ouch!” Later, all activities are assigned to predefine categories, such as “mcais” or “physical exercise.” Diaries are typically kept for one or two weeks; any longer would be a burden for many participants. The diary record itself is usually supplemented with a post-study interview of the participant, addressing behavior over a longer term than the diary covers (Rieman, 1993).

Implementation of diary studies often requires participants to frequently, and even daily, discuss diary entries with the investigator (Rieman, 1993). Frequent investigator involvement, especially initially, also ensures that participants understand the scope and descriptive depth needed for the diary entries. One of the challenges in diary studies, in fact, is convincing participants that seemingly mundane and low-level activities really are of research interest. Calibration of diary entries with investigators is necessary for garnering the type of data required. Another challenge that frequent investigator involvement helps mitigate is declining dedication to diary entry. Investigator involvement helps in keeping interest high and reminds participants of the importance of the diary in data collection.(Palen & Salzman, 2002).

In one of the studies, (Church & Oliver, 2011), participants were asked to record their mobile Internet sessions in a Web-based diary tool made available online. The diary tool was accessible from both mobile and desktop Web-browsers and was designed to capture the motivations and intent surrounding mobile Web accesses while minimizing the time burden on the participants. While this study used a more advanced way of capturing, however the dependency of accessing link online was present. Also, it was limited to this study only, and if one had to use the same setup in another study, it would need a complete redesign of the study method.

Existing work

There a numerous emerging applications in this field, which either lack real time configuration from desktop dashboard or are only made for mobile (Diaro). Later the researcher has to check the application to collect all the data after the study has been completed. This is not so different from conducting physical diary study (Nativeye).

Design

Sampling

The target users for the application are researchers who would have used diary study in the past or plan to use in the feature. The approach involves qualitative research methods, with snowball sampling and criterion sampling as its central sampling method, yet being purposeful. Snowball or chain referral sampling is a method that has been widely used in qualitative sociological research. The method yields a study sample through referrals made among people who share or know of others who possess some characteristics that are of research interest (Biernacki & Waldorf, 2016). Criterion sampling involves selecting cases that meet some predetermined criterion of importance (Patton, 2005). In this case, researchers who are familiar with diary study.

For this project, we sampled one professor who is familiar with the diary studies and two students who had working knowledge of how diary study is conducted. No incentives were provided for the participation.


Data Collection

The Application has three main sources of data. Informal conversational interview (Patton, 2005) was conducted where the questions emerge from the immediate context and are asked in the natural course of things. It took about 30 minutes to gather the data from the participant. Two more interviews were conducted, about 15 minutes each with the students who were familiar with the diary study.


Data Analysis

The data collected from the interview was analyzed using the affinity diagramming method (Nayak, Mrazek, & Smith, 1995). Affinity diagramming is a popular method use to analyze the data, by segregating quotes, notes, etc. This is later sorted to find the patterns. From the affinity diagramming we extracted several main requirements.

  • The application needs to have two elements, one to configure from desktop and other to be used by the participant to store the data.
  • The researcher should be able to create the research, and should provide a key to user to login. This way he can maintain multiple researches.
  • The researcher should be able to create different questions under the particular research. These can also be tasks to be completed by the user.
  • The researcher should be able to set the notification frequency and time period for the question set to be appeared on the mobile application.
  • The participant should be able to disable the notification if desired.
  • The researcher should be able to disable/enable the questions or the question set as desired.
  • The researcher should be able to create keys, to give access to the participants.
  • The participant must be able to enter the key to access the research, to answer the questions.
  • The data from the participant must be synced to the database at all the times, so that researcher can access data anytime he desires.


Conceptual design and Prototyping

We used the above requirements to drive our prototyping and created some prototypes for both mobile and desktop applications. We used the Balsamiq tool for rapid prototyping. Below are some of the screenshots for the same.



Usability testing

The interactive Balsamiq prototype was used to test with users. For this purpose, three users were sampled with convenience. All the participants were from computer science field and usability evaluation was conducted by turning user goals into task scenarios (Neilsen Norman Group). Users were given the time of 2 min (this time was determined as average of the time taken by us to complete a certain task + 40% more time as a buffer) to finish each task and the issues or the problems faced by the users were duly noted. The participants were performing the actions with think-out-loud criteria and about 3 issues were detected and were subsequently fixed in the next iteration. These issues involved, changing the

plus
symbol, and adding an
add button
instead, to give more space for the user and better enable Ffitt's law (Bi, Li, & Zhai, 2013) in action. Another issue involved changing the
tick mark
from answered question to a colored block. This created less obstruction on the screen. Finally, participants wanted camera functionality to directly take picture, rather than uploading an existing image. This made sense, since it was one less step for users.

Develpment

An extensive study was conducted to determine the optimal way of implementing the solution. Most of us were not familiar many popular development technologies. We decided to go ahead with the SQL 2012 database from the AZURE cloud hosting site by Microsoft.

Visual Studio 2015 was used as the development IDE for the back-end development of the application. We used ASP.NET WEBAPI as the programming framework for the application. ASP.NET Web API is an ideal platform for building RESTful applications on the .NET Framework. RESTful APIs (Fielding, 2000) were created using the C#.NET programming language with the JSON endpoints as the API endpoints. These API’s were hosted on the AZURE website as the AZURE web app.


Courtesy: Maks Surguy's blog

This model is popularly known as the MVVM model of development.

Courtesy: Irmak Tevfik, Creating Universal Apps (MVVM) with Repository to get data from Services using Entity Framework as ORM hosted in Microsoft Azure

The application is developed basically with Model-View-View-model as the API framework. The application had the entity framework as the data layer from which the CRUD operations (GET, PUT, POST, DELETE) are created to enable the endpoints at the view. Entity Framework (EF) is an object-relational mapper that enables .NET developers to work with relational data using domain-specific objects. It eliminates the need for most of the data-access code that developers usually need to write. LINQ (Language Integrated Query) queries were used to talk to the database to enable the CRUD operations. The transaction flow example can be as follows.

Courtesy: elvisboats, MVVM flow

We developed the mobile application, with iOS as platform. We used the AFNetworking framwork to develop the app for iphone. CocoaPods was used as dependency manager for Objective-C, which automates and simplifies the process of using 3rd-party libraries like AFNetworking in the projects. For the desktop version, we used the Asp.NET web froms, with AngularJS as the API client. CORS (Cross-Origin Scripting) was enabled to enable the communication between the API and the AngularJS client.


Evaluation

The developed application was again submitted to the user acceptance testing. The user acceptance test (UAT), (Leung & Wong, 1997) is the final stage of testing in application software development. When testing results meet the acceptance criteria, the software system can be released for operational use. We sampled 3 more students for the testing to try the application. We consulted the professor for the Acceptance testing and a small test was conducted to see the results.

There were minor software glitches, apart from that most of the tests were passed with minimal errors and frustration levels. We encountered various issues, such as Purdue network blocks the azure services automatically, building a work around was hard. Another issue we faced was related to the iOS development. We written all the code for the netification to appear based on the date and frequency, but it required us to get the developer account, which involved fairly big sum of money. This was tried and tested in emulater, but could not be tested in the real application. Other issues we faced some of the issues such as database concurrency errors, which happens, when two people access and update the record from the table at the same time. This required us to drop the tables and recreate everything, and build concurrency defense in the system. Finally, the product was ready to be used by the users.


Demo Video

Acknowledgements

We would like to thank Dr. Alex Quinn, our instructor who has inspired us to create the application set. Most of the usability concepts that went into the applications were directly inspired by the series of lectures in the class. We would also like to acknowledge the efforts of Department of ECE at Purdue for introducing this interesting course and also to the Microsoft AZURE hosting services for providing free hosting of the application.