Cara Membolehkan Pengguna Memilih Masa dan Kekerapan AI Menghubungi Mereka

Minta kebenaran apabila seseorang memahami perkara yang dipersetujuinya. Terangkan jenis hubungan dalam bahasa yang mudah: contohnya, peringatan yang diminta oleh orang itu atau kemas kini berkala. Nyatakan tempat mesej akan diterima dan kekerapan penghantarannya. Jangan jadikan gesaan kebenaran sistem pengendalian yang tidak disertai penjelasan sebagai satu-satunya penerangan; orang perlu tahu perkara yang ingin dihantar oleh aplikasi sebelum membuat keputusan.

U.S. Web Design System menasihatkan agar pilihan hubungan hanya dikumpulkan untuk saluran yang benar-benar boleh disokong oleh sesuatu perkhidmatan, dan menyatakan bahawa syarat serta jangkaan masa untuk dihubungi perlu diterangkan jika boleh. Dalam produk AI, ini bermakna hanya pilihan penghantaran sebenar patut dipaparkan dan tujuan setiap pilihan perlu dinyatakan. Jangan jadikan pilihan pemberitahuan sebagai syarat untuk menggunakan ciri lain yang tiada kaitan. USWDS: Pilihan hubungan

Anggap persetujuan sebagai pilihan yang boleh disemak semula oleh pengguna. Panduan pemberitahuan Apple mengesyorkan pilihan jelas untuk bersetuju atau menolak jenis pemberitahuan, serta cara dalam aplikasi untuk mengurus tetapan pemberitahuan. Produk boleh mengikut prinsip itu dengan halaman tetapan yang merumuskan pilihan semasa, supaya seseorang tidak perlu mencari-cari dalam tetapan peranti yang tiada kaitan untuk memahami jadual aplikasi itu sendiri. Apple: Mengurus pemberitahuan

Benarkan orang memilih tempoh yang sesuai dengan rutin mereka, seperti hari bekerja antara 6 hingga 8 malam, atau waktu berulang pada hari yang dipilih. Paparkan hari serta waktu mula dan tamat bersama-sama. Jika kawalan itu menetapkan “tempoh untuk dihubungi”, terangkan sama ada mesej boleh diterima pada bila-bila masa dalam tempoh itu atau pada waktu tertentu. Jika tiada mesej yang layak pada hari tertentu, nyatakan sama ada sistem akan melangkau hari itu atau menangguhkan mesej ke hari berikutnya.

Reka bentuk praktikal boleh menawarkan beberapa tetapan awal yang mudah difahami, seperti “sekali seminggu” atau “hari bekerja”, sambil membenarkan jadual tersuai jika produk menyokongnya. Tetapan awal perlu diterjemahkan kepada jadual yang kelihatan, bukan label yang kabur. Contohnya, “mingguan” perlu memaparkan hari dan waktu yang dipilih, manakala “sehingga tiga kali seminggu” perlu menjelaskan sama ada tiga ialah had atau sasaran. Ini ialah saranan reka bentuk: dokumentasi platform menyokong penghantaran berjadual, tetapi pasukan produk perlu menentukan dan menerangkan peraturan penghantarannya sendiri.

Nyatakan zon waktu dengan tepat. Labelkan jadual menggunakan nama lokasi atau zon waktu tempatan semasa peranti, dan beritahu pengguna sama ada jadual itu mengikut mereka ketika mengembara atau kekal pada zon asal. Perbezaan UTC sahaja boleh mengelirukan apabila peraturan waktu penjimatan siang atau peraturan zon waktu kerajaan berubah. Pangkalan data zon waktu IANA merekodkan peraturan mengikut lokasi dan dikemas kini untuk mencerminkan perubahan yang dibuat oleh badan politik, termasuk perubahan pada perbezaan waktu dan peraturan waktu penjimatan siang. IANA: Pangkalan Data Zon Waktu

Contoh pengesahan yang baik: “Setiap Selasa pada pukul 7:00 malam mengikut waktu tempatan semasa anda. Jadual ini mengikut zon waktu peranti anda.” Ayat itu hanya tepat jika pelaksanaannya benar-benar menjejak zon semasa pengguna. Jika jadual kekal pada zon yang dipilih, nyatakan nama lokasi itu. Apabila seseorang mengembara atau zon peranti berubah, paparkan jadual yang berkuat kuasa dan sediakan cara untuk menyemaknya.

Orang mungkin mahukan satu jenis hubungan tetapi tidak yang lain. Jadikan peringatan pilihan, kemas kini produk dan kategori lain yang berbeza boleh dipilih secara berasingan, bukannya menggabungkannya dalam satu suis “pemberitahuan AI”. Jangan reka kategori yang tiada padanan dengan tingkah laku produk sebenar atau jadikan kategori sebagai alasan untuk menghantar mesej yang tidak dipilih oleh pengguna.

Pemisahan ini juga selaras dengan kawalan platform. Android mewajibkan pemberitahuan diberikan kepada saluran dalam versi moden, dan pengguna boleh mengubah tingkah laku saluran; panduan Android mengesyorkan saluran yang membolehkan orang menyesuaikan pemberitahuan yang diterima. Aplikasi boleh menamakan saluran dengan istilah yang mudah difahami, seperti “Peringatan berjadual”, dan menerangkan kandungan setiap saluran. Android Developers: Mencipta dan mengurus saluran pemberitahuan

Pastikan senarai saluran cukup ringkas untuk difahami. Sesuatu saluran patut mewakili pilihan bermakna yang mungkin mahu dibuat oleh seseorang secara berasingan. Tetapan produk itu sendiri masih perlu menerangkan kandungan dan jadual: kawalan saluran sistem pengendalian boleh mengubah sama ada dan bagaimana pemberitahuan dipaparkan, tetapi tidak menerangkan dasar penghantaran aplikasi atau menggantikan jadual dalam aplikasi.

Sediakan jeda sementara dan suis untuk mematikan terus. Nyatakan tempoh jeda dengan jelas—seperti sehingga tarikh yang dipilih atau sehingga pengguna menyambung semula—dan tunjukkan sama ada mesej berjadual akan dilangkau atau ditahan. Kawalan matikan perlu menyatakan kategori atau saluran yang terjejas serta mengesahkan perubahan itu serta-merta. Apabila pengguna menyambung semula, jangan pulihkan jadual terdahulu secara senyap tanpa menunjukkan perkara yang akan berlaku seterusnya.

Sediakan kawalan ini pada skrin tetapan pemberitahuan dan, jika sesuai, melalui tindakan pada pemberitahuan atau pautan terus ke tetapan. Android menyokong tindakan dalam pemberitahuan dan menyediakan cara pada peringkat sistem untuk pengguna mengurus pemberitahuan akan datang; kawalannya berbeza mengikut peranti dan versi Android. Oleh itu, laluan dalam aplikasi tetap berguna untuk memaparkan jadual penuh dan mengubah pilihan pada peringkat produk. Android Developers: Pemberitahuan

Kawalan pada peranti tetap penting. Pengguna boleh mematikan pemberitahuan aplikasi atau mengubah tingkah laku saluran pada peringkat sistem pengendalian, tanpa mengira jadual aplikasi itu sendiri. Antara muka tidak patut memberi gambaran bahawa tetapan dalam aplikasi mengatasi pilihan tersebut. Jika pemberitahuan sistem dimatikan, paparkan status yang jelas apabila pengguna membuka tetapan dan elakkan gesaan berulang kali supaya mereka menghidupkan semula pemberitahuan.

Berikan pilihan kekerapan secara terus kepada orang ramai: contohnya, maksimum satu mesej sehari, had mingguan atau bilangan hari yang dipilih pengguna. Takrifkan tempoh pengiraan dan perkara yang dikira sebagai mesej. Jika beberapa kategori boleh menghantar mesej, jelaskan sama ada had dikenakan bagi setiap kategori atau merangkumi keseluruhan produk. Had bagi setiap kategori masih boleh menghasilkan jumlah keseluruhan yang tinggi, jadi reka bentuk yang berguna selalunya turut merangkumi had keseluruhan.

Had hanya berkesan jika semua laluan penghantaran mematuhinya. Semak peringatan berjadual, percubaan semula, mesej tertangguh dan mesej yang dimulakan oleh ciri berlainan berdasarkan keadaan pilihan yang sama. Jika mesej tertangguh, tentukan sama ada mesej itu luput, diterima kemudian dalam tempoh yang dibenarkan atau digugurkan; terangkan tingkah laku yang penting kepada pengguna. Elakkan daripada menghantar beberapa mesej yang terlepas serentak selepas peranti bersambung semula, kecuali jika pengguna memilih tingkah laku itu secara jelas.

Penghantaran platform tidak sama dengan keputusan produk untuk menghantar. Firebase Cloud Messaging menyatakan bahawa mesej biasanya dihantar serta-merta, tetapi peranti mungkin tidak tersedia atau penghantaran mungkin tertangguh; perkhidmatan itu boleh menyimpan mesej dan cuba menghantarnya kemudian dalam tempoh hayat yang dikonfigurasikan. Ini bermakna produk tidak patut menjanjikan bahawa setiap pemberitahuan akan muncul pada minit yang tepat. Produk boleh berjanji untuk menjadualkan penghantaran dalam tempoh yang dinyatakan, sambil menerangkan bahawa keadaan peranti dan platform boleh mempengaruhi masa pemberitahuan itu muncul. Firebase: Menetapkan tempoh hayat mesej

Perbezaan ini turut mempengaruhi kekerapan. Jika pemberitahuan telah beratur lalu tiba lewat, sistem patut menyemak sama ada pengguna telah menjeda atau mematikan kategori itu sejak pemberitahuan dijadualkan, serta sama ada penghantarannya akan melebihi had semasa. Reka bentuk yang jujur membatalkan atau menyekat mesej dalam giliran yang sudah lapuk apabila pilihan terkini pengguna menyebabkan mesej itu tidak lagi layak dihantar.

Gunakan urutan ini untuk menjadikan tetapan itu satu komitmen yang mudah difahami pengguna:

Namakan jenis mesej yang benar-benar boleh dihantar oleh produk dan jadikan setiap kategori pilihan mudah difahami.

Minta pengguna bersetuju untuk setiap kategori dan saluran penghantaran yang dikehendaki. Jangan pilih hubungan pilihan bagi pihak mereka.

Benarkan pengguna memilih hari, waktu atau tempoh, serta kekerapan maksimum. Nyatakan sama ada had itu merangkumi semua kategori atau dikenakan bagi setiap kategori.

Paparkan zon waktu dan nyatakan sama ada jadual mengikut pengguna apabila zon waktu peranti mereka berubah.

Jadikan kawalan jeda, sambung semula dan matikan jelas kelihatan, kemudian paparkan keadaan semasa dan waktu hubungan seterusnya yang layak.

Sebelum penghantaran, semak semula jadual, had, status jeda dan pilihan kategori. Anggap penghantaran ke peranti mungkin tertangguh, dan terangkan janji produk berdasarkan perkara yang boleh dikawalnya.

Ringkasan tetapan yang ringkas boleh memudahkan orang menyemak aturan itu: “Peringatan berjadual: hidup. Selasa dan Khamis, 7–8 malam waktu tempatan. Maksimum: dua kali seminggu untuk semua kategori. Jeda atau matikan pada bila-bila masa.” Pilihan sebenar perlu mencerminkan keupayaan produk; jika produk tidak dapat menguatkuasakan had yang dipaparkan atau mengikut waktu tempatan dengan andal, produk itu perlu mengubah pelaksanaan atau mengehadkan dakwaannya sebelum memaparkan kawalan tersebut.