This week, I was able to integrate the hardware and the software by creating a server on my app-side. This server would wait for a STOP signal from the stop button, then would instantly stop the audio. I was having problems with the audio not playing earlier, but I was able to update my XCode version and have it work as normal. Now, every part of my app is fully working, except the API key functionality. That will not take much time, but I don’t want to add it unless I’m sure that it’s absolutely necessary — I am not totally sure if every professor needs to send their API key, or whether just one will suffice. This week, I plan to have my teammates create test Canvas classes with their own accounts in order to see if that matters, then either add or remove that functionality.
I am very on track with my progress, I am almost completely done, and am just waiting on integration from the ML side. Next week, I plan to help Nithya collect data for the ML model and do anything else my teammates need, since my subsystem is basically done.
These are the tests I’m planning on running:
1. Have a visually-impaired person test the app for compatibility with VoiceOver. I will give them my phone, and have them navigate the app and ask for feedback about where it can be improved to make it more accessible.
2. Have a visually-impaired person rate the usefulness of the device, and the outputs from the ML model by allowing them to use the app in conjunction with a pre-prepared slideshow, and compare these values with what we said in our use-case requirements (>90% “useful”)
3. Have sighted volunteers rate the usefulness of the device, and rate the graph description model, and compare with what we said in use-case requirements (>95% useful). If they feel like we are excluding too much of the graph information, we will refine the ML model and gather and train with more data.
4. Test the latency of button press to the start/stop of sound, and compare with what we said in our use case requirements (<100ms)
5. Test the accuracy of our ML model by comparing it to the test set error, as we said in use case requirements (>95% accurate).