Memilih Data Tempatan Untuk Aplikasi Harian

Aplikasi waktu solat tidak perlu menjadi pusat kawalan hidup yang penuh warna dan notifikasi. Ia perlu membantu pada waktu yang diperlukan.

Solatku ialah projek Flutter yang menggabungkan waktu solat dan beberapa alat harian. README menyebut 14 zon JAKIM, cache bulanan, doa, al-Quran, cuaca, masjid dan kiblat; checklist pula menunjukkan beberapa bahagian sudah dilaksanakan manakala sebahagian audio masih dalam proses. Oleh sebab Solatku ialah beta, jurnal ini membezakan antara apa yang sudah ada dalam dokumentasi projek dengan perkara yang masih menjadi arah pembangunan.

Data setempat, zon dan keadaan offline

Dalam catatan ini, saya mahu simpan proses sebenar di sebalik projek ini. Bukan sekadar menyenaraikan ciri, tetapi menjelaskan mengapa sesuatu keputusan terasa penting ketika ia dibina. Bila kita vibe code, banyak perkara boleh muncul dengan cepat. Cabarannya ialah memilih perkara yang patut kekal, perkara yang patut ditangguhkan dan perkara yang patut dibuang.

Saya mula dengan soalan yang paling mudah: apakah momen pertama pengguna membuka aplikasi ini? Untuk solatku, jawapannya tidak sama seperti aplikasi sosial atau dashboard kerja. Pengguna datang dengan niat yang spesifik. Jadi skrin pertama, bahasa yang digunakan, keadaan kosong dan cara aplikasi memberi maklum balas semuanya perlu mengurangkan geseran, bukan menambah satu lagi tugasan.

Bahagian yang mengambil masa

Bahagian yang paling mudah dilihat biasanya bukan bahagian yang paling susah. Kadang-kadang kita boleh siapkan satu kad, butang atau halaman dalam masa singkat, tetapi keputusan tentang data, cache, platform, fail dan pemulihan keadaan memerlukan lebih banyak perhatian. Di situlah projek kecil mula mengajar saya tentang kerja produk sebenar.

Saya juga belajar untuk tidak menyamakan “sudah boleh berjalan” dengan “sudah selesai”. Aplikasi yang boleh dibuka masih perlu menghadapi internet perlahan, data kosong, pengguna yang menukar tetapan, skrin yang berbeza dan keadaan apabila sesuatu servis tidak memberi respons. Menyediakan keadaan ini mungkin tidak nampak menarik dalam screenshot, tetapi ia menentukan sama ada pengalaman itu terasa boleh dipercayai.

Apa yang saya ubah dalam cara berfikir

Sebelum ini saya cenderung mengejar ciri kerana ciri mudah dijadikan bukti kemajuan. Sekarang saya cuba mengukur kemajuan melalui kejelasan. Adakah pengguna faham apa yang berlaku? Adakah mereka boleh kembali ke tempat yang sama? Adakah aplikasi membantu mereka menyelesaikan niat asal tanpa perlu membaca manual panjang?

Soalan-soalan ini juga membuat saya lebih berhati-hati dengan ayat promosi. Saya tidak mahu menjanjikan fungsi yang belum diuji atau menggunakan perkataan seperti “sempurna” hanya kerana projek nampak kemas dalam satu paparan. Lebih baik sebut dengan jujur bahawa sesuatu masih beta, sedang dibina atau memerlukan maklum balas. Kejujuran itu menjadikan jurnal ini lebih berguna dan projek lebih mudah dipercayai.

Langkah seterusnya

Selepas fasa ini, fokus saya ialah memperkemas aliran utama, menguji pada lebih banyak keadaan sebenar dan menyusun semula perkara yang masih kabur. Saya juga mahu terus mencatat perubahan kecil supaya perjalanan projek tidak hilang di sebalik commit dan screenshot. Catatan ini akan menjadi rujukan apabila saya kembali beberapa bulan dari sekarang dan tertanya-tanya mengapa sesuatu keputusan dibuat.

Catatan untuk diri sendiri

Satu perkara yang mudah dilupakan apabila melihat hasil akhir ialah jumlah percubaan yang berlaku sebelum sesuatu kelihatan kemas. Ada susunan yang perlu dibuang, nama yang perlu ditukar, idea yang nampak bagus tetapi tidak membantu, dan keputusan teknikal yang hanya boleh dinilai selepas digunakan berulang kali. Menulis jurnal memaksa saya berhenti seketika dan melihat keseluruhan perjalanan itu, bukan hanya bahagian yang berjaya.

Saya juga mahu membezakan antara membina untuk demo dengan membina untuk penggunaan harian. Demo boleh kelihatan meyakinkan selama beberapa minit. Produk sebenar perlu terus masuk akal pada hari kedua, ketika pengguna tergesa-gesa, ketika data belum tersedia, atau ketika mereka tidak lagi ingat cara sesuatu fungsi berfungsi. Perbezaan kecil ini akan terus menjadi ukuran untuk iterasi seterusnya.

Jadi, ukuran kejayaan untuk fasa ini bukan jumlah ciri yang dapat dipamerkan, tetapi sama ada idea asalnya semakin jelas selepas dibina. Jika pengguna boleh memahami tujuan aplikasi, menyelesaikan tugasan utama dan tahu apa yang masih dalam pembangunan, itu sudah menjadi asas yang lebih sihat untuk langkah seterusnya.

Kesimpulannya, solatku masih merupakan kerja yang sedang hidup. Ada bahagian yang sudah jelas, ada yang masih kasar, dan ada yang hanya akan benar-benar teruji apabila lebih ramai orang menggunakannya. Itulah nilai jurnal ini: bukan mendakwa semuanya siap, tetapi menyimpan proses dengan cukup jujur untuk menunjukkan bagaimana satu idea berubah menjadi aplikasi.

Ini sebahagian daripada perjalanan WartaAI—membina dengan tangan sendiri, belajar daripada perkara yang tidak menjadi, dan berkongsi hasilnya supaya projek seterusnya boleh bermula dengan lebih baik.