People using Kerika love the text block feature – the one that lets you create richly formatted text blocks on a Kerika page that contain pictures, tables, lists and links – but all too often they try to create these text blocks by copying and pasting text from a Microsoft Word document.
The problem with doing this is that Microsoft Word produces a gigantic amount of HTML junk, even with the simplest text.
Here’s an example: create a new Microsoft Word document and type in the words “Hello, World!”. That’s it: just two words, a total of 13 characters including spaces and punctuation, using your default font. Nothing fancy – no colors, bold or italics, no lists, nothing at all. Just two words.
Now try to copy and paste this text into something that will display the HTML generated by Microsoft Word. One option is to paste this text into a Kerika text block, and then use the “View as HTML” option to see all the HTML that comes with these two words, but we will be temporarily removing the “View as HTML” feature in our next version as part of our rewrite of the text block feature. (More on that later…)
You will find that Microsoft Word produces an astonishing 1,287 words, which add up to 18,008 characters of HTML, just to represent a total of 13 characters of content. In other words, your simple bit of Microsoft Word text exploded by a factor of 1,385.
(If you look at the HTML, you can see, of course, that this expansion factor doesn’t stay constant: a lot of the HTML is simply a dump of a lot of styling information that wouldn’t change proportionately as you increased the size of the original Microsoft Word content, but still…!)
Here’s how you can say “Hello, World!” using 1,287 word of HTML:
We recently talked about a shift within Google Docs that resulted in their using a new domain name – googleusercontent.com – to store images that users upload.
The way Google stores images on various sub-domains of googleusercontent.com is a bit of a mystery to us: it isn’t just that when you upload images to your Kerika pages they get stored by Google in some seemingly-random sub-domain of googleusercontent.com, but that the location may change from day to day!
This is making it very hard to run the Chrome browser with the “Disable third-party cookies” preference turned on, because you may find that each day some of the images on your Kerika pages are not being displayed because they have suddenly shifted to a different sub-domain of googleusercontent.com – one that you haven’t previously whitelisted.
Firefox used to have a very simple way of whitelisting domains for which you were happy to get cookies, but that disappeared several versions.
Chrome doesn’t offer any easy way of whitelisting domains either, presumably because Google is strongly in favor of third-party cookies since these underpin so much advertising. There’s an extension for Chrome called “Vanilla Cookies” that supposed to allow you to whitelist domains using wildcards, but it doesn’t seem to solve the whack-a-mole problem with googleusercontent.com as far as we can tell.
Now, your only options appear to be:
Disable all third-party cookies, which means that images you upload to your Kerika pages are not shown because they are being stored somewhere on googleusercontent.com, which is a third-party since it is neither kerika.com nor google.com, or
Allow all third-party cookies which means all sorts of junk can find its way onto your computer.
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.
If you visit this blog, you get a total of 8 cookies placed on your computer from blog.kerika.com – unless, of course, you block all cookies, in which case you probably aren’t a Kerika user. Of these, just 2 are of any use to us: they help us with Google Analytics.
The other 6 are placed there because we use the WordPress software to publish this blog. We haven’t any use for them, but haven’t gotten around to turning the off because that would require us to fiddle with various PHP files.
And if you use the Kerika software, you get a total of 6 cookies from kerika.com. Of these:
2 are from Google Analytics. They help us understand which of the nearly 80 pages that currently comprise kerika.com are of real interest to people. These cookies are called _utma and _utmz.
1 comes from the fact that we use CometD, an open source implementation of the Bayeaux protocol, for our real-time communications. We haven’t any use for this cookie, but haven’t gotten around to turning it off. This one is called BAYEUX_BROWSER.
1 is related to our use of Jetty, an open-source, Java-based Web server. We haven’t any use for this cookies either, but, as with CometD, we haven’t gotten around to turning these off either.
And, finally, we get to the two cookies that are of practical use to us:
The claimedID cookie helps us identify you as a registered Kerika user, and
The tabs cookie helps us bring you back to the projects you had open when you were last using Kerika.
Sorry about all those useless cookies.
That’s the problem with using third-party software like WordPress, CometD and Jetty: each comes with its own platter of cookies, and to turn them off requires one to dig into the code for each of these systems. Frankly, it doesn’t seem worthwhile, at least in comparison to fixing bugs and delivering new features, which is where all of our energy goes!
But, in comparison to other software vendors, our use of cookies is far from excessive, and that’s because we are not in the advertising business. Google, on the other hand, is very much in the advertising business, and taking a look at the Chrome browser cookies on one of our development machines, here’s the very impressive count we found for the original Cookie Monster:
google.com
43 cookies
accounts.google.com
5 cookies
apis.google.com
1 cookie
checkout.google.com
4 cookies
chrome.google.com
2 cookies
code.google.com
3 cookies
docs.google.com
12 cookies
groups.google.com
4 cookies
mail.google.com
29 cookies
plus.google.com
2 cookies
plusone.google.com
2 cookies
profiles.google.com
2 cookies
sandbox.google.com
2 cookies
support.google.com
8 cookies
talkgadget.google.com
1 cookie
tools.google.com
1 cookie
www.google.com
19 cookies
www.googleadservice.com
1 cookie
translate.googleapis.com
1 cookie
deployment.googleapis.com
2 cookies
fastflip.googlelabs.com
1 cookie
igoogle-skins.googleusercontent.com
1 cookie
That’s a total of 144 cookies! And when it comes to local storage, Google has a fairly big footprint:
clients6.google.com
Local storage
mail.google.com
Database storage, Local storage
news.google.com
Local storage
plus.google.com
Local storage
www.google.com
Database storage, Local storage
There’s a lot of controversy about Google’s announcement that they will merge data collected from their various services to provide more targeted advertisements. If that means they have figured out how to consolidate information gathered by 144 cookies from 22 different services – well, one can’t help but be impressed at the technical challenge they have taken on!
We have a feature in Kerika that had been behaving more like a bug for one of our users, and the root cause of her dissatisfaction turned out to be a very obscure problem with the way Firefox runs on Linux.
First, some background: one very cool feature in Kerika is that you can see little thumbnails of pages so you can tell at a glance what each item contains. Here’s an example of a project, as it appears on a user’s “All Projects” page:
Example of a project thumbnail, as it appears on a user's My Project page
Kerika displays the project as a small thumbnail. You can see these thumbnails in several places in Kerika: for example, when you are viewing a project page where items represent sub-projects, or when you are using the Breadcrumbs to navigate back up the hierarchy of projects and pages.
To create these thumbnails, we have a “Render Server” that runs on a Linux virtual machine on Amazon’s cloud. The Render Server automatically produces a new thumbnail of your project about 3 minutes after you have finished making your changes to the page.
(Why not instantly? Because in our experience, people often make a bunch of relatively small changes within a few seconds: for example, they might move something on their page several times, fairly quickly, before they are completely satisfied with where they have placed the item. If we created a new image with every single action a user takes, we would flood people with updated images every few seconds; instead, we wait for a couple of minutes until after the user has finished making changes before updating the thumbnail of the page.)
Well, this Render Server runs Firefox 9. There are a class of fonts that are supposed to be “browser safe”: i.e. all browsers are supposed to support these fonts. This class is commonly thought to include about a dozen fonts, including Trebuchet MS, but in reality the set of browser-safe fonts may actually be much smaller. And, it turns out, Firefox 9 on Linux doesn’t support Trebuchet MS after all!
Which brings us to our user and her very obscure bug… She had been using Trebuchet MS as a font for her project pages, and her pages included a number of diamond shapes. Kerika has a feature that resizes shapes automatically to fit all the text contained within the shape, so that, for example, if you increase the font size, the shape will resize automatically to accommodate the larger footprint of the text.
Whenever our user made a changes to her page, after about 2 minutes the Render Server would automatically try to create a new thumbnail of the image. But… since Firefox on Linux doesn’t support Trebuchet MS, Firefox would fall back to the closest font it had, which was Times New Roman. The footprint of Times New Roman is quite different from that of Trebuchet MS, so the diamond shapes need to be slightly taller and less wide, and the Render Server would automatically adjust the shape when it created the thumbnail for the page.
As a result, our user found that her diamonds were changing size in some random manner, which was both puzzling and annoying. The bug was obscure indeed, because it ultimately had to do with Firefox not supporting Trebuchet MS on Linux even though that font is supported by Firefox on Windows and Macs.
Luckily, our team includes some unusually smart people! One of them spotted the quirk fairly quickly and the fix is going to be relatively easy: we are already providing our users with an extended set of fonts, and for these we provide Firefox with the necessary CSS to render the fonts. We hadn’t been providing the custom CSS for Trebuchet MS, thinking that it was already supported by Firefox, but now we will.
In case you are interested, here are the fonts we currently support:
We rolled out our latest version over the weekend, and it features some big improvements in usability. As usual, feedback has come in from all sources, and is always welcome, but for this particular version we need to acknowledge the particular contributions of Alexander Caskey, Barry Smith, Seaton Gras, Andrew Burns, and Travis Woo.
We were able to incorporate most of the improvements that were identified, although one significant one couldn’t make it in this particular release. (That’s to do with providing a project-centric view, and we will talk about that in a separate blog post.)
So, here’s the bundle of goodness that is Kerika today:
There are fewer buttons on the Toolbar, and we have made them more clearly visible.
We combined the old Team and Share buttons into a single Share! button, since “sharing” and “managing a team” are very closely related activities.
We have also dropped the old Join! button that let people ask to join projects owned by other users. This button apparently had little practical use, and dropping it helped simplify the overall user interface.
The Preferences button has been moved: it is now part of the “Manage Account” drop-down menu. We have also implemented something we call “implied preferences”: now, when you set a particular style preference, such as a font style or color, Kerika assumes that this is your new preference going forward (until you change it something new in the future).
We simplified the user interface by completely hiding buttons and menu options that are unavailable. For example, if you are viewing a page where you don’t have permission to make changes, the drawing toolbar on the left disappears.
We have made some extensive improvements to the formatted text feature (the one that you access with by pressing the “T” button on the drawing toolbar). When you are creating or modifying a block of formatted text, the toolbar for this now appears above the canvas area, where it doesn’t get in your way, and the drawing toolbar is temporarily hidden.
We have hugely expanded the selection of fonts and colors that are available, and made it much easier to change the appearance of several items on a page at the same time.
A “help bar” appears when you are viewing an account to help guide you.
We have added more pricing levels to support smaller teams.
We have made numerous fixes to the feature that produces snapshots (thumbnail pictures) of your project pages. We got most of the kinks out; there are a small handful that we are working on this week.
We will be continuing to work on usability: over the next several weeks we will be making some changes to support a “project-oriented view” for you, as well as improvements that will make Kerika more tablet-friendly.
There aren’t many bloggers that take a data analytics approach to popular hype: the kind of stuff that Rich Barton called the “Y Combinator, TechCrunch, Benchmark, Sequoia spin cycle” Here’s another beauty of a pie chart:
The extent to which Google's senior management use Google+
And the money quote: “In total, of the 18 most senior people charged with overseeing Google, 11 have either not joined or have never made a single public post, and 5 have barely used it at all.”
