Panduan praktis untuk merencanakan, merancang, dan meluncurkan portal informasi pemerintahan atau layanan publik: aksesibilitas, konten, keamanan, hosting, dan pemeliharaan.
Portal layanan publik tidak bisa menjadi “semua bagi semua orang” pada hari pertama. Mulailah dengan menulis pernyataan tujuan yang jelas yang muat satu halaman dan dapat dibaca oleh tim pengadaan, pimpinan, dan staf garis depan.
Putuskan apakah portal terutama berupa:
Keputusan ini memengaruhi segala hal berikutnya—dari struktur konten hingga verifikasi identitas dan dukungan.
Daftar kelompok kunci dan tugas utama yang harus mereka selesaikan:
Jangan berlebihan: audiens didefinisikan oleh apa yang mereka coba lakukan, bukan demografi.
Sepakati beberapa hasil terukur kecil, seperti:
Rencanakan bagaimana Anda akan mengukurnya (analitik, prompt umpan balik singkat, penandaan pusat panggilan).
Tuliskan realitas yang membentuk ruang lingkup:
Ringkasan tujuan dan metrik sederhana menjadi titik referensi saat prioritas saling bersaing di kemudian hari—dan menjaga proyek fokus pada nilai publik.
Portal pemerintah yang baik dimulai dengan kejelasan: apa yang sebenarnya orang coba capai saat mereka datang? Jika Anda merancang berdasarkan departemen internal, Anda akan memaksa penduduk menerjemahkan birokrasi menjadi niat sederhana. Riset membantu Anda membalik itu.
Kumpulkan “tugas utama” dari sumber yang sudah Anda miliki:
Cari pola seperti “memperbarui,” “mendaftar,” “membayar,” “melaporkan,” dan “memeriksa status.” Kata kerja ini nantinya akan membentuk label navigasi, halaman pendaratan, dan alur formulir.
Pilih beberapa layanan prioritas (mis. izin, tunjangan, pembayaran) dan petakan perjalanan dari perspektif pengguna. Sertakan:
Ini mencegah portal yang menjelaskan kebijakan tetapi tidak membantu orang menyelesaikan tugas.
Buat persona sederhana dan praktis: “Seseorang yang mengajukan bantuan untuk pertama kali,” “Pemilik usaha kecil yang membayar biaya,” “Penduduk dengan keterbatasan bahasa Inggris.” Fokus pada kendala (waktu, stres, perangkat, literasi, kebutuhan aksesibilitas) daripada demografi.
Jalankan wawancara singkat atau uji kegunaan ringan dengan prototipe atau sketsa. Minta peserta menyelesaikan tugas utama dan menjelaskan apa yang mereka harapkan. Anda akan menemukan istilah yang membingungkan, langkah yang hilang, dan masalah kepercayaan lebih awal—sebelum konten dan implementasi mengeras menjadi pekerjaan mahal untuk diubah.
Portal layanan publik berhasil ketika orang dapat menemukan apa yang mereka butuhkan dengan cepat—bahkan jika mereka tidak tahu departemen mana yang bertanggung jawab. Arsitektur informasi (IA) adalah “peta” situs Anda: konten apa yang ada, bagaimana dikelompokkan, dan bagaimana pengguna berpindah.
Sebelum menggambar menu, kumpulkan apa yang sudah Anda miliki:
Beri tag setiap item dengan metadata dasar (topik, audiens, tipe layanan, terakhir diperbarui, tim pemilik). Ini mencegah membangun ulang halaman yang sudah ada—dan menyoroti konten yang usang atau duplikat.
Sebagian besar penduduk datang dengan niat: “memperbarui lisensi,” “mendaftar tunjangan,” “melaporkan masalah.” Struktur kategori di sekitar tugas-tugas itu, bukan nama lembaga. Tes sederhana: jika seseorang tidak dapat menebak menu yang benar tanpa mengetahui struktur pemerintah, pengelompokan perlu diperbaiki.
Jika beberapa kantor berkontribusi pada satu perjalanan, perlakukan itu sebagai satu layanan dengan langkah yang jelas. Tautkan ke halaman pendukung (persyaratan, dokumen yang diperlukan, kontak) dari hub layanan tunggal.
Targetkan layanan utama dapat dicapai dalam 2–3 klik dari beranda. Gunakan beberapa kategori tingkat atas, plus jalan pintas menonjol untuk tugas dengan permintaan tinggi. Hindari “mega menu” penuh istilah internal; gunakan label sederhana yang orang akan ucapkan dengan jelas.
Pencarian sering menjadi navigasi utama. Rencanakan secara sengaja:
Jika dilakukan dengan baik, IA dan navigasi Anda mengurangi panggilan, keluhan, dan putus sambungan—sambil membuat portal terasa tenang dan dapat dipercaya.
Aksesibilitas bukanlah “tambahan” untuk situs pemerintahan—itu bagian dari memberikan akses yang setara ke layanan. Usahakan memenuhi WCAG (biasanya WCAG 2.2 AA) dan perlakukan aksesibilitas sebagai persyaratan desain, bukan pemeriksaan akhir.
Gunakan struktur halaman yang jelas: satu heading utama (H1), subheading logis (H2/H3), dan teks tautan deskriptif (hindari “klik di sini”). Navigasi konsisten dan tata letak halaman yang dapat diprediksi membantu semua orang, termasuk pengguna dengan disabilitas kognitif dan orang yang menggunakan pembaca layar.
Buat keterbacaan mudah: pilih kombinasi warna kontras tinggi, jaga panjang baris nyaman, dan hindari teks yang sangat kecil. Elemen interaktif harus memiliki status fokus konsisten sehingga pengguna keyboard selalu tahu posisi mereka.
Pemeriksaan otomatis berguna, tetapi tidak menangkap semuanya. Sertakan pengujian manual sebagai bagian dari definisi selesai:
Desain inklusif juga soal kata-kata. Gunakan bahasa sederhana, jelaskan langkah yang dibutuhkan, dan hindari jargon serta akronim yang tidak dijelaskan. Jika sebuah istilah harus digunakan (mis. istilah hukum), definisikan di tempat muncul.
Formulir sering menjadi titik di mana orang mengalami kesulitan. Pastikan setiap field memiliki label yang terlihat, teks bantuan yang jelas di tempat yang rawan kebingungan, dan pesan kesalahan yang spesifik serta diumumkan ke teknologi bantu (mis. “Masukkan nomor Jaminan Nasional Anda” daripada “Input tidak valid”). Jangan hanya mengandalkan warna untuk menunjukkan kesalahan.
Tambahkan pernyataan aksesibilitas yang menjelaskan status kepatuhan, masalah yang diketahui, dan opsi kontak untuk melaporkan masalah. Letakkan di tautan footer yang konsisten (mis. /accessibility) dan pastikan jalur umpan balik dipantau dan ditanggapi.
Portal layanan publik berhasil atau gagal berdasarkan apakah informasi tetap akurat. Tata kelola konten adalah sistem praktis yang menjawab: apa yang diterbitkan, oleh siapa, bagaimana diperiksa, dan bagaimana tetap diperbarui. Tanpa itu, halaman menjadi usang, jawaban duplikat muncul, dan kepercayaan terkikis.
Sebelum menetapkan tugas, definisikan “hal” utama yang dipublikasikan agar semua orang menyusun informasi dengan cara yang sama. Model sederhana untuk banyak portal meliputi: layanan (panduan langkah demi langkah), berita, peringatan, lokasi, dan kontak. Untuk setiap tipe, tentukan field yang diperlukan (mis. kelayakan, biaya, waktu proses, dokumen yang diperlukan, jam kantor) sehingga konten konsisten lintas departemen.
Tata kelola bekerja saat tanggung jawab eksplisit. Definisikan siapa:
Dokumentasikan ekspektasi waktu putar, plus jalur “perubahan mendesak” untuk peringatan darurat dan pembaruan sensitif waktu.
Portal membutuhkan bahasa yang sederhana dan konsisten. Panduan gaya Anda harus menentukan nada dan tingkat bacaan, terminologi yang disetujui (dan sinonim yang dilarang), cara memformat tanggal, waktu, alamat, dan penomoran, serta aturan untuk tautan (mis. hindari “klik di sini”). Tempatkan panduan itu di satu lokasi dan tautkan dari dokumen alur kerja internal Anda.
Setiap halaman harus memiliki tanggal tinjau dan cara menandai “pemilik keluar organisasi.” Tentukan kapan konten diarsipkan, bagaimana versi disimpan, dan apa yang harus dicatat di catatan perubahan. Versi bukan birokrasi—itu cara membuktikan apa yang berubah, kapan, dan mengapa.
Portal layanan publik harus terasa sama dapat digunakannya apakah penduduk membaca bahasa utama atau tidak. Dukungan multibahasa bukan sekadar menerjemahkan kata—itu memastikan orang dapat menyelesaikan tugas utama dengan keyakinan yang sama.
Jangan mencoba menerjemahkan semuanya pada hari pertama. Prioritaskan halaman yang langsung memengaruhi kemampuan seseorang untuk mendapatkan bantuan atau memenuhi persyaratan:
Pendekatan “tugas utama dulu” membantu memberikan nilai cepat dan mengurangi risiko terjemahan parsial atau usang untuk layanan kritis.
Terjemahan mesin bisa membantu untuk konten penemuan, tetapi berisiko untuk instruksi terkait hukum, keselamatan, keuangan, atau kepatuhan. Untuk hal yang dapat menyebabkan seseorang melewatkan tenggat, mengirimkan formulir yang salah, atau salah memahami hak mereka, gunakan terjemahan profesional dan langkah peninjauan.
Jika Anda menyediakan terjemahan otomatis untuk halaman non-kritis, beri label jelas dan simpan bahasa asli satu klik jauhnya.
Pengalih bahasa harus mempertahankan konteks: ketika seseorang mengganti bahasa, mereka harus tetap di halaman yang sama (dan idealnya bagian yang sama), bukan diarahkan ke beranda.
Buat pemilih mudah ditemukan dan dapat diprediksi:
Kejelasan budaya mencakup detail kecil yang diandalkan orang:
Jika formulir bagian dari portal, uji di setiap bahasa untuk memastikan placeholder, pesan validasi, dan teks bantuan juga diterjemahkan dan mudah dipahami secara budaya.
Situs multibahasa gagal ketika terjemahan tertinggal dari pembaruan. Tambahkan aturan tata kelola sehingga konten tetap sinkron:
Saat membuat keputusan platform, pastikan IA dan CMS mendukung versioning dan relasi konten per-bahasa agar pembaruan tidak hilang.
Portal pemerintah berhasil atau gagal berdasarkan seberapa andal ia dapat menerbitkan informasi akurat dalam skala. CMS harus membuat “jalur aman” menjadi jalur termudah bagi editor, sambil menjaga konten terstruktur agar dapat digunakan ulang di seluruh situs dan saluran lain.
Cari CMS yang mendukung izin jelas dan akuntabilitas. Minimal, harus menyediakan akses berbasis peran (mis. penulis, peninjau, penyetuju, admin), alur kerja persetujuan, dan jejak audit lengkap sehingga Anda bisa menjawab “siapa yang mengubah apa, dan kapan?” tanpa tebak-tebakan.
Riwayat versi dan rollback mudah sama pentingnya. Saat kebijakan berubah cepat, tim perlu memperbarui halaman dengan percaya diri, mengetahui mereka bisa mengembalikan revisi sebelumnya jika terjadi masalah.
Hindari mengunci informasi penting dalam desain halaman satu-kali. Gunakan field terstruktur (judul, ringkasan, kelayakan, dokumen yang diperlukan, biaya, waktu proses, saluran kontak) sehingga konten yang sama dapat muncul konsisten di:
Pendekatan ini juga membantu konten multibahasa dengan menjaga terjemahan sejajar field-per-field daripada menyalin seluruh halaman.
Tentukan beberapa template halaman sehingga orang tahu apa yang diharapkan:
Petakan sistem yang harus dihubungkan portal: formulir online, penyedia pembayaran, sistem manajemen kasus, layanan peta/lokasi, pemesanan janji, dan analitik. Putuskan konten mana yang tinggal di CMS versus yang ditarik dari sistem eksternal.
Jika Anda sedang membuat prototipe atau memvalidasi perjalanan layanan sebelum berkomitmen pada pembangunan penuh, pendekatan vibe-coding bisa membantu tim bergerak lebih cepat tanpa melewatkan tata kelola. Misalnya, Koder.ai memungkinkan tim menyusun alur warga lewat chat, menghasilkan aplikasi web kerja (React) dan backend (Go + PostgreSQL), dan beriterasi dalam “mode perencanaan” sebelum detail implementasi mengeras. Bila pendekatan tervalidasi, Anda dapat mengekspor kode sumber agar sesuai dengan tinjauan keamanan dan persyaratan pengadaan.
Tulis “editor playbook” singkat yang mencakup konvensi penamaan, aturan peninjauan, pemeriksaan aksesibilitas, dan cara menangani pembaruan mendesak. Jadikan bagian dari onboarding dan simpan di tempat sentral (mis. /content-guidelines).
Keamanan dan privasi bukan “ekstra” untuk situs pemerintah—mereka bagian dari kualitas layanan. Orang akan menggunakan portal publik hanya jika terasa aman, menjelaskan dirinya sendiri dengan jelas, dan menangani informasi pribadi dengan hati-hati.
Mulailah dengan minimisasi data. Untuk setiap field formulir, mampu jawab dua pertanyaan secara sederhana: Mengapa kita perlu ini? dan Apa yang terjadi jika pengguna tidak memberikannya? Jika field hanya “bagus untuk dimiliki,” hapus atau jadikan opsional.
Di mana Anda mengumpulkan data, tambahkan teks bantuan singkat tepat di sebelah field (jangan disembunyikan). Ini mengurangi pengabaian dan membangun kepercayaan.
Gunakan HTTPS di seluruh situs—tanpa pengecualian—dan arahkan ulang trafik HTTP otomatis. Lalu amankan akses admin:
Formulir publik menarik penyalahgunaan otomatis dan dapat menjadi tidak tersedia pada saat kritis. Gabungkan beberapa langkah perlindungan daripada mengandalkan satu alat:
Terbitkan pemberitahuan privasi yang sesuai aturan lokal dan ditulis untuk warga, bukan pengacara. Nyatakan apa yang dikumpulkan, mengapa, siapa yang dapat mengakses, dan berapa lama disimpan. Untuk cookie, gunakan pendekatan persetujuan yang sederhana dan hindari pelacak yang tidak perlu.
Jika menerima lampiran (KTP, sertifikat), anggap itu berisiko tinggi: batasi tipe file, pindai unggahan, simpan dengan aman, dan batasi siapa yang dapat mengakses. Tetapkan proses penghapusan dan uji—privasi termasuk kemampuan menghapus data bila diperlukan.
Orang datang ke portal layanan publik ketika mereka butuh jawaban cepat—sering di ponsel lama, paket data terbatas, atau jaringan tidak stabil. Jika halaman berat atau situs turun, kepercayaan langsung menurun.
Anggap "lambat tapi bisa digunakan" sebagai baseline. Jaga bobot halaman rendah secara default: kompres gambar, hindari media auto-play, dan hanya muat skrip yang langsung mendukung tugas di halaman tersebut.
Aturan praktis: jika halaman tidak membantu warga menyelesaikan perjalanan layanan, jangan biarkan itu memperlambat perjalanan.
Untuk konten yang sama untuk semua orang (panduan, kriteria kelayakan, lokasi kantor), caching dapat mengurangi waktu muat dan beban server secara drastis. CDN bisa menyajikan aset lebih dekat ke pengguna dan membantu menyerap permintaan mendadak. Pastikan aturan caching menghormati privasi (mis. jangan cache halaman yang dipersonalisasi).
Tentukan target sederhana dan terukur sejak awal dan tegakkan saat desain dan pembaruan konten:
Publikasikan target ini secara internal agar tim konten dan desain memahami komprominya.
Tenggat, perpanjangan tunjangan, cuaca buruk, dan keadaan darurat dapat menyebabkan lonjakan dramatis. Siapkan dengan pengujian beban, hosting yang dapat diskalakan, dan modus “terdegradasi tapi fungsional” yang menjaga tugas inti tersedia (pembaruan status, formulir kunci, opsi kontak) meskipun fitur non-esensial dihentikan.
Tambahkan pemantauan uptime, pelacakan kinerja, dan alerting sebelum peluncuran. Lacak kinerja pengguna nyata (bukan hanya tes lab), tetapkan ekspektasi on-call, dan dokumentasikan langkah respons sehingga masalah dapat ditangani cepat dan konsisten.
Sebagian besar orang mengunjungi portal layanan publik untuk melakukan sesuatu: mendaftar, memperbarui, melaporkan, meminta, atau membayar. Tugas formulir adalah membawa mereka menyelesaikan tugas itu dengan usaha minimal dan keyakinan maksimal.
Rancang perjalanan sebagai beberapa langkah jelas (mis. Kelayakan → Detail → Dokumen → Tinjau → Kirim). Tampilkan posisi pengguna dengan indikator progres sederhana, dan gunakan bahasa yang jelas sehingga setiap langkah menjawab “Apa yang harus saya lakukan sekarang?”.
Validasi input secara inline saat mengetik atau saat meninggalkan field—khususnya untuk masalah umum seperti tanggal, nomor identitas, batas ukuran file, dan field wajib. Saat ada kesalahan, tampilkan pesan yang dapat ditindaklanjuti di samping field (“Masukkan tanggal lahir Anda sebagai DD/MM/YYYY”) dan pertahankan apa yang sudah mereka isi. Hindari peringatan samar seperti “Input tidak valid.”
Jika memungkinkan, beri pengguna opsi menyimpan draf dan kembali nanti, terutama untuk aplikasi panjang. Setelah pengiriman, berikan tanda terima yang jelas: nomor referensi, apa yang dikirimkan, dan cara melacak status. Kirim konfirmasi lewat email/SMS bila sesuai, dan beri tahu pengguna apa yang harus dilakukan jika tidak menerimanya.
Jika harus menerbitkan PDF, sediakan versi HTML yang dapat diakses sebagai opsi utama, dan pastikan dokumen yang diunduh memenuhi persyaratan aksesibilitas. Ini mendukung pengguna mobile dan pembaca layar (lihat /accessibility).
Tetapkan ekspektasi segera setelah pengiriman: jadwal tipikal, tahap peninjauan, cara komunikasi keputusan, dan cara memperbaiki kesalahan atau mengajukan banding. Langkah selanjutnya yang jelas mengurangi panggilan ulang dan membangun kepercayaan.
Portal layanan publik tidak pernah "selesai." Kebutuhan orang berubah, kebijakan berubah, dan masalah kegunaan kecil dapat cepat menjadi masalah besar. Rutinitas pengukuran dan perbaikan yang stabil membantu Anda memperbaiki yang penting, menunjukkan akuntabilitas, dan melindungi kepercayaan publik.
Mulailah dengan sinyal yang terkait hasil nyata, bukan metrik vanity. Fokus pada:
Situs pemerintah harus mengumpulkan data seminimal mungkin untuk memperbaiki layanan. Utamakan laporan agregat, periode retensi lebih pendek, dan hindari menangkap data sensitif di URL, log pencarian, atau nama peristiwa. Jika menggunakan perekaman sesi atau heatmap, miliki justifikasi publik dan kontrol ketat—atau lewati sama sekali.
Buat dashboard sederhana untuk pemilik konten dan tim layanan: “Halaman mana yang gagal?”, “Konten mana yang usang?”, “Formulir mana yang menyebabkan panggilan dukungan?” Dashboard harus mengarah pada keputusan, bukan sekadar pelaporan.
Jalankan uji kegunaan ringan pada tugas dengan traffic tertinggi setiap kuartal. Prioritaskan perbaikan yang mengurangi kesalahan, kebingungan, dan kontak ulang (panggilan, email, kunjungan tatap muka).
Sediakan saluran umpan balik di halaman kunci (mis. “Apakah halaman ini membantu?” plus komentar opsional). Tentukan siapa yang membacanya, bagaimana mengkategorikan masalah (bug konten, bug teknis, pertanyaan kebijakan), dan target waktu respons—sehingga umpan balik menjadi perbaikan, bukan kotak hitam.
Meluncurkan portal layanan publik bukan garis finish—itu saat penggunaan nyata dimulai. Peluncuran yang mulus mengurangi panggilan dukungan, melindungi kepercayaan, dan memberi tim Anda ruang untuk memperbaiki situs dengan aman.
Buat daftar periksa yang bisa dijalankan oleh pemilik peluncuran non-teknis, dengan kriteria “lulus/gagal” yang jelas. Sertakan setidaknya:
Rencanakan pelatihan sebelum peluncuran, bukan sesudah. Sediakan sesi singkat berbasis peran:
Padukan pelatihan dengan buku panduan sederhana yang disimpan di tempat orang benar-benar akan mencarinya (mis. intranet dan ditautkan dari /help).
Tentukan tugas berulang dan pemiliknya:
Tulis runbook satu halaman untuk pemadaman atau kejadian keamanan: siapa yang on-call, bagaimana memposting pembaruan publik, data apa yang harus ditangkap, dan kapan melibatkan legal/komunikasi. Latih sekali sebelum peluncuran.
Sisihkan waktu dan dana untuk perbaikan pasca-peluncuran, peningkatan berdasarkan pengguna, dan perbaikan aksesibilitas. Anggaran kecil yang konsisten lebih baik daripada membiarkan masalah menumpuk hingga perlu pembangunan ulang besar setiap beberapa tahun.
Mulailah dengan memutuskan apakah portal terutama berisi informasi, transaksi, atau keduanya dengan sekumpulan layanan peluncuran kecil. Lalu tulis pernyataan tujuan satu halaman dan sepakati beberapa hasil terukur (mis. penyelesaian tugas, pengurangan panggilan, waktu publikasi pembaruan).
Ini membantu menjaga cakupan realistis dan menjadi referensi saat prioritas berbenturan.
Sebutkan audiens berdasarkan tugas yang harus mereka selesaikan, bukan demografi. Kelompok umum meliputi penduduk, pengunjung, pelaku usaha, dan staf internal.
Untuk masing-masing, buat daftar tugas utama seperti “mendaftar”, “memperbarui”, “membayar”, “melaporkan”, atau “memeriksa status”, dan gunakan tugas-tugas itu untuk mengarahkan navigasi dan prioritas konten.
Gunakan metrik yang mencerminkan hasil layanan nyata dan mudah dilacak:
Putuskan sejak awal bagaimana mengukurnya (analitik, prompt umpan balik, penandaan panggilan).
Mulailah dari sinyal permintaan yang sudah Anda miliki:
Cari kata kerja berulang (“mendaftar,” “memperbarui,” “membayar”), lalu validasi dengan wawancara cepat atau uji kegunaan sebelum membangun penuh.
Petakan perjalanan untuk beberapa layanan berdampak tinggi dari perspektif pengguna:
Ini mencegah portal yang hanya menjelaskan kebijakan tanpa membantu menyelesaikan tugas.
Lakukan inventaris konten jujur terlebih dahulu (halaman, PDF, formulir, microsite), dan beri tag setiap item dengan metadata dasar seperti topik, pemilik, dan terakhir diperbarui.
Kemudian susun navigasi di sekitar tugas pengguna (mis. “Daftar,” “Bayar,” “Laporkan”) daripada organisasi, dengan tujuan layanan utama dapat dicapai dalam 2–3 klik dari beranda.
Anggap aksesibilitas sebagai persyaratan desain dan bagian dari definisi selesai. Praktik kunci meliputi:
Terbitkan pernyataan aksesibilitas di jalur konsisten seperti /accessibility dan sediakan jalur umpan balik yang dipantau.
Tentukan sistem sederhana untuk siapa menulis, meninjau, menyetujui, menerbitkan, dan memperbarui konten—gunakan peran bernama, bukan “departemen”.
Tambahkan aturan siklus hidup (tanggal tinjau, pengarsipan) dan panduan gaya yang menyeragamkan terminologi, format (tanggal/waktu/alamat), dan penulisan tautan. Ini menjaga informasi akurat dan konsisten dari waktu ke waktu.
Prioritaskan terjemahan untuk halaman yang memengaruhi kemampuan seseorang menyelesaikan tugas utama:
Hindari terjemahan mesin untuk instruksi kritis hukum/keamanan/keuangan. Pastikan pengalih bahasa menjaga pengguna pada halaman yang sama, dan bangun status terjemahan dan jadwal tinjauan ke dalam alur editorial.
Pilih CMS yang mendukung izin berbasis peran, alur kerja persetujuan, jejak audit, dan riwayat versi dengan rollback mudah. Strukturkan konten ke dalam field (kelayakan, biaya, waktu proses, dokumen) sehingga dapat digunakan ulang.
Rencanakan integrasi lebih awal (formulir, pembayaran, sistem kasus, pemesanan) dan tetapkan non-negotiables seperti HTTPS, MFA untuk staf, minimisasi data, caching/CDN untuk halaman publik, dan pemantauan sejak hari pertama.
