Food carts have become a key component of our culinary culture here in PDX. We love that we can get phenomenal food all over town without paying for the overhead associated with brick-and-mortar establishments. It also doesn’t hurt that we can then eat wherever we please—on a park bench, at the office, or, here at Janrain, on the rooftop of the Dekum building, which is a magisterial thing on the 12 or so nice days we have in a calendar year.

There are lots of phenomenal food carts, but Nong’s Khao Man Gai is considered by many to be one of a very small handful of the best PDX food carts if not the absolute, undisputed best.

So what does Nong’s serve that makes it so special? Many would assume that Nong’s serves a broad, continuously shifting array of dishes. I mean, if this place is one of the best of Portland’s over 500 carts, then surely they must have earned this reputation through a diversity of offerings, right? That’s what I would have thought. And this is indeed the approach that the vast majority of food carts take, sometimes offering dozens of menu options.

But Nong’s seems to succeed because it offers you shockingly little choice. In the picture below you’ll see the only thing that you can get at Nong’s (excluding beverages, of course):

But far from alienating their potential clientele, Nong’s thrives in a major way. They continuously win culinary awards of all sorts. They’re frequently featured in publications about Portland’s food culture. And, most tellingly, the lunchtime line is almost always exasperatingly long. And when you do make it through the line and bring your chicken and rice back to the office, your response is almost invariably the following: “That was barely a wait at all. I would have waited an hour or more for the fermented bean curd sauce alone.”

The UNIX Philosophy

So what on Earth does this have to do with UNIX? Well, it’s simple: Nong’s and UNIX have the same core philosophy. There are a variety of formulations of the UNIX philosophy, but I’ll do something super hacky and deprecated and consult the UNIX philosophy Wikipedia page and try to distill the philosophy into a few core tenets:

• Small is beautiful
• Make each program do one thing * and one thing well
• Favor simplicity and portability over feature completeness
• Write programs to work together

The antithesis of the UNIX philosophy in computing consists, then, of the following:

• Big is beautiful
• Make programs do a whole variety of things
• Favor comprehensiveness of function over simplicity
• Write programs to work autonomously

Yes, this is an extremely rough expression of the UNIX philosophy, but I do think that it elucidates some crucial points. According to this worldview, complex processes should almost always be broken up into smaller processes in the name of transparency (e.g. teasing out problems and speeding the application of solutions); it’s always better to have a toolbelt with a lot of small tools with clear purposes than to have a toolbelt with one big tool that does everything; and larger systems should be carefully woven out of these smaller pieces.

The UNIX Philosophy in Action at Nong’s

The UNIX philosophy is typically associated with computing—unsurprisingly—but I see no reason why it can’t be applied to organizational theory. Nong’s makes one thing—chicken and rice—and does it extremely well. In this, it is a spiritual devotee of the UNIX philosophy, even if an inadvertent one. Nong’s menu has no aspirations whatsoever to be comprehensive, and they seem to have no plans to change their menu. It might be fair to say that limited ambition is another core component of the UNIX philosophy.

Going down this path has benefited the organization in a variety of ways:

• Efficiency: when the line gets long—as it very often does—doing one thing and doing it well helps Nong’s with queue efficiency in a drastic and immediately apparent way. No one dilly-dallies figuring out what to order, and the cashier doesn’t have to navigate a sophisticated user interface in taking orders.
• Friendlier learning curve: new personnel are quickly brought up to speed. Instead of learning how to cook 50 dishes, they learn how to make one. Now, Nong’s chicken and rice is deceptively complex, and there’s a lot of careful work that goes into it. Nonetheless, less conceptual overhead means quicker turnaround times for new employees.
• Competitive advantage: whereas other carts always face the possibility that another Thai or Indonesian or Lebanese or Ethiopian or whatever cart is going to cut into their profits, Nong’s absolutely owns chicken and rice. If anyone came along and tried to do exactly what they do, they would be seen as a cheap knock-off.

With all of this going for it, is it any surprise that Nong’s succeeds?

Toward a UNIX-Flavored Federation of Processes?

If the UNIX philosophy can work for Nong’s, it can probably benefit all kinds of organizations and processes. Modularity and learning curves and feature completeness are not just concepts for IT departments. They also have a place in any and all discussion of organizational competency and success more broadly.

I long for the day when all of Portland’s food carts adopt the UNIX philosophy and drastically limit their scope. The result would be fewer total menu options but a far higher quotient of out-of-this-world menu options. The food cart ecosystem would be transformed from an assemblage of redundant menu offerings and reinvented wheels into a thriving federation of lean operations. So next you’re at a food cart, talk with the owner and share this vision. Urge them to consider seeking the Nong’s path.

What do you think, Dear Reader? Should modularity trump completeness? Are limited feature sets usually a good thing? Am I crazy for thinking that the UNIX philosophy has real-world relevance?

Using social login, marketers can instantly gain permission-based access to the profile data they care about – rich demographic data and interests straight from a consumer’s social network profile. This data set not only includes a pre-verified email address, name, location and birth date, but also relationship status, political views, hobbies, favorite books, music, movies and television shows. The key is to create micro-segments of consumers who share similar demographic or psychographic characteristics and use them as the basis for targeting.

By selecting the right tools to store and leverage social profile and consumer data, and taking the time to build intelligent segments, marketers can dramatically improve email marketing ROI.

Some of the email performance results organizations have achieved include:

• Email segmentation based on demographics and interests led to a 244% increase in email open rates, a 161% increase in email click through rates, and a 330% increase in revenue per mailing for online retailer Paper Style

• Email segmentation led to an 80% increase in email open rates

• Personalized eCommerce emails led to a 30% increase in average order value for Shoes.com

We share more real world examples and best practices for utilizing social profile data for email segmentation in our ebook titled From Information to Insights: Understanding Big Data Online, if you are interested in learning more.

Complying with COPPA:  Frequently Asked Questions (A Guide for Business and Parents and Small Entity Compliance Guide) has 92 questions covering all things COPPA.  Of special interest are the questions focused on the requirements of the new COPPA Rule, such as the following:

• What should I do about information I collected from children prior to the effective date that was not considered personal under the original Rule but now is considered personal information under the amended Rule?
• I already have a privacy policy for my children’s app.  Do I have to change it to comply with the amended COPPA Rule?
• I know that the amended Rule made some changes to the direct notice that must be sent to parents before I collect personal information from children.  What are those changes?

A thorough review of the FAQs is recommended for a clearer understanding of the expanded COPPA requirements.

Last night, the Technology Association of Oregon honored some of those companies who are putting Oregon on the map with their technology and mission. It can’t be easy to choose just four to put a spotlight on, because Portland has an abundance of technology companies who have or are on the verge of success.

For all of us at Janrain, just to be in the company with the likes of Iovation, Puppet Labs, FEI, Digimarc, Vendscreen and the other nominees for Technology Company of the Year is such a compliment to all that we’ve achieved. And to be selected as the Rising Star Technology Company of the Year is a huge and humbling honor that reflects the smart, dedicated people who bring their talent and passion everyday to the important work we’re doing on behalf of our customers.

Congratulations to all the nominees, winners and those who devote themselves to this incredible technology community. Thanks to the Technology Association of Oregon for acknowledging the great work we, and the entire community, are doing.

By the way, the Portland tech community would likely edit that common goal mentioned above to read: bring the very best technology to the world, and put Portland, Oregon’s Silicon Forest on the global map as the premier community for starting and growing world-class technology companies.

What you’ll find below is more of a streamlined presentation of a lot of disparate sources (for example here and here) than a 100% new tutorial, but I hope that it serves to put in easily digestible narrative form a lot of the currently existing information. I’ll be putting together an extremely simple product management tool (basically the most barebones and useful Basecamp clone out there). I will do nothing on the UI level and will interact with the server only via cURL. I’ll save views and fancy aesthetics for another day.

Get a Snap Application Up and Going

Since this tutorial also serves as a rudimentary introduction to Snap for the uninitated, I’ll briefly walk through starting a new Snap application. If you’ve installed Haskell, cabal, and Snap, simply create a new project directory (we’ll call our project projectomatic), navigate to the directory, and initiate a new Snap application:

mkdir projectomatic
cd projectomatic
snap init

Once we’ve done that, if we run ll or ls or whatever, we’ll see that a variety of files and directories have been created. I won’t delve too deeply into that here, so I recommend reading up here if you want to learn more about the anatomy of a Snap application. I could have run snap init barebones to begin with a much more stripped-down application, but I’m going to go for a full installation so that we can more quickly get up to speed on using Snaplets.

Setting up Our Application to Use PostgreSQL simple

Snaplets are somewhat difficult to explain, but I’ll try to encapsulate it briefly. Snaplets are sort of a portal to the outside world from within a Snap application. Snaplets enable you to access state—database transactions being a perfect example of that—in a relatively painless fashion. Setting up our application to use PostgreSQL Simple involves using the very handy PostgreSQL Simple Snaplet. First, install that using cabal (cabal install snaplet-postgresql-simple), then add that to your dependencies in your projectomatic.cabal file, run cabal install, then modify your src/Application.hs file like so:

{-# LANGUAGE FlexibleInstances #-}

import Control.Lens
import Snap (get)
import Snap.Snaplet
import Snap.Snaplet.PostgresqlSimple

data App = App
    { _pg :: Snaplet Postgres }

makeLenses ''App

instance HasPostgres (Handler b App) where
    getPostgresState = with pg get

With the normal snap init install, your application is set up to use a few other Snaplets out of the box. Feel free to leave those in. I will remove them for the sake of brevity in this tutorial. What you see above is that I’ve embedded our Postgres Snaplet within our App data type and then used the makeLenses ''App function to generate an accessor pg that we can use elsewhere. Lastly, I’ll define the instance HasPostgres (Handler b App), which will enable the application to have access to Postgres-related state.

Now that we have our handy pg accessor, we need to go over to our src/Site.hs file and do some additional setup. First, add the PostgreSQL Snaplet to the imports:

import Snap.Snaplet.PostgresqlSimple

Now, we need to add our pg constructor to the core of the application. Let’s modify the definition of the app function to include our Postgres Snaplet:

app :: SnapletInit App App
app = makeSnaplet "app" "My stunningly advanced Snap application." Nothing $ do
    pg <- nestSnaplet "pg" pg pgsInit
    addRoutes routes
    return $ App pg

We’re almost ready. All we have to do now is configure our Postgres connection. When we ran cabal install after adding the snaplet-postgresql-simple module to our dependencies, Snap created a snaplets/postgresql-simple directory on its own (wasn’t that sweet?). In that directory, there’s a file called devel.cfg where we specify our database connection. Here’s what mine will look like (yours will vary, of course!):

host = "localhost"
port = 5432
user = "luc"
pass = ""
db = "projectomatic"

There are other configuration possibilities, but this will be enough to get me up and going. Once this is done, try running cabal install and see if you get any compiler errors. If so, see if you can debug on your own. If not, then let’s move on to the next section.

Our Project Data Type

Haskell is a real stickler for data types, so we now have to start being both explicit and careful about everything we do. Let’s define our Project data type in our src/Site.hs file. We could do it in a separate file if we wanted to, but let’s keep it simple. I’ll be using the Text data type here—as use of strings is widely considered to be deprecated in Haskell)—so I’ll make sure and add Data.Text to my imports:

import qualified Data.Text as T

We’ll keep our data type simple:

data Project = Project
  { title       :: T.Text
  , description :: T.Text
  }

Setting up Postgres to Handle Our Data

Postgres is a traditional columnar database (though with a of sugar on top), so we can’t simply start throwing a bunch of key/value pairs at it and expect it to start storing things. We’ll need to create tables that are ready to do our bidding. Oh, and our database. We should make one of those, too. Let’s start with that. In a *nix environment, chances are strong that you can create a new database from the command line (presuming that you have Postgres installed):

createdb projectomatic

If that doesn’t work, either consult one of many Postgres installation tutorials or cut to the chase and download Postgres.app for real ease of use. If that did work, then let’s write a projectomatic.sql file and place it in our main project directory. Here’s what it will need to look like:

CREATE TABLE projects (
  title TEXT NOT NULL,
  description TEXT NOT NULL,
);

Each project will simply have an integer identifier, a title, a description, and a set of users involved with the project. For sake of simplicity, we’ll set things up so that each user will simply have a username and a set of projects that they’re associated with, and none of the values we’re working with can be NULL.

Let’s open up our database using psql projectomatic in the command line and run our SQL script when we get there:

\i /path/to/application/dir/projectomatic.sql

If we get CREATE TABLE as a response, then we’re probably good to go. It’s a good idea to double check by running \dt and making sure that projects and users tables currently exist and are properly constructed. Once they do, we should be good to go within Postgres itself.

Making Our Data Types Ready for Postgres

Like I said before, dealing with data types in Haskell is tough. While I would never assert that dealing with data types in any programming language is “easy” per se, Haskell really does present a pretty formidable learning curve. Fortunately, it’s not too bad if you’re doing fairly basic things.

Previously, we specified our Project data type, but that’s not yet enough to get them to actually interact with Postgres. Putting data into Postgres would likely work fine at this stage, but taking data out of Postgres and transforming it into something that Haskell can use within the application is going to take some work.

So in our Site.hs file, we need to set up a FromRow instance of both of our main data type. This will require the Control.Applicative module as well as a special submodule of PostgreSQL Simple, namely FromRow. Here’s what needs to be added to our Site.hs file:

import Control.Applicative
import Database.PostgreSQL.Simple.FromRow

instance FromRow Project where
    fromRow = Project <$> field <*> field

The funny <$> and <*> operators come from the Control.Applicative module. The most important thing is that the number of fields that you use when constructing the instances matches the number of fields in the database, or else you’ll get all kinds of nasty compiler errors, just as you will if there’s a type mismatch (as when you try, for example, to put a Haskell integer into a Postgres field that takes only a varchar or text).

Setting up these FromRow instance constructors enables us to take data from Postgres (for example the results of a SELECT * FROM projects-style query) and use it in our pure, pristine Haskell application. One thing we should also do is to define a Show instance for our data type. This is necessary because when we make an HTTP request to see a Project (or a list thereof), we want to specify what that will actually look like in the command line. If we don’t specify a Show instance, that means that we won’t actually see anything, even if we’ve done everything else right. I’ll keep it basic:

instance Show Project where
    show (Project title description) =
      "Project { title: " ++ T.unpack title ++ ", description: " ++ T.unpack description ++ " }\n"

Note that we need to use the T.unpack function, taken from the Data.Text module, to convert text into strings (else we get a compiler error).

Time to Get Back to Our Application

So that was a lot of setup, no doubt about it. Now it’s time to actually convert HTTP requests into PostgreSQL queries and consequently data. I’m going to set up our server to take requests that do the following things:

1. Create a new project
2. Return a list of all projects
3. Delete a project

Basically, we’re running simple CRUD operations on the Project data type.

Let’s start with creating a new project. First, our route:

("/project/new", method POST createNewProject)

Here’s our corresponding function:

createNewProject :: Handler App App ()
createNewProject = do
  title <- getPostParam "title"
  description <- getPostParam "description"
  newProject <- execute "INSERT INTO projects VALUES (?, ?)" (title, description)
  redirect "/"

Let’s unpack this a bit. First, notice that this is embedded in a do block, which often (though certainly not always) means that you’ll be dealing with I/O. The first thing that this function does is extract the title of our new project out of the form data passed to the server with the getPostParam function (the same goes for our description). Now, we’ll use the execute function to actually interact with Postgres. In contrast to the query_ function that we will encounter later, execute is typically used in situations where you don’t expect a return value (as when you write to a table).

The dual ?s that you see are places in our SQL bytestring where we will insert values. Immediately after the bytestring, we specify which values we want inserted (in this case the title and the description that we derived from the URL).

Now, let’s work on using the query_ function instead of execute. This is a bit trickier because it involves getting data back from Postgres that then needs to be processed and handled on the application side (whereas with the execute function we passed already-formed data on to Postgres). We’ll start with setting up a route that displays all projects. The route:

("/projects", method GET getAllProjects)

And the handling function:

getAllProjects :: Handler App App ()
getAllProjects = do
  allProjects <- query_ "SELECT * FROM projects"
  liftIO $ print (allProjects :: [Project])

A few things to notice here. First, we store the results of the query in the allProjects variable. That’s pretty straightforward. What’s more difficult, however, is actually displaying those projects. First, have a look at the print function. What is being printed? The allProjects variable is going to be printed as a list of projects. But we can’t just use print on its own because print produces IO (which is always tricky in Haskell).

This is where the liftIO function comes in handy. This function gives us access to the I/O in which the application is engaging, and in our case it will convert the type IO () into the type Handler App App (). And so print is producing IO which is then brought into the application context. Because we haven’t set up any views or anything fancy for displaying the data, the print function will make the results of our GET request show up in the console.

So now we can create a project and get all projects. Let’s add a route and a function for deleting specific projects. First, let’s set up a route to delete a project based on the project’s title:

("/project", method DELETE deleteProjectByTitle)

In a serious project, you would probably want to delete on the basis of an integer project ID or something of the sort, but we’ll keep it simple. Now, our corresponding function:

deleteProjectByTitle :: Handler App App ()
deleteProjectByTitle = do
  title <- getPostParam "title"
  deleteProject <- execute "DELETE FROM projects WHERE title = ?" (Only title)
  redirect "/"

Notice here that we’re only passing one value into our SQL bytestring, hence our reliance on the Only instance. Also notice that we’re not passing the project title via URL, but rather by way of form data.

So now we have some routes that interact with Postgres and do some really basic things. Let’s put our server to the test.

cURLing Our Way to Victory

As mentioned before, I’ve said nothing about views or HTML rendering or any of the sort. At the moment, our application has zero views. I’ll cover Snap’s default templating system, Heist in a future tutorial. For now, though, we’ll interact with our server the old-fashioned way: via cURL (my favorite tutorial can be found here).

Let’s go through a set of examples involving each of the routes that I set up earlier. First, let’s fire up our server.

cabal install
projectomatic -p 3000

Now, let’s get a list of all of our projects:

curl -X GET http://localhost:3000/projects

At first, this should return an empty list (no surprises there). So let’s create a project. Let’s create a project called “Getting in shape” and give it the description “Daily exercise:”

curl -X POST http://localhost:3000/project/new \
-d 'title=Getting in shape' \
-d 'description=Daily exercise'

Now, when we run a GET request on /projects again, we should get the following in the CLI:

[Project { title: Getting in shape, description: Daily exercise}
]

This means that our server works. *whew*

Now, let’s delete the project that we just added to the database. Remember from above that the URL takes the form /project, while our title is passed in via form data. Our cURL request should look like this:

curl -X DELETE http://localhost:3000/project \
-d 'title=Getting in shape'

If we have more than one project in the database with the title “Get in shape,” then all projects with this title will be deleted. This is yet another reason why working with integer IDs for important data types is much better than working in terms of attributes like this. In a future tutorial, I’ll do a deeper dive into Snap and Postgres that does precisely this.

Just a Basic Intro

Like I said before, this application has no views or rendering, no error handling, no authentication. It’s just an HTTP server talking to Postgres. I’ve also only covered a minimal smattering of what the PostgreSQL Simple Snaplet has on offer. But I hope that it has at least served to show that using Postgres and Haskell in a web development context is not as intimidating as it may seem at first. There are some conceptual leaps (at least for a previously OOP-oriented person like myself), but patience pays off.

Earlier this month I had the pleasure of meeting Krysten Jenci, the Director of Electronic Commerce for the International Trade Administration (ITA) and head of the U.S. Department of Commerce’s Safe Harbor Frameworks team, and Christopher Hoff, one of the two Administrators on that team. As part of the ITA’s effort to promote a better understanding of the role the Safe Harbor Frameworks play in facilitating commerce between the U.S. and Europe, Krysten and Chris came to Portland, OR to meet with privacy professionals and counsel (including fellow IAPP and ACC members) to discuss the continuing viability of the U.S.-EU Safe Harbor Framework and initiatives in furtherance of the White House Privacy Blueprint. While they were preaching to the choir with regard to the continuing importance of the US-EU Safe Harbor Framework, some points made during the discussion bear repeating:

• Under existing law, the data protection authorities of the European Economic Area (EU member states, Liechtenstein, Iceland, and Norway) are obligated to accept that Safe Harbor-certified U.S. service providers are as “adequate” as EU-based service providers in providing data security for processing personal data transferred from the EU. Moreover, the U.S.-EU Safe Harbor applies to cloud service providers as well. This shouldn’t be news, but to counter questions raised by the non-binding July 2012 Article 29 Data Protection Working Party Opinion on Cloud Computing and related statements made by certain EU officials, the ITA recently published clarifications on this subject to set the record straight.

• In a service agreement between a data controller and U.S. Safe Harbor-certified processor, it is not necessary to include the EU standard contractual clauses to assure the data security of personal data from the EU, because certifying adherence to the Safe Harbor principles provides adequate assurance of data protection. If you once negotiated with a European counterpart who insisted otherwise, you know that creating the proper understanding in this regard can be an uphill climb.

• Even after the proposed EU General Data Protection Regulation (Proposed Regulation) is finalized, the U.S.-EU Safe Harbor Framework may continue to be recognized as affording adequate assurance of personal data protection, because the Proposed Regulation grandfathers in such recognition. Although one proposed amendment to the Regulation (often referred to as the Albrecht amendment) would have the recognition sunset two years after the Proposed Regulation takes effect, passage of this amendment is not assured and even if it were enacted, the sunset provision would take effect no earlier than 2016. 

Finally, even where there is a clear understanding among a company’s privacy and legal teams on the value of the US-EU Safe Harbor Framework and its role in facilitating commerce between the U.S. and Europe, this understanding may not be shared with the company’s engineers tasked with planning how to transfer and process data from several countries most efficiently. Engineers lacking knowledge of the benefits of Safe Harbor could mistakenly conclude that EU law requires keeping EU data hosted within the EU, even when it would be more efficient or otherwise desirable from a business perspective to centralize hosting in the U.S. with a Safe Harbor-certified services provider.

So, here’s a call for spreading the good word on the continuing viability of Safe Harbor and clearing up any misunderstandings that may be muddying the waters for your engineering teams and others involved in planning international data exchanges. They will thank you for it.

What are you up to? That’s a trending question these days. Most people are probably thinking that question when they visit your website. You probably want to collect profile data so you can offer them relevant emails, content, and/or product recommendations. But do they know that?

Unfortunately people are (very) skeptical and their trust is not easily won. Now, thanks to the advancing caliber of hackers in various basements and even high schools, the battle for trust becomes harder each time another high-profile brand has their database compromised.

Yet, just like my fiancé loves her flowers, people who visit your site love personalization and recommendations made just for them. Amazon is a poster child for using tailored content to win shoppers’ hearts, so how do you get users to trust you to do the same?

Tell Them What You’re Up To

You just need to simply answer the question: What are you up to? Tell your site visitors why you’re collecting their data, how it’s going to benefit them, and what kind of control they have. Being informed increases comfort and trust.

Channel 4, one of the largest UK television broadcasters, went as far as to create a viewer promise, landing page and video for this very purpose (see below). The spirited and brutally honest talk show host Frank Carr walks users through everything from why Channel 4 collects personal data to the benefits of drawing in advertisers. The video makes the consumer the center of Ch4’s universe and eliminates any questions about how the user’s data is being used. This ambitious level of transparency catches the users’ attention, helps them see the benefits of registering, and eases their nerves.

Seldom do I visit a site that effectively calls out registration or the advantages of creating an account with a brand. Don’t keep the benefits of registration and data a secret from your users. You should be advertising the awesome and relevant experiences that providing a little profile data could provide.

So what are you up to?

How cool is that?

We’re thrilled to be honored with membership into Gartner’s “cool social technology” club (our words, not theirs) along with 140 Proof, Influitive, Woobox and Zuberance. The report’s focus is around the opportunity that exists for digital marketers in leveraging the social web to reach their online goals, and goes on to recommend these cool vendors for organizations to call upon.

Our motivation at Janrain isn’t necessarily to “be cool” but we think it’s pretty darn awesome to work with brands we all like, know and buy from such as Universal Music Group, Fox, Dr Pepper, Samsung, AMC, Guitar Center and Pac12. In our book, it’s our customers that we find pretty cool because they understand exactly what Gartner analyst Julie Hopkins means when she writes:

Janrain simplifies the process of managing multiple online identities to remove the “digital hassle” often associated with the user’s broad social participation.

In other words: our customers know that password fatigue is a real problem and leverage our social login technology to remove the obstacles that stand in the way of allowing their website visitors to quickly log in to their site.

So, while we’re humbled to be called a “cool vendor” and thank Gartner for the recognition, we really want to thank our customers who make us who we are by choosing Janrain in the first place and relying on us to earn their trust everyday.

On the heels of my recent SXSW panel moderated by Jeremiah Owyang with Chris Saad at Echo, we wanted to continue the dialog in a deeper way around the vision for a more real time, connected future.

This white paper reviews the evolution of social media experiences, and builds a model of how these experiences will continue to evolve as the tools for social media experiences become better understood and more widely available.

We also discuss how the role of social is shifting to become more integrated into the overall marketing strategy, accelerating growth of all marketing initiatives.

What do you think the future of social will be? Let me know in the comments.

Segmented content feeds

While the news feed will remain the default setting on the Facebook home page, users will now be able to toggle between viewing two additional distinct feeds – one featuring updates from friends, and a second exclusively featuring updates from brands liked by the user. Because consumers still use Facebook primarily to interact with friends, and the average Facebook user has 262 friends as opposed to liking about 80 brand pages, Facebook users may increasingly self-select into the content feed featuring updates from friends as opposed to brands.

How will this impact social media marketers? It could yield a decrease in impressions for posts from liked brand pages. If we assume that impressions within the friends feed will trump impressions within the feed for followed brands due to our natural predisposition to favor content from friends, then brands will need to find new ways to penetrate the news feed and disseminate their content. Social sharing, which empowers online consumers to share comments, articles, purchases, products and other content from websites directly to their social network, is the golden ticket.

Increased emphasis on visual posts

Facebook is tweaking its news feed algorithm to place greater emphasis on posts and status updates that include rich media. We shouldn’t be surprised by this change. After all, our eyes organically gravitate toward images and videos within the news feed, and these types of posts tend to generate the highest click-through rates.

This change dovetails with a recent assertion that Facebook’s EdgeRank algorithm provides up to 1,300 percent more weight to shares than likes in terms of placement within the news feed. This is good news for marketers seeking to encourage the use of social sharing on their own websites, due to the fact that content published to Facebook via an effective sharing technology solution dynamically incorporates a thumbnail image from the page, in addition to populating the page’s meta title and description into the shared post.

You’ve probably heard us say it before, but as networks such as Facebook, Twitter and LinkedIn become so entrenched in our culture, social feeds are evolving into a powerful recommendation engine for new content, ideas and products. In short, our friends are helping us navigate the web. The latest evolution in Facebook’s news feed will reward digital marketers who grasp this paradigm shift and empower consumers to advocate on their behalf.

What do you think of Facebook’s news feed changes? How do you plan to evolve your social sharing and Facebook strategies as a result of the changes? I’d love to hear your take in the comments below.