İzin ve bildirim ekranları: izni ne zaman, nasıl istemeli?

Kısaca

Mobil uygulamada konum, kamera, mikrofon ya da bildirim için izin gerekir. İzin penceresini telefonun işletim sistemi açar. Android'in geliştirici belgesi bunu açıkça yazar: uygulama bu pencereyi özelleştiremez.

Aynı belge bir boşluğa da dikkat çeker. Sistem penceresi hangi iznin istendiğini söyler, ama nedenini söylemez. Bu boşluğu iki şey kapatır: doğru an ve gerekirse sistem penceresinden önce gösterilen kısa bir açıklama.

İngilizcede buna "permission priming" deniyor, ben ön açıklama ekranı diyorum. Burada ekranın akıştaki yerini anlatıyorum. Ekrana yazılacak metin için mikro metin örneklerindeki izin isteme bölümüne bakın.

iOS ve Android bildirim izni için ne diyor?

İki platformda da kullanıcı izin vermeden bildirim gönderemezsiniz. Fark, pencerenin kaç kez ve ne zaman çıktığında. Aşağıdaki maddeler Apple ve Android geliştirici belgelerinden.

• iOS

  • Bildirim göndermeden önce kullanıcının onayı gerekir. Pencereyi sistem gösterir.
  • İlk istekte sistem kullanıcıya sorar ve cevabı kaydeder. Sonraki istekler pencere açmaz.
  • Geçici izin (provisional) isteyebilirsiniz. Bildirimler sessizce, yalnız Bildirim Merkezi'ne düşer. Kullanıcı orada bildirimleri tutmayı ya da kapatmayı seçer.
  • Kullanıcı uygulamanın izin ayarlarını istediği an değiştirebilir.

• Android

  • Android 13 (API 33) ile bildirim izni POST_NOTIFICATIONS adlı bir çalışma zamanı izni oldu.
  • Yeni kurulan uygulamada bildirimler varsayılan olarak kapalı.
  • Uygulamanız Android 13 ve üstünü hedefliyorsa pencerenin zamanını siz seçersiniz. 12L (API 32) ve altını hedefliyorsa sistem çoğu zaman açılışta sorar.
  • Kullanıcı pencereyi kaydırıp kapatırsa izin durumu değişmez. İki kez reddedilen izin kalıcı ret sayılır.

Android'de bir tuzak daha var. Uygulamanız 12L ya da altını hedefliyorsa ve kullanıcı bir kez "İzin verme" derse, sistem bir daha sormaz. Bu, uygulama silinip yeniden kurulana ya da Android 13'ü hedefleyen bir güncelleme gelene kadar sürer.

Android 13'e yükselen telefonlarda ise uygun durumdaki eski uygulamalar izni otomatik alır. Kullanıcı daha önce bildirimleri kapattıysa bu ret yükseltmeden sonra da geçerli kalır. Navigasyon ve diyalog farkları için iOS ve Android tasarım farkları rehberine bakabilirsiniz.

İzni bağlam içinde isteyin

Apple'ın gizlilik sayfası açılışta izin istemekten kaçınmayı söyler. Tek istisna, uygulamanın o izin olmadan çalışamamasıdır. Örnek olarak konumsuz işe yaramayan bir navigasyon uygulamasını verir.

Bildirim için Apple'ın geliştirici belgesi bir görev uygulamasını örnek verir. İzin, kullanıcı ilk görevini planladıktan sonra istenir. Belgeye göre kullanıcı böylece bildirimlerin ne işe yarayacağını görür.

Android'in bildirim izni sayfası da kullanıcıya önce uygulamayı tanıması için zaman vermeyi önerir. İyi anlara örnek olarak şunları sayar: kullanıcının zil simgesine basması, bir hesabı takip etmesi ya da yemek siparişi vermesi. Uygulamanın üçüncü ya da dördüncü açılışını beklemeyi de seçenek olarak anar.

Kargo takip uygulamasında bu an bellidir. Kullanıcı bir kargoyu açıp durumuna baktığında "Dağıtıma çıkınca haber verelim mi?" sorusunun anlamı ortadadır. Açılışta sorulduğunda ise neye haber verileceği belli değildir.

Android belgesi bağlamın bir de şeffaflık tarafını anlatır. Örneği bir e-posta uygulaması: her yeni e-posta için mi, yalnız alıcısı tek siz olan e-postalar için mi bildirim alacağınızı orada seçersiniz. Ne için bildirim gönderdiğinizi söylemek kullanıcının izin verme olasılığını artırır.

Ön açıklama ekranı (permission priming)

Çoğu durumda ayrı bir ön açıklama ekranına gerek yoktur. Apple'a göre ideal olan, o anki bağlamın izni kendiliğinden açıklamasıdır. Kullanıcı kargo ekranında "Haber ver" butonuna bastıysa ne istediği zaten bellidir.

Ayrı bir ekran gerekiyorsa iki platformun kuralları farklıdır:

• iOS: HIG tek bir buton ister ve bu buton sistem penceresini açmalıdır. Adı "Devam" ya da "İleri" gibi olmalı, "İzin ver" olmamalı. HIG ekrana kapatma ya da vazgeçme gibi ek bir eylem koymamayı söyler. Tek istisna, yasal bir onay almanın gerekmesidir.
• Android: Belge, açıklama akışında her zaman bir vazgeçme seçeneği ister. Örnek kodda bu açıklama ekranı yalnız shouldShowRequestPermissionRationale() true döndüğünde gösterilir.

Apple bu kuralla kullanıcının yanılmasını önlemek ister. Ön ekrandaki buton sistem penceresindeki izin butonuna benzerse, kullanıcı o butona farkında olmadan basabilir. Takip izninde Apple daha da net. Sistem penceresinin görselini göstermek ya da izin butonunu işaretlemek, reddedilen tasarımlar arasında sayılıyor. Bu tür hileleri dark pattern rehberinde topladım.

Ön ekranı iki platformda aynı kodla çıkaracaksanız butonları platforma göre ayırın. Akışın sırası için onboarding kalıbına da bakın. İzni onboarding adımlarına değil, kullanıcının ilk gerçek işine bağlayın.

Deneyin: açılışta iste, bağlam içinde iste

Aynı kargo uygulamasını iki farklı zamanlamayla açın. Önce "Açılışta iste" ile reddedin, sonra kargoyu açıp zile basın. Ardından aynı şeyi "Bağlam içinde iste" ile yapın.

Açılışta mı, bağlam içinde mi?

Bu örnek JavaScript ile çalışır. Kapalıysa iki akışın farkını yukarıdaki ve aşağıdaki metinden okuyabilirsiniz.

Örnek Kargo uygulaması, metinleri ve sistem penceresinin sade temsili benimdir. Pencere Apple ya da Google arayüzünü kopyalamaz. Demoda izin tek kez sorulur. iOS'ta ikinci istek pencere açmaz, Android'de iki kez reddedilen izin de kalıcı sayılır.

Açılışta reddeden kullanıcı, zilin ne işe yaradığını görmeden tek şansınızı harcamış olur. Bağlam içinde reddeden kullanıcı ise neyi reddettiğini bilir. Kargonun durumu iki akışta da ekranda kalır.

Kullanıcı reddedince ne olur?

Kısa cevap: uygulama çalışmaya devam eder, yalnız o özellik eksik kalır. Android belgesi ret sonrası için beş ilke sayar. Ben bunları ekrana şöyle çeviriyorum:

1. Kaybı en aza indirin. Bildirim yoksa kargonun durumu yine uygulamada güncel kalır.
2. Dikkati doğru yere çekin. Mesajı özelliğin sonucu nerede görünecekse orada gösterin. Kargo örneğinde bu yer zil kutusu.
3. Somut olun. "Bazı özellikler çalışmayabilir" yerine hangi özelliğin çalışmadığını yazın.
4. Arayüzü kilitlemeyin. Tam ekran bir uyarıyla kullanıcıyı durdurmayın.
5. Kararına saygı gösterin. Belge, fikrini değiştirmesi için sürekli hatırlatmayı saygısızlık sayar.

Örnek koddaki bir not da önemli. Belge, ret sonrası kullanıcıyı ikna etmek için sistem ayarlarına bağlantı vermemeyi söyler. Bu yüzden demoda ayarlar yolu ret anında çıkmıyor, kullanıcı zile yeniden bastığında çıkıyor.

Apple tarafında kural daha kısa. Belgeye göre sistem cevabı ilk istekte kaydeder ve sonraki istekler kullanıcıya sormaz. Fikrini değiştiren kullanıcıya gösterebileceğiniz yol, Ayarlar'daki bildirim bölümüdür.

Ayarlara yönlendirme

Ret sonrası ayarlar bağlantısı verebilirsiniz, ama zamanına dikkat edin. Kullanıcı aynı özelliği kendisi yeniden istediğinde ona yolu gösterin. Ekrana girer girmez "Bildirimleri açın" bandı göstermek ise ısrar olur.

İki platformun da doğrudan bildirim ayarlarına giden bir yolu var. iOS'ta UIApplication.openNotificationSettingsURLString iOS 16 ile geldi ve uygulamanın bildirim ayarlarını açar. Android'de Settings.ACTION_APP_NOTIFICATION_SETTINGS API 26 ile geldi ve tek bir uygulamanın bildirim ayarlarını gösterir.

Bağlantının yanına kullanıcının orada ne yapacağını bir cümleyle yazın. Ayarlardan dönen kullanıcı için de izni yeniden kontrol edin. Apple ve Android belgeleri, kullanıcının izni istediği an değiştirebileceğini hatırlatır. Bu yüzden bildirim göndermeden önce durumu her seferinde sorgulayın: iOS'ta notificationSettings(), Android'de areNotificationsEnabled().

İzni aldıktan sonra

İzni bir kez alırsınız, kullanıcı ise onu her an geri alabilir. Android belgesi, kullanıcının uygulamanın günde kaç bildirim gönderdiğini görebildiğini ve izni her an kaldırabildiğini yazar.

Apple'ın bildirim sayfası da aynı şey için birden fazla bildirim göndermemeyi önerir. Gerekçesi, Bildirim Merkezi'nin dolması ve kullanıcının uygulamanın tüm bildirimlerini kapatabilmesi. Kargo için söz verdiğiniz iki bildirim "dağıtıma çıktı" ve "teslim edildi" ise kampanya bildirimi eklemeyin.

Benim notum

Mobil uygulama audit'lerinde en sık gördüğüm izin sorunu açılış ekranı. Uygulama açılıyor ve kullanıcı daha logoyu görmeden bildirim, konum ve takip pencereleri arka arkaya çıkıyor. Kullanıcı üçünü de aynı refleksle kapatıyor.

İkinci sırada ret sonrası suskunluk var. İzin reddedilince özellik sessizce kayboluyor, ekranda hiçbir açıklama kalmıyor. Kullanıcı neden kargo bildirimi almadığını hiçbir zaman öğrenmiyor.

Kendi ürününüzde şunu deneyin. Uygulamayı silip yeniden kurun ve her izni reddedin. Sonra her ekranda neyin çalışmadığını ve bunu ekranın size söyleyip söylemediğini not edin.

Bu akışı ürününüzde baştan kurmak isterseniz Tasarla & Yayınla Sprinti izin ekranlarını tasarımdan koda kadar kapsar.

Kontrol listesi

• İzin, kullanıcı o izni gerektiren işi başlattığında isteniyor.
• Açılışta istenen izin varsa, uygulama o izin olmadan gerçekten çalışmıyor.
• Bağlam izni açıklamıyorsa sistem penceresinden önce kısa bir açıklama var.
• iOS ön ekranında tek buton var ve adı "Devam" ya da "İleri".
• Android açıklama ekranında bir vazgeçme seçeneği var.
• Ön ekran sistem penceresini taklit etmiyor, izin butonunu işaret etmiyor.
• Ret sonrası uygulama çalışıyor ve eksik özelliği adıyla söylüyor.
• Ayarlar bağlantısı yalnız kullanıcı özelliği yeniden istediğinde çıkıyor.
• Bildirim göndermeden önce izin durumu her seferinde kontrol ediliyor.
• Aynı olay için birden fazla bildirim gönderilmiyor.