Baik - ini saya susun sebagai isi file spec (pola default page ERPNext v16), dengan penanda ✅ = ada di codebase, ⚠️ = hasil ukur screenshot (perlu verifikasi di branch v16). Semua angka dalam CSS px.

File Spec - Pola Default Page ERPNext v16

Jawaban inti dulu: fix atau ratio?

Filosofinya: "chrome fix, kanvas fluid". Semua ketebalan chrome (lebar sidebar, tinggi header, tinggi baris, tinggi tombol) adalah angka fix. Yang ratio/fluid hanya dua: lebar header & content (sisa lebar setelah sidebar) dan tinggi sidebar & content (sisa tinggi setelah header). Tidak ada komponen yang diskalakan proporsional terhadap layar - karena itu pola ini aman di monitor berapa pun tanpa perhitungan.

3 zona besar

Komponen kiri atas (Brand Bar: logo + teks)

Window dropdown (saat Brand Bar diklik)

Komponen kanan atas (view controls) & filter bar

Isi content (list view)

14 inch vs 19 inch - apa yang berubah?

Artinya: di 19 inch tidak ada yang membesar - yang terjadi adalah kanvas fluid menampung lebih banyak kolom dan baris. Ukuran fisik komponen hanya berubah bila OS scaling berubah (125% → semua CSS px ikut ×1,25), bukan karena inci monitornya. Ini konsekuensi langsung dari pilihan "chrome fix": konsisten secara fisik di PPI相近 (14" ≈112 PPI vs 19" ≈116 PPI hampir sama), dan tidak pernah terjadi UI "raksasa" di layar besar atau "sempit" di layar kecil.

Rekap fix vs ratio (jawaban langsung pertanyaan terakhirmu)

• Fix: lebar sidebar (v16), tinggi header, tinggi brand bar, tinggi tombol/pill/baris/paging, padding, logo 24, lebar dropdown.
• Fluid (sisa ruang, bukan ratio persentase): lebar header, lebar content, tinggi sidebar, tinggi content.
• Fluid-isi: tinggi dropdown (mengikuti jumlah item).
• Ratio sejati (persentase): hanya sisa-sisa mobile (overlay-sidebar 40%/60% ✅) - tidak dipakai di layout desktop.

File spec ini sekaligus menjadi pembanding sempurna untuk frame BMP kita nanti: BMP mengadopsi filosofi yang sama (chrome fix, kanvas fluid) dengan angka kita sendiri (header 48 vs 60, sidebar 216/224, dll.).

Mau saya lanjutkan dengan file pembanding (delta ERPNext-vs-BMP per zona), atau kembali merampungkan modul Framework (Website / tanya-jawab)?

Pola Positif #1 - Toggle collapse sidebar muncul saat hover, dengan differensiasi tipis

Gambar F: Collapse/Expand toggle

Perilaku yang diamati (v16): kondisi normal toggle tidak terlihat; begitu kursor menyentuh sidebar, toggle muncul di tepi rail. "Manis" karena chrome hanya ada di saat dibutuhkan.

Spec BMP - tangga 3 state:

Kenapa resep ini cocok dengan Foundation:

1. Differensiasi lewat tone surface, bukan hue baru - putih di atas greige adalah bahasa hierarki rail-vs-canvas yang sudah kita punya; handle "meminjam" warna canvas.
2. Teal tetap langka - hanya sebagai tint saat hover handle, konsisten aturan "teal = aktif/primary".
3. Border + shadow memberi kedalaman, sehingga handle terbaca sebagai objek yang bisa dipegang.

Kalimat prinsip untuk dokumen:

Kontrol hover-reveal muncul dengan differensiasi minimal dari sekitarnya (tone surface + border + shadow), dan menegaskan clickability hanya pada hover dirinya (tint accent). Muncul perlahan bukan berarti muncul samar.

Bawaan aksesibilitas dari Pola #1 tetap melekat: focus-visible untuk keyboard, always-visible di touch, dan state collapse tersimpan per user