This is the first in what I hope will be a series of posts on web development at Plaxo. We all believe that delivering a rich user experience over the web is an important part of what we do here. For some, it's a great addition to the address book or calendar they already use, and for others, a purely web-based solution is becoming increasingly attractive (as is true for many applications these days). In both cases, the challenge is the same: how can you push the envelope of the web development (from a technical and a design perspective) so that users feel like they're interacting with an intuitive and respsonive app that's always available on any computer?
Luckily for all of us, the current excitement over AJAX and related technologies is resulting in a rapid expansion of what's possible (and practical) to do with a web app. We have a pretty large AJAX-focused web dev team at Plaxo, and we're learning a lot of lessons that we're eager to share with the community (stay tuned). But I wanted to start by sharing the history of our web efforts to date here, highlighting the approaches we've taken so far and the current challenges we're wrangling with. So here goes:
As you probably know, one of the benefits of using Plaxo is you can always access your data on the web using Plaxo Online. This is particularly handy when you're away from your usual computer and you need to look up a phone number or calendar event. If you're using a Plaxo toolbar with your PIM app (e.g. Outlook or Thunderbird), Plaxo keeps a (secure and private) synced copy of your data server-side that you can access using Plaxo Online. So we have a full online address book, calendar, tasks, and notes web app, most of which is AJAX-like. The cal/task/note page is almost entirely AJAX (all data dynamically loaded, little if any full page refreshes) and the contacts page (which is older) is partially-dynamic (e.g. popping up a contact to edit its details and then saving it redraws the data inline in the list, but changing views or resorting still causes a full reload).
Other AJAX pages in Plaxo Online include our eCards site (the most modern and by-the-book AJAX implementation we've done), "My Plaxo" (a dashboard of your information and recent activity, each component of which is dynamically loaded, and which lets you grant permissions to your contacts dynamically like clicking on stars in Netflix), our premium Address Book Optimizer tool (aka the "super de-deduper"), and the web version of our Update Contacts Wizard (which loads your address book and proceeds through a multi-page wizard all with JavaScript and DHTML).
I say "AJAX-like" above because we've actually been building dynamically updating web pages in Plaxo Online since early 2003, which is well before the current wave of enthusiasm and related design patterns emerged. [Inside Plaxo, we generally refer to all these techniques as "remote scripting", which I believe we picked up from reading that great, (relatively) old ADC article (this was before "AJAX" was coined).] The fact that we're often loading and displaying thousands of contacts or calendar events forced us from early on to consider alternatives to reloading everything from scratch any time the user clicked an action. There were two techniques we used early on (and still use) with good results: (1) outputing data from the CGI as JavaScript and then drawing the actual HTML client side; and (2) communicating asynchronously with the server via hidden iFrames.
The first technique is basically a clever compression technique (why download redundant HTML 1000x when you can just download the data and expand it client-side 1000x to the full HTML?) but it paved the way for building AJAX-like apps because we were already accustomed to getting JavaScript and dynamically turning it into HTML. The second technique was our pre-XHR AJAX (and is still discussed in various places as an alternative to XHR), though it has certain drawbacks, most of which have been mentioned elsewhere. Interestingly, at first we just loaded HTML pages with their own JavaScript in the iFrames and called that JavaScript onload to update the parent's state/UI. While in retrospect that isn't always as clean as just requesting data and processing it yourself with a callback, it's quite powerful because you can execute arbitrary code and that code itself can be dynamically generated using the results of whatever you just posted. Initially we tried using the DOM methods to dynamically add and update UI, but we quickly found this to be too slow (and inconsistent cross-browser) so we mainly use innerHTML now.
In recent months, with the renewed excitement around AJAX (and having hired a few more amazing web engineers), we've re-doubled our efforts in building up a solid framework for building dynamic web apps. This includes all of the fun topics discussed on Ajaxian and elsewhere: good coding style for building and maintaining complex, modular code (we use a mix of techniques from Atlas like registerNamespaces, prototype's Class.create for declaring classes); robust logging and debugging with JavaScript (venkman and MS Script Debugger are both helpful when used properly, and we're still experimenting with a variety of lighter and heavier logging systems); data exchange formats (as mentioned earlier, we used to load custom html/javascript, and we use XML in some places, but we're now moving towards JSON with a callback wrapper specified on the query sting like Yahoo! does); and so on.
Since we want Plaxo to become a platform that anyone can plug into to "Plaxo-enable" their own apps and web sites (users should be able to maintain a single up-to-date address book and calendar that follow them around everywhere they need it), we've also spent a lot of time recently playing with cross-site security issues. A good example is our Address Book Access widget, which lets you quickly access your address book from many sites around the web. We also use the widget on our own sites: for instance, when you're sending an eCard on ecards.plaxo.com, you can popup a window to select recipients from your address book (the names and e-mail addresses are then filled in for you). Since the client (eCards) is on ecards.plaxo.com and the data-source (popup) is on www.plaxo.com, they're effectively foreign sites (setting document.domain to "plaxo.com" is of little use, as it breaks XHR in Firefox, at least pre-1.5, and we wanted a client-side solution without resorting to hosted proxies to call foreign sites, not to mention that non-plaxo.com sites also need to be able to use the widget). Even more challenging, we wanted the Plaxo Online popup to be able to auto-fill the form on the eCards site, but this is not possible using any straightforward approach (especially if we want to keep the majority of the code on www.plaxo.com so we can rev it as needed and minimize the burden on the client implementor). Currently we accomplish this with a rather abstruse (but well-founded) technique that our founder Todd Masonis refers to affectionately as "the JavaScript wormhole" involving nested iframes and dynamically-generated JavaScript, the details of which I think I'll save for their own article. But we're now working on other (less scary) solutions like JSON with callbacks, which seems like a very promising way to avoid cross-site security restrictions while still keeping everything client-side. [I'll be talking more about our experiences with cross-site AJAX issues at OSCON this year, and I hope to see you there!]
Which brings me to the point of this rambling: It's been great to see how the budding community of AJAX developers appears rather eager to share tips and recipes. We'd like to share more of our (hard-learned) lessons from Plaxo too (blogs like Ajaxian seem like a good forum for that exchange). This is still an immature and quickly developing arena, and we're all in this together, so the more we can learn from each other's trial and error, the quicker we can all make progress. In particular, two areas that we think deserve more attention are cross-site communication and authentication.
The web-2.0 vision of sites consuming each other's services as mashups will only be realized if we can work out good design patterns for passing data back and forth between different domains. It's one thing to slap a Google map on your page (which is essentially a black box), but it's another thing to have a rich 2-way data-driven interaction with a foreign site (e.g. search your Plaxo address book for contacts that live in Mountain View and plot them on a map). In the latter case you can't use XHR or iframes, so you have to use something like JSON-with-callback (or proxy your RPC using Flash like Yahoo! does with its new maps). It seems like most existing web services are designed for server-side consumption, but this doesn't scale as well as a client-side solution, nor is it as flexible.
Another problem we deal with routinely at Plaxo but that hasn't really hit the AJAX community is user-authentication to access private data. Most REST-ful web services are stateless and just retrieve public data from URLs. But this doesn't work if you want to let a user sign in and access their own address book. The two main issues are (1) how/when do you make users sign in (or check that they're already signed in), and (2) how to let a 3rd-party make authenticated calls on behalf of a user (ideally without having to store the user's password). The best (and pretty much only) example we've seen of progress in this area comes from Flickr, but their solution is pretty heavy-weight--they force you to sign in on Flickr's site (no REST login) to get a token, and they force you to sign all your query params with the auth token once you have it. These are both great ideas for ensuring security, but they're cumbersome to implement (particularly in JavaScript) and they don't let 3rd-party clients have embedded signin UI, which in some cases would provide a better user experience. [Google also seems to be dabbling in this area with GData, though as of this writing it's mostly still TBD.] Just like with the cross-site issue, I'm sure that if more sites grapple publicly with authentication we'll see some promising alternatives and gradually reach a synthesis of best practices.
This turned into a longer write-up than I'd originally planned, but the summary is we're excited about Ajax and Web 2.0 at Plaxo, we've done a lot of work so far to push the envelope of what's possible, and we're looking forward to pushing it further in collaboration with the community.
-- Joseph Smarr