Final Presentations

• Download this transcript - PDF (English - US)

The following content is provided under a Creative Commons license. Your support will help MIT OpenCourseWare continue to offer high quality educational resources for free. To make a donation or view additional materials from hundreds of MIT courses, visit MIT OpenCourseWare at ocw.mit.edu.

PROFESSOR: Well welcome everybody. I think most of the people here in this class-- the presentations in this hour are teams Kate, Don, and Chris. So team Don, in particular, if you want to make sure you're cued up and ready to go, that would be great. The presentations are nine minutes in length. We will have a hard stop at nine minutes. I have some signs that we'll show, and why don't we get to it. We have three presentations in this hour.

We should introduce the panelists quickly as well. Julie, do you want to start? And then maybe Rob as well. A quick introduction, that'd be great.

JULIE GREENBERG: Sure. I'm Julie Greenberg. I work for MIT through the Institute of Medical Engineering and Science and the Programming, Health Sciences and Technology. And I'm excited to see these presentations.

ROB MILLER: I'm Rob Miller. I'm a professor of computer science here, and I'm one of the [INAUDIBLE].

PROFESSOR: OK. Team Kate, take it away.

PHILLIP ABEL: Hello everyone. We are Team Kate. My name is Philip Abel. And with me here is Raquel, Jenny, and Dhruv. Today we're going to talk about the project we worked on all semester, particularly on the different prototypes that we created for different cochlear implants [INAUDIBLE] that we created over the course of the semester. The design process that we went through, the experiments that we ran, and the results we got, and what we learnt from the process.

So let's talk about client, Kate. Kate works at a Cambridge Disability Center, which means she is particularly concerned with ensuring that homeowners in the Cambridge area follow the guidelines that ensure that people with special needs can access buildings, in the Cambridge area specifically. So that's just an example of one of the things she does. And in addition to that, she has a profound hearing loss and wears cochlear implants.

There are two main problems with this that Kate wants-- at the beginning of the semester, two main problems that Kate wanted us to address were the issue that her cochlear implants weren't water-resistant, and then, in addition to that, the implants-- she wasn't able to properly distinguish between noise from behind her or when someone was speaking in front of her whenever she was in a noisy settings-- in a noisy setting, sorry.

So it was this problem that we decided to tackle. And for this, we came up with a HAAT context, which was to create cochlear implants attachments that provide water-resistance and then also enable sound blocking. So the idea of having water-resistance was to have something that would help Kate be able to go out whenever-- let's say in seasons when it rains more often, she would be able to go out and not have to worry about whether her implants are going to get wet or not.

And then in addition to that, we decided-- we also thought about making covers that would enable her to hear more clearly whenever she is in a noisy sitting. In particular, she would be able to distinguish between the sound that's coming in front of her from the one behind her. Then, in addition to that, we didn't really tackle the problem of attachment, but it was just one main idea that we tried to integrate into all the different covers that we made, to ensure that whenever she attached it on her ear, it's wouldn't fall off.

So over the course of the semester, we brainstormed different prototypes. At first, we began with this idea of creating one compact cover that would have all the functionality she wanted. For example, a cover that would be water-resistant in addition to blocking sound. But when we spoke with Kate during the iterative design process, Kate told us she would want a more modular design. So we decided to go with a modular approach. So Raquel will take it over from here.

RAQUEL: OK, so I'm going to talk now about the process of creating our prototypes. So here you see version one of our prototype. So what we used originally was just plain Instamorph, which is plastic pellets that you can melt down and form into solid plastic. So if you see in the top left here, those were our original ideas for the rain cover. So something to cover the ear piece of the cochlear implant, and then something to cover the coil piece, which is the flat, disk-like piece.

And then on the right here were our ideas for the sound blocking attachments. So we had this idea to just slip something onto the implant itself. If you look at the picture above, the microphone is actually located right on the very top of that curve. So that's why we're creating these pieces-- to basically fit right there on the top, where the microphone is located.

We also dabbled a little bit in trying to create some things out of silicone and clear resin and didn't have much success on that, but it was part of the process. So these are v2 prototypes. So we started to try and think about how we can make these more aesthetically pleasing. We tried to start incorporating color into the Instamorph, incorporating a little hood for the cord that comes out of the implant and also incorporating a back layer to the rain cover. So here you see a plastic sheet to provide water resistance on the back side of the cover as well.

And then here is the next version of the sound-blocking prototype, which we made of Sugru, which we found we could just make look a lot nicer and smoother than with Instamorph. So then onto our final prototypes-- it's kind of the next round. So on the left is a new version of the sound-blocking with Sugru, but with a lot less Sugru, so it's a lot less heavier.

And then we incorporated Dycem, which is a material that provides grip, because we were having an issue with it falling off of the implant. The middle part is the coil cover. So we did end up using black Instamorph with the back cover. I'll just say really quickly, and then a vinyl cover for the water cover. Final prototypes two-- so we are moving forward with the ear cover, with 3D printing. So these are our first prints of that. And we're working with Danger!Awesome to make these look a little nicer and continue on with that.

DHRUV: So in order to determine the [INAUDIBLE] prototype, we performed two sets of experiments. So one is the sound-blocking experiment, and the other was the water-resistance task. So in the sound-blocking experiment, we actually divided it into two parts. One was the quantitative estimation, where we wanted to quantify how well our cover actually blocked sound from behind and enhanced sound from the front. The other was the qualitative analysis. And we wanted to [? value if ?] the cover actually caused increased comprehension for Kate or not.

And the other type was the water resistant touch. And the goal was to restrict the amount of water that goes into the implant. So the sound-blocking experiment, we asked Kate to touch in the center of the [INAUDIBLE] table in one of the quiet classrooms of the [INAUDIBLE] department. We placed the laptop at various angles around Kate, and placed at different frequencies and intensities.

For each angle, and for each intensity, we wanted to determine the minimal threshold at which Kate is able to hear the sound. This experiment was performed both with and without the cover. On the right, you can see the comparison of the result for both with and without the cover-- had a frequency of 1000Hz.

As you can see, the listening of [INAUDIBLE] and in the field of view of Kate, and with the [? anterior ?] views behind Kate.

JENNY: For the water resistance testing, we did two tests. One was this water bead test where we put water on top of the cover to just measure whether the cover was actually waterproof or not, and we put the implant, and then a paper towel, and then the cover on top and let the water sit for both 10 seconds and then 10 minutes and then checked to see if there was any wetness underneath that seeped onto the paper towel. There ended up not being any witness on the water bead test and-- for the water bead test and the rain test.

And the rain test was just another one where it is a little more realistic. We placed the implant on a vertical surface with the coil cover as well and then splashed water on it as if it were raining, and we also found that there was no wetness either. So for the subjective results-- this is, I guess, another term for Kate's feedback-- she provided very good feedback from the beginning. She was really involved with our design process, and these are a couple quotes that we pulled from the most recent feedback she gave us on the sound blocking covers, and we actually tested them out at a restaurant-- using them at a restaurant in a noisy environment, just to find a realistic setting and found that the designs worked well.

PROFESSOR: In another 30 seconds or so, you should probably wrap up.

JENNY: That's perfect, because this is the last slide. So a few things we learned-- our project was kind of this assistive technology that we were augmenting onto Kate's assistive technology, her cochlear implants. And that was interesting for us to learn that-- of course, assistive technology is supposed to help someone with their disability, but it's, of course, not perfect, and we had to patch it to make it even better and more useful for Kate.

Throughout the design process we explored a lot of options, and we felt that we could have gone through this process faster finding that ends quicker so that we could have moved on and created more prototypes and gone even further in our project.

PROFESSOR: Great. Thanks very much.

[APPLAUSE]

 

We will get questions from the panelists first. Rob, Julie?

ROB MILLER: Sure, I can start. So how many of these prototypes showed a whole range of things? Which of those actually made it into Kate's ears?

JENNY: [INAUDIBLE] step back. This prototype, the 3D printed piece, is something we're actually going to go with. And all of them made it onto Kate's ears. She wore them all at some point, but this is the final, final one. And then the coil that you see in the middle-- this one here is made out of Instamorph, and we decided not to 3D-print that, because this is already of pretty good quality-- or of quality good enough that we wanted to use for our final prototype. So this is also going to be used as well.

JULIE GREENBERG: Could you go to the slide that shows the sound testing?

JENNY: Yeah.

JULIE GREENBERG: And could you-- [INAUDIBLE] OK. So your results show that it was enhanced a little bit-- the sounds coming from the front. And it was mostly suppression of sounds coming from the rear?

JENNY: Yes.

JULIE GREENBERG: And that was all tested with the 1000Hz tone?

JENNY: Yeah.

JULIE GREENBERG: Or were there multiple frequencies?

PHILLIP ABEL: There were multiple frequencies at which we tested.

JULIE GREENBERG: Becasue these are the results?

PHILLIP ABEL: So these are the results that we got from that. I think Dhruv was the one in charge of the sound directionality test.

DHRUV: So actually it was tested at different frequencies. Like the normal frequencies for getting an audiogram, which is [INAUDIBLE] from 250Hz, then it's goes up to eight kilohertz. But the results that we have accumulated are just for one frequency, which is like one kilohertz, but in the final report that we're [INAUDIBLE], we will mention about all the differences, with all the tables and do that.

So just to give an idea of how the tech performed we actually mentioned only one kind of frequency in the presentation.

JULIE GREENBERG: OK. Thank you. I wanted to understand this, but now I want to ask the addition. So at the beginning you mentioned-- so I wanted to see if you could clarify both what the goals were in terms of-- was it about distinguishing sounds front and back, or was it suppressing some and enhancing others?

DHRUV: Could you repeat the question? I'm sorry, I'm having hearing loss. Could you repeat the question?

JULIE GREENBERG: Was the goal of the design distinguish where the sound the sound was coming from, or to help her hear some sounds and not others depending on the direction?

DHRUV: I would say no to both. It was more about blocking sound from behind and enhancing sound from front. So [INAUDIBLE] just about analyzing the 2D space around Kate so that they could block the background noise and actually understand that it's coming from the conversation in the front.

JULIE GREENBERG: So you were using direction to define what was desirable and what was undesirable.

DHRUV: Exactly, exactly. I mean it was not very well-defined, but you could see the field of view that we have catered here, from the [INAUDIBLE] field of view. it was about 135 degrees, and we were able to argue that in the field of view that is about 135 degrees for a normal [? woman, ?] we were able to enhance sound. And from the behind, that is, outside the field of view, we reduced the sound.

JULIE GREENBERG: So how did that goal then affect your design? Because the other thing that I was hoping your could calrify-- I think this is a question for the whole team-- is the fact that at one point you said Kate wanted modular solutions, but you attempted to design something that would provide both the water-resistance and the sound-blocking in a single device. So how did that all fit together?

RAQUEL: So what you said is right. Our first thought was, let's make one large cover that can provide the rain protection and also some sound-blocking. But she wanted a more modular approach, I think, because it's not always raining, and you don't always need this large cover. So she wanted something smaller that she can just put on a little bit more discreetly. Like if she's in a meeting, for example, and she's really more focused on the sound directionality, or she's out with her friends, and she's really more focused on hearing what they're saying in a noisy environment.

JULIE GREENBERG: Do you design two different things? I guess I'm still confused. You designed two different things, and which one of that--

[INTERPOSING VOICES]

 

RAQUEL: So we did design two different things. So one is a set of rain covers. So a cover for the ear processor, which is the curved part, and then a cover for the coil, that you see on the right here. And then the left picture is the separate piece, which is the sound-blocking piece.

PROFESSOR: OK. I think in the interest of time, we have to move on, but thank you team Kate. I think you've done great work sort of prototyping through this [INAUDIBLE]. All right great, we're going to do Team Chris next. If you can get set up, that'd great.

CAROLYN: I'm Carolyn, and this is Phoebe, Durk, and Aarti. And we are Team Chris. So some context on our client-- his activities that he wants to do and his assistive technology-- is that Chris is an MBA student at Boston College, and he has a genetic condition called Miyoshi Myopathy. Miyoshi Myopathy is a late-onset form of muscular dystrophy. So when Chris was about 22, he started to feel some weakness in his muscles, especially in his legs. And now he uses crutches and a scooter, depending upon the distance that he wants to go on campus and at home.

So because he uses these devices, he needs to know a little bit more about his surroundings before he leaves. He needs to know if his route is accessible, and if his destination is going to be accessible for him. And right now uses a few different things to help them with that. He uses Google Maps. He uses Yelp, and sometimes he even calls ahead to see what the features of the building are before he arrives. But what he really needs is something that's more centralized and more comprehensive so he knows exactly what his route will look like and exactly what features are in the building before he leaves his house.

So that's what we tried to do, is create a central location for all of that data, so that he has one place to go, and he will know ahead of time if he's going to be able to use the building the way he wants to.

PHOEBE: So to do that we made a website called Successible Maps, and we based it on Boston College first, to scope it down a bit. Our first step was to make paper prototypes. So each team member made pretty much drawings of what we thought the website should look like. This consisted of either text or just image-based, and we presented this to Chris, and he picked his favorite features out of each of them, and we use that feedback to create our second paper prototype.

And here, his feedback was that he liked the map interface, and he liked how we had pop-ups for obstacles such as potholes, as well as a bigger pop up on top of each buildings for plans, and in there, flags of obstacles inside the building and pictures of different rooms. Feedback on this prototype included a clear distinction between the floor plan and the text description we had of each floor, as well as a summary page for every building-- that's a general overview of different entrances and exits for every building.

Our next prototype-- sets of prototypes are the software prototypes, which included our back-end model of the data, such as buildings, and flags, for floor plans, as well as the front-end of how the website would look and feel for our client. The feedback for this was that Chris liked it, and he wanted to see a couple more icons such as an elevator icon, as well as time stamps for every flag obstacle, or obstacle flag, or things that pop up, so that he can keep track of what is actually recent and relevant.

DURK: As far as our success metrics go, we had three main criteria we were looking at, one of which is the number of clicks it takes to access the information, second of which is how long it actually takes to get the information Chris is interested in. And finally, the amount of certainty that he is left with after using the application to get all of the information. To address this, we tried to design that all into our app. So I can give a quick demonstration right now. So we created it-- let's see. So our app ended up-- sorry about that-- Sorry, just a second here, and I'll pull it up to show you exactly what we did. It is a-- there we go. Sorry about that.

So we have two different methods in which we went about presenting information that Chris is interested in. The first of which is we have various flags that call out for different information. So, for example, accessible entrances-- you can click on the flag, and it tells you that, say, this is the only accessible door to Stokes Hall, and that specific information about that location as it's overlaid on the Google Maps-- you can see what it actually looks like.

We also have things like alerts at various other locations that can call attention to other types of information that might not be seen in other manners. Finally, on buildings, you can click on the building itself and view the information about the building and its floor plans. So you can click on an individual floor, and see the floor plan, and pieces of information about the floor such as locations of accessible bathrooms, or where the elevators are located.

Now Chris stated that as far as our metrics go, we succeeded on the metric of the number of clicks as it takes less than three to get to the desired information about the buildings, and as far as the actual time that it takes to accomplish it, Chris said using previous methods, he would take up to 20 minutes to figure out a route from building to building, and with our app he believes he can do it in five to 10 minutes.

So a 50% to 75% reduction there, which we were pretty happy about. And then he found it very easy to utilize, and it was able to find the relevant information very quickly. He gave us a couple more pieces of feedback, which we are going to continue to incorporate in, such as adding the labels onto the buildings to say what their names are, and some images actually into the flags and the alerts to show more specific information.

AARTI: So a few of the lessons that we learned throughout the semester while working on this project-- so specifically for Chris-- for his specific problem, we learned that things that are labeled as accessible don't necessarily mean they're accessible to him. So, in general, what he wanted us to do for the semester was gather the specific facts that he can use and figure out for himself if the facility is accessible for him, because he didn't want to trust other people's opinions, because it's not necessarily true for him specifically.

And so other lessons we learned, which were overall assistive technology-specific or just design-specific where that you really need to get to your client really well. So you have to get to know their needs, their specific wants, and don't go in with assumptions. So we went in with a few, but they were knocked down once we just had conversations with him.

And also, in general, universal design is really difficult, and you happen to think really hard about it. So the product that we made is specific for Chris, but if we want to make it accessible to people with different types of disabilities, there's a lot more work that we have to put into it. Overall engineering lessons that we learned were one, to continue to use the iterative design process. And, for our team specifically, a huge lesson we learned was throughout the semester we separated tasks and we were very modular with it. So we separated front-end from back-end entirely. But when we wanted to put them together a few weeks ago, it became really difficult, because the front-end people didn't know what was happening in back-end, back-end didn't know front-end.

And so we learned that we have to continue throughout the semester to at least update each other on what's going on so that we know in general what's happening in the whole scope of things. And so that's what we learned this semester. Thank you. Any questions?

[APPLAUSE]

PROFESSOR: Thanks very much. We can go to the panelists.

ROB MILLER: You said that Chris thought that he would be able to [INAUDIBLE] four times as [INAUDIBLE]. Did you actually [INAUDIBLE] anything on that? Did you [INAUDIBLE]?

DURK: Yeah, so the reason that we said that is that we did model it after the Boston College campus, which he is already familiar with. So he did actually go through the process of looking up the information, but I mean-- so he thought that he could do it in that time, because that's what it took him to look it up. Even though he's already familiar with it, it's not really an unfamiliar place. We chose to focus on Boston College because it was more directly-- we had the information, and we could get a better idea of what it was he wanted, because he had sort of seen all of the bad parts and knew what information he wished he would have known at that point.

PROFESSOR: Julie, questions? OK. I have a question just on the data side of things. The data that you use to populate your map-- did you hand-collect that, and are there certain sources of data that might be useful for the rest of campus or for other sort of structured data sets that might be useful for a project like yours?

DURK: So the right now, we put in all of the data that we're using. But one thing I didn't actually show is that users can input new information into the app. So they're able to add new flags very easily as well as new buildings, new floors onto buildings, and update that with information. So right now it is fully dependent upon users to input the information, but any user can put that information into the database.

PROFESSOR: Other questions from mentors or from students in the class? Anyone? OK. I think your team has really done some interesting work, some very good work on this campus accessibility question or this environmental accessibility question. So well done. Great. Thanks a lot.

[? IAN: Hi, ?] everyone. My name is [? Ian, ?] and this is Christina, and our third member Jane is not here today. But our team is Team Don, and we created an app called Your Friendly Reminder. Your Friendly Reminder is a reminder system that will send daily emails to our client Don, and allow him to see his list of calendar events in the early afternoon where he typically tends to have a cognitive deficit. So first we'll go through the background of our client and then you in a little bit about our design process, and how we kind of came to this design, and then we'll go through our final prototype and along with our testing and our reflections.

CHRISTINA: So a little bit of background about Don-- he lives independently, but he's actually very active, and he's an advocate for people with disabilities, so he goes out to meetings all the time to speak at them. And during his childhood he contracted Polio, which affected his left leg. And back in 2002, he had a stroke, and this limited the use of the left side of his body. And as a result, he has cognitive difficulties, which is what we focused on for our project during the semester.

So about his cognitive difficulties-- around 2:00 PM every day, on a typical day, he would start to have trouble processing his thoughts, and it affects how he can communicate with people. So one of the things that we wanted to focus on was, since he's a very busy person, was to help him remind be reminded of and encouraged to complete his tasks that he has scheduled throughout the day and also to ensure that he acknowledges the reminders rather than ignoring them.

So some of us is the technologies that he currently uses-- he uses a leg brace to make sure that he doesn't hyper-extend his knee. He also uses a cane to help him walk. He has Velcro on his shoes, but one of the most important pieces of technology that he relies on is his iPhone. And so he pretty much stores everything on his iPhone, everything about his day, and he keeps notes on his iPhone. And currently, he enters all of the events for his day into his Yahoo calendar which then is imported into his iCal, and then he accesses his events from there.

And from then, he gets reminders about when his events are and what they are. So from this, we wanted to create a reminder system that would not only remind him of his upcoming tasks for the day, but also encourage him to stay focused while he's experiencing cognitive overload. And the goals of our project was to make the reminders more gentle and humane so that he would be encouraged to actually look at them. And reminders that would help him internalize what the upcoming tasks are rather than just dismissing them, as he does now. And we also wanted to make sure that his calendar could be backed up, because that's something that is very important to him.

So for our first prototype, we actually thought of making an app and. So we had and test out a paper prototype of this app where he could enter in his events, and it would create a reminder for him. And we were thinking about ways to make this more of an interaction where it would-- rather than stressing him out with, oh, you have all these events for the rest of the day; it would help him to calm down and focus.

[? IAN: And ?] so one thing we figured out about this design is that we're basically just creating a new application that already does what iCal does. And so we went to our second design, where we used Google scripts to import his events from Google Calendar and use that information to be able to reformat it and send him an email that will show him his list of events.

So you can see here in our second iteration that we were able to grab his calendar events, but it's just in a list form. So he is PPAT, AAPT, REMINDER, et cetera. And these calender events would be listed in a single list, so that Don could simply look at this email in the afternoon and be like, OK, I have all these events, and this is just one more thing that will help me make sure I complete everything successfully and attend all of the events that I need to.

And so we move from this to our third, iteration where we were able to focus on what it would look like in his phone. And so we wanted our reminders to be more gentle and more humane, rather than a little pop-up from Apple or Siri saying, reminder, you have x event-- snooze, or OK, or dismiss. And so with this Google script, we were able to send him a cute little email that not only would that not only had an image of a cute puppy, or a kitten, or something like that, but also had colors, and it was personalized.

And we found out later that Don really like the idea of having a personalized email just for him. And so this email-- we called it your friendly reminder, and we were able to use all of the information that he already has, but be able to use it in a way to where he looks at it and he feels good. And so one of the problems that we ran into is that we really wanted a response system.

And so we wanted to send an email. We wanted him to be able to look at this email. But how are we going to check to see if we could do that. We didn't really want to hack into his email and check what time he read it, and so the way that we decided to implement this was to have a response system. So he would simply respond muffins or whatever keyword we had. And so you can see right here, there's a little text, and it'll be bigger in a second.

To stop these reminders, reply to this email with the word muffins. And so he would reply to this email with the word muffins, and then we would send him another follow-up email saying, thanks for your reply. We got your message. And so one thing we found is that he didn't like the continuous spamming of the emails, which I'm sure we can all relate to.

And so we worked through that, which I'll tell you a little bit about in a second. And so our final prototype removes these constant reminders. And so there's just one email that will send to him within an hour if he hasn't responded. And then we want to still be able to have this reply mechanism so that we can still make sure that he reads the email, because as annoying as it is to keep on receiving emails, we want him to look at this email, and we want it to be effective.

So here's an example of what a sequence would look like. So you'd send him an email in the early afternoon. So this one was sent around to 2:26 PM. And so you can see his events for today. And we changed the keyword to brownie. And then there's another cute kitty picture, and so we-- in our back-end we have a rotation of these. And so you can see that Don checks his email quite frequently, and he responded within one minute, responding the word brownie.

And so we, in response, sent him one last email saying, got your message. Thanks for replying and have a great day. And so this is what our final prototype looks like. And so we tested it on him-- like I said, we first tested it with trying to find a balance between sending him too many emails but ensuring that he checks our email and doesn't dismiss it like his other reminders. And so he found them to be kind of annoying. He I might have even said, "I find it harassing"."

So we tried to limit that to two emails, because we still wanted to see what was the threshold of emails we could send before he really got so annoyed at us that he would chuck his phone at the door. And so he still found them annoying, but then we tried testing them with zero follow-up emails, and we found that he still liked the idea of having to respond and having someone A.K.A Your Friendly Reminder follow up on him within an hour to make sure that he checked.

And so, in conclusion, we've also learned that it's challenging to evaluate a system like this. How do we each how do we use our success metrics? And how do we use data points such as the time we send emails, the time he responds to emails, and how do we make sure that this product is effective for him? And so we found that that was really difficult to do, but I think we were able to, because one of the things he said was "It's one more step that leads me to the end."

It might be one more thing that will ultimately lead me to the end of the day where I've completed all my tasks, even though I do have it in my calendar. I can look at it myself, but one more email helps me. And so a little aside-- after the 10th time, the puppy gets old. So we start switching the pictures to different kittens, and frogs, and little puppies.

So our final prototype was something that we believe will really help him, and that we believe will really allow him to have more gentle humane reminders that will ultimately help him with his cognitive deficit in the early afternoon. And the next steps were looking for a work-around. And we've already talked about this, so I will ask for questions. Thank you.

[APPLAUSE]

 

PROFESSOR: Questions from the panel? Julie, Rob?

JULIE GREENBERG: So I think you're right. It is challenging to evaluate a system like this. But if you had a lot more time and resources, what would a more rigorous evaluation look like? So currently, we have a Google doc in the back-end where all of the data that we have, including what time the emails are sent out, what time he responds to them, and what time our system is responding to him-- we have a few data points. But it's only about three days worth since we've implemented this Google Doc, but we've been testing this for probably about a week and a half to two weeks. And each, probably, couple of days, we'll get some sort of reminder-- we'll get improvements that we will implement. Does that answer your question.

For example, the sending him two follow-up emails rather than four.

ROB MILLER: Do you know if this is having any effect? But I love the way you expressed one of your goals as getting him to internalize the [INAUDIBLE], not just look at it and dismiss it. Do you have any idea about whether this is [INAUDIBLE]?

[? IAN: We ?] do not. One of the things we really want to was to find how many times he comes back to this email. Because what we would like for him to do is at 5:00 PM, be like, oh what do I have going on today? Let me go back to this email that Your Friendly Reminder has sent him. So no we do not have that data. The only thing we have is just his personal feelings about it-- whether he feels like it helps him.

And he says that it has, and so we're hoping that-- at this point it's enough for us to feel like we've done something.

ROB MILLER: A follow-up question actually also about internalization. So this keyword idea for replying rather than just [INAUDIBLE] button there, then [INAUDIBLE]. Runs the script and checks it off. But the keyword is interesting, because it seems like there's a possibility that you can help him internalize it by making the keyword relevant to what he's supposed to do, instead of just muffins, unless he actually is supposed to bake some muffins.

[LAUGHTER]

But if he's supposed to do something else, [INAUDIBLE]. Did you think about that? Did you talk about that?

GUEST SPEAKER: The keywords are currently just randomized. We were thinking of doing something along the lines of reading through his events and then picking out a word from that event and then making that the keyword, and that's something we did debate, but we never really implemented that, because we wanted to add the other features, but that is something that we have thought, and is a good idea, and that we could implement. Any other questions?

AUDIENCE: [INAUDIBLE] have you thought of using this application for persons with other types of disabilities, such as psychiatric or abnormal [INAUDIBLE]?

GUEST SPEAKER: Well right now, a lot of stuff is hard-coded, so we can't really extend this of more than one user. And that is something that we do want to try to expand, but apparently-- I tried to look all over Google, and they don't save your first name for some reason. So even your first name is hard-coded, and that's something that we would need to step away from in order to expand this to other users. But that's something that we would really like to do.

AUDIENCE: I think cognitive overload is something hard to empathize with sometimes What were your experiences trying to empathize with Don during this entire semester?

GUEST SPEAKER: So I think the biggest one that did affect us was trying to get conversations steered n a direction-- it's understandable that you have a lot of stuff going in your mind, and just simply keeping a conversation going on one way did prove to be a little bit tougher than we expected, but that is part of the cognitive overload, to have one goal in mind.

And it was hard to empathize with that at the beginning, but the more we did interact with Don, we understood that this is an issue, and it's not his or our fault, and we understood that we needed something to make this better for him.

PROFESSOR: Maybe related to that, can you talk a little bit about the design process? does that mean that sometimes you have to kind of push or nudge ideas in a certain direction? How do you sort of navigate this user input in this process?

GUEST SPEAKER: So just getting ideas at the beginning of the project was a little bit tricky. Especially-- if you guys didn't know, we actually started off with a different project for most of the semester, and then we decide to switch gears and go something more software-oriented, and was definitely a tough process to go through, but once we got something going, it was a lot easier to streamline the process.

PROFESSOR: OK. I know that your team has had quite a ride this semester, but I think that has come up with something very promising with some interesting results. So well done. Great.

[APPLAUSE]

GUEST SPEAKER: Hi guys, we're team Jeffrey, and then we're here to present our product, which is called touch 'n' sign.

GUEST SPEAKER: Which Jeffrey named.

GUEST SPEAKER: Yeah. So let's give a little overview first. So our client is Jeffrey. He's sitting right over there. So his disability is that he's blind, and generally he lives with himself, but sometimes he has a seeing aide at his house, and he actually goes out quite frequently. Like sometimes he goes out to the neighborhoods, but every week or so, he'll sometimes go out to further places like to watch a movie or to catch an opera.

And he's also a pretty active member of a number of community organizations. And, as such, he's in charges of financial matters as well as other matters. And because of this, he often needs to sign legal documents or other important papers.

So the goal of our assistive technology for this semester is to have a way for him to sign these legal documents that he needs to sign without the help of his seeing aide. And so before, usually he just has his seeing aide come over, and then he'll manually guide Jeffrey's hand to the place he needs to sign, but sometimes he can always be at his house. . So then we wanted to come up with a way for him to be able to sign his signature on the paper, even when his seeing aide wasn't there.

And sometimes, for certain organizations, they actually need his actual, written signature on the paper. So like sometimes we thought about maybe just somehow printing it on there, or some other way of electronically putting it on there, but they need this thing called a wet signature. So then this was not always a possible solution. So what with Jeffrey has already is he has a software called JAWS, which is this really cool software for blind people on the PC that essentially reads out what's on the computer. And it's like pretty intuitive, and it's a very detailed in terms of the things that it can describe to you.

He also has an OCR software, and Optical Character Recognition software, or he has someone that can do for him, in which he can convert general documents into Word documents that has the same characters in the same places. So what he needs is in two steps. The first step is he needs some way, given a Word document, to find where he needs to sign on the Word document. So if you're given an electronic Word document, he needs a way to know on this document, where the signature is.

And then after he has that, he needs to-- from that information, on the physical document he needs to be able to locate that on the physical document. So then we broke it up into two steps. And then the first step is like a software step and then the second step is a hardware step.

GUEST SPEAKER: So basically here is the software design. So the first design we have activates through a macro toolbar in the Microsoft Word. So you can see that whenever which we find the signature file where we first scan the documents, and then we locate-- so JAWS will read underscore, underscore, underscore, so we know that it's a signature field.

So then we trigger the macro we have. So it reads out the horizontal position and also the vertical position, basically giving Jeffrey x-y coordinates to work on at the mechanical solution part. And it also tells him which pages it is on. And also, for the final design, we basically simplified this thing that Jeffrey needs to remember and also the action that he has to do. So we activate the macro through hot keys, and also we have more intuitive wording, and also we rounded the decimal place, because it doesn't have to be too accurate.

So the hardware design iteration one. So the approach we have is that we do fast prototyping. We have like multiple iterations. So this is the very first design we have. So the feature it had is completely made by cardboard and also floss. And also along the board, you can see that there are dots along the edge to indicate the coordinates.

So the x-y bar are tied on the floss to slice through. So the feedback we got is that it's not accurate enough like for Jeffrey to read the numbers, and also it's hard it's hard to put the paper on, because the x-y rails are tied onto the board. And also Jeffrey has to count the number of the bumps. So if he's interrupted, he has to count again, which is not very convenient for him.

And also the second design is that we improved it by using a magnet bar, instead of using the bump that we manually made by the cardboard. So it's easy to slide, but then the guided bars are still too thin to be accurately lined up so that you can be very horizontal and vertical. And also the movement on the magnetic stripe is not smooth enough, because the cardboard is not even, and also it's hard to tell if the rails were straight.

GUEST SPEAKER: So this is our third design. So we took Jeffrey's advice, and we made the board a lot bigger, because he wanted to have shoulders so that if, for example, if he needed to sign really close to the edge of the paper, we would be able to move the rail to that. So for the third design, we wanted to do something different. We added the braille ruler onto the horizontal guide bar so that after he finds the vertical position, he can simply move his hand along the Braille ruler on the horizontal bar in order to figure out the x part, the horizontal position of it.

But the feedback that we got was that the thicker guide bars made it a lot more easy to line up, because we had the braille rulers on the side so that if we had a three-- if the guide bars are three inches wide, then he could line it up against the braille ruler and have it be very straight. And that was pretty accurate. But the problem was that like this design demanded too much of the user, because if you had to use one hand to move down the bar, and then you had to use the other hand to move along the horizontal position, it was very hard to keep track of the horizontal position and sign at the same time.

So Jeffrey actually preferred like the previous design that we had over this one. So we don't have a picture here, but basically what we did for the third iteration prime is we took stuff from the third design, but instead of just having just one guide bar with a horizontal ruler attached to it, we put the horizontal braille ruler onto the board, and then we added onto it another guide bar, so he would be able to move two guide bars, and not have to keep track of the position with his hands. And then we still used the same base as before.

So the feedback that we got was that again like the thicker guide bars made it a lot more accurate, and then it was a lot more easy to use than the previous one. OK, so we actually found online at this place called MaxiAid, something that does the same thing that we were trying to do. So we bought it, and we tried to test it out. So it's like a commercial product built on a clipboard, and it has a ruler that goes down. And then it has a thing that clicks if you move it across, so you can find the x-y positions.

But the feedback was that Jeffrey really liked the idea of holding stuff down with the clipboard, because it makes it really stable. And he likes the stability of it, but the problem was that it was just not a very accurate solution, because it wobbled around a lot. It could only click, and the clicks were hard to count. And there was no place on the board for a Braille ruler, so it was hard to find the position.

So our final prototype-- we decided to kind of just make a higher fidelity version of the third design that we had, and instead of having tapered edges, we decided to go with just non-tapered edges, because that would make it easier. Because we didn't really see the point of having tapered edges, and we made the whole board magnetic so that it'd be easier for the rails to stick on, and they wouldn't fall off.

And it's very similar to the third design.

GUEST SPEAKER: We're going to watch a video of him using the software. So right now he's trying to find where the signature bar is on the [INAUDIBLE].

JULIE GREENBERG: Oh, is that JAWS talking?

GUEST SPEAKER: Yeah.

GUEST SPEAKER: This is his computer, yeah.

GUEST SPEAKER: All right. So I solved. Wow, that's super.

[LAUGHTER]

PROFESSOR: Can you tale 30 seconds and wrap up please?

GUEST SPEAKER: Yeah. This is him, and this is what the result was. And then we measured a bunch of--

GUEST SPEAKER: We wanted to know how accurate it was, how fast it took him to use the mechanical prototype, and what he thought of his overall satisfaction, and these are kind of like the summary of his results. And then there are a lot of things that we learned through this.

GUEST SPEAKER: So basically the first thing that we learned was that there could be a lot of challenges that we didn't predict, and also the fast prototyping actually helps so that we can make more iterations. And the second is that the details are the most important part while we are doing the design. And the third is that we need to take into account the burdens that we have on our client. And also the manual testing is very important to find the flaws and the bugs.

And the fifth thing is that nothing can be really perfect. We have to make a trade-offs. So we have to choose what we value more. And the last thing is that documentation is really important. It's easy to fall behind, so it's really hard to make it up. And that's a good ending.

PROFESSOR: OK. Thank you very much.

[APPLAUSE]

Let' start with questions on from the panel.

ROB MILLER: I'm going to use my question to ask you to back up to the slide where you showed the numbers, just so that we can look at them a little bit more. What do you think happened overall on design [INAUDIBLE]?

GUEST SPEAKER: Because it was a commercial product.

ROB MILLER: Oh, that was the MaxiAid.

GUEST SPEAKER: So we wanted to see what we could take from that, and we [INAUDIBLE] the clip art that stabilized the paper. But in terms of accuracy, it was hard for Jeffrey to count the clicks.

ROB MILLER: So which one is the final clipboard prototype that you did?

GUEST SPEAKER: So we have it here.

ROB MILLER: OK, but it's not in this [INAUDIBLE].

GUEST SPEAKER: No, it's not. I mean we didn't test it yet.

GUEST SPEAKER: Any other questions? Raquel?

RAQUEL: Can you go back to explain the accuracy? Like how many times did you test it? How did you determine how accurate it was? Was it one time?

GUEST SPEAKER: Yeah, we tested it a few times for each, and then we essentially looked at-- so generally the accuracy for how wobbly it was was not a problem. it was essentially where the signature line started versus where he started signing it. And then we just took the average of those.

ROB MILLER: What did you find more challenging in this project-- the software side of it or the hardware side of the [INAUDIBLE] of an accurate measurement of the [INAUDIBLE].

GUEST SPEAKER: I think personally found the hardware side a bit more challenging. I think we are more towards the software side as our studies, so it's more out of our comfort zone the do the hardware side. And part of it is also iterating on hardware is more of a time-intensive process.

GUEST SPEAKER: I think we had hard time trying to scope out our project-- do we want to handle documents of all sizes, or do we just want to do it for 8.5" by 11" pieces of paper. And I think we wanted to make the hardware solution very elegant, so it took a lot of time to figure out how to make it so that it's easy to use and simple enough to understand.

GUEST SPEAKER: And also, a lot of challenges that Jeffrey had using our project, we cannot see well during the design. For example, he wanted the entire surface to be flat. And also, he wants to be able to have a [? bump ?] to align with the bar. So we kind of don't know that when [? were ?] [? able ?] to see everything, but when he used it within-- at that time, we realized what the flaw of the design is so we can redo the thing.

PROFESSOR: OK I think this team has done some great iterations and made good use of Jeffrey's abilities. So well done. All right. Thank you

[APPLAUSE]

We'll let Team Felicity set up.

ARI: Hi everyone. So our product is vibeAware. My name is Ari, and these are my teammates Becca and Simi. And our client is Felicity. Felicity has neurofibromatosis, which has, as a result, left her profoundly deaf and with low vision. However Felicity is very active, and she tends to go out with friends, she has doctor appointments, goes to cafes, and of all of these activities, she notices that it's really hard for other people to get her attention. So that's why we decided to create vibeAware.

VibeAware is a device with two components. The first one Felicity wears and the other one she gives to a friend. When the friend wants to notify Felicity and get her attention, they can just a toggle the button on the remote and then Felicity will get a vibration that'll let her be aware that someone's trying to notify her. Hence the terrible word pun. And we're going to talk about the design process.

SIMI: So through our project we used an iterative design process. And our iterations went as follows. Our first design was a toy car spin-off. Our second design was a light ring. Then we created a custom circuit and finally, refined that to our final design. And I'll go over those more specifically now. So in our first iteration, we asked ourselves the question, how do we get an RF signal to trigger a motor. We're all software-focused in our studies, so we don't really know a lot about hardware.

So we thought that the best way to do this is to use something that's already out there. And that is a toy car. A toy car has two switches that essentially trigger two different motors using an RF signal. So we took apart a toy car, and we learnt a lot through this process. We learnt about RF signals. We learnt about how this works, what components are necessary to make it work. And through this design, we kind of played around to see what we could get-- how big of a design we could get.

But our pros in this design were that we learnt about RF signals; we found something that works at a long range. The cons are obviously that it's huge, and bulky, and it has a lot of pieces that we don't need, and it's not customized. So we went to our next iteration, and we asked ourselves the question is it possible to create this with a smaller design?

Again, we went with something that's already out there. We went with this little tiny light switch that basically is remote controlled. And we kind of hacked that to create our own little vibeAware ring. So this essentially is a little light with a motor attached that we hacked on, and the remote control essentially turns on the motor as a notification.

The pros of this design were that it was very light and small, but the cons were that it works at a very limited range, the battery was short-lived, and the circuit was just hacked, it wasn't customized to what we wanted it to do. But we got something to work. So now we're going to talk about iteration three, which basically progressed our design further by three steps.

We asked ourselves the question, can we get better range with a smaller device? And Ari's going to talk more about this.

ARI: So the first thing we felt was that we weren't going to be able to reach our design objectives using off the shelf hardware, and we'd have to go and create our own circuit. So this is our first end-to-end custom circuit product that we made.

[CLAPPING]

[LAUGHTER]

And I'll talk about what we did. So basically we did a search on different hardware components that we'd like to use. We ended up getting a small cellphone vibration motor from sparkfun. And the other component we had was the receiver and the key fob. So this was great. This had a remote control that was already made, and a corresponding chip that we just had to supply power to. You didn't need any other microcontrollers or extra stuff. And when you hit the remote, it would set one of the pins to high on this transmitter/receiver device.

It had up to 25 feet of range, depending on line-of-sight obstructions, and it was only $12. So using that and other basic components like LEDs, push buttons, we were able to create this design. So we started with this schematic, and we had different-- pretty much the easiest way you could try to set this thing up. We tested it out on a breadboard, and then we tried to put it all into a small proto-board. And afterwards, we put it in a cardboard box.

So surprisingly, Felicity was really excited when she received this, but we felt that we could probably do a little bit better. And so the pros of it was it was our fully functional circuit design. It had longer range than the ring, and it was much smaller than our RC car. The con was we really didn't spend time thinking about the enclosure. This one also had a very large battery pack, and again, the circuit wasn't completely closed, so it was a little bit fragile.

So after this we said, how can we improve this? How can we make it more durable?

BECCA: So I'm Becca, and I'll talk about this final design that we put together. So the goal of the final design was to make something that was a bit more durable and compact, and so what we decided to do was create an acrylic shell for our final circuit, and we also want to think about how we could make the vibration a little bit more strong. And so we decided to go with a nine volt battery, instead of the smaller batteries that we were using before. And in this final design we've considered both maintainability and also usability.

Because we were using this nine volt battery we have to make some minor circuit adjustments. So since the receiver uses five volt, we had to use a linear voltage regulator to interface to two components. And so we edited that. And also in this final design, we had to consider how Felicity was going be using it, and so how these various components like the motor, the switches, the LED, and the battery were going to be positioned in the final design. So I'll talk a bit about this later, but these are just sketches of us brainstorming as we were thinking about it.

And also, as we were thinking about this, we decided to make the final design a necklace instead, because at one point in our interview, Felicity had mentioned that her sternum area is one of her most sensitive areas. And so if we could leverage that, and put a motor next to that, we thought that the notification would be more effective. And so when were making the acrylic shelling, we first designed it in the software, and then just used a laser cutter to create the acrylic shelling. And that's what you can see here. And this was the size we had to make in order for the battery and the circuit to fit inside of it.

And so this is our final design. It's actually a shiny black encasing, but we had to tape it when were first testing it out, but as you can see, first the antenna has to pop out, because we wanted to maximize the signal strength, and we put the LED at the top of the necklace device so that it maximizes the visibility when she sees it.

And we have two switches. So one switch is she flips it on when she first wants to use the device. And the LED will turn on that so she knows it's on. Then when her friend triggers the device and it starts vibrating, she can press a second switch, which is a push button to reset the device and turn off the vibration. But the device will keep on listening until she switches off the LED.

And so when we're positioning the switches, we knew that Felicity was right-handed, and so we put the switches accordingly. And we also put the motor on the back side of the necklace so it was touching her skin. So some pros of this were that it was more robust, and we thought about the positioning a bit more, but inside the circuit is a bit messy, and the battery is really heavy.

So the reason why we decided to go with the nine volt battery was because we wanted to make sure she could still replace it once we've given this to her a little while later. Because we were really tempted to use a smaller battery, but it'd be a lot harder for her to replace, and we really wanted to think about maintainability.

So we're running out of time, but we also considered distance and vibration. And she approved of the vibration strength, and with the distance we ended up with 25 feet range, which is good for the use cases that we were considering. And just wrapping up and talking about some learning and reflection that we had with this project, personally it was really hard as a team for us to narrow the scope because Felicity had a lot of great project ideas, and we also are all software-oriented so it was hard to learn about the hardware.

Designing AT is really difficult because we have to customize, and it's hard to scale something that you're customizing. But working with Felicity was amazing. She was a really fantastic and understanding client, and we really learned a lot through the process. Thank you.

[APPLAUSE]

 

ROB MILLER: So your presentation actually looked like a lot about exploring [? the ?] products, right? [INAUDIBLE]. I wonder if you could say more about what you learned about how [INAUDIBLE]. Some of it came out at the end, [INAUDIBLE]. The sensitive areas, but can you say something about her sense of comfort while wearing something like this?

BETH: So a few use cases-- so we thought about this idea early on actually in the semester, but we moved away from it-- but some use cases that Felicity had initially mentioned were like during class-- she'd take some classes, and it's really hard for her to know when someone has told her it's her turn to speak, and so this was one use case there. And also when she's with friends, and she's at a concert or something, and if she gets lost from our friends, this would be an easy way.

She doesn't always carry her phone on her person, and so if they text her, she doesn't always know, or if they're calling her. And so this would be a quick way to grab their attention. One reason why we moved away was we thought about security, and if she went to a coffee shop, and she wanted them to use it, how comfortable would people feel when someone's just walking up to them with this random remote, asking them to press a button to ask for their attention.

So that's why we felt like, socially, it would be a really awkward device. And so we moved away from it.

ROB MILLER: Did you ever actually try that? Like go to a coffee shop and [INAUDIBLE]?

BECCA: Well we did it with-- we were just filming, and we asked them if we could like just videotape our conversation while she was ordering something, and they were already really uncomfortable, and so--

ROB MILLER: [INAUDIBLE].

BECCA: Well it wasn't a-- oh, sorry.

SIMI: So she actually told us that she was uncomfortable with giving this device to someone else. I think part of one discussion we had was that she didn't want to have to explain to someone else why she's giving it to them, because she already has like trouble hearing them and communicating with them otherwise. She wants every piece of information told right away so that she doesn't have to answer questions, and she was worried about the questions that she would have to answer if she gives someone this device.

BECCA: And I guess the way we mediated that was in the end, the use cases we had for her and the ones that she wants is to use this with friends and people she's already familiar with.

GUEST SPEAKER: I have another question. [INAUDIBLE]. Were there any kind of pre-fabricated circuits that we could have used? I mean I love the fact that you were able to-- it was very instructive [? building ?] the circuit. But [INAUDIBLE]. Do you think that would have been something that could have served the purpose?

BECCA: Yeah. So the receiver itself is pre-bought. So that's something we used out of the box. I think our functionalities are a bit more unsophisticated that we didn't have to turn towards [INAUDIBLE] and more expensive things. The biggest, bulkiest thing is the battery, and that was just something we decided to use, because it was easily replaced.

PROFESSOR: OK. With your team, I think over the course of the semester, you've gotten to know Felicity better. I'm interested in seeing what the results are in evaluating with them, and I think you've done some strong work putting together this prototype. Well done. All right. Thanks.

BETH: Imagine you're in your room; you're sitting in your wheelchair, and you pull something out of a drawer. All of a sudden the drawer starts falling on top of you. Now because you have limited mobility, you can't just move that drawer back up, and because you aren't able to yell for help, you're pretty much helpless. My name's Beth. This is Tanya and Laura, and this semester we had the pleasure of working with Margaret, our client.

She found herself in this very situation, and because of that, she wanted to have a better way that she could call for help. She lives in The Boston Home, which is an assisted living community for about 90 residents in Dorchester, and she was diagnosed with multiple sclerosis, so she is bound to wheelchair, as are all of the residents of the home.

And like I said, the goal of our project is to design a system that allows her to call for help. Currently the system in place in The Boston Home is just inaccessible for a large percentage of the time. Currently, it's a button that's attached to the wall, and when you're pulling the drawer open, the button's nowhere to be found. So we did was develop an iPad app-- we call it InstaAid-- and it allows Margaret and many other residents to call for help.

LAURA: So we frequently visited The Boston Home throughout the course of the semester to speak with both Margaret and other staff members at the home so that we could receive feedback as we iterated through several prototypes. What you see here is an iPad screenshot of our first prototype. Before we got to the stage, we did do some paper prototype sketches as well and then implemented that on the iPad. And in our first iteration, our home screen was too large buttons for urgent and non-urgent requests.

Pressing the urgent button results in a video chat with a nurse at the nurse's station, and then pressing the non-urgent button leads you to the screenshot you see in the middle with six cookie-cutter requests that residents commonly have such as please give me water. And pressing any of these buttons also leads that resident to a video chat with the nurse to specify more information about the request.

Some feedback we received from this iteration was that we should replace that colorful icons that we previously had with larger and more contrast icons, so that it's easier for residents to distinguish. And we were also advised to remove the urgent and non-urgent distinction for requests, because each resident at The Boston Home might have different views of what urgent means to them.

And finally, after pressing one of the buttons for common requests, rather than being taken to a video chat, we showed the resident a screen that gave them information about whether their request has been received by the nurse and whether it's currently being addressed. So with this in mind, we moved on to our second iteration. So you can see the difference in icons that we have here-- with the black and white, the higher contrast.

So we now have video chat and send message as two special icons that we hadn't implemented yet. But then the other four buttons lead to the request sent screen that you see on the right-hand side. And it also gives the option to close the request. And we also made a prototype for the nurse in this iteration. You can see here on the left hand side that the nurse currently has two outstanding requests, and then if you presses the process request button, it turns to green, and then she can close it once it's completely fulfilled.

Some feedback from this iteration is that we should introduce a login system that persists even when the app closes so that residents don't need to login every time they open the app. And at this point, we still needed to implement sending custom text messages to the nurse and the video chat.

TANYA: So before we went on to test our final prototype and go on to actually deploy this at The Boston Home, we decided to conduct a couple of experiments so that we knew what we are dealing with. So the first thing we asked Margaret was how often she was unable to access the call light system when she needed aid. And she responded that it was about 90% of the time.

And we also timed the amount of time that it took for a nurse to respond to her request by pressing the call light button, and that ended up being approximately eight minutes every time she did that. And finally, because we're using the iPad application, and it depended on her being able to send this request to the nurse's station, we wanted to make sure that the Wi-Fi network was robust enough to handle this. And we found that it was pretty adequate-- that it covered most of The Boston Home-- but there were a couple of dead zones and transitions might have been an issue if she was moving while she was doing this.

So taking this all into account, we made our final prototype and were able to give this to Margaret at The Boston Home. So I'll just walk you through a workflow of potentially what a resident might do.

So they are led to this home screen with the high contrast buttons and can press something like bring water, in which case they will go on to the request sent button. That request is then sent to the nurses side. It'll appear, and they can go ahead and say that they want to process their request-- that they've received it. And then that'll show up on the resident's side, saying request processed. They can go ahead and close the request if they want.

The nurse can also go ahead and close the request on their side as well once it's been fulfilled. Residents can also send a text message. So it's a custom message that they can send if they don't have any of the preset ones. So I need to take my medications, and they can tell the nurse that they want that, and that will show up as a custom message on the nurse's side as well. And it proceeds from there.

So this wasn't shown in this screencast, but there's also a video chat capability. So this is us testing it with Margaret. She can simply press the button, and then it connects directly with the iPad, so she's able to do that.

And what was great was when we left it at The Boston Home for a week, Don actually was kind of to make this Nurse's iPad mount. So, as you can see, it's at the nurse's station with a bunch of the other devices there. So the nurse typically needs a computer, the call light system itself, as well as a desk space for paperwork. So we put it right in the center of the desk so that they'll be able to see it, and it's always going to be on. It's never going to turn off.

And so that's just a closer up version of that. So after this, we went back, visited our experiments, and tried to see what the results of our week-long test were. And we found that Margaret was successfully able to send the request via her iPad and then receive aid from the nurse when she requested something. So the iPad was actually only inaccessible one time, but during that one time, the call light was also an inaccessible, so she had to find a different way to request aid.

And we also found that the response time is faster. It was about three minutes. And we are not completely sure about how that's going to work with logistically, because we believe that this might be a faster response time because it's a new system, but we kind of want to see how it pans out in the long run. And we also found that there were no problems with Wi-Fi connectivity

BETH: So from the very beginning, Margaret's vision was for her to not just be the only client-- for the entirety of The Boston Home to be the client. So in this current week, we've actually been working to deploy this system on more resident's iPads, and we've already received feedback, and we're hoping to incorporate that. We've also received the piece of feedback that would be very helpful to have the location of the resident when they send the request, and that's something that we would propose as a feature project.

So ultimately, through working on this project, we want to reiterate that when you design for one client, that doesn't necessarily scale for all. We learned this. We also learned that it's very helpful to receive feedback from many, many individuals, not just your direct client. So we worked with a lot of the individuals in The Boston Home. And finally, it was difficult for us to scope this project initially, because there is so much potential, but we wanted to deliver a product that was very useful in the time constraints of this class.

Ultimately, we'd really like to thank our client Margaret, Don Fredette, who many of you have worked with. We really appreciate his help on our project and all of The Boston Home staff have been really great at giving us feedback. Thank you.

[APPLAUSE]

 

GUEST SPEAKER: I'm just wondering what the variables that you find really difficult to work with were. Things that were sort of [INAUDIBLE] in an ideal world have a little more control over [INAUDIBLE]?

TANYA: I think one of the main things is definitely working with the nurses. So had started out with, of course, talking to Margaret, and then we found that as much as we needed to talk to Margaret, we also needed to talk to the nurse to get her input on the UI, and so on, and make sure that she's comfortable with using this system at her desk.

But one, it was kind of hard for us to meet with her, because every time she was there, she was always busy addressing other residents' requests. And secondly, she actually ended up leaving halfway through the semester, so the feedback that we had gotten from her and was not necessarily ported over to the next person who's going to be there. So working with that and making sure that whatever was going to be used from the nurses side would actually be used, even though the residents would be comfortable with the system, it's not necessarily certain that the nurse would be able to do that. So that was a bit of a hardship.

ROB MILLER: I'm wondering how much-- you had a slide about experiments, and you had a slide about [? results ?] [? from ?] [? your ?] [? prototype. ?] How much data was behind each of those slides? So when you were measuring eight minutes as a response time, how many trials was that? [? When you were ?] measuring her success with the new system over the course of the week. How [? many tests ?] [? did you actually ?] [? get ?] [? there? ?]

BETH: So that's a very good question, and we're going to answer honestly-- not enough for a very good metric. So honestly, we spent an hour with her. We did it maybe five times, and that was kind of the average. However, to have a really good metric, we would--

ROB MILLER: Five times using the old system you mean?

BETH: And five times using the new system to have some kind of a comparison. But, of course, it's variable throughout the course of the week, and there are many different variables that would change that time. So a more rigorous amounts of metrics-- we could write scripts for our current system to figure out how much time is collapsing between when the request is sent and when it's processed. And that's something that we would propose to do for future work.

ROB MILLER: She had it for a week, but it wasn't actually logging the usage.

BETH: We have analyzed the logging-- we haven't logged it, and we haven't analyzed it either.

PROFESSOR: Well, we'll Team Beverly-Ann get set up. I think it's impressive what you've done to build this end-to-end system. Can I ask a question-- it was pretty early on in the semester that you chose to go with an all-software solution as opposed to plugging in some kind of wireless button into the wall as you might imagine you might go in that direction.

Can you reflect a little bit on that? Do you think ultimately it was the right decision? Or when you made that decision, did you know what you're going down?

LAURA: Sure. So all of us are software people, so that was partially an initial reason for why we wanted to go down this route, but another reason was just that we had a lot of great ideas for features that we wanted to see in this app that wouldn't be possible if we had chosen to interface with the existing system. For example, this video chat-- the concept of sending custom messages, maybe even being able to receive feedback about how far along in the process their request is in terms of being addressed. So all of us are really happy with the way it turned out. Margaret was excited about the concept of video chatting and other residents that we've tested this out on were also happy with the ability to send custom text messages, so we think it worked out well.

[APPLAUSE]

 

PROFESSOR: Let's get Team Beverly-Ann to set up.

VINNIE: Hi everyone. We're team Beverly-Ann. I'm Vinnie.

SHRUTI: I'm Shruti.

ROBERT: I'm Robert.

VINNIE: And this is our final presentation. Our client's name is Beverly-Ann. So she has a wide variety of interests. She's a social worker for the Department of Children and Families. She's learning how to code using Scratch and Arduino in her spare time. She loves Wii Tennis. She has a backyard garden, and her main goal is to maintain an active mind. And she's also been diagnosed for 11 years with the Charcot-Marie-Tooth, which is a neurodegenerative disease that affects the extremities.

SHRUTI: So everyone's experience with CMT is different, and in the case of Beverly-Ann it mainly manifests in sensory failure and muscular failure in her hands. So if you can see the diagrams over there-- on the left hand, on the blue areas are completely functional, but the green areas are experiencing muscular failure, and they tend to curl in. So they don't open, and thus they're very useless to her. On her right hand the sort of gray areas are areas where she can feel really well, but the red areas are areas where she cannot. She feels numbness. And so she has trouble gripping things as a result, because she loses feeling in that hand.

And so as there is not just a really consciously think about actions she performs, and this includes like picking up and holding on to objects, typing, and walking down stairwells with railings. And you'll see in the next few slides we chose to focus on the problem with her right hand.

ROBERT: So the assistive technology challenge over here is that because Beverly-Ann is so worried that she's going to drop something whenever she's grabbing it, she becomes less confident in grabbing objects with just one hand. And here we are trying to reinstall her confidence in grabbing objects with her right hand by notifying her whenever her grip is becoming loose.

And to design our product, we put them into three stages of prototypes. And so, Shruti talked about before, we focused on the problem with her right hand, because she normally uses her right hand to grab objects. And very early on, we decided that we want to quantify her grip pressure and then notify her whenever her grip is becoming loose.

So these are the early-stage brainstorming ideas we had, and we were focusing on exploring different choices of where to put the pressure sensors as well as the circuit boards. So the left part shows that we put in the pressure sensor on the upper palm, whereas the right part showing another idea of putting the pressure sensor on her fingertips. And then later on, we followed the second idea.

So this is our prototype stage one, and it's a low-fidelity nonfunctional prototype. And we were exploring multiple designs for this [? look-a-like ?] prototype by asking Beverly-Ann to try out different versions and then see which one feels the most comfortable. And then this upper part are the pictures that are for the minimalistic design for the gloves. That's the stage one prototype. For the stage two prototype, we were mostly interested in making a functional design, so basically fulfilling our goal of being able to notify her-- one, she gripping something and it's slipping.

So we constructed a circuit on a breadboard, and we hooked it up to an Arduino, and then we coded-- we uploaded code to the Arduino that would cause a vibration motor to vibrate whenever the sensors that are also hooked up to the circuit sense that you're gripping the object, and then it's released past a certain threshold. And we actually tested this with Beverly-Ann, and she really liked how loud the vibration motor was and how strong it was, and she mentioned that it actually helped her consciously remember like, oh, I need to re-grip and grip stronger.

And she actually also really liked the material of the glove that we used, and she asked us not to cut it like how we did for our first prototype. And is also pretty easy to grip with the material that we were using and mostly we used this prototype to test the range of sensor values that output when she grabbed different types of objects, for example a cup, or a mug, or utensils, and they actually turned out to be around a similar range.

SHRUTI: So the main problem with the previous prototype was that it wasn't portable because we have to plug it into the computer. So the final prototype which is actually on my arm right now is both functional and portable. So the idea is that we printed a circuit board to do what our breadboard was originally doing, but that breadboard was way too heavy. So we got one custom made, and that's here. And then on the back, we have an Arduino lily pad, which is a lighter version of an Arduino, and it provides the code and the power supply to the circuit.

We have sensors attached to the gloves, and then we have an arm band. We discussed with her a lot how she wanted to carry this device around, and her main constraint was that she wanted it to be light, but not on her upper arm or too close to her wrist-- somewhere where it would be stable. And so we chose to make an arm band right around here, so that it would be portable. And the vibration motor is sewn into the arm band, so that if I were to turn the switch on to start it so that we don't waste battery life, and squeeze it, and then let go, I can feel the vibration, even though you can't hear it, so that's not disruptive to other people around.

And the other thing that we made sure to do was that our power supply is pretty light. It's only one AAA battery, and because it's like a standard AAA battery, she can replace it whenever it goes out of battery. So we don't have to worry about prolonging its lifespan.

ROBERT: So for experimentation, we mostly did with our stage two prototype, when we met up with Beverly-Ann. So we focused on two things. The first thing is test whether the prototype is working as we expected, in terms of notifying Beverly-Ann whenever her grip pressure becomes loose, and also to see whether it actually decreases the time when she drops the objects.

And also, the second thing we focused on, is to compare two cases-- one is when she wears the glove. And then the other case when she does not wear the glove in terms of when would you grips different types of objects, including a cup, phone, plate, and a fork. And record different holding times in the case when she grabs various objects, both when she wears the glove and the when does not wear the glove.

SHRUTI: So we took a lot of data in the beginning, especially when we had to make our second prototype, to figure out how to sort of adjust the code so that it would work for her range of however she would grip. And so, if you can see here, this is like an example of the kind of data we had to get. A lot of it is just voltage readings, but the key voltage values here are what voltage do we see when she drops-- or she's about to drop the object that she's holding. And what finger are we reading this value from.

And so based on that, we were able to figure out how to tune the code to accommodate for all of her fingers. We were also able to get time. So the time in the very last column is approximately how long she is holding it before she either unconsciously slips it, or needs to put it down. And we actually saw just between not having a prototype versus having that second prototype, a noticeable increase in the amount of time, by about 50%. Unfortunately since our prototype only recently became portable, we weren't able to give it to her for a long period of time.

And so we'd like to measure her drop rate over about a week, and then see, after she's gone accustomed to the device, whether the time it takes for her to drop it is longer now, instead of what it was before. And that's what we'll be doing over the next few weeks.

VINNIE: Here are a couple reflections that we had on the design process. So one thing, especially, is that simplicity is key. I know this is something very emphasized in the class, and that's very true. Another thing is that, in order to design something that your client can use in real life, it's very important to have multiple prototypes and to be able to deal with any technical difficulties that you have, that come up with the process. And, of course, you always have to listen to who you're working with, because you're a partner and a team, it's not a customer/company sort of relationship.

And some reflections on 6.811 PPAT-- we were all really glad we took the class. We kind of wish we had other ways to educate ourselves through about disabilities beforehand, but we're really glad this class give us the opportunity to explore that. And I'm just going to leave you guys with this one quote-- "If there's one thing that PPAT has taught me, it's that a disability isn't a good enough reason to stop doing anything." Thanks, and we'll take questions.

[APPLAUSE]

 

PROFESSOR: Team Art can get set up while we take questions.

GUEST SPEAKER: Is the [INAUDIBLE] design-- is that something she'll have to [INAUDIBLE] wearing and using [? based ?] [? on her ?] [? lifestyle ?] and where the wires are out and there. Are there any ideas for casing it?

SHRUTI: So in terms of actually being able to slip it on, we found that that's relatively easy. And in terms of body placement, we checked with her to make sure that was OK. The wires are honestly our biggest problem right now, because they stick out, and if they get caught on to something, that could be really dangerous and could rip apart the circuitry. So along with giving her the prototype to see how it works for her out in the field for like the next few weeks, we're also going to talk about how to cover all of the circuitry so that it doesn't stick out.

And we have like cloth and other materials ready to like start sort of making this more compact.

AUDIENCE: Have you thought about using conductive thread?

SHRUTI: So we did. The only issue was that the board that we were using required some components that would require wires anyways, and so, as a result-- and plus, actually connecting to the glove would have definitely required wires, because there's like a gap in cloth here that she wanted to have a watch or bangles and such. So we needed to use wires anyways, so we figured that we might as well go the whole way with wires. And this way, we can modify stuff easier.

[? VINNIE: The only thing ?] [? placed ?] [? in the lilypad ?] though is that that's actually the one she's working on herself. Like she's [INAUDIBLE].

AUDIENCE: Can I ask a question?

PROFESSOR: Yeah sure.

AUDIENCE: My last question is actually-- so it seems like the big thing for her is that she needs to remember that she is trying to grip something. And I wonder how much of that reminder is simply from wearing something on her hand, because it's kind of bulky, and so it's kind of like, oh yeah, I'm wearing this. All right, I [INAUDIBLE]. And [? that's ?] [? it. ?] [? Will you ?] [? have ?] [? to vibrate ?] only when she's about to drop or if it's everything that's [INAUDIBLE]. If it's vibrating the entire time she's holding something, is that enough of a reminder to prevent her from dropping?

VINNIE: So I'm not really sure, because when we were talking to her, and she was focusing on it-- so when she had the glove, we ended up having to just ask her questions so her mind would be distracted off of it. So I think if it's a continuous vibration, she might get habituated to it and not recognize it as something that she has to respond to.

SHRUTI: That was that was our main concern-- that if we just had some sort of static device, that she would get used to it, and then start ignoring it. But when we did the data analysis, we made sure that as soon as her grip starts to slip-- and we worked on this really carefully with her-- it would buzz immediately. And she really felt that it notified her as soon as she was in any danger of dropping something. So she was like, this is much better than having some sort of consistent reminder.

ROBERT: Also, I feel like it's not really about her forgot about she is grabbing something-- she knows she's grabbing something, but it's just gradually, over time, she's not sure how much force she is exerting, because she cannot feel her fingers. So because of that, she generally loses confidence in grabbing things, just because of the fear of she might drop it. So it's really more about telling her that you won't drop it, and just be confident with grabbing things. And then whenever you are about to drop it, we will notify you. So having that confidence really puts it back into a normal condition-- we're giving her the capability of grabbing things with one hand.

PROFESSOR: OK. Thank you very much.

RACHEL: Hi everyone. I'm Rachel. This is Jessica, and this is Stephanie. We're Team Art, and we're here to talk to you about the vertical screw lift that we spent this semester designing and building. First we'd like you to meet Art, who's actually right over there. We are really happy he was able to come today. He is an avid hacker, rock climber, and member of his community, which is the town of Billerica, Massachusetts, where he lives with his girlfriend.

He is a very active, gets himself around, is very independent, and wanted to be able to take advantage-- he works a lot with mechanical tools, and he wanted to be able to get in and out of his wheelchair onto the floor. He's in a chair because he has T5 Asia B Paraplegia, and that means he has no motor function and limited sensory function below the legs-- below the waist, sorry.

He has a hacker space at the Artisan's Asylum in Somerville, and this is where we spent most of our time meeting with him. So, as I just said, our goal was to design a lift to help Art move up and down from the floor in multiple settings. So the idea was he would be able to use it at his home, or at the Artisan's Asylum, or maybe bring it into his car to take it wherever he might be going. And we had a couple of design goals with this-- we wanted a clearance height of four inches or less. We wanted it to be able to lift Art in less than 45 seconds, because existing devices like pull swings tend to be very slow. And we wanted it to weigh less than 20 pounds which is what his girlfriend is capable of lifting, but lift up to 300.

The bottom line though, really the most important thing in all of this, was that we wanted our design to be portable, and we wanted it to be safe to use. And with a mechanical device like this, this is surprisingly difficult to accomplish. So I wanted to walk you all through the sorts of designs we were considering while we were doing this. The first thing we talked about as a team was this scissor lift design, which is used quite frequently in industrial settings. It's what you might see on one of those like cherry picker things that the telephone guy uses. But they're very complicated pieces of machinery, actually, and the actuators and hinges are very expensive for them.

So we decided this is not a good option. Next we thought about a sort of out-there solution-- the idea of using a lifting cushion. But these, we realized after talking to Art, would present us with stability problems-- if we wanted variable height, which we do he might want to transfer to a 12-inch surface or an eight-inch surface, or maybe to something higher than his chair even. If it was only partially inflated, transferring on and off of the cushions would be a huge problem.

So we started talking about using this tripod design, which would be very stable, and had fewer parts than the scissor jack, we thought. But the more we talked about it, the more we realized that the pulley that we had designed, like right here-- that pulls the seat up and down wasn't going to provide a safety for Art when the motor was off. So the seat would be in danger of sliding up and down. And so we'd have to install some sort of manual break or chain mechanism, and we thought long and hard about how to implement this and decided we weren't sure how to do it, so we needed another idea.

And those of you who were able to join us last time will remember that we brought in this cute little prototype about this big that had a screw built into it, which basically-- you turn the screw and the seat goes up or the seat goes down. And the thing that's really wonderful that this is that even when the motor's off, the seat doesn't move vertically at all. It's quite stationary. It's very stationary, even on our big design. So we can go to the next slide.

STEPHANIE: So we will be showing you our product and our functions. So currently what Rachel is doing is connecting a few 24-volt batteries through Anderson plugs to our motor, which was provided by Don Fredette of The Boston Home. It's been critically useful. So as you can see, because that's a bi-directional switch, we have the capability of having the motors turn to different directions, so we can essentially move the seat up-- Yes, thanks.

As you can see, it functions perfectly fine. So what exactly is this contraption made of? Well, the frame is actually made up of a bunch of 80-20 aluminum rods that we actually scrounged from an abandoned laser in the physics lab. So the entire frame would probably cost you $200 to maybe $400 if we purchased directly from the 80-20 site, so we got really lucky there.

The lifting mechanism is actually-- it's essentially a Acme rod that we-- a threaded Acme rod that we purchased ourselves. And this is the life-size version of the tiny screw that you guys saw in the previous balsa wood tiny model. And we were able to obtain that motor that's turning the Acme rod and these batteries from again Don Fredette from The Boston Home.

The seat is made of aluminum, and it was actually water jetted by someone from the course three department. It weighs approximately 8 to 10 pounds, so it bears a decent bulk of the weight. And there is a lot of connective hardware in our device. To actually interface the motor with the Acme rob, we had to purchase a few sprockets and a chain in order to actually have the motor actuate the spinning motion of the rod itself. And we had to purchase several flanges, flange bearings, and thrust bearings in order to reduce friction between the Acme rod and the 80-20 frame itself, as well as actually connect the Acme rod to the seat.

So as Rachel mentioned before, our desired features involve preferably moving Art up and down about 22 to 24 inches in less than 45 seconds. We would like a clearance distance of four inches, and we wanted the device to weigh less than 20 pounds. Currently, our device lifts and lowers a complete length in approximately 30 seconds, so we definitely met the first feature. We also met the second feature in the sense that we have a clearance distance of four inches. Unfortunately, we were unable to make this apparatus weigh less 15 pounds, because it weighs 30 pounds. And that can be attributed to the really, really heavy aluminum frames.

And currently, it actually does not lift weight, because the motor does not provide enough torque to actually lift a significant amount of weight.

JESSICA: So we got pretty close with this design, but there are still a few improvements that we would have liked to make. First and foremost, we need higher torque motor. Our current motor does not have enough torque to actually lift weight and that's the primary function of our device, so if we can't perform that, it's a problem. We would also like to reduce the weight of this contraption, because it is a little heavier than we'd like. So lighter and thinner parts would be optimal.

Another issue is portability. That was one of our original design goals and we haven't quite gotten there yet. Our current idea would be to add wheels to the back end of it and a handle so that you could tilt and pull back. And safety-- the device is pretty safe, except for the loose chain that's open here, so we would like to be able to cover that. And some of the things that we've learned through this project are that parts are expensive. Software is not so expensive. Parts are expensive.

Understanding and designing for your user is very important, but you also have to keep in mind safety, and feasibility, and it can be pretty complicated. Iteration, therefore, is key. That is one of the most important things you can do. And sadly, with our limited time frame, and our large device, it was hard to iterate as much as we wanted.

Like I said, the most valuable resource there, of course, would be time, since we didn't have enough time to iterate as much as we'd like. Reaching out to others for assistance-- that's super important. We received a lot of help from Art from the Department of Material Science. And we received a lot of help from Don, who gave us a lot of parts, and who helped us connect all of this together. And from the PPAT staff in general. And so with that, we'd like to thank you guys and open the floor to questions.

[APPLAUSE]

 

ROB MILLER: I wonder if you could talk a bit about-- I know you said that it can't actually lift anyone, but did Art try to get on it? So what is the process like for getting yourself situated on that platform? And is it stable enough to be [? in that ?] [? state ?] without falling over [INAUDIBLE]?

STEPHANIE: So it's definitely based on Rachel just standing on the apparatus and jumping on it-- it's definitely stable in terms of actually holding up weight. But the issue is--

RACHEL: I should add though-- this is a new development. That was not true until Sunday, when Art helped us [? machine ?] apart to keep the seat stable. We had all of this working, except the [? seat ?] was wobbly for the longest time, and we were concerned about this as a design feature, obviously. We actually didn't get to the point of having tried it, but we'd like to do that [INAUDIBLE] questions?

GUEST SPEAKER: [INAUDIBLE].

[LAUGHTER]

STEPHANIE: Ideally though, there should be no issue with Art transferring into and out of the chair, because this would be positioned right next to his wheelchair, so that he would have to do a slide over onto the chair, once it's set at the ideal height.

ROB MILLER: But if you're on the floor--

[INTERPOSING VOICES]

ROB MILLER: [INAUDIBLE] lift himself up and [INAUDIBLE].

RACHEL: Yeah. So the clearance of four inches was a design goal given by Art. Four inches is the maximum distance that he's comfortably able to move vertically to a different surface.

JESSICA: And so we were trying to counter that with the design [? itself. ?]

GUEST SPEAKER: So that frame that's parallel to the chair, and running through [INAUDIBLE] come up to seat height, and then you would [INAUDIBLE].

PROFESSOR: Any questions?

AUDIENCE: What do you think are the trade-offs of making it lighter and the safety [? constraints? ?] if it's lighter, wouldn't it be easier to tip over? Have you guys thought about what happens if it falls over.

RACHEL: So I guess I should talk into the microphone. Basically, no, because the center of mass of this contraption is always going to be over the center of the center of the frame, and with a user on it, or transferring onto it, there's always going to be weight over the support base. In terms of making it lighter, we wouldn't be looking probably to replace the entire frame. We might make it out of like a smaller 80-20. i feel like that was a possibility. But the biggest thing we could do to reduce weight is to reduce the thickness of the seat.

Half inch aluminum holds up like 1,000 pounds, and that's just unnecessary. It's just happened to be what we had lying around. It was what we didn't have to pay for. And if we had a lot of time, we would probably go and mill out some shapes in the bottom to optimize thickness where it was necessary and cut out extra weight where it wasn't.

The other reason that it's heavy in general is just that we ended up finding that lighter components, like components that weren't made for heavy-duty usage we're going to stand up to the wear and tear we expected this device to see. We actually had a second prototype that never made it in here, because it was terrible. We bought cheap components, and they were lighter components, and they didn't work at the rotations. That rod right now is turning at 400 RPM, and so it has to be able to spin really smoothly and without bending. And so any material that's tool-grade steel doesn't work and et cetera, et cetera.

PROFESSOR: All right. In the interest of time, we should move on, but thank you very much.

[APPLAUSE]

Can we get Team Paul to set up?

YI: So we're Team Paul. My name is Yi.

LEXIE: I'm Lexie.

BRADY: And I'm Brady

YI: And we are design a coffee crane. Which we'll let you know. So first we just want to quickly review. So our client is Paul. He has been an amputee for over 30 years, so he uses these forearm crutches to help him. And then because he had an injury with his hip, [INAUDIBLE] so he's been kind of regaining his strength. And he's doing physical therapy now, so he's mostly staying home. So our client's not going to be around. So we're designing this for the home.

So the problem statement is we want to design a device or a mechanism that allows Paul to carry at least one full cup of coffee around his house without spilling of without gripping onto the cup like is, which is how he carries it before. And the success metrics that we had were current status-- well, I guess, the previous status-- is that coffee cup can only be filled to one third full. So in the morning, he can only fill it up to one third, walk to the sofa, and then sit down, and then drink the one third cup of coffee and then go back to get more.

And he had to claw-grip on the cup. So because he's using crutches, that sometimes can be turbulent-- so even if it's only one third full, it can still spill on his hand. And so when we were coming up with goals, we two goals-- the livable goals and the ambitious goal. So we wanted to design something that doesn't spill when it's 2/3 full, and there's no need to hold on to the cup like he does now, where it's clawing. And then hopefully it can be removable with 20 seconds on and off time. And then Paul gives us a rating of six out of 10, and it works for one of his mugs.

Because that's one of the main things Paul wants is he wants to use his mugs, instead of maybe a thermal or something. An ambitious goal is no spill with coffee cup 3/4 full, and no need to hold it. And then removable within 10 seconds, and then Paul rates it eight out of 10, and it works for all of his mugs. And then just some of our early prototypes. So we were thinking of maybe if we just cover the cup with one of these, which works really well-- it will not spill. And then just maybe put it in one of the stage holders, and then just put the stage holder on his crutches.

And because his mug didn't fit in that-- that's too small-- we were thinking of another kind of cover, which is the flexiCover. So it takes actually a lot of strength to put on, and you have to stretch it. And then we were thinking, well, maybe we can use some sort of gyroscopic cup holder idea, which allows it to swing. And then this works horrible, and there's spilling even when you put the cup in.

And then we thinking this kind of clamp to clamp onto his crutches, which we have here. And Paul actually destroyed it, because it's too weak. He broke this things when we tested it. And then, after all those iterations and looking for the right products, we have a final prototype.

LEXIE: So our final prototype-- one of the main we-- products that we found was the Spill Not. And basically it's a product that if you put a coffee mug on it, you can put it at any angle basically, and it won't spill the contents. And this has to do with the forces-- as you move this way-- counteract the other forces. So, magic.

[LAUGHTER]

But this definitely works with basically any mug that you could put in here, and it definitely works with all of Paul's mugs, and probably any he would get in the future. And it definitely is no spill. The only time it would spill is if it hit something or gets jarred in any way. So we decided to put it on a rod far away from his crutch so it wouldn't actually hit into his crutch, and basically just put a hook on the end so that he could easily connect it onto the rod.

And then it would be easy to just slip on and off. And we needed a stronger clamp, obviously. This is not actually the one we ended up using. I don't have a picture of it. We got clamps from Don Fredette, and basically it's a clamp that he would leave on there permanently, and he's really OK with that. He actually really likes that it's there and it's very solidly on his crutch. And then he can just attach this rod to the clamp then. And then we added this handle on it to make it even easier to put on.

And this is the product on Paul's crutch. It doesn't have the handle on it yet. This picture was taken before we put in on. So some of the assumptions that we made while making this final prototype were that when he's putting the Spill Not on and off, he would be able to remain standing, and he wouldn't spill anything. And that basically he would be able to move around his apartment and maneuver in there. And so when we went to experiment with this, we actually were using the weaker clamp at the time, so we basically couldn't test with the coffee cup in it, but we were able to test different rod lengths.

So there's eight-inch, and then we also tested a 12-inch, and then we tested where he was able to hold it out this way with his crutch, and this way, and then this way basically. And we found that straight ahead was the best orientation, because it didn't knock into the wall and all the other ones did, with the eight-inch. So this is a video of Paul putting the clamp on.

And as you can see, it doesn't take very much time, because the clamp is already on there, and he's just putting the rod on. And then he puts the Spill Not on top of it. And he can maneuver with it. And it just kind of hanging out there. And he's able to maneuver. That's his cat. He's able to maneuver around his apartment fairly easily.

BRADY: So as you can see from our success metrics, we had Paul test out the prototype. We left it with them for a week. Asked for his feedback, and he gave us very, very enthusiastic feedback. He loves it. He rates it 10 out of 10. It was actually really nice to see when we walked in the door when we met with them that he had the clamp still on from when we'd given it to him last week. He said he hadn't taken it off. So that was really nice.

And he said he's been walking around his apartment with full cups of coffee. He hasn't spilled anything yet, so he's really really happy about that. Obviously he doesn't need to hold the coffee cup, because it's out on the Spill Not. So that was another one of our ambitious goals that we met. The one part that we didn't quite meet is it does take a little bit longer to put on and take off, because it is that rotating motion putting on and taking out the extension as opposed to, say, a quick release clamp or something like that. But that was a trade-off we were willing to make because it's definitely more sturdy.

Like we said, he destroyed our other clamp, because he's got really, really good grip strength. And like we said, it works for all of Paul's mugs. So that part's fantastic.

All right so what did we learn through all this? Nothing is as simple as it first appears. You kind of underestimate the task when you think, oh, I just need to have him walk around his apartment with a full cup of coffee-- how hard can that possibly be? But it turns out, it was actually really, really difficult, and if it hadn't been for the Spill Not, we probably wouldn't have been able to accomplish the goal that we had set for ourselves, but that Spill Not was definitely a lifesaver.

Fail fast and iterate until success. Like we said, the covers probably would've worked OK, but they're really hard to put on and take off, so from then that kind of sparked the rest of our ideas. And then with the Spill Not, we thought maybe he could just hang it off the handle of his crutch but that doesn't really occur to you-- well what happens if it bumps into his crutch, and all of a sudden it start's spilling everywhere?

So fail fast and iterate from there. And finally, keep the end user involved. Paul met with us pretty much every week. He was always available, and we definitely came up with something in the end that he's very, very happy with. And from Paul we learned to be grateful for the small things, such as being able to carry a full cup of coffee.

And his favorite quote and the thing and he said literally every time we visited was 'You guys are doing wonderful stuff. This is great. So keep it up." All right. That's it.

[APPLAUSE]

 

BRADY: Yes?

ROB MILLER: So what you ended up with still has three parts to it right?

BRADY: Yes.

ROB MILLER: There's the bar; there's the Spill Not, and [? the coffee ?] [? cup. ?] Did you explore trying to cut that down to two? Certainly, you need the cup to be able to [INAUDIBLE]?

BRADY: You mean as in from here and eliminate the hook portion?

LEXIE: Well when you're spending it on, it would kind of-- I mean you could do it, but I think that it was a little bit hectic if you wanted to spin it on, it would kind of flip the Spill Not around.

BRADY: Plus the other part is how Paul uses it is once he's out of the kitchen and into his living room, the table is actually at just the right height where he can remain standing and gently set the Spill not. Onto the table and unhook it from his crutch. So then he doesn't run the risk of-- he would you have to remain standing and try and unscrew it with the cup still on the Spill Not.

ROB MILLER: It helps with the delivery.

BRADY: It helps with the delivery time onto the-- exactly.

[? ROB MILLER: The ?] other part of that would be that if you could attach the clamp to the rod, but is difficult for him--

[INTERPOSING VOICES]

 

BRADY: Finding a clamp that worked really well and then finding the correct length rod to keep it out, away from the crutch was kind of an iterative process. Like I said, we tried out the 12-inch, we tried out the eight-inch. and. Other thing is he really liked the idea of keeping it on there permanently, at least the clamp. And if there would have been a quick release clamp that worked very well, we probably would have looked into that a little bit further. But the clamp that he liked the best thing and that definitely worked the best is the one that was on there permanently. So it made more sense to just be able to unscrew the rod.

AUDIENCE: Could I suggest that maybe you look into getting him a crutch you would attach this to that he only uses in the house?

BRADY: So Paul's crutches are actually custom.

AUDIENCE: Are they super expensive?

BRADY: Yeah. The previous group mentioned like $200 to $400 for aluminum, we'd be easily double that max price.

ROB MILLER: [INAUDIBLE] bend you over for any kind of adaptable gear.

AUDIENCE: What?

ROB MILLER: It's called any time you say, oh, adaptable equipment. Drop your drawers and bend over, because there's something you really don't like.

GUEST SPEAKER: I'm wondering if we can get t-shirts with that "Fail fast, iterate until success."

[LAUGHTER]

 

BRADY: The MIT motto right?

PROFESSOR: In the interest of time, thank you very much.

BRADY: Thanks.

KELLY: Hi guys! I'm Kelly

EDDY: I'm Eddy.

EUNICE: I'm Eunice

KELLY: And we're here to talk to you guys about script speak. So our client this semester was Barbara, who was a former teacher who now lives at the Leonard Florence Center. Barbara, over a year ago, found out that she was diagnosed with Primary Lateral Sclerosis, which is a neurodegenerative disease, which results in muscle weakness. As a result, speaking for her now is very hard, and her speaking has gotten more unclear as time has progressed.

Because of her first speech, she's faced several challenges in different sorts of environments. When it comes to group environments, it can be very hard for people to understand her, because often they're very, very noisy. She also trouble speaking to people who don't understand how her speech functions, such as non-native English speakers, or a taxi drivers-- people who just don't have correspondence with her.

She's also found that in virtual environments, It's. Also very difficult for her to talk to people. So through phone or video chat. I'm

Currently she's tried out two solutions besides speaking, and one of them was called Proloque4Text. This is an assistive text to voice app, and she found a very unintuitive to use, because technology is not her forte. And she also try using something called a BoogieBoard, which is a more physical board that she can use instead. And through this, she found that it was nice because she could write, but also kind of inconvenient, because she would have to write out everything she wanted to say, and she couldn't save it anywhere.

And so both of these solutions we're lacking something. And knowing that she was technologically not very equipped, we knew that had to be simple to fix her problem. And so we decided to create ScriptSpeak. ScriptSpeak is a text to voice app, whose main purpose is to be as simple to use as possible, as well as customizable, so the user can enter in any phrases they want. And ultimately, it should expanded the environment in which she can speak.

EDDY: So our success metrics are here. Our livable goals is what I'm mainly cover, which is we wanted her to be able to attempt to speak-- one of the main reasons is you use it or lose it, right? So she continues to try and use her speech, but even over the course of this class, we have seen a significant decrease in her ability to pronounce certain syllables. So we want to be able to try, but if she ends up not being able to speak, we want to be able to either type out the phrase, or if she's already spoken that phrase, she can find it in her history or in her favorites within five clicks.

We want to basically have her increase the efficiency of her speech by lowering her response time by about 20% overall. So basically, an amortized cost over how many times she reuses phrases, as opposed to her current method, which she has to type every phrase, whenever she's going to speak it. So she can't really reuse or use the components that are available, even though the features are there. It's just very complicated for her. And larger, noisier environments from five to 10 people.

So right now she's really OK with speaking to you and using her current apps when it's one-to-one or one-to-three, especially for our meetings. But in other settings, she wasn't unable to use her apps because the iPhone is too low. And the iPad app she hadn't used for an extended period of time, so she was very uncomfortable using it. So we wanted to give her a solution she can use in both of those settings.

So we started prototyping with her main point being keep it simple. The simpler the better. So we started off-- we gave her this paper prototype where we had her test. And right from the start, we found out that we found that most of the common UI functionality that we're all used to with apps in the app store don't really seem intuitive to her. So swiping to delete, and a few other of these characteristics were not something she would use. So we stripped that down, and we went back to how UIs are more intuitive in terms of you see, and you click on it, and that's what you get.

So we see here the star for favoriting and so on. Then we created our second prototype really quickly, because we wanted to get something in her hand with App Inventor. So we built basically an app that she could click the text and it would like play, and she can add text and store that into her history. So that was our initial prototype.

Then we started having the iOS app. So we don't want to have no interaction until too late. So we started of-- we had her history page and her favorites page right from the start. But we needed to update a few things so we could have the stars be on and off as she would like it. And then we connected both. So whatever she did on the history page, it was reflected on the favorites page if it was necessary.

And then after we finished this, we brought it to her, and we got a piece of feedback we didn't expect, which is that she wanted it to connect between her iPhone and her iPad. Initially, she said that her iPhone was too low-- the volume was too low, so she really couldn't use it in most environments, but then she told us that if she's going to be a smaller setting, she's in her phone with her, because it's less heavy. So we needed to connect both of them.

So we just connected the apps through Parse, and we're going to deliver that to her. So the functionality is the same. It's just now whatever she types in in one will be reflected in the other. So we'll have a demo for you.

KELLY: Now we're going to show you guys a demo using the simulator. However, the text-to-speech doesn't actually play on a laptop, so we will play it for you on our iPad. But as you can see, we have the app working on both the phone and the iPad, so it's customizable for both.

EDDY: Trying to find your screen.

KELLY: Pull it that way.

EDDY: This way? Seems like the simulator cannot be dragged.

KELLY: It can't be dragged over.

EDDY: It cannot be dragged over.

KELLY: Can you switch it? No, you can switch the-- [INAUDIBLE].

 

I don't remember [? that. ?]

EDDY: In any event, we do have--

KELLY: Wait [INAUDIBLE] should be moving.

AUDIENCE: Go in System Preferences.

EDDY: Oh, in System Preferences? So in any event, we do have the app loaded onto our iPad. So we added the feature that she can compose a sentence with previously said text, and then she can play it in the end. So can store her name, and whenever she has to type in her name, it's always there for her. We also added that she can delete her messages, and she can go to her history, and in her history she can favorite the items. And then if she deletes these items--

SYNTHETIC SPEECH: This is awesome.

EDDY: So she can play it. A little plug-in there. And if she delete these from her--

SYNTHETIC SPEECH: This is awesome.

EDDY: I'm sorry. If she deletes these from her favorites, it reflects in her history. And since we also delete it from the history, it no longer shows up. We have another, more intensive-- technical difficulties.

KELLY: Sorry, the simulator's too big for that screen, so we just have to go.

EDDY (WHISPERING): So we'll just continue on. It's fine we'll just continue on. it'll be fine.

KELLY (WHISPERING): I don't know how to use this.

EDDY: All right.

KELLY: Present, present, present.

EDDY: So that's most of the functionality. And now it's connected as well. And she's been using this past week. A week and a half.

EUNICE: So we did a couple experiments with her to see how well our app worked compared to all the other ways. So we asked her to say a short phrase first. So just to say "Hi, my name is Barbara" four different ways. First by speaking, and then writing on the BoogieBoard, and then ScriptSpeak, and then also her app Proloque. As you can see, the second time-- the orange is when she writes the phrase the very first time, and then she saves it in the app. And then when she closes the app and then access it the second time, ScriptSpeak is a lot faster.

The first time takes a while, because this was on her iPad, which is new. So the auto correct wasn't trained enough with what she usually says. So another thing that we also measured was the number of clicks that it takes. Also for ScriptSpeak, it takes a lot fewer clicks. As you can see here. And also for Proloque, the other app, it is very inconsistent, because it's very confusing for her.

So even though she saved it, she couldn't find it, so she had to end up typing it again, which is why it takes so many clicks. This is a video of her using Proloque. Play it. We don't have time for the video.

EDDY: We can play it.

KELLY: Oh my gosh. OK, we can move on then.

EDDY: So basically in the video, you see that she doesn't feel comfortable with Proloque. So we asked her to repeat the phrase, and she has to type out the entire phrase again, because she doesn't know where it's stored. Whereas, in our application, she was able to go to the other screen, and immediately just find in her history, and then she favorited it after that, and she had it as well. So she was able to play from the history page without any real time. It was like a three, four second time to reply, whereas the other [INAUDIBLE] was just as when she typed it.

EUNICE: And then we asked her to repeat the experiment, this time with a longer phrase. And as you can see, the second time it was a lot shorter. With Proloque, it seems like the second time is also a lot shorter, but actually it didn't really work, so she clicked it, and the phrase was entered into her text like multiple times, and she was very confused about it. So actually, even those it was fast, it didn't work well.

And as for the number of clicks, similarly, it was fewer clicks, but it didn't work. So that didn't accomplish the goal. This is the amount of time she used it. So we left the app with her over a weekend. And she used-- this is the information we got from her iPad. She used this phrase twice, three times-- so she was actually using this app to speak. And she also used on her phone more, but we couldn't get the data for that.

PROFESSOR: I think we're going to stop here, just so that we have time for questions. Thanks very much.

[APPLAUSE]

 

Questions?

GUEST SPEAKER: I know that in the beginning, you were going with a different direction with Barbara, right? For using kind of a [? door ?] automation, something. Was it really difficult to kind of switch gears and go in another direction when you realized the first goal wouldn't be achievable.

KELLY: Yeah, that was probably the hardest thing we had to deal with all semester, because when we finally chose our idea to go with software and develop and app, with lost around a month's time. So we had to really cram it all in, but it basically made us realize that early on we got to learn how to fail fast. And so you can go with an idea, but only until you realize that's it's not possible. And you shouldn't just hold on to one thing, because you think that that's the only idea that she wants.

And so it's really important to always communicate with your client and throw out any ideas you have as well, because you're also part of the solution, and you have as much say in it as they do. And you can bounce ideas of each other and come up with something really awesome.

EDDY: Another part of that is that part of what we have here in our lessons learned is we came up with an idea of the ScriptSpeak that we were never asked for initially. She really didn't think of it as a possible solution. She wanted home automation, and we focused on that, until we found out by regulations that we would have too short of a time to actually make a difference.

So we were able to make an idea and converse with her about something that she didn't particularly want. And then the moment we came up with that idea, she was like, oh, I love that. Do that. Forget the door. So it was a hard process, but we ended up liking the project we had. And we're all CS majors, so it was definitely our home-field advantage.

GUEST SPEAKER: So was it something that you just intuitively knew would help her?

KELLY: So she actually mentioned many times that she would like an app that would help her speak better, because it's the most difficult problem she deals with. She just didn't know that it was possible to create something that could fix it. And so we realized that hey, we're CS majors. We can definitely do this for you. And she was amazed the see that it was actually possible.

PROFESSOR: Other questions or comments? OK. I think we're at the time today. Thank you very much Team Barbara.

[APPLAUSE]

Well, down there today everybody. Thanks for coming out for these three hours of presentations. We will have a class selection next Wednesday at one o'clock, and then the showcase is from 3:00 to 5:00 next Wednesday. Thanks very much.