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

My main responsibility at work is to put together wireframes–a document of diagrams and annotations detailing different specs and interactions about each page of a site. It may involve deriving the functionality, flushing out the content, deciding what the content is, and how each component behaves. This document then gets passed around between the client, the creative, and the development teams. For the most part, it’s a lot of fun.

However, because the wireframes are used by everyone, deciding what information to put on it and where that information should go (to ensure everyone gets what they need out of it) becomes a challenge. Documentation becomes extremely important because we want to make sure everyone is on the same page, but if they can’t find that data or if they don’t read it, the vision falls apart.

While we’re waiting on the new projects to go into production, my manager and I had a brainstorming session to figure out a new wireframe template. The information that we need to include are:

• Project title
• Version and edit control: what version of the wireframes we’re using, and what has been changed since the last version
• Page number
• Page reference: different from page number because page numbers are variables, and not necessarily the same across all copies which makes referencing difficult
• Page title: e.g. homepage, sitemap, contact page
• Documentation/Page modification date
• Reference: sites that have the interaction that we want to develop
• Source: if the project is a redesign, and we’re designing off an existing page then that page would be considered the source
• Template: e.g. A (one column), B (two column 75/25), etc
• Annotations: reinforces the interactions that the diagram illustrates
• Client feedback: comments, approval status, etc
• Callouts to the client/creative/development

The designs that I came up with before the brainstorming session look like this:

When I was working on wireframes in the last two weeks, I had a lot issues with the ratio that came with a landscape orientation. If the pages are long–and pages are often longer than they are wide (even though screens are wider than they are long)–I find myself trying to cramp everything together. For example, I would shrink a textarea to look like a text field so that I can fit in a submit button. So we spent a good amount of time trying to decide whether we should go portrait or landscape, legal or letter.

Some conclusions

Actually, not really conclusions but things that we’re going to test with the next set of wires:

• Two different scaling of wireframes: one portrait to be used for sites with long pages, one landscape for sites with short pages.
• Annotations take up a substantial amount of time. Taking the idea from OLM, if we develop a library of reusable annotations that we can just drag and drop onto the diagram, it might save us some time. Especially if we reuse interactions like the accordion or the flyout.
• Have a change log to keep track of revisions and client approval.
• Reference numbers at the top left hand corner to be screen friendly and the bottom right hand corner to be print friendly.
• A mini sitemap visualization on all pages to put current page into context. This requires a lot of effort to maintain, and we’re not sure whether it’s worth the reward. If we change the site map, we’d have to update every page.
• Reserve certain colours/styles for annotations.

My task for tomorrow will be designing the change log page.

I wouldn’t want to be waited on by him when he’s angry…