Visual Algorithms • UX/UI Case Study

B-tree Deletion Visualization

Beginner-friendly deletion flow with clear rebalancing rules: borrow, merge, and shrink height.

Deletion is often harder than insertion because removing a key can cause a node to fall below the minimum number of keys. This project teaches deletion by showing the exact moment a node becomes “too small,” then visually applying the correct fix.

The UI emphasizes: (1) where the key is removed, (2) which rule is triggered, and (3) how the tree rebalances while preserving B-tree invariants.

Watch Demo

Quick Facts

Goal

Teach deletion + rebalancing with simple rules learners can apply confidently.

Audience

CS beginners + non-CS learners studying balanced search trees.

My Role

UX/UI design, instructional flow, animation planning and implementation.

Tools

Manim (Python), web presentation, captions + rule-based explanation.

Why Deletion Feels Hard

In a B-tree of minimum degree t, every non-root node must keep at least t-1 keys. Deleting a key can make a node drop below this limit (an underflow), and that's when rebalancing rules must run.

Rebalancing Rules After Deletion

Rule 0 — Root Special Case

The root can have fewer than t-1 keys. If the root becomes empty and it has a single child, the tree height shrinks by making that child the new root.

Rule 1 — Delete from a Leaf

If the key is in a leaf, remove it. If the leaf still has at least t-1 keys, you are done. If it underflows, apply Rule 3 (Borrow) or Rule 4 (Merge).

Rule 2 — Delete from an Internal Node

If the key is in an internal node, replace it with either: in-order predecessor (max of left subtree) or in-order successor (min of right subtree), then delete that replacement key from the leaf where it came from. Rebalance if needed.

Rule 3 — Borrow (Rotation)

If a sibling has at least t keys (more than minimum), borrow one: move a separator key from the parent down into the underflow node, and move one key from the sibling up to the parent (with child pointers rotated accordingly).

Rule 4 — Merge

If both siblings only have t-1 keys (can't borrow), merge: pull the separator key from the parent down, combine the underflow node + separator + sibling into one node, and remove that separator from the parent. If the parent underflows, the fix may cascade upward.

Memory tip: Try Borrow first. If you can't, Merge. If the root becomes empty, shrink the height.

How the Visualization Teaches This

Highlight removal (deleted key flashes / fades out).
Underflow alert (node visually marked when it drops below minimum keys).
Rule callout (Borrow vs Merge shown as a short caption).
Before/after transforms (smooth transitions so learners see what moved).
Consistent structure (same layout rules across every step).

Demo / Media

Animation

This animation demonstrates B-tree deletion and the balancing rules that follow: replacing internal keys, borrowing from siblings, merging nodes, and shrinking the root when needed.

Process

Rule map: translated textbook deletion cases into 4 repeatable rules (Borrow/Merge/Replace/Shrink).
Storyboard: designed step sequences where each “why” is explained in one short sentence.
Animation pass: focused on clear movement of keys/children during borrow/merge.
Polish: improved pacing and captions for the hardest moment—cascading fixes upward.

Outcome

Learners can recognize underflow and choose the correct repair action: borrow when a sibling can spare a key, otherwise merge, and finally shrink the root when the height can be reduced. This supports confident understanding before code implementation.

Next Steps

Add “Rule labels” directly on the animation timeline (Borrow / Merge / Replace / Shrink).
Add a short checkpoint quiz after each case (“Which rule applies here?”).
Optional AI helper: explain why Borrow wasn't possible and why Merge was chosen.