I'm not talking about the kind that you lace up! In the technical world strings represent characters of text. In the legal world, we manipulate strings extensively. When we write motions, client letters, notices, etc. we are basically manipulating strings. It is for this reason that string manipulation is essential to a real elawyering application.

Personalization

When it comes to personalization in elawyering applications I am an extremist. In order to implement extreme personalization, you have to know how to manipulate strings in a way that delivers a dynamic and personal experience. For example, if you were sitting there and reading questions to your clients from a standard intake form, you would try to personalize the experience. Instead of asking "How long has the child lived in the State of Washington?", you would ask "How long has Adam lived in the State of Washington. See how easily manipulating strings can make a service more personal?

Dynamic Presentation

Dynamic presentation is tightly coupled with extreme personalization. if we manipulate strings in the proper way we can account for differences in presentation based on the facts of a particular client's situation. For instance, if we asked the question above for more than one child, how would we account for the extra punctuation and length of the string? This is where dynamic presentation comes in. In an elawyering application, I might determine the number of children and modify the string accordingly.

Beautiful Integration

When done correctly, proper string manipulation in elawyering applications can make a world of difference. As a legal professional and a programmer, I see the powerful possibilities of dynamic string manipulation. Of course we programmers must unleash our full arsenal in order to make a full-fledged elawyering application work. This requires artful integration with strong attention to intelligent personalization and tight user interface design.

If you've been following the development of ABIEE™, you know that I am in the client use development phase. Due to intellectual property concerns, I cannot disclose specific information relating to the design of the database. Generally speaking, the database design portion of an elawyering application should be given a tremendous amount of attention. Any elawyering application worth using is heavily databse dependent. The more features in play, the more complex the database will be. For ABIEE™, I am breaking down the database design process into two separate parts. One part is for the client/user portion of the application and one part is for the bankruptcy professional's portion of the application.

Data Integrity

The databse should be designed to ensure optimal data integrity and performance. Elawyering application databases are especially tricky because of the need to integrate document generation and processing requirements into the database.

Utility Database

One more complexity involved in an elawyering application's internal structure as it relates to database design, is the need for a "utility database" section. This is the term I use to refer to attributes that will not necessarily be a part of the central database. Some examples are profile information, account information, some personalization information, etc.

What follows is the client registration use case for the ABIEE™ (Alliance of Bankruptcy Information and Expert Exchange). If you were following the previous related post, you will see that the client registration use case specifically builds upon the global client use case. Before the client can access any major features of the application, he/she must register an account. Although it is possible to allow anonymous browsing and functionality, up front registration makes the most sense.

The Registration Process Overview

Basically, a client will complete a brief and painless registration form. When they click submit, pertinent data will be entered into a database table. Next, the client and the site administrator will receive notification of the event.

Developer's Perspective

The programming portion of the registration use case is fairly straight forward. Once the client enters information on the form and clicks submit, logic will be written to add that information to a database table. Additional code will be written to confirm the registration with the client. Finally, code will be written to notify the site administrator that a new user has in fact registered an account.

Designer's Perspective

The eventual graphic design of this input form will reflect the overall look and feel of the application (the graphic design will come much later in the process). The focus should be on modern design techniques with an emphasis on usability.

Marketing Perspective

At this point, it is important to realize that the client has an open mind and may be interested in additional services/offers. One thing that I will add here is an opportunity to opt-in to marketing  communications such as newsletters and special offers. One more marketing feature that I will add here is an opt-in for a printed information packet of some kind.

Conclusion

Once the client is registered we will have non personally-identifying identity parameters to use for future programming, design, and marketing implementations.

Client_Reg_UseCase.pdf (143.40 kb)

Here is a very clean elawyering application design which reflects the ideas of open, optimized landing pages for elawyering applications. The .pdf version is below and best viewed at approximately 63%.

ElawyeringAppDesign_3.pdf (1.54 mb)