Eric Kilmer, Katelyn McGee, James Udischas, Meghan Riegel
The Pennsylvania State University
Problem Statement/Research Question and Background
The goal of our project was to design an AAC (augmentative and alternative communication) system for teenagers (adolescents) with head trauma that are unable to communicate verbally. The system will be used in a hospital setting by a speech pathologist or the teen’s parents. The type of ACC tool we designed will help teens communicate by scanning through an array of images. The images could range from food, TV, or the teen’s nurse. The intended goal was that the teen will understand that she should select the image of what she wants to communicate.
We designed a web application that allows a parent or speech pathologist to log in and see their teen’s or client’s interface. The users can upload their own images to be used in the scanning array. Another feature of the system is a training mode. This setting allows the teen to practice using the system and learn how to effectively communicate with this device.
One of the major goals of our project was to reduce the learning demands of the AAC system and make it more intuitive for a teen to use. We used references from research that explained the most effective scanning practices. According to the research in McCarthy’s 2006 article, the “presentation” mode is proven to be most effective for teens and young children to understand. In order to implement this practice, our tool scans through the array of images and enlarges the current image to appear as if it is being handed or offered to the user.
The final system has a simple and easy to follow interface that allows for easy operation and customization by the user. As our team is comprised of all computer engineers, we used our knowledge of programming to create a smart system that puts more of the burden of learning on the technology and not the child or parents.
Problem Statement
We designed an AAC system that is simple for parents and speech pathologists to use in a hospital setting and easier for teens to learn and operate. Today, many scanning practices are not intuitive enough for teens and children to understand. Our application incorporates effective scanning practices from research provided by our sponsor to decrease the learning demands.
Technical Approach
We initially approached this problem by looking at the required specifications:
Technical Requirements
- User accounts – Parents and speech therapists need to be able to log into the application and have their account be associated with one or more patients.
- Configurable – Users must be able to choose the content and number of images presented to the child.
- Usability and training – The application must be designed in a way so that it is intuitive for the users and easy for them to teach the child how the application is to be used.
- Security – In order to comply with stringent privacy requirements, the application must be encrypted and the patients’ and users’ information kept private.
The first major question we had to answer when deciding how to approach this problem was how this application will most likely be used. It needs to be large and easy to see for the teen, yet portable. Therefore, we made an application designed for a tablet. Initially, we had three options: an iPad application, an Android application, or a web application. We made our choice with the budget, the portability of the application, and our engineers’ skills in mind.
Considered Approach #1: iPad Application
Implementing an iPad application requires developing in Apple’s integrated development environment Xcode and in their programming language Swift. To ensure quality and security, Apple requires that applications go through an approval process before being allowed to upload an application to the App Store. Additionally, we would need a developer license from Apple, which costs roughly $100/year.
One major advantage of an iPad application is the accessibility. It is easier and more intuitive for a user to simply click on an icon on their home screen than to navigate to a website. It would be able to be used without an internet connection. Sleekness of design is another draw for iPad applications. Xcode makes it very easy to design nice looking apps that have a standard user interface, so that users can easily figure out how to use it.
There are some drawbacks to developing an iPad application. The largest is that it would be limited to Apple products and would not be usable on another operating system like Android. Unfortunately, Android applications are developed in an entirely different language than Apple applications are, and therefore, it would be like writing two completely different applications from a developer’s standpoint. Additionally, none of the engineers in our group are proficient in Swift, so we would spend more time learning how to develop the application and less time working with the sponsor to test and improve the application.
Considered Approach #2: Android Application
Implementing an Android application requires developing in Android’s integrated development environment Android Studio and in the Java programming language. To distribute on the Google Play store, Android requires users to go through a similar review process to Apple’s and to purchase a developer license. The one advantage over Apple is the ability to distribute via third-party stores to bypass these checks and costs, though the tradeoffs with user trust is significant.
The advantages and disadvantages of an Android application are similar to those of an iPad application, though Android does have a few additional advantages over Apple. First, Android is a more widespread operating system than Apple, making it more likely that the application will be able to be used. However, the same issue still holds: it is impossible for us to know for sure what devices the user has. The other major advantage is the expertise of the engineers in our group. Most engineers are very familiar with Java, so it would be easy for us to develop this application quickly and move on to testing and improvement.
Final Approach: Web Application
We ultimately chose to develop the application as a website. We utilize the Django Python web framework, which is advantageous for the following reasons:
- Django makes it very simple to develop well-organized and high-performing applications
- Django is very secure and makes it easy for developers to make safe applications
- Django integrates perfectly with databases
- Django implements user accounts very well.
- Django is written in Python, which is a common and easy-to-use applications well known by all of our engineers
As our backend, we use an Apache server and a MySQL database. As our frontend, we use the Bootstrap CSS framework to quickly and efficiently develop a nice-looking website.
Item | Item Description | Estimated Expense |
Domain Name | An internet domain to assign to our website. GoDaddy. | $10 |
Web Hosting | Server space to store the application and its back end resources. GoDaddy. | $55 (1 year) |
Total Estimated Expense | $65 |
There are several additional advantages to building a web application over an iPad or an Android application. First is accessibility. Though an internet connection would be required for a portable, every user would be able to access the site on any device. We have also provided documentation on how to set up the web site to run on a local machine, thus removing the requirement for internet. The second advantage is that deployment will be much quicker without having to go through the approval process present on the Apple Store. We still take security and privacy seriously, however, and we developed the application to ensure that we protect user and patient information.
Outcomes
Our project consists of a fully operational web application that acts as a single-switch scanning solution. This web application is aimed towards teenagers with head trauma, which means it is simple and easy to use and understand. Our solution features the ability to upload and save pictures taken by a camera in order to add new options to the scanning selection. In order to make this product easy to use for a caretaker, we provide both a write-up of its features and how to use them, as well as a video demonstration.
Cost
The budget for the project was set at $1000. The project did not reach this limit however. Below is an outline of expenses for the project:
Significance
While it may seem trivial to understand the concept of scanning for communication as a person without brain trauma, it is much more difficult to grasp after major damage to the brain. This scanning solution provides an introductory learning experience for adolescents who have never used scanning before. Our interface is simple and customizable so as to not put stress on the user when first starting to learn scanning. The images are customizable to allow the user or care-provider to choose the images that are most direct towards the message being communicated. Finally, we designed our solution to be accessible from anywhere and any device that can open a web browser.
Reference Documents
Light, J. (1993). Teaching automatic linear scanning for computer access: A case study of a preschooler with severe physical and communication disabilities. Journal of Special Education Technology, 12(2), 125-134.
McCarthy, J., McCarthy, J., Light, J., Drager, K., McNaughton, D., Grodzicki, L., ... & Parkin, E. (2006). Re-designing scanning to reduce learning demands: The performance of typically developing 2-year-olds. Augmentative and Alternative Communication, 22(4), 269-283.
McCarthy, John, et al. "Re-designing scanning to reduce learning demands: The performance of typically developing 2-year-olds." Augmentative and Alternative Communication 22.4 (2006): 269-283.
Ratcliff, A. (1994). Comparison of relative demands implicated in direct selection and scanning: Considerations from normal children. Augmentative and Alternative Communication, 10(2), 67-74.
Wilkinson, Krista M., and Shannon Hennig. "The state of research and practice in augmentative and alternative communication for children with developmental/intellectual disabilities." Mental retardation and developmental disabilities research reviews 13.1 (2007): 58-69.
Woodward, John, and Herbert Rieth. "A historical review of technology research in special education." Review of Educational Research 67.4 (1997): 503-536.