Update News for May 2012
Here is a quick run-down on what you will find in this bulletin:
-
-
Guaranteed Issue Quotes
-
Canadian term4sale.ca Updated
-
Introducing New User Interface To Data Entry Tool
-
First Small Step Completed
In Data Entry Conversion
-
These topics will be dealt with in more detail throughout this bulletin.
Hi I was wondering if there is a quote system for Guaranteed Issue Products like The Edge, IA Perspective & Alternative, Assumption Golden Protection, etc. I receive many calls for such coverage and really need that ability too.
The following was my reply:
Not at this time. My fear is that they will be considered "life insurance", like the other life insurance in our system, and that people will purchase them not understanding what they are buying. What if we offered them through a web service ONLY. A site that quotes these products ONLY. Would that be useful to you?
The subscriber thought that would be a good idea.
After further thought and reflection we moved forward and registered the domain names:
and
gi4sale.ca
Given that the site will be a free service on the web, and that consumers will be able to access them, there will need to be ample warnings about the serious problems/restrictions with these products. The GI products quoted by the site will be those that do not provide full life insurance coverage for the first couple of years.
With that in mind, we will strongly urge consumers to avoid these products unless all reasonable attempts have been made to obtain a normally underwritten product. Clearly a GI product is a last ditch way to obtain some life insurance, when nothing else is available.
If you have a favorite product (or products) that you would like to have quoted on the site, please send the rate books (PDF or excel files) to service@compulife.com and we will see they are added. As always, if you are the first in with a particular rate book, then you will earn a 10% coupon toward your next annual subscription to Compulife’s windows program.
As this will be a free service and available to consumers, we will post the same agent listings at the GI4Sale site as we do for the term4sale site. If you are listed as an agent at term4sale.com, you will be listed as an agent at gi4sale.com.
The good news with this project is that it will be a web based solution (ONLY) and will take no time away from our programming efforts to overhaul the data structure. We hope to have a preliminary version of the software on the web by the end of May.
It was important to finish that work before moving forward with the new gi4sale sites. While they will look similar, there will be differences.
In conjunction with changes to term4sale, we have also made a modification to our promotional web site: www.4biggestmistakes.com This is the site that we advertise using google and yahoo adwords, and which links to term4sale.
At first glance the change may not seem like much, but we noticed a definite increase in agent email requests after the change. See if you can figure it out. I will give a 10% coupon to the first subscriber who emails and tells us what change was made. Send your email to service@compulife.com.
This month, before beginning step two in our data conversion process (see last month’s discussion which follows) we took some time out to review some of the new user interface tools that have been more recently introduced into the market. We felt it was important, before investing a lot of time and effort into this big new project, to see what other products language vendors are offering for creating user interfaces.
Our basic quote engine is written in C++, which is a very common, very power development tool for computer software. All our various and current product offerings, Windows, Linux, Windows Server, Palm and Windows Mobile, rely upon the same fundamental C++ language code in order to do the lookups and calculations in our software. C++ language compilers, for different operating system, are widespread. The C++ language is the most generic way for us to provide software for these different hardware systems.
The C++ part of the software is what we refer to as the Compulife “engine”. When someone purchases our internet “engine” for use on either a Linux or Windows based server, they are for the most part getting the engine. The only thing that is added and compiled into the code is a thin layer of additional code that lets it interface with the html pages that talk to it. The engine can be called from a web based user interface (html) which passes to the engine the client variables. The engine then returns the results formatted by another user interface file called the template (more html).
The user interface that talks to the internet engine is written in html code, which is the same code that is displaying this bulletin. That code can either be plain and simple, or it can be a lot more exotic, all determined by the developer who is designing and manipulating the pages that talk to the internet engine. We developed our internet engine so that the most basic html code will work. While there is more exotic web development software than html, such software all respects and can talk in html, which makes our internet software super flexible and something that will work with just about anything a web developer wants to program with.
When we develop our own applications, that rely upon the internet engine, such as Term4Sale or the mobile or web quote options that we provide, the interface is always html based. For more sophisticated work we use PHP which is a more interactive, stepped up version of html. We keep it as simple as we can to ensure that the web based software will work well on all browsers in the market.
The problem with folks who develop with more exotic web based tools, and who create much more complicated web pages, is that all browsers may not run the pages the same way, or in some cases may not run them properly. The simpler the code, the better your chance of not having problems with different browers.
The html code is essentially what is used to create the “user interface”, the part the user sees and works with. When someone clicks a “submit” or “compare now” button, the code calls our interet engine and passes to the engine the information it needs to calculate results. None of that is visible to the user, and because it is not visible, the user interface is external to our software. The part you don’t see is what we call the engine.
All that to say that we are completely devoted to doing our engine work in C++; that is not changing. What we have been studying are tools for creating user interfaces.
In that regard the Compulife Windows software actually is a combination of both the engine and the user interface which is also developed by us. The Windows based user interface is compiled and combined with the engine into a single program file. That program file (GOWIN.EXE) will only work on the computer operating system that it was built for, in this case Windows XP or a newer version of Windows such as Windows 7. That same software cannot and will not work on another operating system, such as Apple or Linux. The only exception is for the user of an Apple or Linux computer who has installed a Windows run-time emulator that permits Windows software to be run on that computer.
When we build the Palm and Windows Mobile versions of our software, we had to stop and create user interfaces for those operating systems. Those programs do not work on anything but those operating systems and devices that use those operating systems. Of course no new devices being sold in the market use those operating systems, making that software defunct. We still support it (for now) because some customers still have those devices, but we will not be making any changes or improvements to that software.
And while Palm and Windows Mobile operating systems still exist in the market for new devices, those new devices are using new operating systems that do not work with the old software.
Which brings us to Apple. If we wanted to program for an Apple, the problem is that we would have to develop a completely different user interface than the one that we now use for Windows. But if we did all that work, and got a product for Apple, we would be in trouble is Apple changed their operating system and it no longer ran the old program. We would have some customers who have the old Apple computers, still wanting to run that software, and other customers wanting new software for the new Apple computers. And Apple, unlike Windows, doesn’t feel it needs to have old software run on their new computers.
The only alternative to having to do all that, would be to use a language tool for the user interface that could take the same user interface code that we wrote for Windows, and allow it to be re-compiled for an Apple. Our current tools do not allow that.
So the question we have asked ourselves is whether or not some other language vendor has created such a development tool that we could upgrade to. The answer is that there are several which purport to offer such tools. The next question is how good are those tools and how well do they work. Of course the sales folks will all say that their tools are great and work perfectly, but you really don’t know until you actually spend some time messing with them and testing to see if they perform according to advertising. From our experience few ever live up to the advertising promises which is not surprising. Why do people buy Consumer Reports magazine? They buy it to find out which coffee makers actually make good coffee. Unfortunately Consumer Reports is not reviewing language tools.
And so that is what we spent some time doing in March. Our conclusion is that none of the most promising tools really do a better job than those that we are currently using. While some show promise for the future, at this point we have decided to stick with what we have.
In Data Entry Conversion
So why bother you with any this? The reason is that we don’t want you to think that we have slipped into a coma or gone on an extended vacation. We remain quite busy advancing and improving the software. The problem is that the work that we are doing now is not something that you will see any benefits from for a longer time, perhaps a year. So for those who are curious, we will try to let you know how it’s going. For those who don’t care; please carry on. If we do make a change to the software you use, it will be at the front of future bulletins.
In that regard the first small step of the data entry overhaul has been completed. We have taken our old DOS rate entry tool, and have now re-compiled it and have it running in a Windows 32 / Windows 64 environment.
That’s right, I said our old “DOS” rate entry tool.
As I have tried to explain previously, most of our work over the past 15 years has been to enhance and modernize the quotation program(s) that our subscribers use. The main program is Windows based (GOWIN.EXE) and already runs quite nicely on Windows 32 (Windows XP and Windows 7) and Windows 64 systems (Windows 7 only). We also support Windows and Linux servers for the Internet version of Compulife.
By contrast, the tools that we ourselves use to enter and maintain the data files have largely remain DOS based. There was no pressing need to upgrade those because they have been working quite well. The old rule, “If it isn’t broke don’t fix it”, applied quite nicely. However, it only makes sense to upgrade those old data entry tools at the same time as we are doing a major overhaul to the data structure. The overhaul necessitates major changes to the software, and requiring our programmer to make those changes using old development systems and tools is just the wrong way to go. No one wants to go back to a manual tools after getting used to working with power tools.
So the first objective was to get those old data entry programs re-compiled and operating under Windows 32 so that they will run on both Windows 32 and Windows 64. In that regard our old DOS software will not run in Windows 64, and because our programmer’s development system works best in Windows 64, we needed to do an intermediate step. Conversely, the new Windows 32 version of the DOS software, which now runs in Windows 64, will not run in DOS. Therefore, the change that we are making means the new software will require us to say goodbye to running anything on a DOS based system.
No doubt you will think “it’s about time” but for those who are familiar with the historical versions of Compulife, we still need/want to have the ability to work and function in DOS.
The reason is that all our oldest historical programs are DOS based. If we were to move everything to Windows 64 systems internally, we would not be able to do anything with those historical files.
You have the same problem if you were to order our historical CD for $99, which gives you monthly copies of Compulife back to the early 1990’s. If you are running Windows 64, you cannot use/run those old DOS programs on a Windows 64 machine. Why? Because Windows 64 will not run DOS software which is why I personally still run Windows 32. Windows 64 can run Windows 32 software, but Windows 64 software will not run on a Windows 32 computer.
Our programmer runs Windows 64 because the latest development tools work better in that environment. And there is no doubt that all equipment will someday be Windows 64, so the time is right to move our data entry software to Windows 32, so that it will work in Windows 64. It is also easy to move Windows 32 software, to Windows 64 software, if or when that day ever comes.
Knowing that all this was coming, I had personally moved from a DOS based machine for basic data entry, to a Windows based machine, over 2 years ago. That Windows machine is a Windows 32 machine which happily runs the old DOS software. That system will remain Windows 32 until it has to be pried it from my cold dead fingers. That will let me work and operate in both the old and new world. Once everything is Windows 64, the old DOS stuff will be dead. I will have to keep some old computers around to run it.
On another side note, you should also know that our data entry system is isolated from the web. That is to ensure that nothing can get at it. Apart from protecting ourselves from theft of software, we are anxious to ensure that there are NO viruses in Compulife. Virtually all computer viruses today are web based and web transmitted. By isolating that machine from the web it means nothing can get to it.
The process of re-compiling software for a different operating system is always a pain in the butt simply because the code that was written for one OS (operating system such as DOS) always ends up being somewhat different for another OS (such as Windows 32). What we try to do with the various products that we support is to refine our code so that we make it as “generic” or “vanilla” as possible. That way, whether we are compiling for Windows, Linux or whatever, it requires few if any changes. It also ensures that the next operating system we choose to move on to is as pain free a transition as possible.
Of course that kind of refining has not been going on with the DOS based data entry program that we use in-house. In-house we control the operating system environment and don’t have to worry about having multiple variations for multiple OS. Even so, now that we are going to convert from one data structure to another, it is important to upgrade our data entry program so that we can now use the latest language tools and compilers that we are now using for the Windows program that you receive. It also means less tools our programmer is forced to use, making his job much easier and resulting in higher productivity.
So the first step we decided to take was to convert the existing DOS tools to Windows 32. That is now done. But the new program really looks like the old program because it uses the same old-style DOS interface (the stuff that you see on the screen).
This takes us to the second step, where we replace the DOS interface with a new Windows interface (what we will see on the screen). This will take much longer, as menus and screens have to be re-constructed from scratch in a completely different environment. And this is the part where we slow down and take our time because the new Windows interface will let us reorganize the way that we work with the data on the computer screen. That will make the addition or change of companies and products much easier.
This re-organization is also important to get right as it will be the bridge between the old and new data structure (from the human point of view). When we do the third and final step in conversion of the data entry tools, the look and feel will remain the same. We will have the new look talking to the old data structure, and the same new look talking to the new data structure. The third step will change the way that the numbers are stored and managed internally.
We will also have a conversion system, letting us convert old files to new. But we can’t trust one time conversions to include everything or be bug free out of the can. So, we will continue to maintain the old data, convert it, then make sure it works properly with the new program. Then, we have to test and ensure the new data tools, talk to the new data, and ensure there are no bugs there. Only after a few months of that process can we be comfortable in abandoning the old system.
Incidentally, the current (old) software is called GOWIN.EXE. The new software will be called CQS.EXE. CQS will do everything GOWIN does now but it will do it talking to completely different data files. For a period of time you will actually have both systems on your computer and we will maintain both, until we are completely certain that CQS is working flawlessly, and that the new data entry tools work perfectly.
As I have tried to explain, none of this will produce any change in what you currently have or see. The goal, in converting from old to new, is to ensure the integrity of everything that we have now, and to ensure that none of that is disrupted or lost when we move to the new system.
Once the changeover has occurred, our job of maintaining the data will be much easier. The new structure will then serve as the foundation for adding a lot of new feature and capabilities that will make the software better for you.
Some of the early benefits will seem subtle but you will find them helpful. For example, sometimes we have to duplicate a product entry to deal with state specific variations. With the new system such redundancy will be eliminated. State variations will be something that we can better control internally within a single product entry. Currently we can only manage maximum ages on a state by state basis, whereas the new system will eventually allow us to handle all sorts of variations by state. The benefit for you will be shorter/tighter lists of products without cryptic notes indicating the differences between the multiples of products stored.
Preferred plus product entries will be completely joined to preferred and regular product entries, cutting down the number of product entries in the system. While we have partially disguised this with our “product family” concept, there are still multiple product entries when reviewing lists of products and/or working with state/province approvals. That will be streamlined with the new software program.
The new data structure will also focus on eliminating rate duplication. In the U.S. YRT renewal tables are currently stored for each and every term product, even though many of those renewal premiums may be the same YRT tables for 10, 15, 20 and 30 year versions of term policies. Those YRT tables will eventually have their own storage system, and will be co-shared by multiple products, thereby cutting down duplication and storage. This means our rate tables will shrink significantly, making premium lookups much quicker.
I realize that some of this talk about “faster” may sound silly, given how well our software already performs, but as more and more of our software is used on internet servers, with multiple requests for quotes happening at the same time, the tighter and faster that we can make our data, the faster the software will run and perform, even under high demand situations. At the end of the day, no one likes to wait for something to be calculated and we intend to keep our software super fast.
Of course if anything needs to be addressed in the current Windows program, during this infrastructure transition period, we will see that it gets our immediate attention. But you can appreciate that right now we are not looking to make significant changes or enhancements to the software until the data has been fully converted.
Related Posts
