Cara Membuat Halaman Changelog: Entri, Tag, RSS, dan 'Yang Baru'
Halaman changelog adalah daftar bertanggal tentang apa yang berubah di produk Anda, dengan yang terbaru di atas, ditulis untuk orang-orang yang menggunakannya. Untuk membangunnya, Anda membutuhkan entri dengan tanggal, judul yang jelas, penjelasan singkat dan tag (Baru, Diperbaiki, Fixed), halaman yang mendaftarkannya, URL terpisah untuk setiap entri, dan idealnya feed RSS serta cara untuk memberi tahu pengguna bahwa ada sesuatu yang baru. Ini salah satu hal paling sederhana yang bisa Anda bangun, dan keputusan utamanya adalah di mana entri disimpan: sebagai file di situs Anda, atau di database dengan halaman admin.
Mengapa changelog layak dimiliki
Changelog menunjukkan kepada pelanggan dan calon pelanggan bahwa produknya terus dirawat. Ini memberi tim dukungan dan penjualan tautan untuk dikirimkan ketika seseorang bertanya "apakah sudah bisa melakukan X?". Ini juga tempat untuk menutup lingkaran umpan balik: ketika fitur yang diminta dirilis, entri changelog adalah yang Anda tunjukkan kepada orang-orang. Jika Anda menjalankan portal umpan balik pelanggan, tautkan permintaan yang sudah dirilis langsung ke entrinya.
Changelog bukanlah riwayat commit internal Anda. "Refactored billing service" tidak berarti apa-apa bagi pengguna. "Faktur sekarang menampilkan nomor PPN perusahaan Anda" berarti sesuatu.
Apa yang dibutuhkan halaman ini
Konten untuk setiap entri
| Kolom | Catatan |
|---|---|
| Judul | Apa yang berubah, dari sudut pandang pengguna |
| Tanggal | Tanggal terbit, ditampilkan di halaman |
| Tag | Baru, Diperbaiki, Fixed (dan mungkin Dihapus atau Keamanan) |
| Isi | Beberapa kalimat atau poin; cara menggunakannya, siapa yang mendapatkannya |
| Gambar atau video | Opsional; tangkapan layar lebih membantu daripada satu paragraf |
| Slug | URL entri, seperti /changelog/invoice-vat-numbers |
| Status | Draf atau terbit, plus tanggal terbit terjadwal jika diperlukan |
Halaman
- Indeks changelog: yang terbaru di atas, dengan filter tag dan paginasi sederhana atau "muat lebih banyak".
- Halaman entri: satu entri per URL, agar bisa ditautkan dan dibagikan.
- Feed RSS atau Atom: memungkinkan orang dan alat mengikuti pembaruan tanpa email.
- Halaman admin (hanya di versi database): menulis, pratinjau, menjadwalkan, dan menerbitkan entri.
Tambahan di dalam aplikasi
- Lencana "yang baru": titik pada item menu ketika ada entri yang belum dilihat pengguna. Simpan tanggal entri terakhir yang mereka buka, per pengguna atau di browser.
- Ringkasan email: ringkasan yang dikirim ke pengguna yang memilih untuk menerimanya. Ini membutuhkan penyedia pengiriman; lihat cara mengirim email dari aplikasi Anda.
Keputusan utama: file atau database
Entri sebagai file di situs
Setiap entri adalah file Markdown di dalam proyek. Menerbitkan entri berarti menambahkan file dan men-deploy ulang. Ini pendekatan yang paling sederhana dan paling kokoh: tanpa database, tanpa login admin, tidak ada yang perlu diamankan, dan halaman bisa dipra-render sehingga cepat dimuat dan mudah dibaca mesin pencari.
Ini cocok untuk tim yang orang-orang penulis entrinya nyaman meminta kepada pembuat aplikasi AI atau mengedit file.
Entri di database dengan halaman admin
Entri tersimpan dalam sebuah tabel, dan halaman admin privat memungkinkan siapa pun di tim menulis, pratinjau, menjadwalkan, dan menerbitkan. Ini cocok untuk tim yang pemasaran atau dukungannya menulis pembaruan, atau ketika Anda menginginkan penerbitan terjadwal atau entri khusus audiens (misalnya, hanya menampilkan fitur enterprise kepada pelanggan enterprise).
Biayanya adalah lebih banyak yang harus dibangun dan dirawat: login admin, unggahan gambar, dan memastikan halaman publik tetap bisa dibaca mesin pencari, sesuatu yang belum tentu terjadi pada halaman yang hanya memuat entri di browser.
| File | Database + admin | |
|---|---|---|
| Siapa yang bisa menerbitkan | Siapa pun yang mengedit proyek | Siapa pun dengan login admin |
| Penyiapan | Minimal | Login, penyimpanan, antarmuka admin |
| SEO | Mudah (halaman dipra-render) | Perlu hati-hati agar halaman dirender di server atau dipra-render |
| Penjadwalan | Terbit saat deploy | Bisa dijadwalkan berdasarkan tanggal |
| Biaya hosting | Statis | Membutuhkan aplikasi dan database yang berjalan |
Menulis entri yang dibaca orang
- Dahulukan manfaatnya. "Ekspor laporan ke Excel" lebih baik daripada "Modul ekspor baru".
- Sebutkan siapa yang mendapatkannya. Semua paket, hanya Pro, dirilis bertahap minggu ini.
- Tunjukkan. Satu tangkapan layar atau klip singkat.
- Kelompokkan perbaikan kecil. Entri mingguan "Perbaikan dan peningkatan" dengan poin-poin membuat halaman tidak banjir.
- Jujur tentang penghapusan. Jika sesuatu akan dihentikan, katakan kapan dan apa yang harus digunakan sebagai gantinya.
Prompt pertama yang berhasil
Tambahkan changelog publik ke situs kami di /changelog. Setiap entri adalah file Markdown dengan judul, tanggal, tag (Baru, Diperbaiki, atau Fixed), gambar sampul opsional, dan isi. Halaman indeks menampilkan entri dari yang terbaru dengan tanggal, tag, dan paragraf pertama, memiliki tombol filter tag, dan menampilkan 10 entri per halaman. Setiap entri memiliki halaman sendiri di /changelog/<slug> dengan judul halaman dan deskripsi yang tepat untuk mesin pencari. Tambahkan feed RSS di /changelog/rss.xml. Buat tiga entri contoh. Sesuaikan dengan desain situs yang ada, pastikan mudah dibaca di ponsel, dan pra-render halamannya agar cepat dimuat.
Untuk versi database, ganti kalimat pertama dengan "Simpan entri di database dengan status draf/terbit dan tanggal terbit, serta tambahkan halaman admin yang dilindungi kata sandi untuk menulis, pratinjau, dan menerbitkannya."
Langkah pembuatan
- Putuskan file atau database menggunakan tabel di atas.
- Bangun halaman indeks dan entri dengan beberapa entri contoh.
- Tambahkan tag dan filter.
- Tambahkan feed RSS dan tautkan dari halaman.
- Tambahkan judul halaman, deskripsi, dan entri sitemap untuk setiap entri. Panduan kami tentang SEO untuk situs web yang dibuat dengan AI membahas dasar-dasarnya.
- Halaman admin dan login, jika Anda memilih jalur database.
- Lencana "yang baru" di aplikasi Anda.
- Tulis entri sungguhan untuk beberapa bulan terakhir agar halaman tidak diluncurkan dalam keadaan kosong.
Kesalahan umum
- Menyalin pesan commit. Tulislah untuk pengguna, bukan untuk pengembang.
- Satu halaman raksasa tanpa URL per entri. Tidak ada yang bisa menautkan ke perubahan tertentu, dan mesin pencari melihat satu halaman alih-alih banyak.
- Pembaruan berhenti setelah sebulan. Changelog yang terakhir diperbarui setahun lalu menandakan produk yang sudah ditinggalkan. Tetapkan ritme yang bisa Anda pertahankan.
- Memuat entri hanya di browser. Mesin pencari dan pratinjau tautan mungkin melihat halaman kosong. Pra-render atau render di server.
- Mencampur insiden. Gangguan layanan termasuk di halaman status, bukan di changelog.
Kapan alat changelog hosted adalah pilihan yang lebih baik
Ada alat changelog dan pembaruan produk hosted, dan sebagian datang bersama papan umpan balik atau widget di dalam aplikasi. Alat itu layak dipakai jika Anda ingin popup di dalam aplikasi, penargetan audiens, dan analitik tanpa harus membangunnya sendiri, atau jika tim Anda sudah membayar alat yang menyertakannya. Perangkat lunak blog atau pusat bantuan Anda mungkin juga sudah memiliki format yang sesuai.
Membangun sendiri masuk akal ketika Anda menginginkan changelog di domain Anda sendiri, dengan desain Anda sendiri, dan sepenuhnya dapat diindeks, yang untuk daftar sederhana dari postingan bertanggal sebenarnya tidak banyak pekerjaannya.
Membangunnya dengan Mythex
Di Mythex, Anda bisa meminta agen menambahkan changelog ke proyek yang sudah ada atau membangunnya sebagai situs kecil tersendiri, dan melihatnya di pratinjau langsung selama dibangun. Versi berbasis file tidak membutuhkan database. Jika Anda memilih versi admin, agen menambahkan database Postgres khusus ketika entri perlu disimpan (atau ketik /database), dan tangkapan layar disimpan di penyimpanan file proyek. Login admin adalah sesuatu yang Anda tambahkan dengan pendekatan autentikasi Anda sendiri (resep menambahkan login).
Aplikasi Mythex baru sering berupa single-page app yang dirender di klien, yang menurut resep SEO kurang kuat untuk pencarian, jadi mintalah halaman changelog statis atau yang dipra-render jika Anda ingin entri ditemukan di pencarian. Resep yang sama membahas judul, deskripsi, dan sitemap. Sebagai titik awal dengan changelog bawaan, lihat templat pusat pengetahuan produk.
Pertanyaan
Apa saja yang harus ada di sebuah entri changelog?
Tanggal, judul singkat yang menjelaskan apa yang berubah bagi pengguna, beberapa kalimat atau poin yang menjelaskannya, tag seperti Baru, Diperbaiki, atau Fixed, dan opsional tangkapan layar serta tautan ke detail lebih lanjut.
Apakah changelog memerlukan database?
Tidak harus. Jika satu atau dua orang menerbitkan pembaruan, entri bisa disimpan sebagai file Markdown di situs dan diterbitkan setiap kali deploy. Gunakan database ketika orang nonteknis perlu menulis dan menjadwalkan entri dari halaman admin.
Seberapa sering saya harus memperbarui changelog?
Setiap kali ada sesuatu yang akan diperhatikan pengguna telah berubah. Banyak produk kecil mengelompokkan perubahan setiap minggu atau dua minggu sekali; yang penting adalah ritme yang konsisten agar halamannya terlihat hidup.
Apakah changelog baik untuk SEO?
Bisa sedikit membantu: setiap entri adalah halaman yang dapat dirayapi tentang sebuah fitur, dan halaman yang diperbarui secara rutin menandakan produk yang aktif. Beri setiap entri URL sendiri dan judul yang deskriptif.