New Check-In Score Formula

Written by Corey Watts on September 24, 2017

With this release we've updated the check-in score formula. A significant amount of refactoring and various code improvements have also been included. As a result, the score calculation code is cleaner and easier to read and test. Most importantly, however, the formula is now mostly sane.

We had considered eliminating the check-in score altogether. It is difficult to create a satisfying formula and this new version isn't entirely satisfying. Please, as a reminder, do not take your check-in scores as gospel.

The score now has a maximum value of 100. The scores you now receive will be lower numbers than what they used to be...that is because the maximum score value was previously 1000.

Please direct questions or comments to our new mailing list. You can subscribe on this page.

The New Formula

  1. For each category, calculate the percentage of selected behaviors and double that decimal number: ($selected_behaviors / $all_behaviors) * 2. Then take whichever is smaller: that number or 1.
  2. Normalize each of the category weights: ($category_weight * 100) / $sum_of_category_weights. Then, for each category, multiply its weight by its score calculated in step 1.
  3. Sum the category scores calculated in step 2. That's your overall score.



It doesn't matter which specific behaviors a user selects within a category, only the number of behaviors selected. However, each category has a different number of selectable behaviors. To avoid giving a larger category a naturally higher potential score, we calculate the percentage of behaviors selected in each category.

Doubling selected behavior percentage

Selecting just one or two behaviors in a category is a big deal as you move down the scale. To reflect this, we double the percentage of selected behaviors in a category. Remember, we have a normalized weight for each category -- essentially the maximum point value a category can have. We multiply that maximum point value by the percentage of selected behaviors. Example:

A person selects two behaviors in the Relapsed/Moral Failure category. That is 2/11 (18%) of the behaviors selected. If the Relapsed/Moral Failure category has a normalized weight of 32 points, they would receive .18 * 32 or just under 6 points added to their score. To enable each category to properly affect the score we double the percentage of selected behaviors -- instead of 18% * 32 we calculate 36% * 32. Increasing the score by 12 (rounded) points is more appropriate.

The minimum of that doubled percentage or 1 is then multiplied by the category score. We don't want the Relapsed/Moral Failure category to supply more than it's assigned weight to the overall score, so the maximum it can contribute is 1 * 32 points.

We have News

Written by Corey Watts on June 30, 2017

We have news! No, literally, we now have "news feed" functionality on this site. We spent a bit of time to create a new extension for Yii2 (the framework this site is built in). It provides an easy way to write posts in a simple format (Markdown) that is then automatically converted to HTML markup. You can take a look at this extension here: yii2-markdown-files.

With this addition, announcing larger changes is easier to do. Thus, we hope you won't be blindsided by the large and semi-large changes we have in the pipeline right now. They should be released soon (hopefully...).

As a teaser:

  • COMPLETED We're in the process of radically improving the formula for calculating the "Danger Score". This new formula should make more sense and be on a 1-100 scale. What?! The current scale is NOT on a 0-100 scale? It's a dirty little secret but it's true. It will be much better, but the numbers you're used to will change.
  • COMPLETED We've almost completed major refactoring of some of the deeper code in this application. We're no longer storing what is essentially static data in the database. Instead, it's stored in memory. This will make certain parts of this application easier to test and will hopefully increase performance by a small amount.

Usernames have been Eliminated

Written by Corey Watts on April 29, 2017

As you've likely noticed we've elminated usernames from the Faster Scale App. There wasn't a tangible purpose or use for usernames here; at least none that an email address couldn't serve. Making our users remember an extraneous username didn't seem very nice. Additionally, we were able to delete a bit of username-related code. Deleting unnecessary code is a great way to keep the project clean and tidy. We've completely deleted all usernames from the database too.

To help you remember not put your username in the login page, we've added a reminder just above the form. Additionally, if you enter something that doesn't look like an email address the form will fail to validate.

If you have any questions or encounter any problems please send us a message on the Contact Form.