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.
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.”
There’s a remarkable graphic over at the theunderstatement.com that shows how infrequently updates to Androids have made it into the hands of end-users. Here’s the graphic and the money quote:
Android and iPhone update history from theunderstatement.com
Other than the original G1 and MyTouch, virtually all of the millions of phones represented by this chart are still under contract today. If you thought that entitled you to some support, think again:
7 of the 18 Android phones never ran a current version of the OS.
12 of 18 only ran a current version of the OS for a matter of weeks or less.
10 of 18 were at least two major versions behind well within their two year contract period.
11 of 18 stopped getting any support updates less than a year after release.
13 of 18 stopped getting any support updates before they even stopped selling the device or very shortly thereafter.
15 of 18 don’t run Gingerbread, which shipped in December 2010.
In a few weeks, when Ice Cream Sandwich comes out, every device on here will be another major version behind.
At least 16 of 18 will almost certainly never get Ice Cream Sandwich.
Also worth noting that each bar in the chart starts from the first day of release – so it only gets worse for people who bought their phone late in its sales period.
It’s well worth reading the entire blog post, which is one of the most detailed analyses we have seen in a while. While Google has done a great job of rapidly innovating on the Android platform, they have completely neglected the job of getting these innovations into the hands of end-users.
We finally got the browser Back button working (along with the keyboard backspace key) to help you navigate back and forwards through your Kerika pages and other websites that you may be browsing at the same time.
You might be wondering why it took so long; after all, the Back button has existed in browser since the very beginning, and “breaking the Back button” is one of Jakob Nielsen‘s cardinal sins of Web usability.
The story is somewhat complicated, and it helps to understand two critical features of Kerika:
Kerika lets you have multiple projects open at any time, each within its own tab. In other words, Kerika lets you create tabs within a browser tab. Since all of these Kerika tabs are within a single browser tab, in some sense they all share the same URL as far as the browser is concerned. This makes things tricky for us, since each Kerika page actually has its own unique URL. So, how can we map several URLs, for several Kerika pages, to a single browser tab? Hmm…
Kerika offers super-fast updates when somebody on your project team makes a change to a project page that you are viewing: we aim for sub-second responsiveness in terms of letting you know that something has changed in your project. You don’t get that kind of speed using AJAX, which is what most people think means “real-time Web”. (That’s just so Web 2.0…) Instead, we use a newer technology called Comet, which is based upon the concept of “long polling”.
These constraints made it tricky for us to get the Back button working: we had to be able to “load” the browser’s Back button with a new URL every time you switch between Kerika tabs, and we had to do this fast enough to not compromise our exacting standards for delivering real-time performance.
We were finally able to do this because modern browsers are now offering Web applications easier ways to load the Back button stack in each browser tab. This is relatively new, and now supported across enough modern browsers for us to be able to offer this (seemingly routine) feature!
The latest version of Kerika, hot off the presses, contains our biggest innovation yet: if you have pages contained within pages, these will now show up as small snapshots.
Here’s an example of a set of projects, as viewed from the My Projects page of an Account:
A thumbnail view of a project page
Projects can now be viewed as little thumbnails: this lets you see, at a glance, what’s inside a particular project!
This feature extends all the way inside a project that consists of a series of nested pages. Take, for example, the Product Management page shown above: if you open it up, you will see that it contains some sub-projects within it, and these sub-projects – which have their own pages – can also be viewed as thumbnails:
A subproject also shows up as a thumbnail
This feature is probably the coolest innovation ever! It took a really long time for us to build, since we were working on this while doing all the other usability improvements, bug fixes and new features we have delivered over the past few months, and we think it will improve the overall usability of Kerika in a very big way.
There are all sorts of side-benefits to this feature:
Now, you can upload a snapshot of the project to LinkedIn and Facebook along with your comments; the picture will contain a live link to your project.
We have made it possible for you to embed a snapshot of a Kerika page in your own website or blog, using the Share! button that’s now more powerful than ever.
These snapshots of pages are automatically updated whenever a member of your project team makes a change to the project: we wait a couple of minutes after the last change has been made before producing a new snapshot to avoids sending you a flurry of new images.
There are also two new ways for you to embed either a Kerika page, which you can use as a regular website page, or the entire Kerika application, in your own website or blog. (This is a big enough topic to deserve it’s own blog post.)
And there’s more to our latest version!
You can see the page URL of any project at any time (unless you are using Internet Explorer which continues to lag in its support for the HTML5 standard.)
When you upload documents to a project page, they are now stored in your own Google Docs account, not the Google Docs account of the Project Leader. This is a big change, but one that was necessary to allow the use of the same document in multiple projects. Previously, we passed ownership of the document to the Project Leader, but this meant that ownership could pass through several people’s hands if the same document was used in multiple projects.
The browser’s Back button (and the keyboard backspace key) work now! Yeah, it took us a while to get this working, but there were some serious hurdles that we had to overcome first, relating to the way different browsers support HTML5. More on this in a subsequent blog post.
We have added a new diamond shape to help you draw flowcharts. We are not keen to add a lot of shapes; we want to keep the Kerika user interface clean and uncluttered, but we felt that a diamond shape could really help with flowcharts so we have added our first new shape in six months!
Pages now automatically refresh if the application detects that there was a problem connecting to the server. The old dialog box that used to pop-up asking you to refresh your browser – which we found as annoying as you did – has gone away.
You can now add a Twitter feed to a page by just providing “@name” as the URL. Adding Twitter feeds to Kerika pages is becoming more popular with our users, so we made the process of using the Magic Plus button simpler: just enter “@kerika”, for example, when you use the Magic Plus button to add content from the Internet and you will get our Twitter feed added to your Kerika page.
Speaking of which, the Magic Plus button got even more magicky: now you can add content from dozens of third-party sources to a Kerika page. (You can see a handful of them listed on our website, but don’t be shy: just add any kind of URL and see if Kerika can’t automagically figure out how best to show it on your project pages.)
We also spent some time improving our text blocks, after seeing just how popular this feature was becoming with our users:
We have better icons for the buttons; the old ones weren’t as intuitive as they could have been.
We have added a new background fill color so that you can have even fancier text blocks.
The text block feature has better buttons and a new background fill color capability
We have done a ton of usability improvements and bug fixes, as usual, and we will continue to do so in the future…
One usability improvement was to “undo” a previous improvement: we had made a change in our last version that we thought was a good idea, but it turned out that everyone liked it, even us, so we have taken that out. Now, when you resize an item on your page using the grab handles, the item resizes in just one direction rather than in all directions.
We made it easier to add large (high-resolution) pictures to your Kerika pages. Previously, high-res pictures would appear initially with full resolution and crowd out everything on the canvas. Now, pictures appear with a maximum initial size of 640×480 pixels, and you can, of course, resize it to be larger if you like.
Finally, we have revamped our website completely and would love to get your feedback. We are featuring sample projects on our home page, and the Example pages.
We want to feature your work on our site! Create projects that are open to the public, that show your skills and share your knowledge, that related to open-source, advocacy, political action, interests in hobbies and sports… It’s all good.
Apple just announced a new platform and nobody noticed.
Far too much of the commentary from Wall Street about the launch of the iPhone 4S has been superficial, focusing on the fact that it is a “4S” and not a “5”. Why, oh why, wail the analysts, couldn’t Apple just have called it the iPhone 5 and made everyone happy?
This misses a rather big point about the iPhone 4S: the “S” may ostensibly stand for “speed”, since the new phones have a faster processor, but in our opinion the “S” really stands for Siri, as in “speech”.
OK, so we don’t have our hands on a real iPhone either, which means we are guessing, too, and using the very limited collection of videos and demos that are publicly available for our guesswork/analysis, the most extensive of which is Apple’s own promotional video.
This promo video, however, does provide a very good indicator of the vast potential of the new speech platform that Apple has just launched. Yes, there’s a whole new platform for personal computing out there now, thanks to Siri, and it’s not just limited to iPhones.
Siri is more than speech processing: it is an impressive attempt to bring interactive voice response (IVR) to the masses in a way that does not immediately induce rage against the machine. There are two major innovations with Siri, only one of which has gotten any real attention:
There is the AI needed to understand the user’s speech and translate the nouns, verbs and indirect references (like “this weekend”) into API calls, and here Siri promises to be a considerable leap forward from the kind of hugely annoying systems we all accustomed to dealing with when we call our bank or insurance company.
There is also the AI needed to generate voice output from the system, and here Siri looks like it could do with some work, particularly if it is to sound less synthetic.
The far more impressive work is the Siri’s integration with the calendar, email, Google Maps and iTunes programs, as well as external web services like weather.com. This is the new platform that just got launched: the integration of a speech interface to all personal computing devices: not just phones, but also tablets, laptops and TVs.
The iPhone 4S will debut with Siri working seamlessly with mail, calendar, Google Maps, SMS, weather, and basic Web searches. But this is just the start: what Siri does today is similar to what the iPhone 1 did on the day it launched, when it came with a handful of standard applications for email, calendar, SMS, weather and basic Web searches. (Hmm… sound familiar?)
If the iPhone 1 was impressive right out the box, before hundreds of thousands of applications had been written for it, imagine what the Siri platform will be like when there are hundreds of thousands of existing applications and software packages that support a speech interface.
Apple has launched what they hope with be the speech platform for personal computing. Sooner than we developers would like, we will have to start supporting a speech interface to our personal computing applications, and it will have to be a much smarter interface than anything that came before.
If Apple succeeds in making the Siri interface a de facto standard, they will own a fundamental platform technology that would make Bill Gates envious.
This website uses cookies to improve your experience. We'll assume you're OK with this, but you can opt-out if you wish.AcceptRead More
Privacy & Cookies Policy
Privacy Overview
This website uses cookies to improve your experience while you navigate through the website. Out of these, the cookies that are categorized as necessary are stored on your browser as they are essential for the working of basic functionalities of the website. We also use third-party cookies that help us analyze and understand how you use this website. These cookies will be stored in your browser only with your consent. You also have the option to opt-out of these cookies. But opting out of some of these cookies may affect your browsing experience.
Necessary cookies are absolutely essential for the website to function properly. This category only includes cookies that ensures basic functionalities and security features of the website. These cookies do not store any personal information.
Any cookies that may not be particularly necessary for the website to function and is used specifically to collect user personal data via analytics, ads, other embedded contents are termed as non-necessary cookies. It is mandatory to procure user consent prior to running these cookies on your website.
