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.