« December 2005 | Main | February 2006 »
January 31, 2006
Sounds Pods
Problem
Assistive technology is expensive and oftentimes serves only one
purpose (i.e. a vibrating alarm clock for people who cannot hear).
Goal
Build a customizable, assistive technology device that will allow
hearing impaired individuals to experience the world like everybody
else. give them more awareness of their world. Don't wait for the
devices people to use to change (soda machine, alarm clock). instead
build an intermediary to negotiate signals between unassistive
technologies and those in need of assistance.
Idea/Device
Individual pods, globally connected to a wearable vibrating module and
configured from a pc using bluetooth which will help the wearer become
aware of the sounds around them. different pods would be programmed
to react to different sounds and vibrate the wearable with a different
pattern. the system would come with default sounds but would also be
fully customizable with personal sounds. individual pods will be able
to support multiple sounds and multiple vibration.
the started kit comes with a couple of pods. more can be purchased as needed.
Pod Placement/Uses
near the doorbell chime
next to the alarm clock
next to the tea kettle
next to the smoke detector
on the dog's collar for when it barks
on yourself for detection conversation
Other Ideas
configurable via home computer
pod low on battery alert (or maybe they are plugged in?)
default/sample sounds
different vibrations to detect different pods
Research
I went through the Harris website and I think our idea is still very
strong. What we assumed about the market is correct. There are
plenty of custom alert modules for telephone, doorbell, alarm clock
etc but nothing general to allow a hearing impaired person to
customize what they want to 'hear'. It's as if they are segregated by
the industry. This is what we say is important, why would you care
about anything else?
There are a couple of products that did a little more but they had no
customization component. A baby alert system
(http://www.harriscomm.com/catalog/default.php?cPath=1140_44_1086)
which also does an alarm clock and dorbell and an ADA complaint hotel
room kit. The baby alert system would be a great example for our
project. The hotel room kit did four or five things but it wasn't for
the end user to carry around, it was for the hotel room to be wired.
A hotel owner has to buy one per room.
I also spoke to Spencer and he said that what we are suggesting is
feasible. The fine tuning would involve the direction of the
microphone and the proximity to the nose emitter (alarm clock, etc.)
Posted by mb2811 at 08:48 PM
January 30, 2006
MTA Subway Map
A user centered design analysis of the MTA subway map. Link to writeup.
Posted by mb2811 at 01:14 AM
January 29, 2006
Reaction/Notes: Spark Innovation Through Empathic Design
Dorothy Leonard and Jeffrey F. Rayport, 1997. "Spark Innovation Through Empathic Design," Harvard Business Review, volume 75, number 6 (November-December), pp. 102-113.
The Harvard Business Review article reiterates the importance of ethnography informing design but unlike the previous article this one was clearly for the business crowd. While the first reading got me interested in human factors, this second one completely turned me off. Dealing with the bottom line end of the design process is inevitable but I prefer to explore the more humanistic side.
Here ethnography+design is called emphatic design. The article points out that people often don't know what they want and they create workarounds for the failings of technology. In getting used to these workarounds they may not realize other possibilities. It is interesting to note that traditional marketing study methods are great for existing products but fail when a new technology isn't tied to an existing customer paradigm.
Posted by mb2811 at 10:57 PM
Reaction/Notes: Ethnographic Field Methods and Their Relation to Design
This article makes the case that combining ethnographic field methods during the design phase of new technologies allows for more thoughtful and usable products. From personal experience, I have seen time and money constraints cause firms to develop and design new technologies at a conceptual distance from their intended audience. Without end user feedback during the iterative design process, shoddy and poorly designed products emerge.
"Designers should be interested in human behavior in so far as it enables them to design artifacts better suited for the needs of the user." Designers usually have very little information about their intended users and end up imposing their own personal experiences and needs to inform the design process. Designers must also observe to everyone involved with a new technology, not just the population that has the most direct involvement.
The distinction is also made between the top down traditional approaches of market research and the bottom up, user centered approach of ethnography. Traditional marketing evaluation methods such as customer surveys, operability assessments (evaluating prototype usability), focus group and field visits/test make assumptions about the evaluated population and lack flexibility. The ethnographic approach puts an "emphasis on a natives' point of view, holism, and natural settings, provides a unique perspective to bring to bear on understand users' work activities."
Guiding Practices and Field Technologies of Ethnography
The documented suggested practices of ethnography have a loose structure. Different situations require different levels of involvement and different methods of documentation. Primarily, to be an ethnographer evaluating a population's needs is to be respectful and to know how to listen. Evaluations are done in everyday settings, not a laboratory. There is a demand for holism because behavior can only be understood in its context.
"To learn about the world you don't understand you must encounter it firsthand." By observing people firsthand, we can see how people actually behave versus how they think they may behave. An ethnographer takes a nonjudgmental stance and let's things transpire as they are, never coaxing or altering the course of events or the situation (cultural relativism).
Field technique considerations include observation (ideal versus manifest behavior, what people say versus what they do), perspective (observer participant versus participant observer, usually an ethnographer moves along the continuum), focus on observation (what to observe, when to observe, where to observe and when you've observed enough, this is usually when you are no longer surprised), focus levels (person focus, place focus, object focus, event focus), documentation type (notes, video, verbatim transcript versus observation) and interviewing/informal discussion (open ended, allowing the participant to shape the discussion).
There should also be a push to involve those studied in the development of the new technology. The study subjects should, in some way, be exposed to the research data as a sanity check.
Posted by mb2811 at 10:23 PM
January 22, 2006
Assistive Tech
A great mix of people. Designers, people who have a personal stake in improving assitive technology and occupational therapists who have given us a challenge to improve the ghastly contraptions that their clients are forced to use. I'm very excited about this one, it's the class that for me really typifies what ITP is about. It's the class I was telling my friends about when I was applying to a program. "You get to visit different clinics, evaluate people's needs there and build something for them!" With last semester's projects, we weren't getting feedback on our work until the winter show. With this class, we have a target population which we will be consulting as we design and redesign.
The first class was introductions and a short exercise to give us a feeling with what it's like to have a particular disability (cognitive, visual, nervous system, etc.)
Quotes
"Current technology is solving for the general case, 95%, the 5% is what is interesting"
Occupation therapists focus on function. What can't you do?
Posted by mb2811 at 08:46 PM
January 21, 2006
FoundCity
I've been emailing back and forth with John Geraci who runs FoundCity. Last night I ran my idea of 'path sharing' by Matt and we brain stormed about how this thing could work and how it would be implemented. In creating a session over SMS a number of concerns need to be balanced including user overhead. If a user has to declare when a session starts and ends they may be discouraged from using the application. As we worked through what this thing does, we slowly realized that we could play fast and loose with the idea of a session. A session is just any new path and sessions never expire. You can always add to them and then use a web interface to clean them up later. For example, if you are backpacking across europe, it may take you months to finish your path. At the same time, you may want to create daily paths for the individual cities you visit.
I also figured out why FoundCity has distinct email addresses for different cities. I think it's because translating an address to a geocode (lat/long) is a real pain because people enter their city/state combos differently. If you just accept an email address and the email address distinguishes the city, things are much easier. I think that may be too limiting for what I am trying to accomplish.
I had a great time with Matt, i'm really into this idea. We also need to come up with some sort of name for the site.
Here is also something I posted to the ubicommobile wiki:
I played around with FoundCity, an ITP thesis project which leverages geocoding and tagging.
FoundCity allows users to tag 'finds', things they deem of value, in their city and then share these finds with other users. A photo of the find is displayed on a map along with del.icio.us style end user tags of the find.
My interest in FoundCity is as a spring board for a geopsychology project. Mobile use is running parallel to the early days of the web. We started with individual transactions, "give me this web page" and slowly moved into the concept of sessions and batches of transactions that relate to each other over time and by order. For example, "you must login to post a message" involves multiple transactions that need to occur in a certain order.
I want to consider what would it mean to create sessions on a mobile phone using a lowest common denominator platform such as SMS. Foundcity shows me discreet finds related to an individual user and their tags but I am more interested in the path that was created between the finds. Paths must have a start, an order and an end. I'm thinking of building a SMS grammar which will allow users to record and potentially share their paths.
Posted by mb2811 at 11:00 PM
January 20, 2006
First 3D Class
I've been trying to shy away from taking practical skills classes @ ITP (Flash, etc.) because the thinking goes that if I want that I can get a book or take a course at a community college. That's not what ITP is for. The flip side of that argument is that if I could do that, why haven't I already? Part of the school experience is taking the time to figure out all the things I haven't had a chance to figure out on my own. I think this Intro to 3D class falls into that category.
I'm going to try to use this course as a representation skill for a project in another class. 3D rendering is a great when you are trying to get an idea across.
The teacher is good. Fun and geeky. He gave us a challenge to build compelling words, there's so much room for improvement. We're using Maya + VirtTools.
We also talked about sensible technologies which creates haptic 3d interfaces.
Posted by mb2811 at 07:29 PM
January 18, 2006
SMS Session State
An email message I didn't send Dennis because I answered my own question. I think Dodgeball does what I am describing.
---
Hi Dennis--
This is Mike from your ubicomp class. I wanted to bounce an idea off of you, let me know what you think. I want to see what I can do to create a 'session' using SMS. This problem existed with the web. Initially the web was stateless and then people started asking, how do we authenticate people? How can we tell how long they were logged in? From this we got cookies and authentication schemes.
The same problem exists with SMS. Sending an SMS message is a one time transaction. Maybe it's possible to create some semblance of a session with SMS, to create an intuitive, easy to use language that would allow a user to have a session, a start and end point that is longer than one transaction.
Here's an example. Google maps is a one time transaction. You type in an address and it's pinpointed on a map. There are other things you can do once you have zoomed in but that's the main idea.
The Gmaps Pedometer (http://www.gmap-pedometer.com/) is an interactive mapping application. You give it a starting point and click every point along the way. When you're done you have the total milage of your route. The application has a discrete start and end point as indicated by the 'start' and 'end' record buttons.
As a completely hypothetical scenario, what if I wanted to build this application using SMS? You'd walk around the city and check in at different points. You'd have to have some kind of usable, coherent language for the start and end of the session. Start a new session, record a new point, backtrack my session, etc.
What do you think? Do you have an examples of anyone who has successfully pulled of a complicated command grammar using SMS? How complicated is dodgeball? Of all the commands you have, out of the hardcore users, do most people just use a couple of commands?
Posted by mb2811 at 08:41 PM
Introductory Class
A good first ubiquitous class. It's run by Dennis Crowley, the guy from dodgeball but like most everything else at ITP, it's a collaboration. With the technology in question, this class seems more like a collective, keeping up with all of the new developers. If I get into this, it'd be neat to see if there are any local SIG type organizations involved in cell phone applications. The one in Boston I went to was too geeky and not enough forward thinking.
The class is about using available cell phone technologies to build mobile application. The tools and implementation will depend on the audience, the more people one wants to reach the more one has to build things for the lowest common denominator. This limits possibilities and requires a developer to think creatively within a small tool-space. As in building for the web, the most important thing is to know your audience. Building for a corporate intranet with a standard mobile platform gives us a much more extensive tool base than building a viral application where the mobile platform isn't predictable.
As an aside, when building a viral application, wider adoption is more likely when both ends of the spectrum are considered. On one hand, an easy to use application will be more likely to spread but if it has "tech friendly tools" (i.e. downloadable local java thick client on the phone) it is more likely to be evangelized by the tech community.
The other thing to think of is which technology is being used relative to the type of interaction. Single player games (tetris) versus a multi user application (dodgeball or a massive multi player game that uses bluetooth, see mogi).
Quotes / Things
"Build stuff that people can use. Build stuff your friends can use." -Dennis
"Iterative Design. Build early, build often." --Dennis
Providers lock down the location APIs because they want to control the content. It can be done with integrated gps, triangulation or tower signal strength.
"I am interested in connecting people who have with people who need." --Gilad
Acronyms
MVNO - Mobile Virtual Network Operator. Boost is one example. You buy space on a network, possibly Sprint is the only one who sells space. Many small carriers for people with poor credit etc. are MVNOs.
BREW - Proprietary, expensive platform that only verizon uses. The basis for 'get it now'.
Links
ProxyDate - Bluetooth aware dating. Can't find link
All other links are consolidated under a delicious tag.
Ideas
I love the sub alerts project but at the same time cell phones don't work underground. sub alerts has a social component, people can mail everyone else if there was a problem with the train. first responders can fan out data. there might be an accountability issue with this. I would love to work with trains, feet or bikes.
I like the idea of google maps having a bullseye. All the stuff near where you are. What's interesting in the bullseye rings? What content is valuable.
Think of the google pedometer. How can you do an interactive back and forth within a single session as you gradually send more and more data back to the server? The idea of a session. The idea of an audio tour except (as in localprojects) users make their own audio tours. Currently, with these projects, the data is the atomic level and then a 'session' is created with the back and forth with the users. The users are throwing data back and forth creating a session.
Also think about what you have learned in pcomp. Sense/react except think in terms of context. Who, What, When and Where. Contextual Triggers (!!)
Posted by mb2811 at 03:17 AM