I’ve used the in-built Ai, but its not iterative, and I can’t see the underlying logic in the js. Anyone out there that can consult, or @support : can you tell me simply whether you customize the js in the form (calculator) or just the CSS? Thanks.
1 Like
Hi there, @Nathan_Maggard and welcome to the Community 
Sure! Just describe your use case and our devs will be happy to help 
Thanks @Max! Not sure how detailed I can be here. My widget ID is: widget/981be391-d35f-417e-a10e-636785883550. One key question: is there somewhere where the full js of the calculator is exposed, where its editable (by me)?
@Nathan_Maggard There is no option to expose the full code of the widget and edit it. However, you can add some additional functionality using the Custom JS option:
If you are struggling with creating a JS code for your use case, let us know what you’d like to achieve and we’ll gladly look into this
1 Like
My numbering here will correlate to the current order of user input elements on the widget (widget/981be391-d35f-417e-a10e-636785883550)
-
(‘measurement system’): feet/meters: the intent here is to modify the units on the right from sq ft to meters; the math is correct but the units of measure need to change when the boolean option changes.
-
(‘currency’): similar to 1) above, the unit of measure should change from dollars ($) to Euros (€) in the output on the right.
-
(‘your net’s height from the ground’): currently this element behaves in this way (and should not); below 10 ft there is no surcharge, but for each incremental foot (or fraction of a foot) > 10 ft, the surcharge is calculated as 10% of that number. (ie. user input of 11 ft will generate a surcharge of $1.1 (or $1.10). How this should calculate:
If user’s input is between 1 and 8 (ft), no surcharge should be calculated; all inputs > 8 will follow the following formula: if input is between 9 to 15, then [user input x 10 x [total sq ft from ‘dimensions’ above in the calculator] ; if input is > 15, then [user input x 20 x [total sq ft from ‘dimensions’ above in the calculator].
The above formula generates a total height surcharge value which should be added to the ‘dimensions’ output value; these together comprise the ‘total price per sq ft’ output on the right panel (as requested in c. below).
- (‘Additional Wall Height Beyond 6 Feet’): currently the output takes any user input > 10, and multiplies it by 300. This is incorrect. The correct approach is:
The ‘high wall surcharge’ is a 20x multiplier of the user’s input. The user’s input is 'number of feet above 6 ft (the walls on treenets are 6 ft tall by default and the buyer gets 6 vertical feet for free; so here they are declaring some amount of additional vertical wall height, from which we need to derive additional wall-square-footage, which is not the same as the square footage from the dimensions section above); to do this, we multiply their input (presuming a) that the shape of their net is square, and b) that the same height is applied to all 4 walls, so if the user’s input is 2 feet, the equation should look like this: (2 x L + 2 x W) x 20. ie. if the L and W in the dimensions section above are 3 and 5 respectively, we multiply ((the two ‘length’ sides x 3 = 6) + (the two ‘width’ sides x 5 = 10)) x (the multiplier (20)) = 16 x 20 = 320. This 320 result is itself the output that belongs, on the right side panel, to the ‘safety walls’ subtotal.
Note also that this will interact with the new feature mentioned below in item "e) i " below; if another ‘platform’ (the ‘floor’ of a treenet) is added to the overall estimate, then that platform will of course have walls of its own (with a minimum of 6’, etc.); crucially, here we want to assume that the ‘high wall surcharge’ —in that it multiplies against total square footage to get its own surcharge amount— should simply add together the square footage of the initial platform dimensions + any secondary platform dimensions input by the user (which, to reiterate, are optional). That is, the high wall number input by the user should be applied to the ‘additional platform’s’ dimensionality as well.
Other issues:
a.) the minimum (starting) balance of the estimate to be shown should begin at $15,000. All user inputs that would result in calculations below this number should make no intermediary adjustments to the outputs on the right hand side; when user inputs are made that would sufficiently total > $15,000 (or the EUR equivalent), only then should the total be dynamically updated on the right hand side.
b.) the default per sq ft. rate should begin at $75 (and does so accurately currently); the 'material type: ‘webbing or paracord’ input also works correctly, as it functions to modify this base per sq ft rate from the initial 75 to 125 by adding $50/sq ft as calculated by the length/width inputs. However, there is one more element that affects the total per sqare foot price—the ‘height surcharge’ element. All three of these elements combine to generate the total price per square foot (in ‘c.’ just below, which calls for adding a calculated output of ‘price per sq ft’). For directions on how to modify the price per sq ft as regards the ‘height surcharge’, see item 6) (‘your net’s height from the ground’) above.
c.) add an output on the right hand (totals) side titled "price per sq [unit of measure selected above]: divide the [Dimensions subtotal (inclusive of the webbing /paracord setting as it currently functions) + the Height surcharge subtotal] by the ‘total square footage’ output in order to calculate this. All other inputs will not affect the ‘price per sq [unit of measure]’ output on the right hand side.
d.) remove the ‘netting total’ section on the right panel (CSS ID: primary__PrimaryContainer-sc-wurmki-2 bHrnzD) altogether—all minor totals should simply feed the ‘Grand Total’ result.
e.) rename the following output elements on the right panel:
in order from top to bottom:
i. total square footage > area
ii. Dimensions Cost > floorplan
iii. Height Surcharge > elevation
iv. Wall cost > safety walls
v. Environmental Cost > indoor / outdoor
vi. Add-ons Total > accessories
vii. Netting Total > !nix this output entirely!
f.) modification of the input elements on the left panel (not just in name, but additional elements are here introduced):
i. where length and width exist currently, we need a function to ‘add a platform’ (this means ‘add a second net’). This will function to introduce a second set of length and width inputs. This length and width should work just the same as the extant length and width controls, and its results should add to the total square footage commensurately. Depending on your solution, these elements could be hidden until an ‘add a platform’ button is clicked; or these secondary length/width controls could remain exposed (and set to zero if so), and could go unused by the user—that is, they are not required inputs.
ii. Material Type > Floor Material
iii. Environment > Indoor or Outdoor
Lastly: I’d ideally like a JSON object with all of the inputs and outputs organized nicely, so that I can pipe this into our CRM (attributing it to a lead); I might even need to send it to our Typeform to pre-fill some information and then send it on to our CRM. …but a JSON object would be super nice in either case.
If I get a ‘sure we’re working on this’ response from Support in a Forum, I’m putting you guys up for some sort of Epic Heroic Forum Warrior award—
. Please let me pay you for this! (thank you very much for the attention, and let me know what else I can provide to be helpful.)
Hi there, @Nathan_Maggard
I’ll be happy to check these points with the devs. I’ll let you know once I have their response
As for changing names of the calculations and fields, you can easily change them right in the settings:
Noted, and done. Thanks @Max; let me know what they say.
I did not realize the extent to which each field was editable—cool. Also, I didn’t realize I can just write excel formulas—super cool. That said, an update:
What’s remaining that I can’t accomplish without someone on your end:
-
(‘measurement system’): feet/meters: the intent here is to modify the units on the right from sq ft to meters; the math is correct but the units of measure need to change when the boolean option changes.
-
(‘currency’): similar to 1) above, the unit of measure should change from dollars ($) to Euros (€) in the output on the right.
a.) the minimum (starting) balance of the estimate to be shown should begin at $15,000. All user inputs that would result in calculations below this number should make no intermediary adjustments to the outputs on the right hand side; when user inputs are made that would sufficiently total > $15,000 (or the EUR equivalent), only then should the total be dynamically updated on the right hand side.
i. where length and width exist currently, we need a function to ‘add a platform’ (this means ‘add a second net’). This will function to introduce a second set of length and width inputs. This length and width should work just the same as the extant length and width controls, and its results should add to the total square footage commensurately. Depending on your solution, these elements could be hidden until an ‘add a platform’ button is clicked; or these secondary length/width controls could remain exposed (and set to zero if so), and could go unused by the user—that is, they are not required inputs.
misc.) a JSON object with all of the inputs and outputs organized nicely, so that I can pipe this into our CRM (attributing it to a lead); I might even need to send it to our Typeform to pre-fill some information and then send it on to our CRM. …but a JSON object would be super nice in either case.
Your product is amazing. Thank you for building!
1 Like
Hi there, @Nathan_Maggard
Awesome, thanks! I’ll update you here once I have a response from the devs
Dynamic measurements and currencies in Results section
The first 2 cases (dynamic change of currency and measurement) can be implemented with the Conditional Logic feature.
To do this, you need to create 2 separate calculations for each currency/measurement and show them based on the chosen option:
So, for example, you just need to enable the Conditional Logic for the Area in feet calculation and set the following condition: Show Area in feet if Measurement system is Feet:
And the same steps should be repeated for the Area calculation in meters and 2 calculations in euro/dollars
Showing Grand Total (>$15000)
To implement this feature, you need to disable Show in Results feature for Grand Total calculation and rename it (e.g Grand Total 1):
After that, create a 2nd Grand Total Calculation which will be displayed in results using this formula:
Adding the 2nd platform
It’s impossible to create a custom “Add platform button”, but you can use a Choice field as an alternative for this:
Once the Choice field is added, create fields for 2nd Length and Width and set them to be displayed only when the Add second platform field is checked:
After that, add these values to the Area formula and everything should be working fine:
Sending Results to the CRM
If your CRM allows sending data via a POST request, our devs will try to come up with a script for this. To do this, we’ll just need the URL where the script will send the request.
1 Like
Righteous! All is implemented save the currency settings, which, I think, may be quite a bit more complicated as regards conditional logic—because so many of the calculations are priced (or, said differently: because so many of the calculations ‘are currency outputs’). I’ve tinkered with this, using conditional logic on the fields as well as in the calculations.
Would someone on your end be willing to actually perform the currency setup for me? Its pushing beyond what I can conceive of and my calculations are persistently off.
That this is all accomplishable is wicked awesome.
@Max Alternatively, if you could give me a specific currency formula for any one field, that would give me the pattern I need, to follow.
1 Like
Hi there, @Nathan_Maggard
Sure! I’ll double-check it with the devs and will get back to you later
1 Like
Hi there, @Nathan_Maggard
Thank you for waiting!
Our devs have tried to create a widget based on your request. Here is a copy of our devs - https://05d5076835c64a48a91ff46f46a22430.elf.site/
Please test it out and let us know if it works the way you wish. If everything is fine, we’ll just copy its settings to your widget
Note: In this copy, devs added various additional calculations for convenience, which are used to derive the final results. The additional calculations are smaller and the main ones larger.
If the calculator functions the way you need, we’ll remove these additional calculations and copy settings to your widget
Thank you! These are helpful. Could you copy this one into my account as a separate calculator? I don’t want to overwrite the one I’m working on…I’ll likely create a hybrid between the two.
1 Like
Hey there, @Nathan_Maggard
This widget has been successfully transferred to your account
You guys are the best. I’ll see what I can do!
2 Likes
Would you have them look at the Safety Walls input field? It seems to me that it should have a ‘meters’ input version (let me know if the calculation is correct despite the nomenclature on the field—its difficult for me to tell as I look at the calculations) so that the user who’s chosen ‘M / EUR’ is inputting meters in this field and not feet.
1 Like
Okay! I’ll discuss it and will let you know once I have their response
Essentially, we’re asking the user to input feet regardless of their ‘measurement’ choice; yet, a whole meter higher of a wall is absurd, so we’d need a decimal or slider (preferably a slider) for this, whose increments, in the case of meters, in decimeters. So this implies 2 conditionally appearing slider fields and two different outputs (I believe).
Update: For clarity sake: the output, in both $ and EUR, does indeed calculate correctly.
1 Like