mjpizz

same offer, Palo Alto or SF (email in my profile). Happy to listen over coffee, a meal, or breath of fresh air on a hike.

Ah, how long ago? This kind stuff should be resolved in the latest editions. We load all those requests async now, and recently we started pre-loading a few of them to improve performance further. If you have any more details, shoot 'em over. Thanks for keeping us accountable!

Matt here: I work on a lot of our JS here at Olark - would love to dig into any loading issues you saw! We spent a lot of time ensuring that our latest stuff loads async (http://www.olark.com/spw/2011/10/lightningjs-safe-fast-and-a...) so it'd be great to ensure that we're actually succeeding there :)

Feel free to come on over and chat, or shoot an email to support[at]olark.com

It warms my heart to hear that :) Chat has built so many relationships for us too, and you just get much richer feedback (or praise!) from a "real" back-and-forth discussion with a customer.

"...[customized and unique user experience] builds the visitor’s trust and helps you gain better traction."

Ditto this. If you're not focused on personal experiences, it is hard to (1) build or sell a product that people actually want and more importantly (2) engage in meaningful relationships with customers.

I'd love to see more digging in on #2 (relationships) in particular. We came from the relationship-angle, and only recently started leveraging that with more powerful targeting (http://www.olark.com/targeting).

In my opinion, a meaningful two-way customer relationship still trumps a simple "deal popup". However, targeting is a great tool for focusing our attention and cultivating those relationships :)

For sure! I'd really like to - just didn't have time to extract it out this week :) To be useful, you will probably want the collection components too. Maybe some weekend hacking...

Definitely. Though with small modifications, you should be able to have your cake and eat it too:

http://www.olark.com/spw/2011/10/lightningjs-safe-fast-and-a...

...this technique begins downloads immediately, but still avoids blocking window.onload (just ran a brief test myself to verify this behavior). Unfortunately, it requires the third-party provider to adopt LightningJS. Here's to hoping that more providers take notice :)

I agree. LightningJS was originally written for third-party Javascript providers to improve their own embed code, though I think it would be awesome if end-users could easily take matters into their own hands. Maybe something for future development...

Good question. Since LightningJS writes the iframe with a "javascript:" URL, that iframe is really part of the same domain (and therefore same security context). To access the window on the original document, just use the "window.parent" object.

I did just now :) The concepts in Caja are really interesting, but probably outside the scope of LightningJS. We used the term "safe" as in "safe from library conflicts", though I can see how that might have unintentionally indicated that it provides a managed sandbox as well.

That said, some kind of Caja integration could be a pretty nice addition to LightningJS.

Haha, yea I remember that post. Good stuff. LightningJS is really more focused on being "safe" as in "no library conflicts", rather than sandboxing the code itself. In general, end users are copy/pasting embed code directly, so there wouldn't really be a guarantee that the third-party wrapped their resulting code in ADSafe :)

Definitely would be interesting to perhaps include some concepts from ADSafe into LightningJS though - maybe in the bootstrap component?

looks like it's fine now, but worst case you can access the cached version:

http://webcache.googleusercontent.com/search?q=cache:KBsyzf3...

Ditto to that. I play pickup rollersoccer with Michael and Martin, and during those games I have probably learned more about in-depth Javascript and Python than any fundamentals of the sport.

Saw a demo of the SDK yesterday, and all I have to say is: congrats dudes, it looks sweet. I'm not even a game programmer and I want to give it a shot :)

sounds like a good experiment - conversion improvement certainly depends on the site as well. Mind sharing your results afterwards?

For us, we also get a lot of solid suggestions and feedback from chatting with customers, so the benefits are not always solely in the conversion improvement :)

sure, as far as "job responsibilities" go, I agree that keeping the site running trumps answering support emails. That's the primary job of an engineer or ops guy/gal. But hopefully urgent events like this aren't the hour-to-hour norm for a company.

To answer the first half of your question: as an engineer myself, I am personally very invested in good customer service skills. Admittedly, doing a startup (vs. being part of a much larger organization) probably drives my customer interest quite a bit. However, even from an engineering perspective the customer interaction has definitely helped to focus my work on solving real (often recurring) customer pain points and requests, and communicating those back to the customer in a way they understand.

anybody out there with similar experiences as an engineer doing both customer support and development?

great illustrative story. But couldn't this be more a matter of learning good customer service skills, not a matter of intrinsically being "wired differently" as an engineer vs. non-engineer?

interesting point..maybe it's just that the support is best provided by the employees with the "most domain knowledge on product"? In technical startups, these employees happen to be engineers. But in other startups, take for example AirBnB, the most knowledgeable employees might be the ones who have traveled the most.

IMHO, B2C still has some applicability here. It is still beneficial to rotate support among the employees responsible for the final customer-facing product...whether that product is technical or not. Taking a support day periodically to experience your customers' problems firsthand becomes a great way to internalize their most important pain points and desires, so that you can effectively prioritize new products and feature development. Spending quality time with customers can give you a ton of insight into the "whys" and "hows" of what makes them happy :)

Olark definitely allows proactive chat :) - buddies come "online" when someone lands on your site

thanks! I think it's a lesson learned by many...

and regarding monitoring: that number is just a concurrent limit on visitors you can see in your IM buddy list at a time. We're working on better wording, so thanks for that feedback.

if you're a Javascript hacker out there and are interested in helping out: the scanner is having intermittent Firefox issues (http://github.com/mjpizz/reclaimprivacy/issues/issue/9)

for any of the Javascript/HTML/CSS, you can just diff it with the GitHub code to be certain. Also, the backend Python code cannot do anything sketchy with your Facebook data since nothing is done using Facebook's API. And you have my word that I am doing my best to deploy to AppEngine after modifications are made in GitHub. I'm even considering putting up a postcommit hook when I have time.

yea I had the same sense - thanks for that feedback. Maybe a screencast? I don't have much time to do a screencast at the moment, but if anybody makes one I will gladly post it up :)

yes, that is pretty much all of the content. Probably easiest to copy it into a variable called "htmlContentInGerman" or something, and then translate it. I'll figure out how to switch languages later on. Thanks for helping!

definitely, glad you like it.

That bug seems to be a problem periodically, looks like somebody already filed it on the issue tracker:

http://github.com/mjpizz/reclaimprivacy/issues/#issue/2

if you know any Javascript pros who could help, point them at the source code :) Hopefully get some patches tonight.

absolutely, fork it and contribute :)

http://github.com/mjpizz/reclaimprivacy

yea, I understand the concern, that is partially why I linked the source to my own github account (adds some accountability) and left everything uncompressed and commented. Unfortunately, it isn't possible to put the entire source into the bookmarklet itself due to browser length-limitations, so the remainder of the code will always need to be loaded separately.

done. I left the compressed version deployed for now, but the source code is now 100% uncompressed and commented:

http://github.com/mjpizz/reclaimprivacy/blob/master/javascri...

thanks for the feedback, esp about the PARTNER_APPS constant (now called BLOCKABLE_APPS for clarity)

thanks! The scanner definitely does not collect your data, privacy policy pasted below for clarification

------

Our privacy policy is not long:

* we never see your Facebook data

* we never share your personal information

Simple. The scanner operates entirely within your own browser.

I doubt you're the only one - thats why I made the source code completely open:

http://github.com/mjpizz/reclaimprivacy/blob/master/javascri...

The only compressed stuff is jQuery javascript, all other Javascript is uncompressed and commented. Hope that helps.

[edit: updated line number]

right now I'm not sure what the numbers will be - AppEngine's estimate is currently fluctuating a lot because of the big traffic draw.

Haven't decided about other things that might make money in the future (maybe a Diaspora node?), but I fully intend to leave the current Javascript scanning functionality open and free :)