EnCase 7: First Impressions

I was able to play with EnCase Version 7 for the first time this past week at CEIC (which was a great conference, btw). It will take me some time to explore v7 fully and make definite conclusions about much of its functionality. Additionally, just as restaurant reviewers don't visit a new restaurant until its had some time to find its rhythm, formally reviewing v7 seems pointless until 7.02 or 7.03. Still, I do have some immediate impressions.

What I Love

Tabs. EnCase now just has a single row of tabbed windows along the top. Bookmarks? That's a tab. Search results? That's a tab. The familiar tree-table view is then contained within the tab. I've heard some griping that the user interface has changed too much, but the tabs are a break-through and I'll tell you why: your windows stay as you left them.

In previous versions of EnCase, which type of data you were looking at (entries, records, etc.) and the way you looked at data (table, report, gallery, timeline) were global settings. So if you wanted to go from the table view in Entries to the report view in Bookmarks, you had to switch views as well as the tab. Not only is it now far easier to navigate between different windows, but also the individual display settings and contexts for those windows are maintained. I took to this change like a fish to water, and I believe daily users will find it far more effective. Kudos to GSI for rethinking one of the fundamental aspects of the EnCase look-and-feel and pulling it off splendidly.

The EnScript Class Browser. If you write EnScripts, the upgrade is clear. If you depend on EnScripts in v6, you'll need to upgrade, too, because developers are not going to want to support v6 after upgrading. V7 includes a detachable version of the EnScript Types view, so you can edit your code and have the documentation in front of you at the same time. This really should have been possible long, long ago, but I'm glad it's here now. The fact that it generates a separate class browser for your own code is a nice touch.

Search Results. I haven't played around with the search results view enough to know whether it's fully baked, but it seemed darned close. The results of conditions/filters/searches/scripts now live in a separate tab, where they persist. This is similar to bookmarks, but Search Results can contain different types of data, and I believe retain a notion of what generated them (at least if generated through a search). Additionally, like everything else in v7, Search Results are persisted to disk, supposedly allowing for smoother operation with large numbers of items (as opposed to filling up RAM and dealing with the data greedily). The distinction between Bookmarks and Search Results then becomes that Bookmarks are for items you've selected for your report.

What I don't think I'll love

Reports. The new reporting functionality is certainly better than nothing, but I was disappointed nonetheless. First, looking it over, it's clear that the reporting is built similarly to ExportClass in EnScript, which offers very limited display functionality in exchange for portability between HTML and RTF. Second, as with everything else in EnCase, the metaphor is the tree. You must organize your report into chapters, sections, subsections, and so on. Third, there is actually a new report description language built into this, for you to use for customization. There are dozens of html templating languages and technologies... so why not another one?!?! 

Here's my view: this should have had hooks into ASP.Net, and RTF should have been sacrificed on the altar of ancient technologies. I don't really like ASP.Net (or any other Microsoft web technology; give me Python and Django), but it's readily available on Windows and millions of people know it. EnCase would have been open to far more tinkering in one fell swoop. As for RTF, its primary purpose in EnCase is to let you write reports in Microsoft Word. That's useful, I know, really useful even, but not nearly as useful as having first-class HTML reporting support with the ability to save out as PDF. Plus, Microsoft Word supports copying-and-pasting from a browser into Word, so that's still available. Full-fledged HTML5 support would more than make up for the loss of RTF, an unloved also-ran in the document format wars.

What's more, reporting could have been rethought from the ground up. What about something like Evernote or Onenote or TiddlyWiki? The new reporting functionality will be useful to those who want better reporting in EnCase; the Love just isn't there, though. If I need to create great reports, I'll still export the data and use some other tool/technology.

Tags. Maybe I won't love tags. I thought it was really cool you could tag a file just by clicking in the right place in the Tags column. I need to see whether this works in Records and the other views, and what the EnScript support is like. Tags are clearly a head-nod in the direction of review platform capabilities, but review needs specialized—and simplified—controls and functionality. Additionally, it's not clear to me how tags interact with Bookmarks and whether the two should be separate. Is a tag a type of bookmark? Can bookmarks be organized by tag? Is it easy to see overviews of tags? What about multi-case tag review? Will there be any kind of automatic classification done by tag? Tags beg a lot of questions.

The Death of forall(). In EnScript in v7, iterators are the new hotness and forall() is the old and busted. Or so we are told. The problem? forall() is the lone great innovation of EnScript. Recursive descent in every other programming language is a PITA; forall() makes it a joy. What's more, the iterator design in V7, while technically solid on its own, dovetails so nicely into forall() it's a shame the two aren't integrated. There's no reason that iterators could not be used with forall(), regardless of whether the data's in memory or on disk. forall() means "for all" and the extra bit of syntactic sugar guarantees that the iteration will occur successfully without worrying about termination.

In fact, more often than not, forall() maps onto Map. The body of forall() loops are often data-parallel, and with a little bit of work in the EnScript language, forall() could have become a concurrent map(). Trivial parallel processing.

That said, if ItemIteratorClass supports virtual functions, such that we can write our own iterators, then this will be a worthy trade. With our own iterators, EnScripters can do lots of things, like define reverse iterators and create generic interfaces to common routines that use different data structures.

Wait and See

EnCase V7 is hands-down the most significant upgrade to EnCase I've witnessed. It's astonishing the amount of work that's gone into it, and I'm greatly looking forward to using it. The amount of work that went into addressing the everything-in-RAM design of prior versions of EnCase can only be described as Herculean; that GSI's developers went so far beyond such back-end changes and put large amounts of time into rethinking EnCase for the new decade is heartening.

There's a lot to learn, and it will take me some time to puzzle it all out. Conclusions are for another time. I will say that, for the first time in a long time, I'm looking forward to upgrading EnCase and exploring it. I think it will be fun.