Nextpoint: Taking Ajax to Court
Date : 2008 02 14 Category : Tech & Development
AjaxianI used to work in the healthcare sector, and was always amazed to see the amount of paperwork that was required. Literally paper work that is. The industry was full of drawers overflowing with paper.
I imagine that the legal profession has its fair share of this too, but one company Nextpoint, is trying to change that.
I had the opportunity to sit down with some members of the Nextpoint Lab, including Jim Halberg the Ajaxian, to get a tour and discuss their latest products. Below are a few questions about the Ajax implementation, and we finish up with a video showcasing the work.
What are the Nextpoint tools?
Nextpoint’s flagship software product, TrialManager (marketing site, brochure), brings web 2.0 to the world of litigation software. We provide a powerful and easy to use way to manage the mountain of electronic information associated with any case.
What are some of the cool Ajax features?
The site has many small ajaxy features. Things like status bars for uploads or bulk operations, submitting small bits of data that shouldn’t require traditional round-trips, or updating a small piece of the page with some results. The stuff we think Ajaxian readers would be more interested in mainly revolves around our work with images.
A real pain source for many years in trial litigation has been stamping documents. When you decide you want to use a document in court it must be stamped (i.e. “Defense Exhibit 1″) and then communicated to the opposing team of lawyers. With most products today this means, locating the document in the management software; exporting it; printing it; physically stamping it; scanning it back in locally; uploading it back into the management software; and finally transmitting that electronic copy… it’s not hard to see how this could get annoying after the 100th time you’ve had to do it this week. TrialManager provides the ability to electronically add a customized stamp - these can be resized or repositioned as desired and because we’re doing things electronically it’s much easier to do things like “stamp these thousand documents as ‘Defense Exhibits’”. Believe it or not - the server normally can get this task done a bit quicker than a guy with a rubber stamp in his hand. When the machine is done stamping - they’re already electronic copies - you’re ready to go.
Probably the flashiest use of Ajax in TrialManager is our presentation tool, “Theater”. Many of our clients are using this tool to prepare document treatments before a trial, so that they’re ready to call up at a moments notice in a pre-formatted state. It also may be used live in a courtroom to direct listeners attention to important points in a way that visually impresses. We’ll show this off in the demo video we’re going to provide.
What tools are used to create theater?
Theater is mostly a custom javascript application, using prototype and scriptaculous to simplify the Ajax communication and animation. The images are served from a Merb-based server, which uses the GD libraries to do scaling, rotating, cropping, and setting transparency on the fly. The transparency is especially important, so that HTML elements can be used as highlights behind the main image content, keeping the user interface very responsive.
What were the biggest challenges getting all of this Ajax stuff to work?
Even when using Ajax to keep the traffic between client and server light, the latency and server processing time can become quite apparent. Theater employs a few neat tricks to keep the application feeling responsive. The annotations on documents (mentioned above) are done with HTML elements, preventing the wait of a roundtrip to the server to get a new image. When loading new documents, a pre-generated medium-resolution image is loaded first, and then replaced with an exact-fit image once it’s ready, which usually takes less than a second. Similarly, when creating callouts of an image section, the main document image is resized and cropped in a DIV in the browser as a low-resolution preview until the high-resolution version is available. The same thing happens when callouts get resized to make room on-screen for more callouts. Users feel more like they’re working with an application when they can continue to work with the preview versions instead of waiting after each click.
Allowing users to resize and reposition a “stamp” on top of an image presented some challenges but most of the trouble in that interface emerged from making sure that the final position the user set with css/js was properly translated into coordinates that could be used for the actual image manipulation on the backend. Allowing a variety of stamp formats, variable amounts of text, and translating between entirely different measurement systems for fonts on the server vs. the browsers complicated things, as well as the oft-demanded rounded corners to make the stamps look “more natural”.
Originally Theater was based around a tiled-image concept, like Google Maps. The images were pre-cropped into tiles at a few different “zoom” levels, and then further zoom levels were simulated by resizing in the browser. Unfortunately, storing 200+ images for each page of each document quickly became unmanageable. In addition, many browsers use a pretty low-quality algorithm for resizing images, leaving the in-between levels looking “chunky” or “distorted.” Using the GD library, and a streamlined application server that doesn’t load the entire Rails application, we were able to overcome this issue by generating images on the fly. That reduced the number of requests made to the server and creates pristine images of just the right size.
TrialManager Demo
Below is a demo of the product. For a high quality version go here.