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

The problem with following these people is that, while they keep things interesting, they sometimes drone out the people I care most about.

Enter Filttr. Filttr is a clever tool that grabs your twitter timeline (as your home page is called) and applies some algorithmic magic (the best sort of magic, we always say) to show you tweets it thinks you’ll be more interested in.

Filttr offers you the ability to add whitelist and blacklist keywords, which I don’t find particularly useful, since “blacklisting” any particular word or phrase is a bit strange to me (since, without context, how do you know if you’re really not interested, unless you just want to “mute” a particular topic for a bit) but it also offers the ability to rank individuals. So I’ve gone ahead and put a few of my friends on “less” and a couple others on “more” and Filtrr’s timeline is showing me a compressed version of the regular timeline, without all the crap. You can still view hidden tweets, but they’re compressed and cleaned up.

I’ve already suggested that they do a better job aggregating filtered tweets, since they still take up one “row” worth of space, but they’re on the right track here. Further, Filttr threads replies when a friend is replying to someone who had tweeted at them. This is a REALLY nice feature because it gives you context right there. I don’t particularly mind following through an interesting looking reply to see the other side of a conversation, but this is just a nice feature.

You can also establish groups of friends, much like you can do on Facebook, to only see a timeline of a certain subset of the users you follow. This is another useful feature that I’m glad someone else has bolted on to Twitter.

Filttr also offers a free Adobe AIR application to show the feed on your desktop. The app is new and a bit buggy: Scrolling is slow and can spike CPU usage, the app can’t be properly minimized to the system tray, and there are absolutely no options which they say was related to their effort to keep things as lightweight as possible. The app is lightweight, but I’d like to be able to configure a few things, and the lack of even a minimize button is a little strange to me.

When someone builds what is, to me, such an obvious feature for Twitter, it always piques my interest. There’s essentially nothing stopping Twitter from offering the exact same featureset. In fact, I’d expect them to add at least a few of these features. This brings about the argument of the platform versus the provider—many people wondered what would happen with Facebook’s third-party developers, since Facebook’s applications sometimes had direct competition in third-party apps. Thus far, they’ve been able to co-exist, but a third-party app will always be at a disadvantage if the platform decides to start delivering the same applications that the provider is offering. I’ll save the rest of my arguments on that for another post.

For now, try Filttr. It requires you to change the way you do things a bit, but there are some compelling reasons to give it a shot. What do you think?

Filttr (Blog Post) via Techcrunch

Lunascape presents an interesting product, though one that’s only in the Alpha stage, so I’m sure we’ll be seeing a lot of things evolve from them. As a developer, I have Firefox, Internet Explorer and Google Chrome all installed and at the ready. It’s pretty simple, though a bit annoying, to boot up IE to make sure a page renders properly, even though we develop under Firefox.  (There are FF extensions that make this a simple right-click affair, however.) Lunascape simplifies the process a bit by allowing you to switch a tab’s rendering engine just with a right-click. And it works, for sure.

But I begin to question the utility of a browser that lets me switch rendering engines, but provides me with very few debugging tools or console access. We develop under Firefox because of things like the Web Developer extension and Firebug. These superb debugging tools let us delve into the DOM and help us identify our many AJAX transgressions. Without these tools, though, the workflow isn’t improved enough to justify a switch from just running the browsers separately.

Now, Lunascape currently supports IE extensions, so perhaps Firefox extension support is on the horizon… but this seems like something that could be very difficult to accomplish, given that XUL (which powers Firefox and the window chrome surrounding it) is a part of Gecko that exists a bit existentially to the site being rendered: Though, if Lunascape itself is XUL-powered, then that would help considerably.

Even still, the appeal just isn’t there for me. Lunascape clearly is betting on its three-trick-pony concept, but that only appeals to developers who know what a rendering engine is. Firefox is a considerably better browsing option for regular end users, so they’re left needing to improve the value proposition for developers and to give us a reason to switch. And they haven’t done that yet. One way they could start is by offering advanced debugging tools, better if they’re rendering engine-specific. Another might be to allow for regression testing in IE: Allowing us to render in older IE engines, like how IETester works.

For now, I plan on leaving this in the Alpha bin it came in and working with FF 3, Chrome/Safari and IE, side-by-side.

See also: TechCrunch & Lifehacker‘s coverage. (The latter, whose screenshot we borrowed.)

Obviously a free, full-featured, shopping cart and e-commerce solution is great concept. I mean, really, one can’t bitch too much about something that is free (notwithstanding, say, venereal diseases or OScommerce…) Magento’s feature list is comprehensive: coupons, specials, multiple checkout and shipping options, tiered pricing, layered navigation, etc. Unfortunately, when you are neck-deep into anything, you get a better sense of the minor and major flaws lurking just under the rosy surface. Take a look after the jump at some of its more vexing problems.

1. By far, the most annoying thing about Magento is its complexity. If the default installation suits your needs, then Magento is perfect. However, if you need to modify anything (and I mean pretty well anything) like adding new functionality (modules), changing the layout, or creating a custom results (any type of result: users, products, etc) page, then you can expect to spend many, many, many hours digging through the code and fighting the schema. The XML layout method is confusing as hell and custom module creation is, well, good luck.
2. The EAV data model is great. It’s fast and makes sense when you have many, many possible attributes to assign to a specific object. However, trying to make database-level changes to all or a subset of products is quite a pain in the ass. This is not so much a knock on Magento since the model does make sense given the options to add arbitrary attributes and such. I suppose this goes back to Magento’s lack of a well-documented database schema (or decent documentation in general).
3. Performance is horrible. Changing a single attribute to a product in the backend takes an average of about a minute to perform, on an otherwise responsive server. AJAX or not, that is entirely unacceptable. The frontend, despite being cached, is not all that much better. I mean, yeah, you’re talking about a lot of features here but at the expense of performance to an annoying degree. The latest version is supposed to address certain performance issues, so we’ll keep you posted if that situation changes.
4. Why slack on viewing images? When viewing a product with multiple images, why the hell does the image open a new popup window? They’ve built an entire application utilizing AJAX but they can’t implement a simple image swapping feature for product details?
5. While on the topic of images, since Magento’s product entry method requires that you enter each product type as a different simple product, why doesn’t the parent configurable product inherit its child images? For instance, if you had a shirt in three different colors, you might think that by entering the red shirt image in the red shirt simple product that it would automatically show when viewing the parent configurable product. NO! Instead, you have to add all three color shirt images into the parent configurable product. Seems like a serious break of the inventory/product entry methodology that Magento flaunts.

Still, aside from a seriously steep learning curve, lack of meaningful image features, and poor performance, Magento is a very decent product. Again, for free, you really can’t beat it. And it’s leaps and bounds ahead of OScommerce. We’ve just found it to be a very heavy solution to a complex problem. That’s not always a bad thing, but certain problems can make working with it to customize it rather a nightmare.

Enter Clicky. Clicky is an amazing tool with a clean, simple interface that lets us track our users in real-time, including their location, browser resolution, OS and all the other goodies you’d expect. It’s also free, though they have a premium option for managing multiple sites and with a few additional features tacked on.

The interface is clean, easy to use and intuitive. The graphs are nice and Flashy, just like GA’s but everything just comes together:

But they’ve tacked on some additional great features that were sorely lacking in Google Analytics and other packages we looked at. Here’s a quick look at a few of them:

Visitor detail includes where they’re coming from, their IP address, (or their host/organization name, if it can be resolved) and all of their progress on the site:

It features incredibly easy filtering and custom user tracking, so you can easily and automatically exclude yourself or organization from your own hit tracking data. (GA has some filters like this, but they can be frustrating to update and aren’t cookie based, so if your IP changes, you have to remember to change them.)

Clicky also features the stalker-ish and really cool Spy feature. It’s a live view of the traffic on your site, so you can see visitors as they appear, where they browse to and what links they click. This is a premium feature, but Clicky is pretty damn affordable, so we picked up a year-long premium account for all of $40. The only downside to the spy is that it’s consummately boring when no one’s visiting your site, and a little depressing.

There are about a dozen other features that are just done right. They include Google Maps integration when geolocating IP addresses, they intelligently group visitors together to give an accurate “uniques” count, they feature an impressive API and bunches of useful widgets for publishing stats info and they intelligently parse out which search terms are driving you traffic. Some of those aren’t unique to Clicky, of course, but the thoughtfulness prescribed to each of the components and the “what if” approach towards building software with so many features (and such a small dev team) really reflects positively on them and their product.

There are a few issues we’ve noticed with Clicky: Identical pages sometimes are tracked as separate pages, some search terms can screw up the reporting and some scalability concerns have come into play with how they architected the site early on. But they’re very transparent and work with the community to build a pretty amazing stats tracking tool that we considered good enough to pay for.

Check it out, as they’re offering a free 30 day trial with their pro features:

Get Clicky | Web Analytics 2.0

This book attempts to fill that gap by walking us through the delightful and fruitful garden known as the software development lifecycle (SDLC). It provides a brief overview of each phase of development, ranging from pre-project team selection and hiring all the way through deployment and support. In each section, it outlines common pitfalls, ways to get around them and tools others use to keep things running smoothly.

Think of this book as an experienced developer watching your team in action through your whole process, and at the end, sitting you down and saying, “Look, you suck at this. You’re making every beginner-mistake in the book, so I’m going to break it down for you. This is the way you develop software, and here’s why.” This book is not about how to write code at an enterprise level (cf. Fowler, or Zandstra for a gentler intro), nor does it cover any one facet of the lifecycle in particular detail, rather it is aimed at getting you up-to-speed on the entire cycle and pointing you towards other resources to research further.

Following a couple of worthless chapters that we’ll mention towards the end of this review, the book is roughly broken up into chapters that follow each phase of the SDLC. This breadth is at-once the book’s strongest point and its weakest. Both Bob and I observed that certain chapters seemed rather weak, but it became clear to us that the subjects we were most familiar with were also the ones that the book seemed weakest on. It isn’t that these chapters are necessarily flawed, but rather that it is simply impossible to do any one phase justice in such a small amount of space (and the book is quite pithy, at a mere 175 275 pages. [author's note: apparently the php|architect website mistakenly lists the book as 175 pages. Shame on me for not verifying]) Nevertheless, there were so many gaping holes in our process (and must be in yours, as well, if you’re even considering this book still), that the payoff of those seemingly weaker chapters was the incredible wealth of introduction contained in one book. I’ll now outline a few of the chapters I found to be most useful, so that you can get an idea of what you’re in for.

The chapter covering planning was a gem for us. Software development is a notoriously over-time and over-budget undertaking and this book identifies a few reasons why. Reading this section, there were several “mmhmm” moments, where I was clearly able to identify instances where our team had made the exact mistake described. Jansch points out, for example, that software is never done. Give a developer 12 hours to complete a task, and he’ll complete it in 12. It could have been done in 8, but given the 4 extra hours, the developer took some time to create some better icons, add a bit of AJAX, and get everything just so. This tendency means that when we calculate the time required to do a task, adding a margin of time for safety, we are actually locking ourselves in to taking that full amount of time to complete the task. As a remedy, Jansch suggests that we instead quote a task according to the amount of time we think it should be done in. Then, a margin is added to the whole project, so that no individual task is simply allowed to go over. I have no idea if this actually works, but I suspect it addresses at least part of the problem.

The next chapter I was really impressed by was the chapter on tools. In this, Jansch identifies some tools developers can (and should!) use to streamline development and testing. The first subject this chapter addresses is the great IDE vs. Editor debate. Personally, I’ve been using IDEs to develop code from the beginning, but some developers need more convincing and Jansch makes a good argument. More interesting to me was the section on debugging. In the past, I did a lot of desktop application development, and one thing that I’ve always missed on the web-app side was the ability to do things like set watches and breakpoints in code. I was aware of Zend’s offerings in this arena, but had never looked into it any further than Zend Platform’s hefty price tag. As it turns out, there are numerous other offerings in this area.

The QA chapter was another that was useful to me. It discusses both functional and performance testing. We have been using unit testing here for a while, but performance testing was something that we’d only begun to need to consider with some of our more recent projects. In his section covering the topic, Jansch discusses the use of tools such as Apache Bench and Apache Flood, both of which allow you to run automated performance tests against your site. This kind of automation, as Jansch points out, is key in watching for serious performance problems, as well as regression introduced by new features.

One last tool mentioned in the QA chapter that I hadn’t heard of is Selenium (Tech Talk link). Selenium allows you to record and playback automated test cases that can check such things as whether the pages contains key elements (submit buttons, crucial bits of text), or whether the application is flowing correctly. This sounds very compelling to me (though I haven’t checked it out yet), as it addresses one of the key issues we’d been discussing with test-driven development around the office. Namely, unit tests are great for testing a specific very fine-grained aspect of the code, but how do you test the application as a whole? Anyway, that is the subject of a future blog post, no doubt.

Though this book is overall a strong read and a good buy for a team looking to streamline their processes and quit making the same mistakes over and over again, it does have its weaknesses. In this book at least, Jansch is at his best when talking about tools and process, rather than code. While object-oriented development is an important methodology in enterprise development, I don’t feel that the brief section covering the topic provides a very effective introduction. In my mind, Jansch spends a little bit too much time showing code and discussing implementation details (some specific to PHP), and not enough time discussing the advantages of OO on a conceptual level.

Similarly, the opening two chapters discussing the history of PHP, the LAMP stack, and PHP’s growing prominence in enterprise development were a bit too long for my tastes. The first chapter contained a lot of information that, while interesting, is readily available on the internet and hardly relevant to enterprise-level software development. The second chapter, on the other hand, felt like a combination of justification for the book, and sales pitch. Certainly I agree with Jansch’s stance on some of the weaknesses and strengths of PHP, but to my mind, a reader of this book is already aware enough of them to know he needs the book. I don’t necessarily feel that these sections should be removed altogether, but I did feel that in a book as short as this, they took up a bit more space than needed.

To be clear, these are minor shortcomings in an otherwise useful book. The great thing about a book like this is that it puts a lot of ideas into readers’ heads, which they can go on to research further. Just in the process of writing this post, I’ve linked to several projects that themselves would be worthy of their own post, and I even left out a couple of chapters that I liked. In short, I would recommend this book for any team looking for a broad reference they can use to enhance their development process.

At first glance of the index, I got warm fuzzies all over. File hierarchy layout, EAV schema and custom module development…who wouldn’t feel a little happy? However, I’m not really the type of person to give accolades unless something is absolutely stellar. As such, this post will primarily be about the shortcomings of the book.

As developers, one of the most important things we’re interested in with a new software package is how we can modify, hack and expand it to suit our needs. Let me be the first to tell you, the Magento devs did not have this in mind when building their code base. While Kimsal devotes four chapters to module development, at the end of it all, I still didn’t feel like I had the foundation necessary to construct a robust expansion module from scratch. Kimsal does go into detail about the files and contents you’ll need to fit within the Magento/Zend model, but his examples seem to only expand or override functionality already present in the Magento core modules, rather than creating something completely from scratch. About the closest he comes to a completely custom module is the “Points and Rewards Module” chapter. However, the construction of a completely custom module seems so complex that Kimsal either does not include all the finer nuances or simply cannot coherently describe its creation—a sign that does not particularly bode well.

Reading the book also gave me the distinct impression that an actual editor was somehow left out of the loop as the book was rife with grammar and spelling errors. Another annoying attribute is that code continually runs from page to page with no clear delineation or separation. Code and list segments span multiple page breaks, something that of course sometimes cannot be helped, but when you have 11 lines of code on one page with the remaining “</div>” as the only line of code on the next…it gets a little annoying (page 126-127 if you’re interested).

Now, I understand that Magento is very new (as of this post, I think Mr. Kimsal’s book is the only one available [and we have the pre-order PDF of the book, still waiting on the actual book to arrive—Ed.]), but I think that the first book in any series should try to include some sort of reference for at least the most important classes, methods and in the case of Magento, obscure XML tags and attributes. For instance, in the chapter about templating and layouts, Kimsal gives brief descriptions about what the tag names are but lacks any meaningful detail about how to use them and how they interact with other tags (see my previous blog about examples in documentation).

Technical books typically strive to factually explain the topics they cover. Something I found a little interesting was that Kimsal gave negative conjecture at random places in regard to how Magento does certain tasks. I personally find it amusing but some people may not. However, if you’re going to rag on how the subject of your book does things, consider suggesting a better alternative or publish some code to correct the problem. Just a thought.

Finally, you know you might be in trouble when the very last question in the book’s final chapter “Quick Answers to Common Questions,” states, “I give up! Magento is too confusing.” And what pray tell, be Kimsal’s response? ”I hear you…”

A bit half-baked but that could be a condition of what happens when you work to be first-to-market with resource material and it doesn’t help that Magento is no small, simple beast itself. We’ll take a look at any other books that come along and let you know how they stack up.