Olark is absolutely simple to integrate: a single snippet of JavaScript. But it offers a great deal of power: you can push a logged in user’s name and email address through the chat, and set their IP address, browser build, and other details as that user’s “status” when chatting. (You can even have the chat bot message you that information at the beginning of the session.)

The fun doesn’t end there: Olark allows you to actually redirect a user to a different URL, including external addresses, all while maintaining persistent chat. This is absolutely fantastic, as you can literally direct a user to the page they need while still helping them out. Olark reports what page they’re currently looking at, and their new co-browsing feature allows you to literally see what your users see, scroll the page for them, and circle certain elements.

This level of interaction is fantastic: it can help clinch a waffling pre-sale customer who has a small question but isn’t able to find an answer and doesn’t want to go through the trouble of filling out a contact form. Or it can assist with the on-boarding process: new users are the most likely to encounter experience-ruining burrs, problems, small barriers to entry that can be resolved with a simple chat.

The ability to transfer conversations, native Jabber/XMPP utilization (such that I can use Trillian for managing my chats), and a robust API round out the core features of a very compelling product. Olark is free for up to 20 conversations a month and one operator, but the clients we’ve signed up on Olark needed the Gold plan, since it’s the lowest plan that supports SSL.

Check out Olark for pre-sale potential customer engagement, and post-sale onboarding/getting started assistance. Reducing friction for new and potential users is the surest way to build a loyal following or make a sale.

Olark

Google’s Plus release represents their first legitimate effort at a coherent social experience. Right out of the gate, they’ve got a few things incredibly right: amazing notifications unified throughout all Google products, good integration with Picasa and Android, Circles, Hangouts, data portability, and a feeling like this might be around for some time.

Now they need to focus on what’s necessary to make this a second nature, everyday product for people, like Facebook is now for most people.

Open Registrations/Invitations

If anyone can get scale right, it should be Google. Admittedly, scaling instantly in to the millions is a challenge for even the largest companies, and there’s surely a method to their madness here, but they need to be doing whatever they can to get this thing open to as many people as possible. They’re framing the current experience as a “Field Test”, but it’s difficult to test a social networking product if you can’t get your friends onto it. Early adopters are the type of user who will shift their more reluctant friends to a new system. They’re kneecapping their momentum with their limited invitations.

Figure Out Sparks

By far, the most confusing element of Plus is Sparks. It’s an interesting hodgepodge auto-aggregator of news and blog posts on individual topics (or “eccentric hobbies” as their video goes), but it’s presented in a bit of a sloppy way. Since it’s curated automatically, it’s not terribly great at it, which is a bit disappointing as well. Fortunately, Sparks is a nice-to-have within the Plus experience. Perhaps some integration with Reader would help make Sparks shine.

Make Huddles Amazing (Read: Copy Beluga)

I’ve got basically every single friend I speak with regularly on Beluga now. We use it to plan events, see what’s happening for the evening, and coordinate shared rides and the like. It’s a great tool. We also have fun with it. We share photos and links and such. And we can access it from our desktop if necessary. Huddles don’t currently let you access them from the Plus site itself, only from the mobile app. Since Plus isn’t available in the iPhone App Store yet, I can’t try to convert my friends to Huddles yet. And since Huddles don’t let us share photos or set Huddle photos, I don’t know if I’d want to yet. Location sharing is really useful too, and here Google has a definite leg up: it already shares location on posts… why not on huddle updates? Moreover, why not tie directly in to Latitude? Let me navigate right to a real-time-updating friend if I’m picking them up from someone, right from within our Huddle!

Import Profile Pics from… Somewhere!

Most of my connections/friends on Plus are faceless. Make adding a profile picture a required first step. It’s important to associate faces with names, but moreover, it’s WAY less usable to see a bunch of placeholder graphics throughout the product. Import from Gravatar, or, if you won’t violate TOS (heh), from Facebook directly. Either way, make it required, or constantly nag until it gets done.

Release a Stream Notifier or API

If you want us to engage, we need to know things are happening. Right now, it appears the only way to see new posts is to load up the Plus site or app and look at the Streams. Facebook and Twitter have apps or APIs that allow us to get pinged with updates as they happen. You’ll lose momentum and people will stop coming back to Plus if we can’t see what’s happening without having to call up the site manually every time.

Let Me Cross-Post Content Easily

Since Plus isn’t going to overtake Facebook, Twitter, or Linked In overnight, let me cross-post to those places with a click of a button. Better yet, blow everyone away and make it as easy as choosing a “Circle”. Add the Facebook “Circle” and the post auto-cross-posts there. Add the Twitter “Circle” and the shortened form is available for preview before it ends up there. By keeping up the walled garden, Google may be intentionally discouraging this sort of behavior, but this is what will trigger buy-in immediately and ease the transition. Social networks aren’t necessarily a zero-sum game, but two is likely very close to the limit for most.

What’s Next for Plus

Plus is off to a great start. Better than Buzz or Google Wave could ever hope for. It’s exciting, clean, original, and well-executed, with a lot of great features available right out of the gate, and some really innovative concepts. With a bit of polish and a bit more hand-holding, I think Google can convince people to begin using Plus as part of their daily interaction. But the elements needed to keep us checking in and coming back every day aren’t quite there yet. The notifications are a great start, but they only tell part of the story, keeping me informed only after I’ve already engaged. I need a reminder to check in on Plus and see that my friends are using it, and that’s sorely lacking right now.

Google also needs to integrate single-sign-on/Google Authentication with Plus, the way Facebook Connect can be used to allow people to log in or register on a site. It’s not necessary to have a complete app platform available right out of the gate, but Facebook is definitely on to something with Facebook Connect and it’s an important element for any social networking site to drive engagement.

Hopefully we’ll see swift continued development on Plus. It’s a great product out of the gate, but building the product isn’t the hard part in social networking: that’s left to getting users to buy in and keep coming back for more. Plus solves a lot of the qualms people have with Facebook on the privacy, data portability, account deletion, and sharing side of things, and that’s amazing. But it’s not an instant win, and they’ve got a long way to go. Making Huddles indispensible (and consider integrating them with group gTalk) would help, but I’m hoping they’ve got some other unique features up their sleeves to introduce into the Plus fold. I’m disappointed that the Slide-inside-Google-developed Pool Party and Prizes products weren’t built with Plus in mind. It might be time for the left hand to clue the right hand into what’s going on, and to get everyone on the same page.

We needed a password system that was secure but which would allow us to share client passwords across our team, while ensuring limited access within the organization, and unique, complex passwords every single time. We ended up making use of the wonderful KeePass tool, synced through Dropbox.

KeePass is a wonderful password manager (though not as much for Mac or Linux users, for reasons I’ll get to) in general. And it has some pretty great features, some unique to KeePass, others relatively standard fare:

Strong Security
Clearly, any good password manager needs to be secure itself. KeePass supports AES and TwoFish, amongst other encryption standards that are very difficult to crack. Your password database is duly encrypted thusly. Further, you can expand your security by requiring the use of a unique key file in addition to (or instead of, though this isn’t recommended) the password you use to unlock the database. This adds an additional layer of security against things like keyloggers, in that the hacker must have access to and identify the key file to use, in addition to knowing or cracking your password. (A strong password is still important, since simple passwords will fall to dictionary attacks relative quickly.) You can also use your Windows login to unlock your database, but again, this shouldn’t be your only method to unlock, and this doesn’t work when sharing a password database as we do.

KeePass also goes to some length to keep your passwords completely out of process memory. This keeps malicious software from identifying passwords in the memory stream of the process while it’s running. It also can be configured to automatically purge the computer’s clipboard after a set period of time, to prevent a user from walking up to your computer and hitting paste and hoping for the best.

Workspace Locking
Workspace locking goes hand-in-hand with strong security, itself being a subset of the program’s security. You can easily configure KeePass to automatically re-lock your database after a period of system OR KeePass inactivity, when the software is minimized, or when your workstation itself is locked. (I’ve noticed that it can sometimes pause the locking process when the database has changed, though this might have been resolved in recent updates.)

Intelligent Sync Management
KeePass surprised me with its intelligent management of file changes. If a user on my team alters the KeePass file (which is stored to a Dropbox folder we all have access to) while I’m using the file, it prompts that it can merge the changes with any changes you may have made. Unless both of us happened to be editing the same record, the merge typically works perfectly, ensuring that all of our changes are current.

Our Process
We store our KeePass file on our team’s Dropbox folder. We have a very strong password applied to that file, which we change frequently. We also require the use of a key file to unlock the database, which is NOT stored in our Dropbox. This file is distributed manually and only on a few systems. We also maintain several different databases, based on what access a user needs. Unfortunately, there isn’t a way to share a record amongst databases in order to keep it current, so this sort of functionality only goes so far, but if necessary, we’re able to quickly change all of the passwords we need to in the event of a personnel change or other problem.

Dropbox syncs the file as I described above, ensuring we’re all working off of the same copy of the file. If we wanted to, we could enforce a read-only rule that would have one member of the team making all password changes and entries, but this wouldn’t be very efficient for our team, and we trust our team members.

Potential Issues
Unfortunately, KeePass isn’t built to play terribly kindly with OS X or Linux. KeePass is kept in two development variants: 1.x and 2.x, with 1.x being Windows- and WINE-compatible, but missing some great features, and 2.x only working in Mono, to varying degrees of success (as far as those in our organization were concerned.) A solution to this is KeePassX, which works natively in OS X/Linux, but which doesn’t support the kdbx file format used by 2.x. The KeePassX developer is looking to rebuild it to support kdbx, so hopefully we’ll see that problem reconciled in time, but for now, Mono may be your best bet, if you can get it to cooperate.

Neat Bonuses
KeePass has a pretty great Android app that can work together with the Dropbox app to load your database, even if it requires both the password AND key file. I haven’t had a chance to use the iOS apps, but apparently they’re pretty nice as well. I generally use this in read-only mode exclusively, but it’s convenient nonetheless when you absolutely *need* a password. There’s also a plugin system that allows for some cool extensibility, and it’s actively being developed, so you’ll see updates hit on a regular basis. It’s also entirely free.

You can easily sort passwords into folders and sub-folders, assign icons to them, search through records, attach other encrypted data to each record, store record histories, and even have it perform a macro of keystrokes when “auto-typing” your password in. (This is useful if you need to select a database, for instance, from a dropdown. You can even have it launch a new browser tab, browse to the page in question, and go from there, though this requires a bit of configuration to get working.)

Conclusion
Overall, we’ve been very happy with KeePass. We weren’t willing to take the plunge and use an online, hosted solution to store our passwords, if we could avoid it. Because we control the encryption and access requirements, and because Dropbox is pretty secure in and of itself, I feel comfortable keeping our password database on Dropbox, encrypted with AES-256 bit on a strong password, and backed by a non-Dropboxed encryption key.

This is a somewhat unique configuration for our smaller group, and you’ll likely need to modify it accordingly, but hopefully this can give you a great starting place for good password management with your team.

KeePass Password Manager (free!)

Dropbox (free!)

How S3 Versioning Works
Versioning is a critical feature many developers had requested as data stored on S3, while maintained in triplicate across the S3 file-system automatically, is still vulnerable to sweeping delete operations by developers, errant scripts, or other causes. Moreover, developers had to manually version changing files if they wanted to preserve the ability to roll-back to an earlier revision or undo a “delete”. In any event, a lot of custom code had to be created to replicate these behaviors, and most solutions weren’t particularly graceful.

Versioning is easy to enable and brilliant for Amazon: make a simple API call to enable versioning for an entire bucket and all changes to the files within that bucket will preserve versions. Moreover, deletions of files through the typical DELETE API call will simply create a delete marker, making the file unavailable for all intents and purposes, but preserving its presence and all of its versions in the S3 filesystem, until its permanent deletion is called for. It’s brilliant for Amazon because you pay the additional storage fees for each version and for each “deleted” file that hasn’t been permanently destroyed.

This means that versioning can be easily enabled on any existing S3 implementation with out breaking compatibility with existing code. Naturally, developers will need to rewrite their delete calls to make use of the version delete options, but for an application with little-to-no deletions, this is a feature implemented with a single API call.

Amazon also introduced Multi-Factor Authentication. MFA works with security code-generating key fobs that act as a physical token one must have in order to perform an action. In this case, if you enable MFA, you need the token to log in and manage your AWS account, and you can also optionally require the token to commit a permanent deletion of a file version. For the uninitiated, it’s considered multi-factor as you need two types of authentication to login or make deletes on your account. (Your AWS username and password for account management and your AWS public/private key for API calls each make up the other half of the multi-factor equation with the MFA code.)

The S3 Trash Bin
Using MFA, it becomes possible to create a highly robust and secure safety net that prevents the wholesale deletion of an S3 account’s contents without first enforcing an additional review step. After enabling versioning and MFA-Delete mode for a bucket, a developer’s application will continue to function to the end-user as expected. This means very little rewriting of code needs to be performed to get these features up and running. A simple trash bin script could then be created which would identify all files whose current version is a delete marker, and present them to an admin. Since permanent deletions require the MFA code to be appended to the API call, only the individual with physical access to the code (which recycles every 30 seconds) would be able to commit the delete operations necessary. After reviewing the files queued for permanent deletion, they’d enter the code and the script would be sent off to the races.

Naturally, this still leaves some room for error: the script that commits the permanent deletes would need to be scrutinized to ensure that it itself is bulletproof, but beyond that, this should protect against nearly all accidental deletions, and establish a command and control hierarchy for an organization. It’s important to reduce the sheer number of individuals who have complete deletion privileges for myriad reasons, and this helps accomplish that. The MFA key fob is available for all of $13 and you’re off to the races. You simply input your serial number on the AWS site, and Amazon’s servers knows what the code it’s generated should be based on the time and a seed that’s private to them.

More on Amazon AWS Multi-Factor Authentication
S3 Versioning | Amazon Developer’s Guide

While managing your social networking presence on Twitter and Facebook, it can be difficult to quantify the impact of each medium. While I’m a huge fan of Twitter, traffic results from earlier today on one of my sites confirmed for me what may sound like common sense: Facebook fans drive far more traffic per-user than Twitter followers for a given promotional message.

I’m currently running a contest in association with T-shirt company Threadless. (It’s called Threadknits, and it’s based on knitting and crocheting their t-shirt designs into crafts.) Today, Threadless posted a message on their Facebook page and  Twitter, both with essentially the same content: an invitation to check out Threadknits. They were both posted at nearly the same time.

The numbers are what might surprise you. Threadless has almost 1,500,000 followers on Twitter, and “only” 102,000 fans on Facebook. With the posts made within an hour of each other, my traffic on the site shot up, with a couple thousand visitors hitting by day’s end. Here’s the breakdown of traffic driven from each:

 
The difference is absolutely staggering. Whereas Facebook generated an approximate 1.08% clickthrough rate, Twitter’s was closer to, well, 0%. 232 visitors came from Twitter or related sites directly and 450 additional clicks landed on the home page without a referrer, which I’m chalking up to clicks from Twitter clients. (Though, to be fair, this could easily overstate Twitter’s influence.)

On a previous contest, Threadless would tweet and I’d see between 1,000-2,000 clicks on their roughly 1.4 million followers, so while it may be a bit low today, I think the point stands: Even at its best, Twitter for large audiences generates clickthrough rates dramatically lower than Facebook. For 2,000 clicks, the rate at 1.4M followers stood at 0.14%. A quick look at the bit.ly stats on a few links from Ashton Kutcher (the #1 Twitter personality by followers) shows they typically net about 20,000-30,000 clickthroughs, on 4.3M followers, gaining a decent amount on the Threadless best-case scenario all the way up to 0.48% ~ 0.60%. (This accounts somewhat for the viral nature of Twitter as bit.ly clicks are counted for retweets as well.) Naturally, clickthrough rates will vary dramatically even amongst popular Twitter personalities for a variety of reasons. I’d like to focus more on the significant difference between the Facebook and Twitter rates I witnessed today.

There are likely several possible reasons for this:

• The audience may be slightly different—people willing to consider themselves “fans” on Facebook may be more picky with their allegiance than those willing to follow an account on Twitter.
• The phrasing and formatting of the message were slightly different—not exactly apples-to-apples as Facebook includes the logo and a text clip from the website, but I imagine this had a negligible effect.
• My mileage may vary—this is an admittedly small sample size, but I think the evidence and logic around these results indicate they’re not anomalous.
• Most importantly, Facebook lingers while Twitter sails by. Users are probably more likely to follow links during their Facebook time than from a passing Twitter notification unless it’s of particular interest to them.

That last point is particularly important. Facebook, having reconfigured their News Feed yet again, no longer sorts things there chronologically. They’ve merged the Highlights functionality back into the News Feed which they now use to keep certain posts “stickier” than others based on what they believe you might be interested in. (It manages to do a strikingly horrible job at this compared to how it used to perform, but that’s a conversation for a different post.)

With Twitter, the very nature of real-time can be summed up: blink and you miss it. While you can use a Twitter client to review tweets over the past day or two, it’s still less likely your tweet was as visible over Twitter as a post would be on Facebook’s News Feed. I’d like to see some more statistics on total audience reach. The clickthrough rate surely only tells part of the story—I’d be far more interested to learn what percentage of each audience even saw the post, and determine true clickthrough rates from that.

In the end, it’s important to consider the overall spirit of the findings here. Twitter is great for growing virally and interacting with customers, but your message on Facebook may have a far more lasting impression and generate greater returns, even if fans are more of a fight to procure. Engage on both, but recognize the differences between them and leverage each of their strengths. I’ll likely post about the best way to do that for each site in the near future.

(The above graphic represents the total clickthrough breakdown by medium assuming a linear progression of Threadless’ Facebook audience to match their Twitter audience, maintaining the same clickthrough rates from today’s traffic. It’s likely the Facebook clickthrough rate could in fact fall some as their audience grew, but it’s my belief that it would still beat Twitter, user for user.)

You can preview the book beforehand and regenerate the notebook as many times as you’d like, though for now, you can’t hand-pick tweets for the notebook. The notebook also appears to only have non-ruled pages much to my chagrin, but it sounds like TweetNotebook is planning on beefing up their offering in the near future if this takes off. For now, they have three different covers available, onto which your current avatar and cover tweet appears. Here’s mine:

Suffice to say, I’ve already bought mine. I think it’s a fun conversation piece, and I think that it’s a fun look into what was relevant to you a few days, weeks, or for some of us, even a year or two ago, in a blurb. It’s almost like thumbing through a diary in a sense, a simple snapshot at the bottom of each page that makes you pause and try to remember what context surrounded that tweet.

We’ve seen Threadless make T-shirts out of great tweets, and I think it’s no stretch to imagine other potential products that can be built out of a users’ Twitter feed. Consider a timeline, complete with tag cloud, friend diagrams, statistics, and more. Twitter lends itself to these sort of changes in medium because of their brevity and relevance—no one’s wearing a shirt with excerpts from their blog on it, but a poster that shows off my activity on Twitter is fun enough even if you’re not a raging narcissist.

For now, there’s also nothing to stop you from using someone else’s tweets, like a celebrity. (Or a friend, for a gift.) That situation may change if copyright issues arise. All told, my order was just $14.50, including shipping to Tempe, Arizona. Here’s hoping they’ll offer different sizes, bindings, and rulings in the future.

TweetNotebook | via TechCrunch

What makes Speed Tracer different?

Developers have long used Firebug to identify what AJAX requests were causing bottlenecks and to analyze responses to those requests. Firebug is an extremely powerful tool and does a serviceable job with this approach, but Speed Tracer takes things one step further, analyzing the “sluggishness” of your application by examining how busy or blocked the UI is in your browser. This can help developers analyze why their application feels slow, instead of simply focusing on network-based bottlenecks.

Speed Tracer makes use of specific, unique APIs built into Webkit for this very purpose, which gives it a unique advantage compared to other profiling tools. Instead of simply guessing and checking, developers will now have full visibility into what’s causing their applications to appear slow:

Using Speed Tracer you are able to get a better picture of where time is being spent in your application. This includes problems caused by JavaScript parsing and execution, layout, CSS style recalculation and selector matching, DOM event handling, network resource loading, timer fires, XMLHttpRequest callbacks, painting, and more.

Very cool stuff. What’s more, it’s free, open source, and available for users of Google Chrome right now. Check out their tutorial below:

Google Speed Tracer

In spite of the fact that parts of the interview sound like it was recorded at a high school basketball game, Eric provides some great insight, even suggesting at one point to “launch” an idea with just marketing materials and an ad campaign, and no backing product. Based on the clickthrough/conversion rate when customers move to subscribe or purchase your product or service, you can reasonably gauge how the idea might do.

There may be an argument to be made about potentially losing those individuals as sales, but you can ask their email, make up an excuse, or explain that things aren’t ready yet and thus limit your costs to just a simple ad campaign and marketing/informational site. If you’re presenting the idea as you will once it’s built, and no one is clicking through, it’s a good indication that you’re going to want to tweak the idea or that you’re headed down the wrong path.

The interview is split into two parts, and I’ve embedded the first part below.

What is the minimum viable product? (Part 1) | Venture Hacks
Opening Board Meetings (Part 2)

Developing a “web 2.0″ application brings with it a host of new challenges previously unfelt or easily ignored with older, single-page-load-per-action apps. The browser has evolved from a simple page renderer to an application platform that busily executes JavaScript and receives, parses, and displays loads of new data without ever leaving the page. Developers are now struck with the challenge of ensuring their applications manage memory properly and efficiently—your JavaScript can leak memory, killing the user experience on your site, but also impacting the user’s complete experience with their system across the board.

To date, it’s been a bit of a struggle to manage memory, since developers are essentially forced to rely on their operating system’s memory managers to even monitor the memory usage of their browser. Even then, testing can be frustrating, as Firefox, for instance, stores all tabs in the same process. Google Chrome is multi-threaded; each tab is its own process. Chrome also features its own built in task manager, so you can identify which page is using exactly how much memory, CPU, and bandwidth. Even at its most detailed, the stats available only show aggregate memory and virtual memory usage—these abstract figures make troubleshooting individual pieces of your code difficult to say the least.

The folks over at Mozilla’s Developer Tools Lab are looking to change that by building a memory analysis tool that helps devs understand exactly how their application is using memory, and the behavior of the cycle (garbage) collector:

We plan on the initial implementation of this tool to be simple. For memory usage, we want to introduce the ability to visualize the current set of non-collectible JavaScript objects at any point in time (i.e., the heap) and give you the ability to understand why those objects aren’t collectible (i.e., trace any object to a GC root). For the cycle collector, we want to give you a way to understand when a collection starts and when it finishes and thus understand how long it took.

Ben Galbraith and the team are soliciting help and feedback, so if this is an issue you’ve had to deal with in the past, make sure you comment.

A New Memory Tool for the Web | Ben Galbraith’s Blog via Ajaxian