Building a Nepali Typing Tutor for the Browser: Preeti, Unicode, and Honest Speed Measurement

I'm Wilson Shrestha, a web developer in Kathmandu, Nepal. If you learned computers in Nepal, you probably remember Typeshala — the old blue-screen typing tutor where you drilled the same row of letters until your fingers found the home row on their own.

The original software still teaches well, but it was built for old Windows. On Windows 10 and 11 it often needs extra setup to run on 64-bit systems, and it never ran on a Mac, a Linux laptop or a Chromebook at all.

So I built Online Typeshala: a free Nepali typing tutor that runs in the browser. No installer, no font setup, no account. This post is about the three problems that turned out to matter most when building it — and that any developer building a typing tutor, in any language, will run into.

Problem 1: One keyboard, three different outputs

Nepali has three common ways to type, and they are not interchangeable:

• Preeti — a legacy font, not Unicode. Text only looks Nepali when the Preeti font is installed. Still used by older government offices and printing presses.
• Nepali Traditional (Unicode) — real Unicode text that works on websites, email and social media. Follows largely the same typewriter-style key arrangement as Preeti.
• Romanized Unicode — typed phonetically. Easy to learn casually, but a completely different skill from the two above.

The engineering consequence: the physical key a learner presses is the same, but what the software must display, check and score depends on the layout they selected. A lesson engine therefore can't hard-code "key = character". It needs a layout map per key set, and the learner's target text, on-screen keyboard and scoring all have to read from that same map.

You can feel this even on the home row. In Preeti, pressing g then d gives you नम, and k then f gives you पा. Those early real words are exactly why the home row is taught first — the learner gets a win in the first five minutes.

Problem 2: Lessons need gates, not just content

The classic tutor's method is boring on purpose: short drills, one keyboard row at a time, constant repetition. I kept that structure and made the progression explicit:

Home Row → Top Row → Bottom Row → Numbers → All Keys → Custom text + Timed test

Each stage is a gate. A learner moves up only when their accuracy holds — I use 95%+ as the target before raising difficulty (there are five levels, from Easy to Master). This came from a lesson that stood out while building and testing the tool: people who slow down and chase accuracy first end up faster than people who rush for a high WPM number on day one.

The practical features that support that loop are simple:

• Row-by-row lesson sets, so new keys arrive in small pieces
• Live WPM, accuracy and timer, updated as you type
• An on-screen keyboard that highlights the next key, so learners stop looking down at their hands
• Custom text, so learners can practise with real documents — a news paragraph, an office notice
• A timed test mode and a leaderboard, for exam-style practice (in Nepal, Lok Sewa computer operator preparation guides commonly quote around 25 WPM in Nepali as the target — always confirm the exact figure in the official vacancy notice)

Problem 3: Measuring speed honestly

Typing tests do not count actual words. One "word" is a standard 5 keystrokes, including spaces. That keeps scores fair between long and short words.

function scoreTyping({ characters, errors, minutes }) {
  const grossWpm = (characters / 5) / minutes;
  const netWpm = grossWpm - errors / minutes;
  // accuracy needs the correct-character count, tracked while typing
  return { grossWpm, netWpm };
}

• Gross WPM = (characters typed ÷ 5) ÷ minutes
• Net WPM = Gross WPM − (uncorrected errors ÷ minutes)
• Accuracy = (correct characters ÷ characters typed) × 100

Worked example, from a 5-minute test where someone types 800 characters with 20 mistakes:

• Gross WPM = 800 ÷ 5 ÷ 5 = 32
• Net WPM = 32 − (20 ÷ 5) = 28
• Accuracy = 780 ÷ 800 × 100 = 97.5%

Exams care about the net figure, so every uncorrected mistake costs speed. If your tutor only shows gross WPM, you are training learners for a number nobody will grade them on.

One more trap: a Nepali WPM is not comparable to an English WPM. Half-letters, matras and conjuncts often need two or three keystrokes, and many Devanagari characters sit on the Shift layer. A 25 WPM Nepali typist is doing more work per word than a 25 WPM English typist — so benchmark your users against the right language.

Letting other sites use it

Teachers and computer institutes asked to put the tutor on their own sites, so the tool is embeddable with a plain iframe — the same pattern any small web tool can offer:

<iframe src="https://typeshala.wilson.com.np/embed" width="100%" height="700"
  style="border:none;border-radius:12px;overflow:hidden;"
  title="Typeshala Typing Tutor" loading="lazy" allowfullscreen></iframe>

What I'd tell another developer

1. Pick the layout problem first. For non-Latin scripts, "which keyboard layout?" is a product decision, not a settings toggle. Learners who switch layouts every few days confuse their fingers and reset their progress.
2. Gate progression on accuracy, not speed. Speed follows muscle memory; errors practised at speed become permanent.
3. Show net scores. Honest measurement is a feature.
4. Ship it in the browser. Removing installation removed the single biggest barrier my users had.

You can try the tutor, read the full practice plan and the 4-week routine in the full Online Typeshala guide on my site.

If you've built learning software for a non-Latin script, I'd genuinely like to hear how you handled layout switching and scoring — that's the part I expect to keep improving.

Comments

[Alex Shev]

Honest measurement is a feature, especially for a typing tool where the feedback changes how people practice. Separating raw key speed from corrected text accuracy and conversion errors will help learners see which skill is actually improving.