Trusted Cloud Initiative Kicks Off — Novell and the year-old non-profit Cloud Security Alliance (CSA) have announced a vendor-neutral Trusted Cloud Initiative to develop a consensus-based identity management reference model and third-party certification criteria for cloud providers. They say a trusted standard should alleviate the concerns about security, governance and control of their data and IT assets that organizations considering adopting cloud-based computing may have. It was Novell’s idea and Novell has identity management interests. The certification criteria, seal and roadmap will be defined by CSA members, which represent a cross-section of stakeholders, end-user organizations, cloud service, SaaS and technology providers and include Novell, of course, Microsoft, Dell, Rackspace, Qualys, HP, Intel, Cisco, McAfee, ISACA, DMTF and Symantec, as well as individual representatives from Global 2000 organizations and the world’s governments.

Reading Ian’s post is good for all of us, whether we are going to SXSW or not. Now I’ve got to go unpack all of my shorts and cowboy boots

Some of the best advice just landed in my in-box a few minutes ago from AdAge which I thought was not only good for SxSW – but for businesses using social in general – “10 Ways to Not Be a Jerk at SXSW“. One of the recommendations:

“Don’t post every Foursquare/Gowalla/Hotpotato check-in/update to Facebook and/or Twitter. Normally, it’s marginally useful. But no one not at SXSW cares if you’re in Conference Room 9ABCD, Ballroom D or Exhibit Hall 1. Use the app to follow people and see where they’re at. Don’t give your family, friends, and co-workers another reason to digitally silence you. That “which Jonas Brother are you” quiz you just sent all of them on Facebook is reason enough.”

Great advice not only for the conference – but for those venturing out into the social world with their business or organization. It follows the principle “Forget “marketing to” — “interacting with” is the new black. We are moving from a ‘marketing to’ (or clubbing consumers over the head senselessly in 30-second intervals) approach, to a conversational, ‘interacting with’ approach. In the old days, you might win over consumers based on the strength of your marketing message. But, this is no longer the case. Traditional marketing isn’t going away—no advertising outlet has disappeared, from AM radio to TV. However, consumers are now wanting and expecting to participate in the conversation.

When I get into an – umhh..discussion… with my dad about Social Marketing – he is always starts out by asking “Why would I want to tweet about walking up the stairs? Who cares?”. My response is always the same – “You woudn’t, and No One”. Perhaps he should ask “Why would I want to engage in a conversation with someone?” Now that would be a good start.

Authentic reviews from previous guests played a major factor in our location choice, leaving the resort’s websites to almost an afterthought. We wanted to see pictures of real rooms with real families taken with real cameras, not glossy, photoshopped versions with models and fisheye lenses to make the room appear bigger than it was.

Throughout the trip, the resort did a great job of measuring customer satisfaction. In our one week there, we were given no less then three short surveys about different aspects of the resort. And they appeared to be listening. After answering ‘not that we can recall’ to ‘Did the chef come out to talk with you during dinner?’, the chef was very visible every night thereafter. Coincidence, maybe? But the resort seemed very interested in making sure we got the right experience.

But is asking those questions enough these days?

This reminded me of another recent trip to Punta Cana. At the conclusion of that trip, we  went around to say our goodbyes and thank yous to the helpful staff. One woman, in her best english, thanked us, and started writing down a web address. She proceeded to hand us a piece of paper and asked us to post our comments online, since that is how her management company reviews her. What URL did she write: www.TripAdivsor.com.

On almost every receipt these days is a request to answer an online survey about your experience. Imagine if instead they asked you to post publicly about your experience?

Sound on the web is often something that gets ignored or added as an afterthought. These songs are a great example of how well-done music can be more than just background music. They actually became a key part of the campaign. Parry created songs that embodied the 60’s feel for the campaign. They were funny, well produced and darn catchy too. Truly something that you wouldn’t mind sticking on your MP3 player. And kid friendly:

On the one hand, there are the very significant usability issues that must be addressed, but there are various approaches to that.

And while there is some speculation that increasing regulation of the credit card industry, or economizing by consumers hit hard in this recession, will drive people to adopt more micropayment schemes, I think the issues are somewhat more subtle than that.

And I don’t think credit card companies need to worry.

Until Facebook buys a bank.

Micropayments have a long history of falling flat (the earliest I remember was “Virtual Coin”, and I think that was back in 1995.) If you do a Google search for “Wired future of money”, there are maybe a dozen articles stretching back close to 20 years. So there have been a lot of attempts, and they run into all the same issues.

Essentially, the problem is this: it takes money to move money.

Granted, that’s not because the technology is expensive, or that costs scale up with volume: moving $1 between two banks costs about the same as moving $1 billion. The “problem” is that there are so many intermediaries who want a cut, albeit small ones.

Any micropayment scheme needs to deal effectively with three challenges:

1. It needs to be low friction (friction defined as the difficulty of moving money from one place to another)
2. It needs to be ubiquitous (everyone needs to accept it)
3. It needs to handle fraud effectively

Friction

There are basically two types of friction in payment systems: ease of use, and transfer costs. Rendering payment (me giving you money) needs to be as simple as possible. That’s a usability problem, and not very difficult to solve (you need to follow some standard conventions for handling sign-in/authentication, communicating the value of what you are purchasing, and communicating the end of the transaction (the receipt.)

Transfer costs are more difficult: Visa/Mastercard want 3% of every transaction, plus a base fee – and it’s this base fee that kills every micropayment platform. If V/MC wants $0.25 per transaction, you’re not going to do any transactions valued at less than a few dollars. And true micropayments would be dealing in transactions of less than a penny (i.e., 1/10th of a cent to read an article on the WSJ. 1 cent to print it, etc.)

Bank interchange fees come into play there too (that’s the fee one bank charges another to send money electronically.) Again, these fees are small, but significant to a sub-$1 transaction.

As soon as you try to move lots of small transactions between two banking institutions, you’re dead in the water. The embedded costs are too high (and the players have no incentive to make them lower. Remember: the cost is not a function of the transaction size, but transaction volume, and the banks prefer it that way.)

So if moving small amounts money between banks is too expensive, what do you do? You try to create your own ecosystem.

Ubiquity

What do PayPal, EZPass and SecondLife all have in common?

They are all semi-closed payment ecosystems.

Each one works basically the same way: you deposit “real” money from a “real” bank into a payment account with the vendor, and you’re given credits. Sometimes these credits are called “dollars”,  and sometimes they are called “Lindens.” But they all have the same basic characteristic: they can be exchanged readily, and at a near-zero transaction cost, between any two members of the ecosystem.

Moving money from one account to another at any of these “banks” is simply a matter of making a ledger entry. It’s instantaneous, and involves no other outside intermediary. The intermediary only comes back into play when you try to move money out of the ecosystem, back into the banking system. Notice that PayPal doesn’t charge the payer to fund a transaction from a credit card or bank account, but *does* charge the recipient. PayPal bakes these “external” costs into their internal system transactions, because this opens up their ecosystem to be used by non-members. I don’t need to have a PayPal account to pay someone with PayPal.

Sadly, however, baking in this external cost makes micropayments impossible. PayPal’s micropayments fee is 1.9% +$0.05. If I sell a digital good for $0.10, my profit margin (assuming 0 production costs) is only 30%. In the world of digital goods, that’s shameful.

However, once an ecosystem is ubiquitous enough (oh, say, 500 million to 1 billion users), the ratio of internal-only transactions way outstrips I/O transations (with users outside the ecosystem), and the ecosystem manager can afford to remove the external processing charges from these internal transactions.

Why does this matter? Because no one buys eggs from their bank. Eventually you want your money *out* of the ecosystem, so that you can go use it somewhere that the ecosystem doesn’t reach. (And forget the argument about “just putting it on a PayPal debit card”, and going grocery shopping. That debit card lives in Visa/Mastercard’s ecosystem, not PayPal’s.)

So, let’s assume that you’ve got a billion users in your system, and they’re all charging up spending accounts with external funds (for which the funding institutions – the banks – charge a small fee, which you decide to eat), and exchanging Credits with each other in 1/10th of a penny increments. And you take 1.5% of each transaction as your fee (that’s 1/2 what any other merchant card processor charges, and you don’t even charge a per-transaction flat fee, so hardly anyone notices), and so on every transaction you’re making  of a penny. Chump change, right?

1 Billion Users * 100 transactions/day * $0.001/transaction * 1.5% =  $548 million/year in fees.

Yeah, I think that might be worth exploring. And that’s assuming that these users spend an average of $0.10/day online within this ecosystem.

OK, you’ve got $100,000,000/day sloshing around in your ecosystem, which your users have deposited with you, what’s the problem? They are not going to let you hold on to their “real” money for free, so you have to pay interest on those deposits.

And now you are a bank. And that brings with it a host of complications, but it also gets you direct access to the global banking system, which is important if you want to do things like enable cross-border transactions, EFT transfers to other banks, etc. And there’s lower costs to doing those things, which you pass on to your users.

Fraud

I won’t go into it here in too much detail, except to state this: Visa/Mastercard exist for a host of reasons, and one of the big ones is fraud detection and reduction. Recently I read that about  7 cents of every $100 in credit card transactions is fraudulent, which in the above example means that about $25MM/year is fraudulent. And consider, Visa/Mastercard’s stats are from an ecosystem where many transactions are done face-to-face, with signature verification, mailing addresses, etc. In the above example ecosystem, there’s much less in the way of identity verification, so the risk for fraud is higher.

It’s far from clear whether or not there exist any emerging micropayment ecosystems which will meet these challenges. But I think Facebook at least stands a chance of getting there, because it has three things:

• Low friction: paying another user in Facebook can be a single button click, or even a wall post: “Ben pays 1 credit to Patrick”
• High ubiquity: 300MM users and growing, many internationally.
• Good leg up on fraud detection: Facebook knows an awful lot more about your identity than even Visa/Mastercard, and given good pattern matching can probably figure out quickly if you’re setting up a profile as a front.

Like most software platforms, Harvest offers a public (RESTful) API that tinkerers can tap into at will.  This allows for the independent creation of client-side widgets of all shapes and sizes, and generally aids the longevity of the service-driven app.  This Harvest client will essentially be ‘Harvest on steroids’, because I will be adding some additional functionality that I find lacking with the web component…functionality you can only really get with a rich app that can be broken out of the browser and run in the background like a good little daemon.

To do this, I decided that AIR will be the platform of choice for a few compelling reasons:

1. I wanted to learn the platform, including the ins and outs of AS3 and FlashBuilder (still in Beta, but will eventually replace FlexBuilder)
2. I like AIR’s portability across platforms
3. I didnt want to write this in Java

I’ve spent the better part of the last two years developing for the iPhone.  For those out there that don’t know, native iPhone apps are generally written in Objective-C (Cocoa), which is kind of a hybrid of ANSI-C and SmallTalk.  For most developers in the ‘traditional’ world of OOP (C-family of languages), Cocoa can be confusing at first.  The very concepts we were taught in our Comp Sci classes are altered slightly with Cocoa.  It is probably analogous to a Spaniard hearing Portuguese for the first time.  Everything looks familiar…but it’s different.  That’s Cocoa.

Of all the things Cocoa offers, I think the NSNotificationCenter (from the Foundation framework) is definitely one of the best.  It saves developers the frustration of writing low-level event handlers for everything that needs to use them.  In Cocoa, the NSNotificationCenter lives as a Singleton (sharedNotificationCenter), although you could spawn another one if you really need it.

I guess the biggest convenience that NSNotificationCenter provides in Cocoa development is the global messaging registry.  Using it allows you to essentially create informal contracts between various objects in your code.  These contracts are completely arbitrary as they are defined by you, the developer.

In my brief experience with Actionscript 3, Ive had to do a lot of things that call for asynchronous operations, both for performance as well as user experience.  Traditionally in AS3, you would create a subclass of EventDispatcher to handle such events.  To the EventDispatcher, you can add event listeners like so:

1
2
3
4
5
6
7
8
9
10

function mousedOver(event:MouseEvent):void {
 //  do something to indicate the mouseover event
}
 
function mousedOut(myevent:MouseEvent):void {
 // do something to indicate the mouse out event
}
 
myDispatcher.addEventListener(MouseEvent.MOUSE_OVER, mousedOver);
myDispatcher.addEventListener(MouseEvent.MOUSE_OUT, mousedOut);

This is all well and good.  For a quick and dirty script, this is probably the optimal solution.  However, there are some limitations to this implementation.  First of all, the myDispatcher object must be able to handle MouseEvent events.  This enforces a tight coupling of the events to be captured and the objects that need to handle them.  Again, for smaller applications, this is generally fine.  For larger applications, the effort to manage these event dispatches grows quickly.

In Cocoa, UI-level objects have a similar mechanism for event handling by declaring and binding selectors, either programmatically or by creating IBOutlets in Interface Builder.  Another event handling strategy in Cocoa is the use of Key-Value Observing (KVO), which instructs an object to spy on a property of another object.  Then there’s the NSNotificationCenter.

In layman’s terms, the NSNotificationCenter acts as a switchboard.  A listener object tells the switchboard ‘hey, I would like you to tell me when you intercept the message XYZ‘.  A variation of this message that’s important here is ‘hey, I would like you to tell me when you intercept the message XYZ, but only when object A is the sender‘.  Unlike AS3’s EventDispatcher, the listener object does not need to be ‘hardwired’ to listen for a specific event type.  In AS3 event handling, an object that doesn’t know how to handle MouseEvent events wont do anything if they receive them. What’s more, even if the listener object could intercept MouseEvent events, it has no say who the sender could be.  The runtime in AIR/Flash dictates when messages are received.  A NotificationCenter grants the developer that cherished 30,000-foot view of the state of at least one aspect of their code.  If adopted globally, the NotificationCenter will be the only object receiving and delegating messages.  The receiver doesn’t necessarily need to know who the sender was.

Luckily, AS3 provides some key objects and functionality that make the implementation of a true NotificationCenter very straightforward.  The first object is the good ol’ Dictionary.  The Dictionary, again in layman’s terms, is a means to make objects point to other objects.  These objects can be anything in AS3, including functions.  This is one of Actionscript’s major strengths, in my opinion.  The other AS3 goodie that makes a NotificationCenter possible is the ability to treat functions as objects.  Languages that do not do this tend to require the developer to perform some code gymnastics using reflection – a costly mess in even the most robust implementations.  The last piece that makes the NotificationCenter possible is the rest operator (…).  This allows for the passing around of arbitrary data.

And now to the implementation

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

package com.archergroup.util
{
    import flash.utils.Dictionary;
 
    public class NotificationCenter
    {
        private static var _weakKeys:Boolean = true;
        private static var _instance:NotificationCenter = null;
        private static var _oneandonly:Boolean = true;
 
        private var _objectObservers:Dictionary = null;
        private var _eventObservers:Dictionary = null;
 
 /**
 * Constructor
 * Blows up if not called by the public static method
 */
    public function NotificationCenter()
    {
        if (_oneandonly) {
            throw new Error("The NotificationCenter must be called as a Singleton.  Use getInstance() instead.");
        } else {
            _objectObservers = new Dictionary(_weakKeys);
            _eventObservers = new Dictionary(_weakKeys);
        }
    }
 
 /**
 * Singleton creation and fetch method
 */
    public static function getInstance():NotificationCenter
    {
        if (null == _instance) {
            _oneandonly = false;
            _instance = new NotificationCenter();
            _oneandonly = true;
        }
 
        return _instance;
    }

This is just the setup and enforcement of the Singleton pattern. AS3 doesn’t allow private constructors, so a little sleight-of-hand is necessary.  I am creating two internal Dictionaries – one for general notifications where the listener registers to receive the event no matter who sends it, and one messages specific to the notifier.

41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100

/**
 * Registers an object as an observer for an event.  If the notifier param is not set, the observer will listen for
 * all notifications of event.  If the notifier is set, the observer will only listen for event from the notifier
 *
 * @param String event            The notification to be observed
 * @param Object observer        The object listening for event
 * @param Function callback        The function invoked by the observer when the notification fires
 * @param Object notifier        The specific object that is being observed for event <OPTIONAL>
 */
public function addObserverForEvent(event:String, observer:Object, callback:Function, notifier:Object = null):void
{
    if (!notifier) {
        if (!_eventObservers[event]) {
            _eventObservers[event] = new Dictionary(_weakKeys);
        }
 
        var _eObserverDict:Dictionary = _eventObservers[event] as Dictionary;
        _eObserverDict[observer] = callback;
    } else {
        if (!_objectObservers[notifier]) {
            _objectObservers[notifier] = new Dictionary(_weakKeys);
        }
        var _oObserverDict:Dictionary = _objectObservers[notifier] as Dictionary;
        if (!_oObserverDict[event]) {
            _oObserverDict[event] = new Dictionary(_weakKeys);
        }
        var _oEventObserverDict:Dictionary = _oObserverDict[event] as Dictionary;
        _oEventObserverDict[observer] = callback;
    }
}
 
 /**
 * Removes an object as an observer for an event.  If the notifier param is set, this will only remove
 * the object as an observer for event fired by the notifier
 *
 * @param String event            The notification to be ignored
 * @param Object observer        The object that will be ignoring the event
 * @param Object notifier        The specific object that is being ignored for event <OPTIONAL>
 */
public function removeObserverForEvent(event:String, observer:Object, notifier:Object = null):void
{
    if (!notifier) {
        if (_eventObservers[event]) {
            var _eObserverDict:Dictionary = _eventObservers[event] as Dictionary;
            if (_eObserverDict[observer]) {
                delete _eObserverDict[observer];
            }
        }
    } else {
        if (_objectObservers[notifier]) {
            var _oObserverDict:Dictionary = _objectObservers[notifier] as Dictionary;
            if (_oObserverDict[event]) {
                var _oEventObserverDict:Dictionary = _oObserverDict[event] as Dictionary;
                if (_oEventObserverDict[observer]) {
                    delete _oEventObserverDict[observer];
                }
            }
        }
    }
}

The above snippet contains the methods that enable you to tell the NotificationCenter to start (or stop) listening for messages.  In both cases, I’m doing a simple test for nullness before I go ahead and add or remove the relationship.  In the case of the _objectObservers Dictionary, the notifiers become the reference keys, whereas the event names are the reference keys in _eventObservers.  Each key in _objectObservers contains 1..n Dictionaries, one for each event being observed for this specific key.  Those dictionaries in turn use the observer as the key and the callback function as the key’s value.

101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132

/**
  * Broadcasts a notification to all listeners.  A notifier is required, but any object
  * generically registered as an observer for event will also be notified.  The observers
  * that are explicitly listening for event from the notifier will be notified FIRST.
  *
  * @param String event			The notification being broadcast
  * @param Object notifier		The object doing the broadcasting
  * @param Array args			Any additional parameters used for the broadcast
  */
public function postNotificationName(event:String, notifier:Object, ... args):void
{
	//	notify object observers first
	if (_objectObservers[notifier]) {
		var _oObserverDict:Dictionary = _objectObservers[notifier] as Dictionary;
		if (_oObserverDict[event]) {
			var _oEventObserverDict:Dictionary = _oObserverDict[event] as Dictionary;
			for (var o_observer:Object in _oEventObserverDict) {
				var callback:Function = _oEventObserverDict[o_observer] as Function;
				callback.apply(o_observer, args);
			}
		}
	}
 
	//	notify event observers next
	if (_eventObservers[event]) {
		var _eObserverDict:Dictionary = _eventObservers[event] as Dictionary;
		for (var ev_observer:Object in _eObserverDict) {
			var callback:Function = _eObserverDict[ev_observer] as Function;
			callback.apply(ev_observer, args);
		}
	}
}

The notifications are sent with optional arguments (the rest operator) from the caller.  By default, I am notifying object observers before anyone else, but this is arbitrary.  If the notifier is a key in _objectObservers, and the event is a key in the subsequent sub-Dictionary, then call all functions stored within.  If you have the _weak_keys static variable set to false, you will avoid any null pointer exceptions.  This is an advantage over the NSNotificationCenter in Cocoa, where you must remove objects from the notification queue when you deallocate them.

And now a brief usage example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

public function whoami(... args):void
{
        var notifier:NotificationCenter = NotificationCenter.getInstance();
        notifier.addObserverForEvent(HarvestAPI.SERVICE_RESPONSE_AUTHENTICATE, this, _handleServiceAuthenticate);
	var tts:TimeTrackerService = new TimeTrackerService(this);
	tts.whoAmI(args);
}
 
//    ...
private function _handleServiceAuthenticate(... args):void
{
	var notifier:NotificationCenter = NotificationCenter.getInstance();
	notifier.removeObserverForEvent(HarvestAPI.SERVICE_RESPONSE_AUTHENTICATE, this);
 
	//	the variable args should consist of at most one element, an instance of User
	var arr:Array = args as Array;
	if (null != arr && arr.length > 0) {
		var user:User = arr[0] as User;
		var prefs:Userprefs = Userprefs.getInstance();
		prefs.saveWithUser(user);
	}
 
	//	the user has properly authenticated.
	notifier.postNotificationName(HarvestAPI.CONTROLLER_AUTHENTICATION_OK, this, args);
}

This is an actual excerpt from the Harvest app. I am basically calling an authentication service in the Harvest API. On line 4 above, I tell the NotificationCenter to start listening for HarvestAPI.SERVICE_RESPONSE_AUTHENTICATE from anyone who broadcasts it, and then handle the notification with _handleServiceAuthenticate. Since this is a network call, everything must obviously be asynchronous. You’ll notice that in _handleServiceAuthenticate, an object is expected. If there is an incoming object, it will always be nested in an Array.  This particular code then triggers another notification to a controller in an MVC hierarchy.

I’ve been coding against this NotificationCenter for a little while now, and I am really starting to appreciate it.  I’m beginning to really enjoy Actionscript 3.  The language has definitely grown up.

Many organizations today are now trying to evaluate their social marketing results by asking themselves “How can we determine the value of our social marketing efforts through analytics?” With social being so relatively new – there’s not a true industry standard to help in their analysis – but there are a few approaches which they should consider.

When conducting an analysis, or even when calculating ROI, rather than concentrating on how certain metrics from traditional marketing don’t work with social, consider instead rethinking ROI from the ground up. Take into consideration the qualitative and quantitative benefits and the impact to other areas of the organization. If done, organizations begin to see that ROI for social marketing isn’t just a theoretical exercise, like trying to develop cold fusion. There are real across-the-board benefits to be found.

Utpal M. Dholakia and Emily Durham recently conducted a study on local bakery and cafe chain in Texas adding social to their mix in advertising. They concluded that customers spent the same amount of money per visit, increased their number of visits, and generated “more positive word of mouth than nonfans”, “reported significantly greater emotional attachment”, would choose the coffee shop over their competitors “whenever possible” (see “One Cafe’ Chain’s Facebook Experiment”, the Harvard Business Review, March 2010).

A review of the quantitative analytics, consider the measurable analysis: number of Fans, number of mentions, increase in traffic to specified, time of brand exposure, increase in sales, or other measures that the organization tracks on a regular basis.  When reviewing the qualitative analytics, consider the more emotional elements – such as number of positive or negative mentions, brand awareness and brand feeling, referrals from fans (which are always more emotionally beneficial to the brand), emotional attachment, or other not-so-quantifiable measures which have just as much a quantifiable impact on the brand.

Here are a couple resources (that have their own links) to review when conducting your analysis and determining your measure and approach for ROI and analysis:

- Video on Social Media ROI

- Mashable – How to measure ROI

- Olivier Blanchard Basics Of Social Media Roi

People all want to be something, and as a brand you’ve got to give them the opportunity to be who they want to be.

1.  Be the Comedian

We all may not be as funny as Larry David (or even Larry the Cable Guy), but that doesn’t mean a part of us doesn’t want to be the one on stage making people laugh. Create opportunities for people to be funny via cool content, and they’ll be compelled send that message out to others.

2.  Be the Philanthropist

People may be motivated by self-interest, but that doesn’t mean they’re selfish. Altruism is a powerful motivator, as evidenced by the number of people using Facebook to show their support for the issues they care about. If your brand takes part in a cause, it’s a great way to start up conversations with people who care about the same things.

3.  Be the Expert.

Everyone likes being recognized as an expert on something, whether it’s knowing all about Edward Cullen’s vampire family in Twilight, or being history savvy enough to know which portly U.S. head of state once got stuck in a bathtub. A quiz is a great way for a brand tap into that desire to appear smart, and give people a chance to show off their brains.

4.  Be the Maven

Malcolm Gladwell talks about mavens in his book The Tipping Point, those trendsetters and early adopters who just have to be on the cutting edge of a social trend. These mavens like to share with others their latest purchase or music on their iPod. If you can create a motivation with a subliminal message of ‘be the first to share this with others’,  Mavens will take the bait and spread the word.

5.  Be Recognized

‘Norm’ from the SitCom Cheers recieved a warm ‘Norm!’ from the bar every time he entered. This recognition is appealing to all of us and is why we return to places where ‘everyone knows our name’. The same is true in the social marketing world. If you show your consumers you know them, they will want to return and participate further. Foursquare and GoWalla provide the platform to perform this type of recognition.

Check it out. This actually got me excited for the iPad:
http://tinyurl.com/yhxmup6