Sunday, September 25, 2016

Update 09/25/16

In this week's meeting we shared the information we discovered regarding the localization part of our application. We found that iOS does not allow for the collection of low-level data, i.e., wireless access point information. We have yet to do research to determine a method of gathering this information on iOS. Dr. Kuo said she would inquire about collecting WAP information on iOS. Implementing this feature would increase our sample size in the user study that will be performed later.

Dr. Zheng proposed that we focus on the authentication aspect of our app so that we have some basic functionality. There are two priorities for this:

  1. initial login functionality (user profile initialization)
  2. ensure that PIN entry works
We will begin with a simple PIN authentication method and add other methods (QR code, pattern) after we have the PIN authentication functional.  At the moment, we are planning on having the PINs generated server-side, where they will be compared with the PINs sent from the student app.

--Eugene

Sunday, September 18, 2016

Update 09/18/16

Hugo and I have started experimenting with a variety of Qt's modules to understand how app features will be implemented later in development. We have also discussed methods of obtaining location information, as well as methods of facial recognition. 

At the moment we are considering using OpenCV (Open Source Computer Vision Library) as the back end for facial recognition. OpenCV has a plethora of algorithms that will aid in the detection and recognition of faces. Since OpenCV's primary interface is in C++, it will integrate nicely with the C++ components of our app. The library has sufficient documentation and it is open-source, which is always a positive attribute!

Nico has been planning and designing the server-side part of our application. He has researched prospective classroom integration platforms for us to utilize. Mainly focusing on Moodle, we have decided that it will probably not be a practical method of hosting the server, due to issues discussed in Nico's post. In the coming weeks we will begin exploring other options for our server-side needs. 

--Eugene 

Wednesday, September 14, 2016

Server-side development progress

     For the past three weeks I've been working on the design of the server-side component of our application, and consulting with Hugo and Eugene on how the client app is going to tie into this. This post focuses on the prospect of integrating our software with existing classroom management software to see how our software would utilize their APIs if we choose to support them, with a specific focus on Moodle. Since Moodle is a modular, plugin-based system, if we choose to integrate our application with theirs we would need to write a plugin composed of PHP, JS, HTML, and CSS.

     Moodle seems to have substantial support for everything we need at first glance. The Enrollment and Access APIs provides functions that allow us to pull a list of the students' classes, check if our software is used in these classes, pull lists of the students in each class, and restrict the use of our software to those enrolled in the class through role-based authentication. Being role-based, this also allows the teacher to act as an administrator so that they can a student after attendance polling has closed if a student has forgotten their phone. The Attendance Module provides and modifies a database for storing students' attendance record, with pre-set options to account for being present on time, tardy, absent without an excuse, and absent with an excuse. Students may upload files, which we would use for the secret-sharing based authorization component of our application. Moodle also handles software updates and logging for us.

     What's more, since Moodle is open-source, it is installed and managed by each school that uses it. This was an important design consideration-- if each school runs their own copy of our software, as opposed to us running one copy of the server that services every school, we would not need to concern ourselves with operating at a large scale, or with handling potential downtime. Since our plugin would also be open-source, it could be configured by each school to suit their needs. Because Moodle supplies so much support for us, I began to consider developing the entire server-side component of our software as a Moodle plugin, rather than just potentially providing support for it.

     However, there were some serious drawbacks to this approach. First, Moodle's documentation is incomplete, and questions are generally handled by the community. While this is a common approach, this made it difficult to find information critical to continuing with this approach-- like whether an additional JSP could be run from inside our plugin to run our facial recognition algorithm, location-checking, random secret generation, and the other components of authentication our application requires. This would mean that Eugene and Hugo's mobile component would need to interface with this JSP, which would then make calls to Moodle, which I felt defeated the purpose of integrating fully with Moodle. Moodle provides a mobile application that users are free to fork and use for their own purposes, but because this is compiled with Phonegap and Hugo and Eugene have decided to work with Qt, this would be inconvenient. Since they are also implementing methods of authentication we felt were outside of the capabilities of Moodle's native interface, like capturing photos or completing lock patterns, I decided against integrating our server-side component fully.

     This has been a very roundabout way of saying that I'm not going to do something, but not for naught! We learned a lot in the process of examining Moodle as a host for our server. Moodle provides enough support for integrating core components of our application that I could write a simple helper plugin to integrate our software with Moodle relatively easily. Since this is possible with Moodle, it is likely possible with alternative classroom managers like Canvas as well. Furthermore, the importance of each school running their own copy of our server-side software for scalability and modifiability reasons helped me to realize that developing a desktop application server for professors to run as they take attendance is the most flexible method of implementing our server-side design-- more on this in my next post!

--Nico

Friday, September 9, 2016

Update - 09/09/16

In our meeting yesterday, we presented a draft of how the app UI will function and how the different screens will interact with one another:


We were also able to show Dr. Zheng and Dr. Kuo the intial UI we designed in Qt Creator:

 Dr. Kuo suggested that we create a drop-down server list so that the student does not need to re-enter the server information every time. 

We discussed different methods of fraud prevention like wifi-based localization and facial recognition, which will be implemented after there is a base app.

We decided that having the instructor input student details would be the easiest procedure to initially populate information. Another possible method of information population is interfacing with the Moodle/Canvas API and pulling student information from there.

There was also an idea for an additional feature where the app would send notifications to truant students, informing them of how often they miss class.

Dr. Zheng tasked us with creating a small localization-test app so we can determine the accuracy of the Qt Location module. We will also need to collect access point information for each classroom.

--Eugene

Thursday, September 8, 2016

Initial Thoughts

I've researched several cross-platform app development frameworks. We want a platform that's free to use, powerful, and runs on iOS, Android, and Windows Phones. Candidates include PhoneGap, Xamarin, CodenameOne, and Qt. It would be difficult to maintain one code-base per OS, but this is also an option.

Qt seems like the best framework for our purposes. With it we can write efficient and multi-platform C++ code. Not only that, but it comes with a JSON/JavaScript-like domain-specific-language called QML for describing graphics layouts and most application logic. QML doesn't support networking so we will have to write the TCP or HTTP code using C++, but QML works well with C++ components.


Qt gives us the benefits of developing with PhoneGap, an easy-to-use language with WYSIWYG editor, and the benefits of writing the app using a compiled language as we would use CodenameOne and Xamarin.

I learned all of this from its very readable documentation --- another feature!

Qt employs asynchronous functions and a related concept called "signals" for handling many inputs, like clicks or network requests. When used right, these improve the application's efficiency; but we'll have to learn about this new control style.


--Hugo

Wednesday, March 4, 2015

Quick Update

The meetings have been productive. Much of the dataset is complete: we have collected reviews from over 100 applications from top 100 lists on the Google Play store. Theresa and I have been experimenting with different methods of sentiment analysis including Natural Language Processing (our initial focus) and support vector machines (a side experiment).

Dr. Zheng has pointed us in a more focused direction. We're going to test the sentiment analysis on all of the apps that the developers we collected have created. After giving each app a sentiment score, we will create an aggregate score for the developer. This aggregate score will be compared to the overall developer score. In particular, we are looking at developers that have earned the "Top Developer" badge as more interesting examples.

We hope to test this method on the dataset this week!

NMT CREU Team

Tapia Conference Update

I recently attended ACM Richard Tapia Celebration of Diversity in Computing. The conference was very enlightening and enjoyable. It was very refreshing to get to discuss topics in Computer Science with individuals in fellow minority groups.

Many of the talks were non-technical but fascinating. One talk in particular was on using Twitter as a medium to empower minority women in STEM.
Khalia Braswell (pictured right) led a "Twitter Chat" during the workshop. Individuals participating in the workshop (or anyone with the correct hashtag) could participate in a Q/A session via Twitter. Individuals could share their success stories with other members of the chat. Some example questions were:
Q1: At what moment did you feel most Empowered to pursue/remain in STEM?! Q2: What helped you overcome the most challenging moment you had in STEM?
The workshop shared some great ideas about using social media to connect numerous small groups that are all dedicated to the same cause. Thank you Khalia for the experience!

There were many interesting companies fully or partially attending the conference. Microsoft showed off one of its products: Microsoft Power BI. The demonstration provided some amazing visualizations. The presentation made me realize just how far we have come with data visualization.

website_imgs_socialvpn-crop
SocialVPN was a project spearheaded by the workshop speaker
The second day of the conference provided more technical workshops. I attended an interesting instructional workshop on using the internet privately in the age of NSA Spying. The talk was very informative and I learned a lot about tools that I did not know existed such as SocialVPN

I met some interesting people throughout the conference. I enjoyed discussing classes with other students attending the conference; it really gave me a way to gauge my education at New Mexico Tech as compared to much larger schools.

Perhaps the most academically fulfilling moment was during a conversation I had with a student attending Cornell about class size. The student told me that when she started, there were hundreds of individuals in her classes. She thought that this number would get smaller as she went on with her degree. Much to her surprise, the class sizes did not shrink. This made me really appreciate the small class sizes that I have experienced at New Mexico Tech. In my classes, most of the professors know your name and the class sizes are often below 20 people. When I told the student this, she was shocked; she told me I was very fortunate to be able to learn in such a close-knit environment. I am now more appreciative of the quality of education that I am getting at New Mexico Tech.

Overall, the conference was a very fulfilling experience. I talked with a lot of interesting individuals and shared conversation on interesting topics in computer science. In addition, I learned just how useful resources such as Twitter can be in communication and networking. Given the chance, I would like to attend the conference again next year.

Randy Van Why
NMT CREU Team