Author: bdm015

Capturing Emotional Reactions to Data Visualization

Background

There exists a technology that can infer a user’s emotion from their facial expressions which it detects from web cam input.  By utilizing this tool, you can capture user’s emotion at any time.  The idea proposed is to capture the user’s emotion as they see different data visualizations, but this could be applied to multiple situations.  That data could be saved for that user and used in the future to show them things that evoke a certain emotion.  Tailoring content based on a user’s reaction could be a very powerful tool for content creators.  This would create a build-your-own adventure but done subconsciously.  If the user isn’t aware that their facial emotions are being monitored, then there isn’t any bias in what emotion is recorded.

Executive Summary

I propose that we make a browser extension and API that utilizes the webcam technology.  The browser extension could be a new extension or building off of Jordan Sechler’s research project.  This would enable us to collect more information about visualizations for the logged in user.  The data would be sent to a server to be stored in a database and then accessed by the API.  The API could then be a way for permitted web pages to access this data about visualization and use that to customize their pages accordings to your likes/browsing habits.  The API would allow requests for specific visualizations, certain kinds of visualizations, or for all visualizations.  The data on the requested visualizations would be provided and the web site could use it as it pleases.  There would be a way when visiting new sites for the user to approve them to use their visualization history and reactions.  Researchers could ask users or groups of users for their data with a broadcasting permission function.  Extra information could also be asked for and any information contained in the user profile could be used by researchers if given permission.

Viability Analysis

I believe that this project is relatively viable.  With Jordan’s work, a lot is completed so that the database of visualizations doesn’t need to be created but instead added onto.  The information about a person’s reaction would be fine to add onto the database for a certain visualization.  The hard part is telling when the user is looking at the visualization or something else on the screen.  Triggering the extension to capture the user’s current would need to be dependent if the visualization is what the user is looking at.  I remember another senior design project creating eye tracking software which could tell where the user is looking.  In combination with that, the program could then tell if the user is looking at the visualization.  While in theory this could work, it seems like a lot of moving parts and could be pretty faulty.

Risks and Rewards

A huge risk here is the privacy concern.  People don’t want information collected about them and they especially don’t want their webcam on all the time.  This would be very hard to have people install on their own.  In a research setting, it would be fine if the participants are voluntarily participating in some activity.  The reward is that a lot of unbiased information could be captured using a system like this.  

Closing

Having all this information for website creators and researchers would enable a lot of personalized pages and understanding of visualizations.  It could be a new dimension in studying visualizations and web pages.

Trip Sharing Platform

Background

People like to make lists and complete them.  It is a satisfying feeling to check something off a list.  There is a need for a platform to do this for traveling.  While you can document the places you have been by yourself, it becomes cumbersome.  Creating a platform to make lists of places that you want to go could be useful for the person trying to see all of the national parks as well as the person that doesn’t like to travel far, but instead likes to try restaurants in their town.  Being able to keep track of places visited takes a load off our faulty memory.  These lists could be shared to friends or strangers as a challenge.  The gamification could spark adventures and expert curated travel plans.

Executive Summary

I propose that we create an app to create lists of locations.  Utilizing existing geolocation APIs and location databases will be crucial in getting the best data possible as well as not duplicating work that has already been completed.  Each list could have a theme or not with each item being able to be “checked off” only once that person is in that location according to the geolocation API.  No information will be saved in remote databases.  All information will be stored locally on the phone.  If you want to transfer all of the data on the app, then there will be an easy way to transfer.  The removal of user accounts and storing the information in the cloud means that privacy no longer becomes a concern.  Sharing lists with others will be a simple file transfer that transports all of the necessary information from one app instance to another.  This allows fine grained control by the user of their location data and who they want to share it with.  The app itself will be simple and easy to use.  No more complications other than creating lists, sharing lists, and completing lists.

Viability Analysis

I think this solution is very viable.  By keeping everything local, there is no need to design and service servers to store all of the user data.  Once the app is created, it will be self-sufficient.  Transferring lists through just file transfer seems sort of archaic but I don’t think it would be terrible.  I use one app, Paprika recipe manager, that functions similarly.  A big issue is that if a person’s phone dies, then they lose the lists that they have created and any progress that they have made.  Transferring to a new phone wouldn’t be too bad if a migration function was implemented.

Risks and Rewards

It is risky to do everything locally on the app since it provides some inconveniences to the user, but the payoffs in simplicity and privacy are very great.  

Closing

In an atypical approach to this kind of problem, a cloudless way of storing user created data has benefits of simplicity for the maker and privacy for the user.  This comes at the cost of convenience for the user and the possibility of losing all of the user data upon phone failure.

Energy Hill

Background

There are multiple digital monitoring systems for energy and water systems at Bucknell.  Currently they are not connected to any network, thus making administration and observation difficult. Systems such as the solar array, lights, pumps, wind turbine, and water levels could be monitored without being on the Energy Hill or even on campus.  This would make the data accessible for the administrators of the systems as well as researchers using the data from the systems.

Executive Summary

I propose a solution based around a web server.  The devices currently monitoring the systems can send the data continuously if not in very small buffers to the web server where it will be aggregated into a database.  That data can be utilized in multiple facets.  Since researchers just need the raw data so that they can do analysis on it, there would be an interface to grab data for a time range filtered based on different options.  A web interface would be available for the permitted users that are in charge of administering the systems on Energy Hill.  Other users could look at the web interface to get insight of the status of Energy Hill.  They system would be created such that if a new system is implemented on Energy Hill, creating a new database table and web page to view the information would be straightforward.  If the system takes input, then certain privileged users will be able to trigger events on the devices connected to the various systems.  The interface would be mostly visualizations of the data with views for real-time as well as historical data.  The interface would be a web page to support multiple platforms and relieve the need to support multiple apps.  

Viability Analysis

I think there is a lot of components to getting the system up and running.  Collecting the data has its difficulties.  If there was an interruption in the connection between the monitoring device and web server, there would need to be a validation system to make sure that the data was saved before discarding it on the device.  Doing this all in real time would mean a lot of separate data transfers.  The information could be buffered to decrease the number of data transfers, but there is a tradeoff of separate data transfers and how close to real-time the data is. The program that receives the data from the various devices would have a large workload on it since it would need to coordinate the validation of the data as well as inserting the validated data into the database.

One part that I’m not sure of the difficulty is getting the connectivity to the devices on Energy Hill.

Creating the system to be easily expandable for more systems would require a lot of thought of design and abstraction.  I don’t think we could make a system with plug-and-play usability for different types of monitoring devices, but I believe we could make it to be expandable without rewriting the entire system but instead write the functionality for that new module.

Risks and Rewards

The risks of this solution is that there is a lot of work to be done and if not completed, then the work could be for naught.  Another risk is that the data could be stolen so there are privacy issues. If there is functionality to control the monitoring devices, then that could also become an issue if malicious people start messing with Energy Hill.  The reward is that the data from these sensors and devices becomes much more accessible.  Energy Hill will become that much more useful to the Bucknell community.  

Closing

Aggregating the data on a web server allows access of it in multiple different ways.  This lets us tailor the data to different users and make it more accessible.  Autonomizing the administration and observation of these systems on Energy Hill will increase productivity and usefulness of this asset.