As new G+’ers, I imagine many of us scurry about busily categorizing or tagging these people we know, or sort of know, or might know but can’t quite remember, or don’t know at all.  I find myself falling into a pattern of creating circles by workplace, school, or other “where I met them” sort of context.  Pretty soon you’re looking at a dozen different circles.

It’s all neat and tidy (sort of), but my realization now is: When am I going to use these carefully crafted circles? I’m having difficulty imagining a situation where I’d post something only to my Borland colleagues and have reason not to post it to my Microsoft colleagues or for that matter to the general public.

Am I going to become my own Amazon Turk and presort my outgoing posts, sending them only to the people I think would be interested?  Not likely. I know they don’t really read my posts anyway.

On a different level, there is the argument that people who post are desiring to be heard.  So why restrict the scope of your audience by only posting to a circle of contacts?

One communication vector G+ Circles could easily replace is topic oriented or regional mailing lists.  We have a few of these here in the Santa Cruz Mountains to share information p2p about wildfires, road closures, storm damage, local merchants and events.  It wouldn’t be a stretch to imagine a publicly listed circle that people could attach themselves to (inverse of the current Circles paradigm) that provides a service similar to the email mailing list, but without all the subscribe/unsubscribe headaches.

One tidbit that new G+’ers seem to get excited about is the potential to use these Circles to limit distribution of some of their posts, in the sense of having private conversations. This really bugs me, because this is how we lull ourselves into using good tools for the wrong job.  It’s a bad idea to approach Google+ with privacy in mind.  It’s a microblogging publishing platform.  It may have some new knobs to publish to a group slightly smaller than 7 billion people, but don’t kid yourself into thinking limited distribution is privacy.

There is certainly a noble case for being able to post certain personal or sensitive items only to immediate family, (and for posting something *not* to immediate family!).  I can appreciate that argument.  Really, I can – it would be nice to be able to post vacation updates to a select group of family and friends  without telling the whole world that our home is empty and ready to be burgled. I get that.

As appealing as that scenario is, it still makes me uneasy. It’s tempting, but it does not silence the little voice in my head reminding me of the online mantra I learned firsthand at an early age:

If it’s sensitive enough that you wouldn’t want some individual or group to find out about what you said, don’t post it.  Anywhere. Period.

The Google Circles technology may be flawless – or not.  There are plenty of ways for technology to “leak” the wrong bits in the wrong direction, but technology isn’t our greatest or most common mode of failure.  That honor goes to the lump at the organic side of the human/machine interface who is still perfectly capable of screwing things up big time by posting the wrong thing to the wrong group.  Sometimes that lump is me.  Sometimes it’s a friend with whom I’ve shared or entrusted a little bit too much detail. And sometimes the lump posting the wrong stuff to the wrong place is just a congressman from New York.

Having streams of public and private conversations in the same place definitely does not help. We’ve all seen the email follow-up snarky remark that went to “Reply All” instead of “Reply to Sender” and cringed. Or pasted that rude (but hilarious) URL into the wrong IM window. (yikes)

Google Circles is no better and no worse.  Google Circles makes it easy for you to select which subgroup you want to post to, but everyone in that subgroup has the ability to share your post further, outside your control.  Google+ even reminds you of this with a little popup text to be respectful of the original poster’s intent when you share someone else’s limited distribution post.  Yes, you can disable resharing of your posts on G+, but that doesn’t prevent copy & paste or screenshots from helping your post jump the privacy fence.

If you believe there is some truth to the notion that information is hard to keep contained, then you have to accept that anything you post has the potential to “get out” and be visible to a much larger audience than you intended. The simplest way to deal with that reality is to treat everything you post as eventually becoming public information.

Thus far, my work to carefully sort and tag my contacts into their soothing blue pigeonholes is turning out to be all for naught. The blue circles float there largely unused because just about anything I would post anywhere I would post as public, not to any particular circle. Maybe I should start a mailing list…

Share/Bookmark

Whenever I visit my Google homepage now, I have to wade through 5 or 6 JavaScript error notifications before I can do anything.  I suspect the culprit is the Gmail gadget for the Google homepage, as I continue to get script errors while trying to browse email in-situ on the homepage.  The gmail gadget is also missing scrollbars on long messages. None of these problems are present when using Gmail itself, just when using the Google homepage.

As a developer, I have to have script debugging enabled in my browser.  This enables me to debug my web app code in the browser, but it also has the unfortunate side effect of pointing out JavaScript errors on every site I visit.  It’s surprising how much crappy code is out there in production.  Slashdot has degraded into the pretty much unusable range in recent months, and now the Google homepage / Gmail widget is following suit.

The script errors are not specific to IE.  Firefox 3 also notes 5 critical errors in its error console when navigating to my Google homepage. To Firefox’s credit, recording these script errors in a log rather than with popup dialogs is much less intrusive than IE, but that also means that significant script errors can go unnoticed by developers testing their web apps with Firefox.

The errors are:

Error: _IG_AddCustomEventHandler is not a function
Source File: http://www.google.com/ig/f/lZ_kPjC_O4s/lib/libcore.js
Line: 43

Error: _IG_AddEventHandler is not a function
Source File: http://www.google.com/ig/f/irJtX0bmDdM/lib/libdynamic-height.js
Line: 4

Error: _IG_Json is undefined
Source File: http://www.google.com/ig/f/_pVqt4t_Qx8/lib/libviews.js
Line: 1

Error: _IG_Prefs._parseURL is not a function
Source File: http://www.google.com/ig/f/lZ_kPjC_O4s/lib/libcore.js
Line: 78

Error: _IFPC is undefined
Source File: http://www.google.com/ig/f/irJtX0bmDdM/lib/libdynamic-height.js
Line: 2

So, to whoever turned on the new code a few days ago for either the Google Homepage or the Gmail widget for the homepage:  Please review your code and fix the crappy script that you’re dumping on us.  Your developer bretheren thank you for a speedy resolution so that we may get back to debugging our apps instead of debugging yours.

Share/Bookmark

Today was pretty much sponsor’s day – the speedgeeking and chalk talk presenters all appeared to be sponsoring the event in some way.  I discovered a few new things interesting enough to dig into further, but I’m really hoping tomorrow will get back to the “directed anarchy” that un-conferences are famous for.  No session tracks, no agendas, just time slots and rooms and a whiteboard (or wiki) where the conference attendees can nominate and vote for discussion topics they’d like to learn more about.  If there’s sufficient interest and sufficient expertise in the audience to cover the topic, then poof! you have a session.

The discovery of the day for me was Calais, a content digesting and tagging web service offered by Thompson Reuters (the news service people) that brings a smack of semantic web to the content you throw at it.  Given a news article to digest, Calais can identify all the people named in the article, as well as places and market segment key concepts. Calais can also do a fair bit of semantic disambiguation, figuring out that the John Doe in this article is probably the John Doe that is CEO of the company also mentioned in the article.

I need to dig into Calais’ web service API and tinker with it a bit. It sounds very interesting.

The yawner for the day was the Google chalk talk, delivered by a developer evangelist from Google ground zero just down the street. He was showing APIs to integrate Google Earth into Google Maps. Showing stuff on a map has become the cliche of mashups, so if you’re going to demo something with a map (especially to the mashup community) you’d better make it jaw-droppingly fantastic.  Sorry, but adding Google Earth APIs to Google Maps didn’t do it for me. 

To make matters worse, the presenter had to talk his way around a number of technical difficulties, including (but not limited to):

• Really slow page loads and display updates when running his Google Maps + Google Earth demos
• Images from background web apps leaking into the foreground web app (never a good sign)
• A demo of a Singapore library app that flickered so badly that people on the front row fell to the floor in epileptic seizures
• Failing multiple attempts to get the highly anticipated Monster Milktruck demo to load
• And last but not least, crashing the Firefox browser on the big screen.

All of that in 25 minutes. It’s a reassuring to know that even Google can have “those” kinds of demo days.

The seizure-inducing flicker in the Singapore library app was probably due to having faces in the model with no texture defined.  The presenter apologized for the flicker, mentioning that the app developer(s) had some “problems” with their 3d models.  Ok, fair enough, but why on Google Earth would you put that crap up on the big screen?  The concept of showing a 3D map of a library maze wasn’t impressive enough to overcome the presentation flaws.

Hopefully tomorrow’s talk on Google AppEngine will go more smoothly and have more timely content.

Share/Bookmark

The fact that Dion felt the best way for him to advance the state of the art of web development was to leave Google for Mozilla says a lot about Dion’s passion for the art. 

It says a lot about Google, too.

Share/Bookmark

Lukas says he’s had it with S3′s reliability problems and is looking for a replacement, but isn’t all that impressed with the available alternatives in the scalable online hosting space.  Google’s App Engine has earned similar criticism after a June 17 service outtage, reported on TechCrunch in “Google App Engine Goes Down and Stays Down“.  So, Lukas indicates he’ll have to go back to the old solution of building dedicated servers, and shouldering all the associated costs and risks that massive online hosting data centers were supposed to do away with.

It sounds like the market is ripe for someone – anyone – who can deliver scalable services with ironclad uptimes and service guarantees that pay out true value of business lost when the service goes belly up.  It’s not about the cost of the service itself – it’s about the value of your business lost when the service goes down, which is almost always significantly higher than the cost of the service.

The first comment on Lukas’s Delores Labs blog post suggests that if a business can’t survive a 7 hour outtage, then something must be wrong with the products or the business itself.

Service outtages do more damage than just lost sales. They damage your site’s reputation, which is much harder to repair than lost sales. Web consumers are very flighty and very finicky and generally follow patterns of addiction with their favorite web sites.  That is, when they can’t get to their favorite sites, they get cranky.  When they can’t get to their favorite sites for hours at a time, they find a new favorite and probably never return.  Worse, they will shift from being advocates for your web site to vocal critics, and thus indirectly channel traffic away from your site via the social network influencer effect.

Few online services today do not have a close competitor, and the barrier to switching is usually little more than inconvenience and emotion.  The best way to retain your current customers is to not give them a reason to go looking at alternatives. Consumers are couch potatoes - as long as they’re satisfied enough with what they have, they aren’t likely to pay attention to alternatives – even when they have criticisms of the product, and even when the alternatives are superior.  Same as TV:  If you like the current program, you’re less likely to switch channels.  (Works great until the most disruptive element in commercial television – the commercial break) 

I think part of the problem, part of what is missing from hosting providers such as Amazon’s S3 and Google App Engine are service agreements that provide meaningful consequences in the event of service failure.  Google offers no service guarantees – it’s up when it’s up, and we’ll get around to fixing it when it breaks when we can.  The Google engineers definitely have their hearts and souls in fixing things ASAP, but Google the corporation protects the koffers and offers no promises.  Lukas indicates that Amazon S3 offers a 25% refund in the form of future service credits in the event of outtages.  25% might take a bite out of Amazon’s profit margin, but it doesn’t come anywhere close to the kind of horriffic damages provided by “utility grade” service agreements. 

Hosting services don’t yet conduct themselves as true utility grade operations.  Compare the service level agreements of any online service with those of, say, an electrical power company.  If you’re a multimegawatt industrial power customer, chances are good that you can demand service level agreements that are downright terrifying to the service provider. From friends and colleagues I hear stories of manufacturing plants in Silicon Valley that crank out a million dollars worth of product per hour, every hour, 24 hours a day, 360 days a year (allowing for only 5 days of systemwide downtime). When the power fails, the service agreement has the power company make up for the plant’s losses – the power company is held responsible for that million dollars per hour, until they fix the problem and restore power service.

Now that’s what I call an incentive.  Invest in redundant systems, continuous monitoring, and rapid response teams, or your power company will go broke within minutes of the first outtage.

Hosting provider service level agreements won’t leap to the extreme of 2x loss of business damages, but as new players enter the hosting market, they will have to do something to differentiate themselves from other hosting services.  There’s not a lot of room for differentiation in the hardware or the service itself, so the new guys will have to distinguish themselves on cost and service guarantees.  A new hosting provider will make deeper concessions to the consumer in service agreements than the old guard offered.  Google and Amazon don’t need to offer significant service level guarantees primarily because nobody else is forcing their hand by offering better.  Over time, competitive pressures will force an improvement in service level agreements for online hosting services as the hosting market becomes deeply commoditized.

All we need now are more competitors.

Share/Bookmark