Decimal-based scaling (1.0 = 100%) to percentage-based scaling (100 = 100%) in the UI

[obrienciaran]

Current implementation

The scale() and randomZoom() methods use decimal values. This aligns with how developers use CSS and is intuitive for engineers. e.g.

• scale: 1 = 100% (no scaling)
• scale: 2 = 200% (double size)
• scale: 0.5 = 50% (half size)

Question

However, is it better to have the display showing percentages? Personally I feel this is more intuitive to non-technical users.

• scale: 100 = 100% (no scaling)
• scale: 200 = 200% (double size)
• scale: 50 = 50% (half size)

Internally, the CSS-friendly decimal system is used, in the UI the percentage system is used.

Pros and cons

Arguments for decimal values (1.0 = 100%):

• More intuitive for developers familiar with CSS transforms and graphics programming
• Mathematically cleaner (multiply directly without conversion)
• Standard convention

Arguments for percentage values (100 = 100%):

• More intuitive for non-technical users
• Matches how people naturally think ("make it 150% bigger")
• Consistent with how many UIs display scale controls

Other

I think as well we could put an upper limit on the scale. Right now it has no upper limit. If the user enters 1,000,000% for example it will spike the GPU, frames will probably be dropped, the visuals will look pretty awful, and the UI might crash.

---

Discussion

Any thoughts regarding sticking with decimals and moving to percentages in the UI? This shouldn't be a breaking change as internally the decimal system is made, so current projects using this system will be unaffected.

[aagentah]

Thanks for raising this. It's certainly a tough one since so many applications mix the consistencies.

Some initial thoughts

Quickly researching, it seems TouchDesigner, Blender, and Unity all favour decimals in similar instances; with less code-adjacent programs such as After Effects and Resolume favouring percentages.

Considering the nature of nw_wrld (a 50-50 mix of software and frontend development), I'd be curious to keep the current decimal consistency, however make it clearer for users that 1 === 100%.

It also bodes well that 1 is the default value in many of these instances.

Other

I think as well we could put an upper limit on the scale. Right now it has no upper limit. If the user enters 1,000,000% for example it will spike the GPU, frames will probably be dropped, the visuals will look pretty awful, and the UI might crash.

Absolutely, I believe there's already functionality for defining min and max for number types at the module level. It's just a case of enforcing that across the app. I'll take a quick peek!

Discussion

I'd similarly love to hear some different arguments for either. Ultimately, what's decided here paves the way for the consistencies of existing and future option-value sets.

[obrienciaran]

Considering the nature of nw_wrld (a 50-50 mix of software and frontend development), I'd be curious to keep the current decimal consistency, however make it clearer for users that 1 === 100%

This makes sense. What could also be useful here is the up/down buttons change the value in smaller increments. The sudden job from 1 to 2 causing the visuals to double in size immediately made me feel like there was a bug.

Ultimately, what's decided here paves the way for the consistencies of existing and future option-value sets.

For sure! I'd love to contribute to this project but some guidance or a discussion here would be useful I feel. Otherwise I fear there may be more discussion like the decimal vs percentage one above :)

I see the roadmap has Signed and notarized macOS builds + signed Windows builds for frictionless installs so a product is on the way it would seem. As a first step to clarify, would you see this as being an advanced tool or simple tool in terms of complexity? i.e. do you know (or have hopes for) who your audience is yet?

It's just a case of enforcing that across the app. I'll take a quick peek!

🙏

[aagentah]

What could also be useful here is the up/down buttons change the value in smaller increments. The sudden job from 1 to 2 causing the visuals to double in size immediately made me feel like there was a bug.

Absolutely agree. Adding a step property would fix this:

{
  name: "scale",
  executeOnLoad: false,
  options: [
    { name: "scale", defaultVal: 1, type: "number", min: 0.1, max: 10, step: 0.1, allowRandomization: true },
  ],
},

I'm still curious whether to keep improving the existing form elements vs looking into a library that handles these things a bit better natively, with potential for better multi-select, sliders, dials, for the future.

For sure! I'd love to contribute to this project but some guidance or a discussion here would be useful I feel. Otherwise I fear there may be more discussion like the decimal vs percentage one above :)

I see the roadmap has Signed and notarized macOS builds + signed Windows builds for frictionless installs so a product is on the way it would seem. As a first step to clarify, would you see this as being an advanced tool or simple tool in terms of complexity? i.e. do you know (or have hopes for) who your audience is yet?

That's great to hear. I'd love it if you'd be willing to contribute some things, and I appreciate the discussion so far.

I've added some notes for this part of the conversation to the general discussion thread to keep this specific, and your initial question relevant. Let's catch up on there if you like: #6