Relbutton Scenarios: Difference between revisions

From Project VRM
Jump to navigation Jump to search
 
(29 intermediate revisions by 7 users not shown)
Line 1: Line 1:
"Relbutton" is a placeholder name for what we've been calling a "buy button" or a "[[PayChoice]]" button. The "rel" stands for relationship.
'''Note: the action has moved from this page to the [[r-button]] page.'''


The button combines reciprocal symbols for customer and vendor, and is used by either to express an interest in doing business, or the existence of a relationship that relies on independence and choice on both sides.
"Relbutton" is a name for what we've also been calling a "buy button" or a "[[PayChoice]]" button. The "rel" stands for relationship.


Customers can use it as a "pay button" to express a willingness to pay for goods that are otherwise free (such as podcasts, blogs, pieces of music or public radio stations or programs). Vendors can use it to express an interest in doing business on terms that embrace actual relationship -- including terms that are provided by the customer as well as the vendor. With it, VRM meets CRM, and each can engage and improve relations with other.
[[Image:Icon4.gif]]


As a simple symbolic representation of willingness and commitment, by both sides, it provides a visual front for back ends of capabilities and record-keeping (as well as transaction ability) that can help improve markets by making customers independent and informative contributors, and not just sources of cash and data for marketing mills.
The button combines reciprocal symbols for customer and vendor, each represented by red "magnets" facing each other.


We need code. We also have faith that much of the necessary code is already laying around. Conversations are already taking place in the [http://identitycommons.org Identity community]. The scenarios we develop here will help us decide what goes where and how it works together.
It can be used either by a customer to express an interest in doing business with a vendor, or by either or both sides to reveal the existence of a relationship. When that is the case, the two "magnets" appear joined. (Other configurations are reviewed below.)
 
Customers can use it as a "pay button" to express a willingness to buy goods that are otherwise free (such as podcasts, blogs, pieces of music or public radio stations or programs). Vendors can use it to express an interest in doing business on terms that embrace actual relationship -- including terms that are provided by the customer as well as the vendor. With it, VRM meets CRM, and each can engage and improve relations with other.
 
As a simple symbolic representation of willingness and commitment by both sides, the relbutton provides a visual door to back ends of capabilities and record-keeping (as well as transaction ability) that can help improve markets by making customers independent and informative contributors, and not just sources of cash and data for marketing mills.


== Basic Characteristics ==
== Basic Characteristics ==
* The Relbutton represents a free and open web service, available to both vendors and consumers, providing capabilities to both  
* The Relbutton represents a free and open web service, available to both vendors and customers, providing capabilities to both  
* The button can be placed by the customer on anything they might be willing to pay for -- or with which they might be interested in a relationship.  
* The button can be placed by the customer on anything he or she might be willing to pay for -- or to indicate an interest in conversation or relationship.  
* The button can also be displayed by the site as an signal that a displayed item (or service, or whatever) is open to either being paid for, or a relationship, or both.
* The button can also be displayed by the site as an signal that a displayed item (or service, or whatever) is open to either being paid for, or a relationship, or both.
* A web service API allows vendors (i.e. producers, owners, distributors, etc.) to attach Relbutton features to their site, project, products, or content
* A web service API allows vendors (i.e. producers, owners, distributors, etc.) to attach Relbutton features to their site, project, products, or content
Line 51: Line 55:
That data can be anything pertaining to relationship, history, intentionality, preference... it's wide open.
That data can be anything pertaining to relationship, history, intentionality, preference... it's wide open.


As they say in the advertising business, it has legs. Lots of them.
In practical and simple terms, when the customer clicks on the button, it says "hey you" to the vendor. If the vendor responds, the customer's "it's me" data repository and choice matrix comes into play. The databases on both sides might also be called "hey you" and "it's me".
 
As they say in the advertising business, this has legs. Lots of them.


By the way, the symbols are red for no reason other than visibility. They could be another color, or other colors. They could also be a color that changes depending on conditions outlined below.)
By the way, the symbols are red for no reason other than visibility. They could be another color, or other colors. They could also be a color that changes depending on conditions outlined below.)


== Naming and Lexicon ==
Britt Blaser produced this graphical explanation of the relbutton:
"Relbutton" is a placeholder. Other possibilities, with rationales:


* "LetsTalk" button. It aligns with "markets are conversations", is easy for ordinary folks to understand, is friendly, and recognizes that human communications is an encompassing value that needs to be served. Recommended by a successful businesswoman with a long history on both the buying and selling side of retailing.
[[Image:Relbutton.gif]]
* "[[PayChoice]]" button. Because it's already been in use as a placeholder itself. (Follow the link.)
 
* "YouYou" button. Because the symbol resembles a pair of U's.
Note that there are many possibilities here, and the ones shown on this page are the initial few.


== Requirements ==
== Requirements ==
Line 73: Line 78:
* Both parties should be able to cease relationships, on mutually agreeable terms.
* Both parties should be able to cease relationships, on mutually agreeable terms.
* For identity-based interactions, it should obey the [[http://www.identityblog.com/?p=352 Seven Laws of Identity]]
* For identity-based interactions, it should obey the [[http://www.identityblog.com/?p=352 Seven Laws of Identity]]
* A link to the [http://cyber.law.harvard.edu/projectvrm/Relbutton_Functional_Specification RelButton Functional Specification (Spec)]


== Scenarios ==
== Best Fits ==
How might the relbutton be used and deployed? What are some typical examples of how vendors and users might use such a thing?  
The relbutton model will likely be ideal for certain products, vendors, and verticals - perhaps with traditional companies that are seeking mechanisms to better relate to their customers, or in a market where customers are lacking the trust and control they demand. What are the characteristics for these best fits?


=== Best Fit? ===
Alternatively, some new online environments and markets that were created specifically to disrupt artificial boundaries between vendor and consumer, such as ebay, threadless.com or even wikipedia may avoid such distinctions entirely.  
The relbutton model will likely be ideal for certain products, vendors, and verticals - for example, with traditional companies that are seeking mechanisms to better relate to their customers, or in a market where consumers are lacking the trust and control they demand. What are the characteristics for these best fits?


Alternatively, some new environments that were created specifically to disrupt artificial boundaries between vendor and consumer, such as ebay, threadless.com or even wikipedia generally avoid such distinctions entirely.  
"Relate" will also mean something quite different in different markets or areas. These differences need to be respected.


"Relate" will also mean something quite different in different markets or areas.
[http://hengkyongko.com/keunggulan-top-1-oli-sintetik-mobil-motor-indonesia/ TOP 1 Oli Sintetik Mobil-Motor Indonesia]
[http://hengkyongko.com/bejubel-market-place-terbaik-indonesia/ Bejubel Market Place Terbaik Indonesia]
[http://hengkyongko.com/pulauweb-web-hosting-murah-indonesia/ Pulauweb Web Hosting Murah Indonesia]
[http://hengkyongko.com/voucher-hotel-murah-di-rajakamar-com/ Voucher Hotel Murah di RajaKamar.Com]
[http://hengkyongko.com/adira-asuransi-kendaraan-terbaik-indonesia/ Adira Asuransi Kendaraan Terbaik Indonesia]
 
==Scenarios==
 
===Media in general===


The first use case for the relbutton is media. These include
The first use case for the relbutton is media. These include
Line 94: Line 107:
Since the VRM community already includes participants from public media, and since we have been in conversation with public media folks about VRM for more than a year, that would be the best place to start prototyping and scenario-planning relbutton usage.
Since the VRM community already includes participants from public media, and since we have been in conversation with public media folks about VRM for more than a year, that would be the best place to start prototyping and scenario-planning relbutton usage.


=== Hey-You / It's Me ===
Subsequent use cases include
 
* commercial radio
* commercial television
* music
* all other forms of digital content
 
===The MID Radio===
 
An MID is a Mobile Internet Device. These include all handheld units that are capable of using the Internet via wi-fi or the cellular telephone networks. Examples range from the [http://en.wikipedia.org/wiki/Nokia_N810 Nokia N810] to the [http://apple.com/iphone iPhone] to open phones designed via [http://trolltech.com Trolltech/Nokia/] [http://code.google.com/android/ Google/Android], [http://openmoko.com OpenMoko] or any of the other emerging (and mostly Linux-based) devices and their development platforms.
 
([http://www.intel.com/products/mid/ Intel especially] is driving development in this category.
 
In the long run, radio will overcome its current fixed-transmitter and limited spectrum limits (which have been with us since AM/MW/SW radio was established in the 1920s, and FM was established in the 1940s) -- by moving to streaming via wi-fi and mobile phone systems.
 
We can make that run much shorter by building stream tuners for MIDs.
 
Their directories can be populated informally by users cutting and pasting from stream URLs on websites, or more formally by interactive web services.
 
They can be designed to receive streams only at bandwidths permitted by existing connection limitations, moving from one data rate stream to another as conditions permit.
 
They can have UIs that are either directory schema based or that allow users to fan through choices in the manner of Apple's "coverflow".
 
The relbutton should be a standard feature of these radio tuners to begin with. If you design a stream tuner (or, for that matter, a podcast player that allows users to interact by producing as well as consuming data), it needs to support relbuttons and relbutton-based interactions.
 
Where relbutton interactions are not supported, the user should still be able to accumulate data about the source of the stream or the podcast, and escrow that data for future use. (Perhaps, among other things, by advertising the fact that the user is interested in relating to the source, even though the source does not yet support the relbutton. This will allow demand to be heard, even if supply is not yet ready.)
 
Here are some graphical mock-ups of how the relbutton might be used with an iPhone stream or podcast "tuner":


When the customer clicks on the button, it says "hey you" to the vendor. If the vendor responds, the customer's "It's me" data repository comes into play. The databases on both sides might also be called "hey you" and "it's me".
[[Image:Iphonebrowsing 1.jpg|800px]]


[[image:Iphonerelationshipflow 1.jpg|800px]]


=== Downloading a Public Radio Podcast (consumer) ===
Note: The relbutton is now the [[r-button]] (making it parallel to [http://www.equalsdrummond.name/?p=135 the r-card]). Conversation and development continue on the page at that last link.


* An "ideal" user in this scenario is not an existing radio listener, but rather enjoys public media primarily through the downloading and listening of audio podcasts. They likely discovered a program through iTunes or other online media aggregator. Their relationship first and foremost in this context is with the program itself, it's content, creators, and recorded participants. They are blissfully unaware of any affiliated station (or even what a station is) and only vaguely understand affiliation with the network (e.g. NPR, PRI, APM, etc.).
== Call Notes ==
* The user interacts with the podcast in a variety of ways - for example, in a list on the program's website, on a 3rd-party "taste-maker" site, through an RSS subscription in their reader, on their mobile device or phone during playback, or even perhaps as part of a user-created mashup of multiple program bits
[http://cyber.law.harvard.edu/projectvrm/August_19_2008_Conference_Call Relbutton Call notes, August 19, 2008]
* Each platform and mode has the ability to provide some mechanism to allow the consumer to know that there is an opportunity to "relate" to the media, for example, there might be a relbutton next to a download link or on the screen of their iPhone
* (It is likely here that the vendor will initiate a CTA that compels the user to click on the relbutton)
* By clicking on the relbutton, a variety of choices to relate are presented to the consumer. They might include
** Learn more - particularly in regards to privacy and transparency around this relationship (how vendor will use your participation, data, money, etc.)
** Show your support - give a thumbs up. Have that approval possibly disclosed in a variety of ways (e.g. a public signed petition of support)
** Provide general feedback, suggestion or vendor request (text, media, etc.)
** Provide a response to something in particular, such as a vendor request for help (e.g. who should be our guest next week?)
** Provide generalizable information about yourself, such as email address, zip code, download history, other likes/dislikes, or demographic info (what mechanisms could the vendor and consumer use to signal usage of this info, e.g. "I am giving you my email so that you can alert me when and where to find your next podcast")
*** Personal consumer information will generally be already stored and controlled by the consumer; they can choose what to release
*** Vendor might make a request for additional new info (e.g. format and delivery preferences), if elected to provide, the data will become associated with your PDS for future relationships
** Donate money (what mechanisms could the vendor and consumer use to signal usage of this info, what should they be permitted to do, and how are these conditions monitored and regulated e.g. "I am giving you $10 only if you are able to raise $1000 from other donors," "I am giving you $10 towards future production only," etc.)

Latest revision as of 12:01, 26 September 2011

Note: the action has moved from this page to the r-button page.

"Relbutton" is a name for what we've also been calling a "buy button" or a "PayChoice" button. The "rel" stands for relationship.

Icon4.gif

The button combines reciprocal symbols for customer and vendor, each represented by red "magnets" facing each other.

It can be used either by a customer to express an interest in doing business with a vendor, or by either or both sides to reveal the existence of a relationship. When that is the case, the two "magnets" appear joined. (Other configurations are reviewed below.)

Customers can use it as a "pay button" to express a willingness to buy goods that are otherwise free (such as podcasts, blogs, pieces of music or public radio stations or programs). Vendors can use it to express an interest in doing business on terms that embrace actual relationship -- including terms that are provided by the customer as well as the vendor. With it, VRM meets CRM, and each can engage and improve relations with other.

As a simple symbolic representation of willingness and commitment by both sides, the relbutton provides a visual door to back ends of capabilities and record-keeping (as well as transaction ability) that can help improve markets by making customers independent and informative contributors, and not just sources of cash and data for marketing mills.

Basic Characteristics

  • The Relbutton represents a free and open web service, available to both vendors and customers, providing capabilities to both
  • The button can be placed by the customer on anything he or she might be willing to pay for -- or to indicate an interest in conversation or relationship.
  • The button can also be displayed by the site as an signal that a displayed item (or service, or whatever) is open to either being paid for, or a relationship, or both.
  • A web service API allows vendors (i.e. producers, owners, distributors, etc.) to attach Relbutton features to their site, project, products, or content
  • A web service API allows consumers (i.e. users, customer, etc.) to attach Relbutton features to external vendors' site, project, products, or content
  • The relbutton can also be the real as well as symbolic place where VRM and CRM meet.
  • As with Creative Commons licences and symbols, the relbutton and its functions should be readable three ways: by humans, by machines and by lawyers.

Visuals

The relbutton is a set of two images resembling two facing magnets, open toward each other. The shapes symbolize openness, choice, independence, equality and intentionality. They can appear in four ways, each expressing a different message. These are:

1. Open to relating:

Relbutton sm.jpg

2. Relating already:

Relbutton sm closed.jpg

3. Looking to buy something:

Relbutton sm left.jpg

4. Looking to sell something:

Relbutton sm right.jpg

What makes these especially helpful and handy is that they give both sides all the virtues listed above. So, for example, when a vendor puts this symbol on a product or a site...

Relbutton sm right.jpg

... they're saying "We're willing to do business with you on your terms as well as ours."

And, when the customer clicks on a closed button...

Relbutton sm closed.jpg

... data from both sides can be brought in and displayed.

That data can be anything pertaining to relationship, history, intentionality, preference... it's wide open.

In practical and simple terms, when the customer clicks on the button, it says "hey you" to the vendor. If the vendor responds, the customer's "it's me" data repository and choice matrix comes into play. The databases on both sides might also be called "hey you" and "it's me".

As they say in the advertising business, this has legs. Lots of them.

By the way, the symbols are red for no reason other than visibility. They could be another color, or other colors. They could also be a color that changes depending on conditions outlined below.)

Britt Blaser produced this graphical explanation of the relbutton:

Relbutton.gif

Note that there are many possibilities here, and the ones shown on this page are the initial few.

Requirements

Before we proceed, here is what the relbutton should and should not do:

  • All but symbol 4 (vendor side only) should be under the customer's control.
  • It should support true two-way relationships between customers and vendors in all three market domains: transaction, conversation and relationship.
  • Unlike advertising and promotion, it will be a way that the customer makes the first move. It must support the intentions of the customer first, and the vendor second.
  • It should support the ability of the customer to pay whatever they please. Also for the vendor not to accept the payment. For this reason, it should allow the buyer to escrow (or record) the intention to pay, so the vendor can see that if they wish, or accept payment once the vendor puts the acceptance mechanisms in place. This should be visible exclusively to those vendors, even if they do not yet have the mechanisms in place for perceiving them, or for accepting payment. This system will allow vendors payment-acceptance and CRM systems to adapt to standard means by which customers, at their discretion, can transact, converse with and relate with vendors.
  • It should not provide means by which vendors coerce or entrap customers. Once relationships are established, they can be whatever customers and vendors agree upon. But as a means for "hooking up", or accepting payment, relbuttons cannot be under exclusive vendor control. For example, if a relbutton on a music site brings up a list of fixed prices for selections and albums, the customer should still have the choice of offering amounts they please, rather than just the prices offered by the vendor. This doesn't mean the vendor has to accept what the customer offers. It does mean that the customer has the means for offering what they like, including amounts higher than the vendor is asking.
  • It should support the expression of preferences. This includes conditions for relationship, such as selective disclosure of personal data, conditions for the use of personal data, interest in specific (and defined) future products, and interaction requirements. Among the latter might be, for example, the preference not to receive promotional messages when calling for tech support.
  • It should support customers and vendors both retaining records of interactions in the course of relationship, including transaction histories, contact histories and other variables. Among many other thints, these should be able to back each other up at times when the other party loses data.
  • Both parties should be able to cease relationships, on mutually agreeable terms.
  • For identity-based interactions, it should obey the [Seven Laws of Identity]
  • A link to the RelButton Functional Specification (Spec)

Best Fits

The relbutton model will likely be ideal for certain products, vendors, and verticals - perhaps with traditional companies that are seeking mechanisms to better relate to their customers, or in a market where customers are lacking the trust and control they demand. What are the characteristics for these best fits?

Alternatively, some new online environments and markets that were created specifically to disrupt artificial boundaries between vendor and consumer, such as ebay, threadless.com or even wikipedia may avoid such distinctions entirely.

"Relate" will also mean something quite different in different markets or areas. These differences need to be respected.

TOP 1 Oli Sintetik Mobil-Motor Indonesia Bejubel Market Place Terbaik Indonesia Pulauweb Web Hosting Murah Indonesia Voucher Hotel Murah di RajaKamar.Com Adira Asuransi Kendaraan Terbaik Indonesia

Scenarios

Media in general

The first use case for the relbutton is media. These include

  • public media, including stations and programs
  • citizen and participatory media, including otherwise free online publications
  • podcasts
  • online publications, including blogs
  • pieces of music, or artists

Since the VRM community already includes participants from public media, and since we have been in conversation with public media folks about VRM for more than a year, that would be the best place to start prototyping and scenario-planning relbutton usage.

Subsequent use cases include

  • commercial radio
  • commercial television
  • music
  • all other forms of digital content

The MID Radio

An MID is a Mobile Internet Device. These include all handheld units that are capable of using the Internet via wi-fi or the cellular telephone networks. Examples range from the Nokia N810 to the iPhone to open phones designed via Trolltech/Nokia/ Google/Android, OpenMoko or any of the other emerging (and mostly Linux-based) devices and their development platforms.

(Intel especially is driving development in this category.

In the long run, radio will overcome its current fixed-transmitter and limited spectrum limits (which have been with us since AM/MW/SW radio was established in the 1920s, and FM was established in the 1940s) -- by moving to streaming via wi-fi and mobile phone systems.

We can make that run much shorter by building stream tuners for MIDs.

Their directories can be populated informally by users cutting and pasting from stream URLs on websites, or more formally by interactive web services.

They can be designed to receive streams only at bandwidths permitted by existing connection limitations, moving from one data rate stream to another as conditions permit.

They can have UIs that are either directory schema based or that allow users to fan through choices in the manner of Apple's "coverflow".

The relbutton should be a standard feature of these radio tuners to begin with. If you design a stream tuner (or, for that matter, a podcast player that allows users to interact by producing as well as consuming data), it needs to support relbuttons and relbutton-based interactions.

Where relbutton interactions are not supported, the user should still be able to accumulate data about the source of the stream or the podcast, and escrow that data for future use. (Perhaps, among other things, by advertising the fact that the user is interested in relating to the source, even though the source does not yet support the relbutton. This will allow demand to be heard, even if supply is not yet ready.)

Here are some graphical mock-ups of how the relbutton might be used with an iPhone stream or podcast "tuner":

Iphonebrowsing 1.jpg

Iphonerelationshipflow 1.jpg

Note: The relbutton is now the r-button (making it parallel to the r-card). Conversation and development continue on the page at that last link.

Call Notes

Relbutton Call notes, August 19, 2008