Calculation School Settings as a Differentiator — "Same Chart, Different Readings"

 

"The reading I got from this app is different from another app." If you build a Saju app, you will inevitably face this question. Same birth data, different results — naturally confusing for users. Instead of hiding this issue, we decided to confront it head-on. That was the starting point for what we call "Calculation School Settings."

Why the Same Birth Data Produces Different Results

Four Pillars of Destiny (Saju) is a discipline with thousands of years of history. Over that time, numerous schools of thought emerged, each with subtle differences in calculation methods. The key differences boil down to four areas.

Late Night Hour (Yajasi) handling. For someone born between 11 PM and midnight, how do you determine the Day Pillar? One school says the day changes at 11 PM. Another says it changes at midnight. This single difference can change the entire Day Pillar, which cascades into every Ten Gods (Sipsin) relationship.

True Solar Time application. Clock time and actual solar time differ. Seoul and Busan have different longitudes, so even at the same clock time, the sun's position differs. Schools that apply True Solar Time adjust the birth time based on the birthplace's longitude. Schools that don't simply use standard time.

Daylight Saving Time (DST) correction. South Korea implemented DST during several periods — 1948-1961 and 1987-1988. For people born during these periods, should you subtract one hour? Apps that apply DST correction and those that don't will produce different results.

12 Life Stages direction for Yin Stems. When calculating the 12 Life Stages, Yang Stems proceed forward while Yin Stems proceed in reverse — that's the traditional method. However, some schools calculate Yin Stems forward as well. This difference can significantly alter 12 Life Stages results.

calculationSchool — Solving It with Settings

Most Saju apps pick one approach and hard-code it. Some apply the Late Night Hour rule, some don't. Users can't judge which is correct, and when results differ between apps, they don't know which one to trust.

We took a different approach: let the user choose.

We created a settings object called calculationSchool. It contains four toggles: Late Night Hour application, True Solar Time application, DST correction, and 12 Life Stages Yin Stem direction. Users can freely toggle these options, seeing how the same birth data produces different results under different settings.

The core philosophy: "Rather than presenting one correct answer, provide choices." In Four Pillars study, which of these options is "correct" varies by school. Having the app force one answer felt less honest than letting users select the approach their preferred school endorses.

CalculationSettings UI Design

Technically it's just a few toggles, but the UI design required careful thought. The biggest challenge: most users have no idea what these options mean.

First principle: "Set sensible defaults." Without touching anything, users should get results based on the most commonly used settings. Late Night Hour off, True Solar Time off, DST correction on, traditional 12 Life Stages method. This is the combination we judged most widely used in current Korean practice.

Second principle: "Explain each option simply." Next to the Late Night Hour toggle, a question mark icon reveals a tooltip: "If you were born between 11 PM and midnight, this setting may change your Day Pillar." Same approach for True Solar Time: "Adjusts your birth time based on your birthplace's longitude."

Third principle: "Give immediate feedback on changes." When a user toggles the Late Night Hour setting, the app immediately shows whether the chart changes. For someone not born between 11 PM and midnight, the setting has no effect — in that case, we display "This setting does not affect your current chart" to prevent unnecessary confusion.

AppliedSettingsBadges — Visualizing Transparency

Being able to change settings wasn't enough. The results screen needed to always show which settings are currently active. That's why we built AppliedSettingsBadges.

Small badges appear at the top of the analysis results: "Late Night Hour: OFF," "True Solar Time: ON," "DST Correction: ON." At a glance, you know exactly which calculation methodology produced the current results.

When results differ from another app, users can look at these badges and understand: "This app applied True Solar Time; the other app probably didn't." The difference isn't an error — it's a difference in settings. This transparency device transformed how users perceive discrepancies.

These badges seem minor, but their impact on user trust was significant. Showing your work — "this was calculated under these criteria" — is itself an expression of expertise and honesty.

Answering "Why Different Results for the Same Chart?"

The Calculation School Settings feature wasn't just an addition — it was the app's answer to a fundamental problem in the Saju domain.

While other apps present one answer and implicitly claim "we're right," this app says "there are multiple schools of thought in Four Pillars study, each with different calculation methods. You choose." This approach produces two effects.

One is trust. Acknowledging that multiple valid methods exist and providing choice is more honest than claiming only your way is correct. Users respond positively to this transparency.

The other is educational value. Users can directly compare how the same chart changes with and without Late Night Hour applied. For someone studying Saju, could there be a better learning tool?

From Saju App to Learning Platform

Adding Calculation School Settings subtly shifted the project's identity. From an app that simply gives you a reading, to a tool for exploring Four Pillars study. Users aren't passively receiving results — they're actively experimenting with settings to understand the principles behind the system.

This shift also affected our target audience. Initially, the primary target was "casual users curious about their chart." With school settings added, "students of Four Pillars study" emerged as a meaningful user segment. Positioning as a learning tool became a powerful differentiator.

Design Philosophy for Domains with Multiple Correct Answers

The biggest takeaway from implementing school settings: "In domains where multiple correct answers exist, providing transparent choices is better design than forcing one answer."

This principle isn't limited to Saju. Medicine, law, cooking, education — there are many domains where experts disagree. When designing services for such domains, saying "we know the answer" is less respectful to users than saying "here are the options, and here's the reasoning behind each."

When designing this feature with AI, a similar conversation took place. When I asked "Should we apply the Late Night Hour rule or not?" AI explained both sides' reasoning and concluded that "letting the user choose is the most rational approach." AI itself didn't force a single answer in this domain — an attitude that naturally aligned with the feature's design philosophy.

What This Process Taught Me

First, revealing domain uncertainty rather than hiding it actually builds trust. In a field where schools disagree, claiming "only we're right" invites criticism from experts. Acknowledging differences and showing them transparently is both a defensive and offensive strategy.

Second, settings features live and die by their defaults. 90% of users never touch settings. The defaults must be sensible so the majority has a good experience. Customization exists for the remaining 10% of power users.

Third, differentiation comes not from feature quantity but from depth of perspective. Other Saju apps also handle the Late Night Hour and True Solar Time internally. But few offer them as user-selectable choices with explanations of why results differ. This small shift in perspective defined the app's identity.

Coming Up Next

With school settings implemented, the project's functional completeness reached a new level. But the single most impactful element throughout this entire process was something else entirely: design documents. If the Tarot project was built through conversation-to-code, the Saju project was built document-first. Why this difference was a game changer is the subject of Part 19.