September 02 2008 Conference Call

Topic: Relbutton working meeting

Attendees

Agree to meet for a couple hours (Tuesday?) at Digital ID world to whiteboard Relbutton states and behavior as the beginnings of a relbutton spec
Keith to create a functional spec stub
Sean, Dean, Chris and other marketing folk to update us on efforts surrounding clarification and messaging around relbutton and VRM, ala the "Tim Berners Lee description of the web circa 1990" - potentially to include a VRM video or comics ala Common Craft to help explain the power of enabling the customer side of vendor-customer relationships
- Examples: here, here, and here

Good stuff going on with Phil Windley - a related relbutton CRM/VRM effort making progress
Important but difficult attribute of relbutton is that it must be something that the user controls; they can assert/control/have autonomy over; not to be confused with data ownership
Some reasons for a functional spec
- Determine if Relationship cards be used to implement the relbutton
- Determine what might we build and what areas should we leave alone
- Determine what are the complexities and how might we smooth them out
Public radio app should not "lay tracks in the snow"
Functional spec to contain:
- universal characteristics / attributes (requirements)
- states that relbutton can be in
- descriptions of standard behavior (this happens then this happens)
- user/vendor expectations as to what the relbutton can and should do
- affordances
- use cases
IPR - how do we deal with it w/ functional spec without holding us back? Be explicit about ownership up front if possible