Sensorial’Org

I mentioned earlier this month that I will be involved in another project this summer, now I have a little more details.

Reference: Breaking the Disposable Technology Paradigm. Also see the incredible amount of human waste.

The problem

• Advances in computation + dependence on technology => increase consumption on computation devices
• Disposable technology paradigm: expected short usage lifetime => increase in waste. In particular, cellphone waste where consumers replace their cellphones every 17.5 month
• Old cellphones are being deposited in landfills or kept around with no alternative use

The cause?

Questions

• Why did you get your current phone?
• Why did you choose this particular phone? Size? Functionality? Aesthetics?
• What do you do with your old phones?

• Companies offer free cellphones with contract renewal
• Increasing expectation of existing phones in light of new models
• Diminishing battery life (cheaper to get a new phone than to replace the battery); durability
• Perceived lifetime of a phone is independent from its functional lifetime

The challenge

• Recycling old phones is an inconvenience
• People don’t know about organizations out there that take old cell phones
• Although people save old phones because of its potential to benefit another user, people don’t necessarily want the old phone

The solution?

• Reform contract structure and incentive programs
• Mobile phone interfaces that encourage sustainable use
• Novel ways to reuse old cellphones to decrease the need for new devices
• Make phones with biodegradable material
• Make it easy for consumers to recycle their old phones

Ideas

• Indicate the user’s ownership of the phone in comparison to the phone’s expected functional lifetime
• Create a market place for phones to trade ownerhsip
• Old cellphones as a personalized gift; branded as a photo collection, mixed tape, etc
• Increase awareness of recycling options and locations by convenient means, e.g. through the phone itself
• Modifiable outer designs without changing the internal hardware
• Repurpose phones as entertainment devices in clinics and hospitals, pagers in restaurants

Rethinking the Ordinary — Links

• Ikea Hacker
• Yiying Lu’s Extra Ordinary series
• 60 Really Creative Advertisements
• 100 Really Creative Business Cards

The University of Toronto launched its First-year Learning Communities (FLC) program four years ago. It’s a program that is meant to help first-year students adjust to the university lifestyle by providing them with a close-knit community which meets on a biweekly basis. Each community is made up of two mentors (upper year students), a staff/faculty advisor, and up to 24 first-year students all within a specific area of study (e.g. commerce, life science, philosophy, economics, and of course, computer science). Each meeting is an hour and half during which they engage in a mixture of academic and social activities.

I was one of the assistant mentors for the computer science FLC this year, having been in the program when I was in first year myself. Our last meeting was on Thursday; it has been an amazing year. We had a variety of developmental sessions including the academic integrity, time management, resumes and cover letters, better health for a better GPA, and scholarship and research opportunities workshops; however, the social sessions are the ones that I’ll remember most and also the ones that I think are most important. We played board games and video games, we played dodgeball and we went skating. We played pool, and we carved pumpkins. We talked about Pokemon and made masks with googly eyes and feathers. We poked fun at each other over lunch and ruined each other’s chess games after dinner.

I strongly believe that to succeed in university, you have to immerse yourself in the community. That means surrounding yourself with a group of friends that motivate and support you, getting to know your professors outside of the lecture halls, and learning about the opportunities around campus and getting involved in them. The social sessions in FLC reinforces these ideals, and I hope I was able to get that message across to my students.

Last Thursday was the feature freeze; this Thursday was the code freeze. It’s frustrating that I haven’t accomplished everything that I’ve set out to do, nor have I finished everything that I’ve started. The next best thing is to document what I’ve done so that someone else could pick up where I’ve left off.

Following the last progress report:

February

Week 2: Folded the Student and TA Controller into a User controller, and abstracted the Views to handle both types of users.

Week 3: Code sprint! Started the initial mapping of TA to groups, and played around some more JavaScript. TAs are mapped to groups, and that information is sent to the database. A count is displayed next to each TA’s name to indicate how many groups have been mapped to them. This information is not assignment specific however, because towards the end of the second day, the backend was remodeled so I didn’t want to invest a lot of time implementing something that would break with the new architecture.

Still needs to be done is the toggling of groups (e.g. groups that’s been assigned to a TA, groups that haven’t, groups that have been assigned to a certain TA, etc), automatic mapping (e.g. divide the groups evenly between all TAs), and unmapping.

March

Week 3: Since the TA mapping was at a stand-still, I spent the week polishing up the Assignment Rubric’s and Grader’s view.

Week 4 (to be done):

1. Documentation: what’s been done, what’s still left to be done.
2. Documentation hand-off details; where things are; which files are doing what.
3. Documentation within the code; make sure everything makes sense.
4. Refactor some code.
5. File tickets when necessary.

Summary of Deliverables

Screens on the top illustrates how the system was before I implemented my changes. The after shot is on the bottom for the comparison.

Read more…

Reflection

This course has been both been challenging and fun. Challenging in that Ruby on Rails had a steep learning curve and trying to pick up a new technology along with three other different technologies in other courses was difficult. Furthermore, time management is extremely important. On one hand, you’re working on a project that you have an genuine interest in so you tend spend a lot of time trying to perfect it. On the other hand, there are no deadlines. We meet on a weekly basis to report our progress, but you aren’t given an assignment and a date that it has to be done by. So there’s a temptation to push this aside and try to make for it later because something’s due at 10 tomorrow morning.

At the same time, however, it was also really fun and rewarding:

• I had the pleasure to work with Karen Reid, Geofrey Flores, Amanda Manarin, Mike Conley, Andrew Louis, and Severin Gehwolf. My favourite part of each meeting is that it always begin with a little off-topic discussion about how everyone is doing outside of this course. It’s extremely refreshing because it doesn’t feel like I’m in school.
• It’s not computer science without the technological component. Aside from picking up on Ruby and Rails, and Javascript, I was also forced to use the command line a lot more. I’m much more comfortable with writing scripts, using vim, killing processes, using subversion, searching for and through files, debugging, connecting to servers and databases… all that stuff that I learned and forgot about in first and second year came into practice.
• It’s going to be used! Deployment is in September 2009. I still remember how excited I was when I got my first paycheck as a designer. It’s awesome that you love what you do, but having other people value what you do as well is something else entirely.