Here is a quick run-down on what you will find in this bulletin: Merry Christmas…
Update News for August 2016
Here is a quick run-down on what you will find in this bulletin:
-
-
July Was A Busy Month
-
Old and New For a While
-
The Web and Windows PC Will Converge
-
www.term4sale.com Hits 4 Million
-
These topics will be dealt with in more detail throughout this bulletin.
1. Reduce the size of data files. Previously the renewal rates for each product were stored with each product. That makes sense unless the same renewal premiums are being used with multiple products, as they frequently are in the United States, and to a much smaller degree in Canada. By placing the renewal premiums into a single shared file it eliminates the redundancy of storing them over and over.
During the course of converting products from the old to the new renewal data structure we have managed to reduce the footprint of our data files by over 3 megabytes. Previously the largest rate file was the 20 year term: RATE.D05. At the beginning of July the file was 1,369,162 bytes long. At the end of July that same file was 749,437 byles long, a reduction of 45%.
To keep things in perspective, 1,369,162 bytes is no longer considered a large file. Many photographs that are taken by modern smart phones produce individual files that are larger than that. Even so, the smaller a file is the better. A smaller file loads quicker, can be processed quicker, can be shipped and received quicker, etc. Further, it means less maintenance when changing and updating products. Most companies, when they change their rates, don’t make changes to their renewal premiums. Regardless, we can now check and change a single repository for renewal rates. If there is a change we change it in one place and it is done for all the products that use that renewal. If there is no change, we can focus on the basic premiums that did change.
2. Test and refine the new data storage methods. The system for storing the renewal data is different for what is currently used for the basic products in Compulife, but it is the same system that we will convert those basic products to in the near future. Renewal premiums while important, are less critical and so switching over the renewal premium and the storage structure, and releasing all that to our customers gives us another opportunity to fully test the mechanisms to ensure that they are working properly. If there are bugs in the system it’s better to have them with renewal premiums rather than the basic premiums which are the most important and critical to the majority of our customers.
3. Upgrade the data entry system from DOS to Windows. I know this will sound odd to subscribers, but much of the software that you don’t see or receive, the software that we use to enter and maintain data, is DOS based. It’s not that important because you don’t have to use it. In many ways I still prefer the DOS tools as I can personally work in DOS much more easily. Having said that there are improvements that can be made to the software that we use to maintain the companies and products in our system and those improvements are now much easier to make in Windows. Further, actually using that new Windows data entry software and working with it over and over helps us find ways to improve the functionality and features. Often you don’t see possibilities and new ways that you can do things until you are actually working with something day by day. Like most complex mechanisms it takes time to refine the details. That is important as this will be the same software that we use to maintain the basic insurance rates for the new system once we have moved to it.
4. Simplification of the file structure. All the renewal premiums that are external to basic products are now contained in a single file called RENEW.000. That file is a mere 187,643 bytes in size. Of course much of that size reduction is achieved from new proprietary data compression/encryption technology designed by Compulife for storage of rates files. This was first employed for the Return of Premium factor tables which are stored in a similar file called ROPFT.000. Future company product files will be stored in files names RATES.0?? where ?? is the value assigned to the “category” of product.
For example, the current 20 year term products are now stored in two basic files. Those file are:
-
-
- COMP.D05
-
-
- RATE.D05
The number 5 is the value that we use to indicate the 20 year term category. By comparison, the number 3 is used to indicate 10 year term.
Further, and in conjunction with those two files there are 6 more modal premium variations:
-
-
- COMPM.D05
-
-
-
- RATEM.D05
-
-
-
- COMPH.D05
-
-
-
- RATEH.D05
-
-
-
- COMPQ.D05
-
-
-
- RATEQ.D05
-
In these files the M is for monthly, H is semi-annual and Q is quarterly. The only time we use the modal files for storage is when a company’s modal calculation is complex and cannot be handled with a single multiplication or division factor. This is particularly true for no lapse UL products.
When the new storage system is rolled out this winter, those 8 files will all be combined into a single new file called:
-
- RATES.005
From a maintenance and programming point of view the less files the better. Further, the more we can simplify the code and design of the software the easier it is to maintain and improve in the future. While the pressure for new features and capabilities is not crushing us at the moment, there are a list of many new features that we want to introduce, but are holding those for the new CQS.EXE program file that will be introduced at the same time as we roll out the new data file structure.
For a period of a few months subscribers will get both versions of the software and we will only abandon GOWIN.EXE and the old data files once we are completely satisfied that all our subscribers are satisfied with the new system.
The new CQS.EXE software will have all the same functionality as the old but the look and feel will change. We are focusing our design ideas in the context of what we know we can and cannot do with programming for the internet. Our long term goal is that the “mobile edition” of Compulife, called “Compulife Basic”, will have the same look and feel as the new Windows software so our design will be based upon what we can do on the web.
Having said that, the typical user interface that one encounters on the internet still has significant limitations over what we have been able to create in the current Windows interface that we are using. We do not want to take functionality that we have in Windows and give it up because a web browser is unable to match the functionality or simplicity. Our challenge will be to come up with ideas that will work the same in both but we won’t give up some things which our users really like. Here are a couple of examples.
1. Filing to Pick 12. Currently the mechanism for filing products to Pick 12 is to use the right mouse button on the comparison results. On a touch screen you can alternately touch and sweep right. We have not yet found a dependable method for replicating this function on the web. For that reason we will cling to that functionality in the Windows software and hope that by the time we are ready to introduce the Pick 12 feature to the internet, that browsers will have caught up or that we can come up with an equally simple way to do the same thing.
2. Entering or selecting a face amount. Currently you can do either on the client screen. If you want to select a face amount you can click the down button and get a list of face amounts. Alternately, you can click in the face amount field and manually change the numbers. We have not seen that combination handled by browsers, it’s one or the other; not both.
To summarize, wherever possible the new system design will be browser-like in look and feel until we run up against obstacles that would require us to unnecessarily complicate our current ease of use.
Beyond the technical aspects and limitations of browser based software, cloud based software represents some marketing challenges. The problem is not having a customer take our cloud based product and put it on the internet so that everyone can use it and no one else feels the need to buy anything from Compulife because they can get it somewhere else for free. Contrary to the thinking of some, Compulife is not a charity and we need to earn a living from our product. Remember, unlike you, we do not earn a living from the sale of life insurance, our revenue comes from the software licensing fees that we change for our software. The objective is to package and price it so it is fair for everyone. With the move to more cloud based product options that will remain an ongoing challenge.
Previously, we did a press release when we hit 3,000,000. That release was posted on June 24, 2014:
Term4Sale.com Celebrates 3,000,000 Term Life Insurance Comparisons and Counting
It took a total of 366 months to do the first 3,000,000 quote/visits, which is an average of about 122 months per million. By contrast, the last 1,000,000 visits/quotes took 25 months, which is an average of 40,000 per month. Needless to say, the pace of visits is steadily picking up and we are seeing that from our monitoring of the site using Google Analytics.
Related Posts
