Law Technology News - Sample Issue

ence, namely that the look and feel of the application should be identical to the live application.

Once our initial reaction of disbelief was set aside, one thing was certain: Our users’ needs presented quite a conundrum. Previously, our lawyers wanted to work with data online — that was perceived to be the superior process. Initially, we didn’t comprehend why anyone would request offline access.

GE T FIRED UP! Most of our projects present the challenge of defining business requirements and building functions, using our standard processes and tools. We know how to deal with customers who are vague; we know how to write code. But here, we faced a new internal cultural hurdle: convincing internal IT staff that this project had business value and should be tackled with the same zest as other requests.

It sounds like a no-brainer. We are paying these people, why won’t they just do as they are told? At the end of the day, they probably would. But a better approach is getting your team to truly believe in a project. This often makes the difference between an impressive product versus a mundane one that is functional but lacks the panache you get when the team is truly engaged, rather than just going through the motions.

THINKING CAPS. Our second challenge was a technical dilemma. We needed to find an appropriate technology to implement the unusual requirements — lawyers wanted to download hundreds of documents to a laptop computer, with a single user click. This was a culturally challenging issue for IT folks who pride themselves on working with a set of standard technologies and processes to develop new functions at a higher quality level and more efficiently than one might expect.

Our core technologies, those that executed calls back to an Oracle database and then delivered HTML to a user’s browser, did not allow us to easily fulfill this requirement. So we had to brainstorm to decide which of available tools would be best. We encouraged the team to consider everything including

LTN_February_2013_p45_46_Best_Practices.indd 42

the kitchen sink. We discussed open source options, new tools, and imaginative approaches. Complicating the discussion was the reality that there are many types of PCs, devices, and vendor-specific software. Then there’s the reality that it might be shortsighted to use all Microsoft tools in light of the popularity of Google and Apple devices.

We considered writing code to leverage Dropbox, which allows easier integration to each other’s network drive, but dropped that option because of the security concerns. But the fact that we even considered it is a good lesson — because when a team brainstorms, anything is fair game until you dive into evaluating your actual options.

Another approach was writing code using a client-side tool (e.g., Visual Basic) which users would run locally. But we abandoned that option before getting into the pros and cons of different programming languages, because it would require local installs and potentially require users to use certain browsers. It also might have required firewall rule changes to allow certain IT addresses to execute calls into our database. It had the potential to become a huge operational hassle to support.

Yet another tactic was to stand pat and ask users to download files one-by-one, but that wasn’t a viable option.

Ultimately, we chose Java. Lawyers are risk averse; we didn’t want them to worry about security or support, or whether a company might evaporate. So in the end, we selected Java because it is an established “brand name” and would not be perceived as too “out there” or experimental.

That selection presented us with a third challenge, more of a “soft issue” that required a rethinking of one of our core technical philosophies. Xerdict Group has always been of the mindset that any software product we deliver should be simple to use. It should not matter which browser (or version of a browser) is used; we expect our applications to work for everyone. This strategy was generally known as “build to the lowest common denominator.”

We recognized that, at times, we had passed up opportunities to perhaps build a more visually attractive product. But in our view, perhaps not unlike a conservative football coach loathe to take three points off the board when a defensive penalty is committed during a successful place kick, this tradeoff between ease of use and visual appeal was one we were willing to make.

But when we decided to use Java, and to do so for function, not aesthetics, that concept was thrown out the proverbial window. We needed to commit to a particular version of Java, a specific SSL handshake protocol, etc., in order to make the functions work. Many of us initially thought “What a nightmare!”

This was not exactly something that sat well with us from a support perspective, but in the end, as technologists, we needed to accept the fact that while standards and supportability are very important, sometimes meeting a client’s project requirements necessitates an adjustment in your organization’s usual practices.

Everybody loves a happy ending, and things worked out nicely. Our team was reminded how important it is to keep an open mind, move client needs to the forefront of any technology project, and continually reassess our own internal best practices. We delivered a useful product to our lawyers. Our new “offline briefcase” first sent users an HTML file to launch locally that simulated one of our system reports, but runs locally on the user’s browser. In the background, the single download process also copies collections of PDF or .tiff files to a local machine (usually a laptop). Embedded hyperlinks within the HTML document index allow users to quickly locate files in the document collection. This provides “offline functionality” for a document set offloaded to users with no internet connection.