Raypointments — Jingya Wu

Raypointments

Background

Making appointments contributes an important part of everyone’s schedule. Currently there are so many ways to make appointments — email, google calendar, texting, phone call, etc, but there is no tool available that can unite all these methods and create a centralized place for people to make and manage their appointments. A successful final product of this project should at least be deployed as a service for the Bucknell community (specifically for appointments among faculties and students), and might potentially be extended to more general use later on.

 

Executive Summary

To solve the problem identified above, I propose that the solution should at least be a mobile app so that users can carry the application around to use whenever needed and get push notifications to their phone when an appointment is approaching. In order for users to make appointment through texting and phone calls, the application should also be able to access contacts, call logs, and messages, and be able to process and analyze natural language to extract appointment related information from text messages and emails, or even from voice queries if possible. On the other hand, the application should also support appointment reminder in the forms of text, email, and/or phone calls to make it user-friendly for people who are used to these methods of communication. In addition to centralizing other existing methods for appointment making, this application should also allow in-app appointment making. As a appointment making application, popularity is very important, as people will only using it if the parties they are making appointment with are also using the same application. Therefore, intensive research is needed on how to attract users and on in-demand features that existing tools are missing.

 

Viability Analysis

The first stage of this project will be serving the Bucknell community only. This means that it needs to integrate features that are specifically targeted to Bucknell students and faculty members in order to gain attention from our potential users. This is difficult and requires lots of research work to find useful features that we could include in addition to what Google Calendar is already providing.

 

Risks and Rewards

Risk for developing an appointment making application is obvious and stated above, that is the application might not achieve what we planned for it if not many people are using it. It might be easier to promote the Bucknell community to use it given that it is developed by Bucknell students, but it is even harder if we enter the public market and are competing with existing appointment making application like Google Calendar. The rewards are also obvious. If this application gained popularity in the Bucknell community, then it can make students’ and professors’ lives much easier by unifying appointment making and simplifying appointments management so that no one will ever miss an appointment again.

 

Closing

In summary, this application will at least be a mobile app that incorporates as many appointment making methods as possible to provide the Bucknell community a more convenient way to make and manage appointments. At this stage, this project will aid the Bucknell community in a positive way and the risk level remains low. If the application should gain popularity among Bucknell students and faculties, we would then be able to move on to target the public.

 

Jordan Faith Antigua Interactive Digital Map preproposal

Interactive Digital Map

Background

This project is making an attempt to digitally map Antigua’s sugar plantations, their history, and the history of the region around them. The goal is to make an interactive map that acts as an introduction into this history. For these purposes you could use a modified google map, or a paper map representation, that then allows a user to click through each location and bring up a window displaying all relevant information. This map would act as the homepage and navigation bar of the website which would then branch off into the other pages which would be necessary to convey as much information as is required. There is a large amount of information that must be conveyed in a meaningful way, to this end the site has to be easily navigated and understood while still being interesting to the user.

 

Executive Summary

An interactive map would be a good plan to keep a user interested while still letting them achieve the goal of education. This solution would allow the user to navigate a detailed map, either decorative or realistic via google maps, that would let the user navigate to each point of interest and learn about its significance to the local area. These points could be marked via symbols or dots to represent what their significance is, then upon clicking on the marker the user would see a popup that displays minimal information with the option to go to a location specific page to read a more in depth summary. Such an implementation would allow the users to get drawn into exploring the map and make the act of learning an interesting experience. For easier navigation at a later date there could also be the option to lookup locations by name, or by using a list of all points organized by historical purpose.

 

Viability Analysis

Through either satellite imagery or a decorative map it would possible to overlay a second click map that scales based on screen size to ensure that any users could navigate over both maps and click into the points they are interested about. The basic information and the expanded pages could each be their own individual resources, meaning that an external database would not be necessary for initial implementation. Each point would simply be edited in turn if new information is required. This alleviates the need for a robust backend and instead allows for full dedication to a purposeful front end to fully accomplish the goals of this project.

 

Risks and Rewards

This map would allow many people to learn of the history of Antigua through a fun and interactive manner. There is some possibility of error about the history. However, this would be left to those maintaining and updating the website, not the initial builders. Impact from this service would be more niche than widespread, but would still provide useful tools to someone interested in learning about Antigua and the surrounding areas.

 

Closing

A project as important as preserving history needs to have careful attention paid to it. A solution such as that listed above would allow growth later in the sites life, it would allow for continuing expansion of facts and corrections of data as the need arises. It would provide the owner with a set of tools that would fully meet their needs and allow them to have full authority of how the history is represented in the most meaningful way possible. This project would be an interesting challenge to build and make sure that the user’s interface and experience meet the highest expectations of the client.

Jordan Faith PeanutPal preproposal

Peanut Pal

Background

Peanut Pal is a project that intends to assist children who are participating in oral immunotherapy. The app would need to remind the child that it is time for their treatment, make sure the child is aware of the dose, exercise restrictions, and make sure the interactions are simple enough for a child to use. Such an app could utilize voice controls and large displays to make sure the child does not wrongly apply their peanut solution. This app would have to be very easy to use and have many assurances to make sure that the treatment is correct, delivered on time, and followed up with the right actions.

 

Executive Summary

Voice activated user interfaces would be easiest from a users point of view, paired with large colorful displays this type of system would be able to accurately display the days treatment information. This system would have to have many systems of verification, followups in the form of notifications via the phone’s alarm system. With a child’s health being dependent on the correct application of the peanut solution it would have to make sure the data is always verified and delivered to the correct individual.

 

Viability Analysis

This app would require a robust verification system and backend solution. A secure database housing all of the user’s health requirements for this treatment, their treatment times, levels, and special cases would also be needed. The front end display and user interface would be relatively easy to implement, the bulk of the labor would be spent in the database and safety features throughout the app. For the third point about exercise it may also be possible to track the user’s movement through the phone and ensure that they are not exercising in any way.

 

Risks and Rewards

While there is a level of risk in any medical apps, this particular app would be able to alleviate a common and potentially severe allergy. Such an app would have a large impact on the community and allow individuals to no longer have to worry about the threat of a peanut allergy once the treatments are complete.

 

Closing

This app is a great opportunity to make a lasting impact on the user’s life. While challenging this project would be exciting to undertake and ensure that the resulting app is secure, accurate, and helpful to anyone who uses it. Many aspects of this app could be customized to make the child more interested in using it, result in a successful user experience for all involved in this new therapy method.

Jordan Faith TopDoc Preproposal

TopDoc

Background

This project aims to be a study guide, or refresher course, tool for the medical field; accompanying all of the diversity and skill that is required for such a task. As such this would require a relatively data heavy backend and an easy to use front end. The comparison to the language app Duolingo is a good representation of how this app would progress. Such an app would require an easy to use user interface along with rewards and stats tracking to maintain this app as the preferred method of learning over existing techniques.

 

Executive Summary

First this app would need a clearly defined user interface. Whether this be organized through a skill tree, linearly, experience based, or any other method would be decided on by cooperation between the client and coders. The puzzles would be fairly straight forward, the end result would most likely take the form of simple quizzes, picture analysis, and four to five other methods that are quickly learned and then used to focus on material instead of the game. The backend database would have to be very well maintained to ensure only accurate and useful medical knowledge is used in the tests.

 

Viability Analysis

No matter how the user interface side is structured the database side will always retain the same general format; a bank of questions and their relating answers, documentation for each user and their success or failures, and some sort of tracking mechanic to ensure that the user is not too far ahead or behind of their relative skill level. To this end the placement would have to be based on prior performance and a loose algorithmic approach to slowly grade to user. While everyone could start at the same baseline, they would easily be able to test out of the simpler areas and progress into areas more relevant and useful to their area of expertise. Such a structure would allow the user to range in experience from pre-med to experienced doctor.

 

Risks and Rewards

Furthering education is always a good goal, however, something as sensitive as medical training would have to have many precautions built in to make sure that only accurate information was given out. If such an app is to be trusted it must be fully vetted by some form of medical professional. This task would fall to the client instead of the coder. From the aspect of the coder then this is a great product that could serve to further education and make a decent deliverable for proof of concept.

 

Closing

I feel that more than a simple proof of concept would be possible by the end of the term, an app of this size would be able to have the front end finished rather quickly. The backend would be able to be built out via SQLserver and would support continued integration and expansion with new knowledge. This would be an engaging project that would allow to incorporation of a full stack approach to ensure a viable final product to the client.

Film Findr – Eric Marshall

Background

There are dozens of movies released every year – far more than any single person (or even a group of people) can expect to keep up with. While there are websites such as IMDB that allow users to search for facts and information about movies, these sites do not also look for relationships between movies. Having access to such a database would provide both academics and film enthusiasts with a new resource for examining connections between movies – from the words in similar scenes to the colors that were used across a movie.

In such a system, a key feature is the ability to search and navigate easily. By including many possible relations for users to search on, we can guarantee that there will be a wealth of information that becomes available to them. Similarly, making it easy for users to navigate through the database (and even upload films that they wish to be able to analyze) will make the database more accessible and applicable to everyone. Both of these features will make the online database invaluable to anyone who has the desire to examine connections and parallels between different films.

Executive Summary

This project has already been started as a web application and that is certainly the best medium for it, due to the fact that it will provide the most people access on the most devices. At the moment, the data and search functionality are displayed through simple web pages, which could be brought more to life with a reactive interface that would better present the information pertinent to a user’s search, while still allowing them to view more information if desired.

There should also be a feature for uploading new movies, which would allow for the server to automatically pull data from movie files (screenshots, subtitles, etc) and could even have the images taken analyzed by a computer-vision program to retrieve information such as objects in the image from them, allowing for more meaningful searches and relational matches.

Viability Analysis

As with any cloud-hosted database, the cost of hosting will increase with the number of movies that are held in it. Thus, there will be cost constraints associated with the number of movies that can be held in the database while operating within a reasonable budget. Another constraint will come from any sort of remote library for image analysis. The majority of libraries that will be able to successfully analyze the images for metadata in the database will have some cost associated with them (see the Google Vision API as an example). Finally, for uploading we may also wish to consider creating a local application for parsing movies so the size of files that have to be uploaded are drastically reduced in size.

Risks and Rewards

This project has one primary legal exposure with it, involving the use of movies. The movie industry is known for aggressively defending its copyrights and going after people for violating them. Because the database uses only screenshots, however, this should not be an issue with fair use laws. The benefits, on the other hand are significant. Having access to a massive relational database of movies with extra metadata associated with them will allow film buffs and scholars to make connections where they might have not before.

Closing

The film database that is being created will certainly be a revolutionary tool for scholars and film buffs everywhere. To make it truly useful, however, it needs to have comprehensive search and uploading features that are accessible through a friendly and reactive interface, all of which this project will add to the database.

Sienna Mosher Preposal- Trip Sharing Platform

Trip Sharing Platform

Background

Everyone travels in some way- whether it’s traveling to work, national parks, or far off lands.  Yet there isn’t a great way to save your destinations, view more destinations, and share lists of destinations.  One use case of this is when you travel to a new city- Wouldn’t it be great if you could see a list of destination spots compiled by previous visitors?  There are some similar apps out there like google maps that saves your places, or yelp that has customer reviews on local spots… But there isn’t a great list of this that is aesthetically pleasing.  To be accessible this platform should be on the web and also mobily accessible.  The goal would be to provide the service of shared travel lists.

Executive Summary

Creating a social travel network is crucial for solving this problem.  This app would involve integrating with current social media to connect these lists to family and friends.  For location saving, google maps or a similar source may be something we could leverage.  This application should be able to beautifully display lists of travel destinations categorized in a variety of ways – type, location, trip, etc.  This trip list could also serve as a travel itinerary.  The lists can be shared, public, private, editable by one person, or perhaps many.  Every person will have a travel line list that is basically an uncategorized history of all their destinations, all of their check-ins.  To do this it is important that the app is accessible on the go.  Also having locals compile public lists of all the must-visit spots in the area.  

Viability Analysis

The biggest challenge in this app is going to be organization.  There are similar apps out there that attempt some of the proposed functionality, but the user interface is complicated, unorganized, renders many features useless.  Much of development will need to be spent finding the best organization to categorize locations, present the data, and lower overhead for users.  Another issue is that this app needs users as much as the users need the app.  If the locations are all created by users, the app starts with zero locations.  It may be beneficial to internally create a base list of locations in order to overcome this challenge.  

Risks and Rewards

One issue that may arise is moderation.  If we have a list representing a city that anyone of the city can add to, there may be some ill fitting locations added that are private residences, fake places, etc.  Some moderation may be required, if not this is a risk that could possibly result in legal problems.  Rewards include empowering locals to show the world the best things to do in their city, a revolutionary app that lets users have a destination wish list that they can progress through, and a user accountable travel industry.

Closing

In summary this project will bring travelers and locals together via destinations.  Instead of visiting somewhere because “it’s the touristy thing to do” users visit because the people who have experienced it day to day recommended it.  If you feel like visiting all the national parks, you have a digestible list of them to choose from and tick off the ones you’ve visited.  This project will majorly disrupt the tourist industry and create a network of travelers.

Capturing Emotional Reactions to Data Visualization – Ben Matase

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 – Ben Matase

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 Preposal – Ben Matase

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.

Sienna Mosher PrePosal Excurvant

Excurvant UX/UI

Background

Excruvant is an established company focussed on creating the “best online social travel community”.  Several start ups have attempted such a platform, but have not been successful.  Excruvant dreams to combine discovery, booking, and sharing to defragment the travel industry.  With a beta web platform up and running they are well on their way to completing their goal, but wish to improve upon the user experience.  The objective is then to create an amazing, personalized interface so that users are both rationally and emotionally satisfied with this application.

 

Executive Summary

To accomplish this objective the interface must be easy and enjoyable to use and integrating the discovery process, the overhead of booking a trip, and helping the user share.  With a focus on personalized experience, the app needs to get to know the user.  This could be done by asking the user about travel preferences.  Off of this information, we can tailor a custom trip discovery experience that finds not only the best trips, but the best trips for them.  The information regarding each possible trip could include pictures, reviews, age ranges, activities- Anything that can be presented in a concise and organized fashion to help seduce the user.  Then we can seamlessly help them complete the overhead for the trip- booking.  Booking a trip is always a hassle.  But luckily there are several software solutions out there that already solve this issue- We only need to integrate them into our system.  Since we already know some background information about them, we can pre-select a few custom bookings.  To make this experience special we could also suggest travel dates for them based on when it is best to visit the location, with an eye for weather, price, and events.  Next, we need to help them share this trip.  Since this platform isn’t the first form of social media, we need to connect it with existing social media.  This way friends and family can still see your adventures!  An added bonus is exposure to these friends and family that aren’t yet connected with Excurvant’s platform.  Sharing a trip means sharing your interest in certain trips to entice friends to join, sharing when you’ve booked and committed to a trip, and sharing the results.  The goal is to connect all of these together in an aesthetically pleasing way to give the user an enjoyable experience that makes traveling easy, social, and smart.  

Viability Analysis

The integration process with social media and booking may be challenging, but I am sure the majority of these sites have back doors for integration purposes.  The other difficult piece will be the customization- remembering the user preferences, building on them, and connecting them to experiences of others with similar preferences.  

 

Risks and Rewards

The main reward of this project would be to be the first successful social travel application.  A byproduct of this reward is providing a pleasurable and connected experience for users.  There are some risks in tying into developed social media, including possible legal issues that might occur when using their api.  With the booking, we will need to manage a secure connection into the 3rd party booking for users to make purchases.

Closing

Travelers need this app.  Customized discovery, booking, and sharing makes this proposal unique and desirable.  Integrating with existing social media makes the user comfortable and allows sharing to occur.  Integrating the booking means they never have to leave our site when they are planning and executing a trip!  By investing time and resources into this process, Excurvant can come out on top!