Archive for November, 2017

Building a Better World Through Universal Design (quiz make-up)

Thursday, November 30th, 2017

The advancement of assistive technology requires the perceptive eye of someone who recognizes problems from the perspective of those with disabilities. Often times, we try to find problems and create solutions from our own lens, instead of exploring other facets of life that affect those unlike us. Using the principles of Universal Design, I have noticed problems within MIT’s community that could be solved to allow more accessibility for people with disabilities. For instance, size and space for approach and use would dictate that the buttons on building 3 elevators could be lower for little people or those in wheelchairs. There are some areas on campus that do not have ramps despite the high density of people traversing those places, an example of improving the equitable use on campus. In addition, to improve upon the principle of low physical effort, making doors that aren’t so heavy for people with physical disabilities could make their lives much easier.

In addition to improving my perception, the laws of Universal Design have also improved my ability to design our product for Jim. For example, the principle of flexibility in use, helped my team and I recognize that we needed to tailor the shape and opening of Jim’s cardholder to the differing abilities of each arm. More specifically, the cardholder’s orientation and position on his half-table is such that Jim can use his less dexterous arm to slide the card out toward his more dexterous arm (left), in order to grab the card. Moreover, the principle of low physical effort inspired us to make the coefficient of friction between card sleeves low, and make his cardholder short, so he could effortlessly reach his right arm over the cardholder and slide his cards out with ease.

Ultimately, understanding Universal Design not only makes one more perceptive of the issues people with disabilities face; it makes you a better engineer, able to effectively tackle problems that are not apparent at first glance.


The challenges of a restricted developer

Monday, November 27th, 2017

In Team Erica, we have been designing an iOS application that allows Erica to communicate with her desired audience in around three taps on her home screen. Our vision of the app and its layout has been simple to deploy within XCode, the only application that Apple authorizes for software developers to build applications across the iPhone, iPad, and Apple Watch product lines.

Nonetheless, in implementing the actual functionality of our application, we have encountered a few hurdles. Compared to other mobile platforms such as Google Android, Apple iOS places strict limits in certain freedoms apps developed by third parties exercise. One specific instance of this is in sending emails. We intended that our application be able to programmatically send emails in the background to certain contacts after a simple button press. However, Apple does not allow app developers to access the user’s email credentials and send an email message without an explicit preloaded message appearing for the user to confirm. Since the confirmation button is very small, we wanted to avoid having this screen. Thankfully, after some web searching, we were able to find a workaround by implementing the ‘MailCore’ API that is able to programmatically send emails by directly accessing email servers, bypassing Apple’s Mail framework.

For sending text messages, we encountered a similar challenge, solved by implementing the Twilio API text messaging service. As opposed to MailCore, Twilio, however, is not free. In an average case, it costs around 50 cents per month for a single person to use the service. As a team we have been debating who would assume this cost: Erica or someone else? Organizations place restrictions on the freedoms third party developers can exercise in their apps to conserver user’s privacy. Should assistive technology applications be the exception?