User Interface (UI) - It Begins

Before I talk too much about the user interface, I wanted to take a step back and talk about how I have (and will continue to) architected the processing engine.  I’ve tried to keep the engine, or Core as I like to call it, very modular.  This allows me to create new file types, filters, etc. and add them easily to the system.  However, the Core is a bunch of code that will run on an Agent machine.  Agent machines are the work horses that actually do the processing.  They will be controlled by a client application that does nothing more than dispatch work and allow the operator visibility into what is going on in the system at any given point.  Since the Agent machines are not interacted with directly, there is no reason to build a UI around Core.  In fact, Core will be running as a Windows Service on the Agent machines.  Each Agent machine will communicate with a couple of services in order to discover new work to perform as well as report statistical data – I will discuss how all this works in more detail in a later post.

This brings me to the reason for this post.  I started out building a simple UI that is responsible for the following:

• Dispatch work (ingestion, text extraction, index build, convert native to intermediate, image, etc.) to Agent machines
• Allow operator to configure “settings” for each task before submitting to Agents
• Create new projects, custodians and tasks
• Monitor the status of Agent machines
• Manage workload by moving Agents from group to group
• Create and apply filters (DeDupe, keyword, embedded items, RegEx, etc.)
• And a whole lot more 

I used the above list (and a whole lot more) as my requirements document when I started building the UI.  One of the things I had always struggled with on this project was which technology and platform should I use for the UI?  Since the UI is considered a “thin client” because all the real work is being done by the Agent machines and services, I was wide open to picking a client technology.  For example, I could run the entire system from one of the following:

• Windows Forms application – the old-school standard desktop application
• Windows WPF application – Windows Presentation Foundation.  Very similar to Forms, but newer and more agile
• Web-based application – Silverlight or HTML5 browser based application – could be run from Intranet, Extranet, or even Internet if needed
• Mobile Application – iPad, iPhone or Android based application

I quickly realized that I want to use all of the above client platforms and don’t want to be restricted if my needs change later on.  However, the thought of having to recreate the client framework every time I decided to add a new client application was a bit overwhelming. The answer was Application Programming Interface or API.  By creating a Client API, I can write all the critical client side code one time and have each client application use the API in order to “dispatch” the real work.  This way, I can focus on the look and feel of the client application instead of reinventing the wheel every time I create a new project, add a custodian, apply a filter, etc.  I can hear some of the devs out there saying, but wait, you can’t use the same API for Windows and iOS – what gives?  More on that later, but just know that part of my API is a service architecture using binary services.

Unfortunately for me, I did not figure this out quickly enough, so I had a bunch of re-work to do.  Not a big deal, but if I had a dollar for every line of code I have ever replaced with another line of code over the years, I’d be writing to you from my own private island.

I am no longer restricted on what client technology I want to use. For example, I can use WPF for the desktop application and I can create an Executive Dashboard on an iPad.  The possibilities are endless.  I’ve decided to create my primary UI using WPF for this project.  Creating a UI that requires an API is the right choice, but it will slow down the development a bit.  It complicates the design slightly and for every non-UI function the client needs to perform, I have to write and interface it with the matching method in the API – the good news is that once I get the first client completed, the second client will go much quicker sine the API is already done!

The WPF UI is coming along pretty nicely.  I’m using very rich UI controls to keep the look and feel very fresh and intuitive.  I’m no artist, but I’m pretty good at creating an intuitive UI that you don’t need to go and get certified to use (not mentioning any names).

More to come…