Update for Nico 02/27/17-- Putting it all together

This week Hugo and I have made a lot of significant updates to our group's software. These updates were made to prepare to demo the application for our advisors, and to get the application ready to record a use video which we will present at SITE 2017 on March 09.

Between my last post and meeting with our advisors last Thursday, I rewrote our authentication generators to generate random output, made a webapp to generate attendance sessions with associated random authentication key, made verifying the authentication more generic by making it a simple string-comparison between the sent authorization and the session's auth key, and sent some simple JSON to the application. We presented this to our advisors, who asked that we prepare for a demo this Thursday.

Hugo and I spent several days outlining the JSON-based protocol by which the client and app communicate. Hugo also set up a SQLite database to test with before we move on to a MySQL database in the near future. We worked on the client and server over the weekend, and the server now verifies all four types of attendance methods, checks time stamps, logs in, modifies passwords, generates attendance sessions, displays dynamic course data, has test users for our advisors, uses a database table for all relevant data, no longer uses HTML Basic Authentication, and communicates all of this with the client fully using JSON. The server will also display authentication keys for each attendance session, and possibly also attendance logs for each student, before the end of today.

This means that we should be ready for a full demonstration-- the only issue is that some unknown configuration issue with the Tomcat server results in a crash each time a new .WAR file is uploaded, meaning we will simply demo the app on a local server. Less critically, the non-local server is unable to display generated pictures, meaning QR and Pattern authentication are temporarily unusable.

Besides fixing these two issues, I believe that the only tasks that must be completed between now and the user study are now:

• Fix Pattern auth in the client
• Changes necessary after moving to MySQL
• Modifying our SQL create script to auto-generate student accounts
• Writing a script to correlate research IDs with student IDs, for anonymity
• Discovering whether any students are in multiple course
• Generating a course/user junction table using these data and serving user-specific data to the client
• Sending previous attendance data to the client and displaying these data
• Checking Device IDs

Getting close! See you next week.
--Nico Ponder

Update 2/26/17

Work accomplished:
I have completed the NIH course, and tested the mobile application on iOS.

Goal:
This next week will be an important week since we are preparing to share the details of our work at the SITE conference. In addition to preparing for the conference, I will also begin working on material for the 2017 NMT student research symposium.

Outcome:
From the NIH course I have learned how to conduct human research in an ethical manner, and I understand my obligations to protect the rights and welfare of the subjects involved in human research.

-- Eugene

Update: Surveys and NIH course completion

As Hugo has already mentioned, last Thursday he and I decided on new URLs and their associated GET and POST methods and refined our object model to communicate course and attendance information between the client and server. This is to allow us to conduct a demonstration of an attendance session this Thurday, 2/23, to prepare us for our demonstration at the SITE conference and our user study. I have also completed the NIH Protecting Human Research Participants web course to make our IRB approval process more straightforward and to learn how to ethically conduct our research. I have also revised the entry and exit surveys we will be administering during our research to examine specific vectors more closely.

--Nico

Update: Network Interactions

Last Thursday, Nico and I refined the attendance tracking network protocol. We have taken the object model into account to create the set of resources that the server and client expect to send and receive.

1. GET /login: when the client first connects, the server will send a course list or an HTTP status code indicating some sort of error.
2. POST /create: the client will request a new account by sending an anonymous research ID (which every student in the study will receive) and a password. The server will respond with an HTTP status code to indicate success or failure.
3. GET /attendance_log: the client will send a course ID when the user selects a course. The server will send list of attendance logs or an HTTP status code indicating failure.
4. GET /take_attendance when attendance verification begins, the client will request a list of valid attendance methods. The server will send list of valid attendance methods or an HTTP status code indicating failure.
5. POST /take_attendance: when the user fills out attendance verification, the client will send a JSON object containing verification information. The server will respond using an HTTP status code.

The connection will be performed over HTTPS using HTTP BA for authentication and TSL for confidentiality. Data will be transmitted in the JSON format. I have created prototypes for all the types of networking and data serialization/deserialization that the client and server must perform.  I'll implement our protocol on the client side and I'll help implement part of the networking code on the server.

-- Hugo

Update: SRS

We will present our research at our university's Student Research Symposium (SRS). I have signed us up for a 1 hour long poster presentation. We must prepare a concise description of our attendance tracking system, its design, and our research results by April 20th.

http://infohost.nmt.edu/~srs/

-- Hugo

Update: Approving Our Research

I am submitting an IRB application as the principal investigator of our research project. The IRB is in charge of monitoring behavioral research involving humans; this includes software evaluation. We are avoiding collection of personal information by assigning students anonymous research IDs and we will not restrict our research to adult NMT students. Only the instructors will know the true identities of our participants. We have filled out the IRB Application and Form A and await approval before our tentative start date of March 20th

-- Hugo

Update: Using the System

This blog post summarizes the usage of our attendance tracking system. We have been testing it in order to make it usable for the study, and to keep information safe from leaks.

- it must be usable
- it must keep information safe from any unintended accesses (accidental or penetration, some subversions)

This should make students more willing to participate. The basic procedure for students is:

- download from Play Store (we'll support both x86 and ARM devices)
- or download to their laptop (which can run Linux, Windows, or OSX)
- on initial startup, students associate a password with their anonymous research ID
- students will use this password-ID pair to login on every startup
- students may click the bottom-most button until they reach the attendance verification screen
- students may review their list of classes and corresponding attendance records
- they finish by gathering and sending attendance evidence

The procedure for instructors is:

- download QR or Pattern image
- or copy pin or password
- display this code in a prominent location
- wait for students to register their attendance
- download attendance records as a CSV file from the server

We'll refine this process before we begin our experiment.

-- Hugo

Update: QR Decoding and External Libraries

QR codes are an important feature to the project. I have implemented image loading and QR decoding. Part of the implementation involved familiarizing myself with Qt's build process in order to make use of 3rd party libraries. Qt's image selector is specialized on iOS so that users can select a picture from the native gallery. I used the Quicknative library to provide similar functionality on Android. It uses Qt's Java interface to create Java objects and make calls to the Android API in order to provide users access to a native Android gallery for their image selection. I also used the quirc QR decoding library, which searches a given image for QR patterns using a standard floodfill-based algorithm, then it uses the corners of the QR code to straighten the image with a perspective transform. I had to fork this library in order to add C++11 support and a qmake build file `quirc.pri` so that any Qt project can make use of quirc.  After importing these third party libraries, I parsed the `file:///` path, loaded it as QImage, performed some image processing, converted the image to a character array in order to  run quirc's detection and decoding algorithm. Quirc can process pictures which unambiguous represent a QR code and are  distorted only by a perspective transformation (for example, if the picture was taken from the corner of a room). In case of decoding failure, we are able to send the image to the server.  The next step is to perform QR decoding a separate thread, display a loading bar, and let users crop images before processing.


-- Hugo

Update (1/15): Client UI --- Usability Improvements

We need a usable app that works on many different screens. Now that we have designed the system, I can start refining the UI. The first and easiest way I made the cross-platform UI is by using Qt's Quick Controls. These are prebuilt UI elements that can resize to satisfy simple constraints:  for example, a ListView can be used to show a list of similar elements, and a GridLayout can arrange arbitrary Qt elements in a layout with a certain number of rows and columns.  Another part of the solution involved implementing dynamic margins and element sizes. The application has very small visual margins on smaller screens, but it will not spread out the cell-phone centric UI if it is run on a larger screen. I also implemented a useful features for small screens, the UI will have a minimum screen size after which it will display scrollbars in order to keep all content available. The Qt documentation was useful, I have also been testing and modifying the UI in order to make it easier for our users to access all of the app's features.  

Future goals include using a wider range of testing devices and insuring that all new UI elements work on many different devices.

-- Hugo

Update (1/8): Object Model Updates, SQL+JSON+Java Object+QObject, Storage

An important part of any software project involves translating information from a real-world domain to digital information in the artificial system. We have asked ourselves important questions, including: what do we need to represent? how much information do we need to represent students, attendance logs, and classes? In the Onion architecture, this information belongs in the object model I worked on developing the object model with Nico. Here is a draft of our work (objects are indicated using `*`, each object has a list of property names and types):

* course
- course id (short String like 'CSE 101', unique)
- course name (long String)
- instructor name (long String)
- location (long String)
- readable time (long String)

* users
- research id (long String, unique)
- password (long String)

* student-course junction table

* attendance log
- log id (int, unique)
- received time (timestamp)
- sent time (timestamp)
- auth key (long String)
- auth type (short String)
- auth status (ok, late, absent)
- device id (long String)

foreign keys
- attendance id (int, from the attendance session table)
- research ID (long String, from the users table)

* attendance session
- attendance id (int, unique)
- authtype (short String)
- authkey (long String)
- course id (short String)
- start time (timestamp)
- end time (timestamp)

Now we need to represent the model in code.  The data on the server must be stored in a SQL database, converted to Java Object using `sormula`, and converted to JSON using Google's `gson` library so that it may be sent from server to client Once this data arrives at the client, it should be translated to a QJsonDocument and then  into a QObject. This QObject can be easily consumed by the GUI, which is written in the QML language.

An important future goal is extensibility. We will make frequent changes to our data model as the experiment progresses. We need to translate our model to repetitive code across several platforms while maintaining consistent names and relationships. Ideally, we would have one source-code for both the client and the server. Instead, we're using JSON objects, Qt objects (defined using C++), and Java objects to store and transmit information. To help keep the data objects consistent across platforms, we are working on a script that generates (1) a SQL create script, (2)Qt Object and JSON conversion code in C++, and (1) Java object declarations in order to keep names and types consistent and easy to update.

Update 02/19/17

Work Accomplished:
We have completed the IRB forms required for our application.

Goal:
Test the student application on iOS and complete the Protecting Human Subject Research Participants course, which is required by federal law for projects involving human subjects research.


Outcome:
I learned the requirements for getting the Institutional Review Board's approval for research involving human subjects.

--Eugene

Update 2/12/17

Work accomplished:
We have shortened the proceedings file and submitted the final version of our paper. After submitting the paper, we managed to complete the presentation for the SITE 2017 conference.

Goal:
We want to complete the necessary IRB forms and related documents in order to submit a proposal for the user study we will conduct.

Outcome:
I have gained an understanding of what professional research is, and why collaboration skills are important in projects like this.


--Eugene

Update 02/05/17

Work Accomplished:
Our research paper has been accepted to the SITE conference, which will take place March 5 - March 9.

Goal:
Shorten and finalize the proceedings file, along with create the presentation for the conference. I will also be making other plans in preparation for the conference.

Outcome:
By working on this paper, I've learned all the protocol involved in writing and submitting a research paper.

--Eugene