Some numbers out today from comScore suggesting that Google+ users are spending just 3 minutes per month using the service have grabbed a lot of attention, mostly because of the direct comparison being made to how much time users spend on Facebook (6-7 hours per month). No word on how many hours people are spending on Lamebook.
Unfortunately, these numbers sound about right. Fellow entrepreneurs who were initially psyched about G+ seem to have turned much cooler about the service, and we think it may be because of our own bewilderment that businesses were banned from creating Google+ profiles when G+ launched.
To use a wonderfully succinct comparison of social media, startups sell donuts:
Source: douglaswray on Instagram
Google made a strategic error in actively prohibiting businesses from creating Google+ pages last summer when the service launched. (To quote a Google manager, “we are discouraging businesses from using regular profiles to connect with Google+ users. Our policy team will actively work with profile owners to shut down non-user profile.” In other words: get lost.)
So, what lies ahead? Not necessarily doom and gloom, if Google sticks with its long-term strategy as described by Bradley Horowitz in the Wall Street Journal today:
Google+ acts as an auxiliary to Google services — such as Gmail and YouTube — by adding a “personal” social-networking layer on top of them.
This comment is consistent with what we have heard from the Google rank-and-file as well in recent months; to quote one local Googler: “Now that we have built Google+, we need to rebuild Google around Google+.”
As of now, the WSJ article has approximately 1,000 Facebook “likes”; 337 G+s; and 3,210 Tweets. Go figure.
Smartmoney.com, the personal finance website that is owned by Dow Jones (i.e. by Rupert Murdoch’s News Corp.) offers a singular example of how one can design a website so that chrome, fluff and advertising overwhelms the content.
Here are some screenshots from a single page of a SmartMoney article today: we needed 6 screenshots to show you the page because it is around 3,900 pixels in height.
Screen captures of a single Smartmoney.com page
One might assume that a page that long would be filled with content, but in fact, it is filled with advertising, page design elements (also known as “chrome”), links to various News Corp services and other pages (i.e. “fluff”), and even just blank screen space.
To get a better idea of just how much crap there is on this screen, consider this color coding of the page, with purple denoting advertising, yellow denoting chrome or other fluff, and white indicating blank screen space:
The same Smartmoney.com page, color-coded to show what it contains
You can see at a glance just how little of the page is actually devoted to the article. In fact, by counting pixels we figured that just 15% of the page is devoted to the article:
What's on this single Smartmoney.com page
This is not entirely accidental, of course: Smartmoney.com relies upon advertising, so it will try to stretch out an article over multiple pages so that it can show you more advertising as you plow through page after page.
(This particular article has been stretched over 6 separate Smartmoney.com pages, each of which contains the same pitiful 15%, or even less, of pixels devoted to actual content.)
Yet, even if advertising is the laudable goal here, one simply can’t overlook the bad page design: the largest component of this page (54%) is either page decoration or other fluff – a desperate attempt to get people to stay on the site. And considering that more than half of the crap is “below the fold”, why would Smartmoney.com even expect users to wade through it?
“We really look at the service delivery with the case. Was there anything we can learn about what happened? It’s not necessary to see what went wrong, but how were services delivered. Is there something we can learn?” said Sharon Gilbert, deputy director for field operations at Children’s Administration, which is part of DSHS.
No, let’s not.
Let’s not view the horrific murder of two children as a SLA problem with a contracted vendor. Too much blood has been spilled to take such a bloodless view of “lessons learned” about “service deliveries”.
Most browsers allow third-party cookies, by default. And, most of the time, these cookies are used by advertising networks to track users as they move across different websites.
Some folks take the trouble of disabling third-party cookies, which can be done using your browser’s “Preferences” settings: the actual mechanism varies based upon which browser you are using.
If you do turn off third-party cookies, you may find that images that you upload to your Kerika pages do not appear correctly. That’s because all files that you upload to your Kerika pages are stored in your own Google account, so when you are viewing a Kerika project page, some of that content is coming from your Google Docs account.
Recently, Google has started storing images in a new domain, called googleusercontent.com. This domain is used for a variety of purposes, including cached copies of websites visited by the Google search engine, but the general purpose of this domain appears to be to store static content: i.e. content that is not expected to change.
So, if you have turned off third-party cookies in your browser, you may find that images are not shown when you visit your Kerika page. And, the whole process may be something of a mystery to you, although our latest version includes a new warning message when we detect that this problem might exist.
It’s easiest to spot this problem if you are using the Google Chrome browser because that shows you, at the far right end of the address bar, that there is a potential problem with cookies on the page you are currently viewing. Here’s an example:
Cookie warning from Google Chrome
The address bar shows a broken cookie image, and when you click on that cookie image you get a dialog box that tells your page is having problems with cookies. When you see this, click on the “Show cookies and other site data…” button
Click on this button
And this will then show you details of the cookies that are being allowed, and the ones that are being blocked:
Blocked cookies
You need to allow cookies from googleusercontent.com in order for your images to show up correctly on your Kerika pages.
Unblocking individual cookies
However, the problem with googleusercontent.com may not end here: when you enable cookies from somewhere.googleusercontent.com, you are only permitting cookies from that particular sub-domain! In the example above, we are allowing cookies from doc-0k-0c-docs.googleusercontent.com.
Allowing cookies from somewhere.googleusercontent.com doesn’t mean that you have also allowed cookies from somewhere-else.googleusercontent.com: in other words, allowing cookies from one sub-domain of googleusercontent.com doesn’t automatically mean you are allowing cookies from all other sub-domains of googleusercontent.com.
And this can cause repeated problems when you are using Kerika, because when you upload images to your Kerika page, Google may place these on entirely different sub-domains of googleusercontent.com. We have no control over which sub-domain Google chooses at any point, so you could have one page show images correctly – after you have permitted cookies from that sub-domain – and another sub-domain get blocked when you navigate to another Kerika page, even a page that’s part of the same Kerika project.
It’s a tricky problem, and the solution doesn’t lie in our hands since it is entirely up to Google as to where they choose to store your documents within the hundreds of domains and the thousands of sub-domains that they control. The easiest bet, of course, is to allow third-party cookies – which you may already be doing, unless you have changed your browser defaults – but if that’s not acceptable to you, you might want to look at using the Chrome browser and watching out for that broken cookie image in your address bar.
UPDATED NOV 11, 2016:
A reader, Carey Dessaix from Australia, offers a better solution to just allowing all third-party cookies:
Adding “[*.]googleusercontent.com” is a solution.
Just go to Chrome settings > Advanced Settings > Privacy > Content settings.
Click “Manage exceptions” and add the following as allowed which will allow allow subdomains including the actual domain as well.
