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...
...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?
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 :)
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.