Customer Commons – OMIE
Session Topic: Customer Commons OMIE
Convener: Doc Searls
Notes-taker(s): Marion, Lionel
Doc Searls presented the OMIE, a project of Customer Commons, a non profit organization committed to empowering the individual consumer in the marketplace. OMIE is a device--an Android-powered mini-tablet with touch screen--that allows a consumer to engage with apps at the beginning of the demand chain vs. end at the supply chain.
The purpose of the session was to engage participants around apps that we collectively would like to design/see on the OMIE product within this context.
The "r-button" expresses the relationships.
This is the loop:
Demand Chain >
Better Sign-in >
Big Individuals ......
As background, Doc shared the original array of apps that Ian Hamilton suggested when he originally conceived of the OMIE product.
Suggested apps included:
- My wallet- amazon has an AB
- My credit card bill- Mint gets credit card info. Best Buy wish list.
- My guardian
- My fitness (Qs/fitness/health: de-siloed data/athletic/elderly/caregivers)
- My month (timeline)
- My shopping list (comparison engine)
- My loyalty card
- Photo verification- scanability
Ideas also referenced from Australia: my pocketbook
Doc captured jobs for Customer Commons:
- feedback to API developers
- when is it to the customers' advantage?
- pooling the developer forum
- provide help with selling this
- payments- getting the money- $ has to come from the device owner/cloud owner; need capacity.
- Kickstarter around My Wallet app. Show benefit to retailer. Customers pay money-- its a measurable benefit.
Discussion: _________ Data more reliable from scraping than from APIs- thanks Kevin Coxe who offered case study from edentity involving government and data scraping.
Business of access, low-risk approach to businesses could work
Paying for data is ok
Clive Boulton: highly recommended API lecture, search AL3X: https://www.youtube.com/watch?feature=player_embedded&v=VVovVjT_H8A#!
The Interaction Design of APIs: (April 17, 2009) Alex Payne explores the interaction design of APIs, particularly through the lens of the speaker's experience evolving the popular Twitter API. The speaker argues for the notion of a "humane" API", one derived from simplicity, "explorability" and consistency.
We must humanize our conversation in this space.
- Not CPU, Memory, Network
- Yes: CPU = Heart; Memory = diary; Network = ??
Calendar would be a great application.
Reverse loyalty card: An intention card. Scenario: you are at a retailer, and you need "petite" clothing. They do not have any. You announce your intention, that you wish to be notified. The implementation was discussed: the customer can show the OMIE to the retailer and the retailer scans it. Objection--retailer computer systems and integrations are too expensive. It can work the other way: OMIE can scan something at the retailer, then we can implement it in the OMIE backend.
- Most APIs are not made for humans like most reservoirs not made for humans, but faucets are. - Doc Searls