This morning we have designed and coded the basic framework for our new Dynamic Data Inclusion feature that's going to be the foundation for shifting LDMax from process serving software into field service software - and our customers won't even know it happened.
It's like sticking a 302 in your Pinto. It still looks exactly the same until you hit the gas.
See, in your custom job screens, some of you are going to need alot of extra fields. Ever seen a HUD inspection report? Man, its got so many fields and checkboxes on it and if you want LD to make the sheet, you'd have to have like 100 extra fields in your database (we actually wrote a custom program to do this a long time ago - along with a custom program for field calls).
So, if you wanted a program that did field calls AND HUD reports AND process serving AND tenant inspections AND private investigations, your database design would be all over the place (it was) and it would be hard, programatically, to make any changes to it or homogenize it for other agencies that might need other stuff as well.
So.. we needed to come up with a way where the data design on the back end could be fluid. You define a field in your custom job screen design and the program needs to be able to use that field on the back-end seamlessly and automatically. Each customer needs the ability to use the same codebase (your LD) to handle many different fields and designs for the case and job screens. Something like this can make us dial the program in so close to an agency's flow that it fits tighter than an asian condom. The trick is to do this in such a way that 200 of you never notice a thing so that your existing operations are unaffected.
This is the holy grail of programming. Some languages do this for you (Ruby) but, they are modifying the database schema as they go along and when you have many people using the same codebase, that doesn't work out so well. Schemas diminish your flexibility. You can make your database a monster that way and it can't perform well in all situations. Besides, things are going schema-less with key/value stores anyway. One day I want to shift all of you to a massive cluster of computers that all perform queries in parallel. Before that happens, though -- we can use the existing MySQL to do the same thing. :)
That's very valuable to us and gives you an operational edge on your competitors that the other guy just isn't going to have for awhile. One example I'll give you is... California process serving. Some of the proofs have slots for Plaintiff Address. Now, I can add that field to everyone's Case table and make the database design bigger or... I can use the new dynamic data inclusion to handle it. Then, nobody's database design gets changed but customers who need that information can have it. Another good example is private investigations. Many of you are investigators too but... ALL of you do it differently and have different needs for those type of screens. Your program needs to fit your flow.
You shouldn't have to take your whole business and shoe-horn it into the way your software works. LD has always been able to be dialed-in pretty tight anyway. This is just the next level.
I'll be letting you know when we have it working for a customer and then we can all take it for a ride.
Very excited here, this new way of doing the custom screens is a game-changer and is just the start for 2016. Remember, there's still a whole lot of really cool security, authentication and encryption stuff coming. :)