iOS kullanıcı deneyimine bir bakış 3: bildirim modelinin kalbine yolculuk

merhabalar. iOS kullanıcı deneyimini kurcalamaya devam ediyoruz. şimdi de son yazımızda sözünü verdiğimiz gibi iOS bildirim modelini masaya yatıracağız. ama bunu yaparken zaman zaman o yazıya referans vereceğimizden eğer hala okumamışsanız, mobil bildirim modellerini incelediğimiz yazıyla başlamanız iyi olabilir.

giriş

iOS bildirim modeli, daha önce değindiğimiz mobil bildirim konseptinin, android ile birlikte en tipik iki örneğini teşkil ediyor. bu model, ayırd ettiğimiz 3 parçalı arayüzü tamamen temsil ediyor. örneğin, ayarlar-bildirimler kısmından bildirim ayarlarını yapılandırırken; bildirim merkeziyle de tüm bildirimleri toplu şekilde görebiliyoruz. ve elbet cıhazla etkileşim halindeyken gelen bildirimleri yanıtlayabiliyor, silebiliyor ve yönetebiliyoruz. tüm mobil bildirim modellerinde benzer şekilde çalışan bu temel yapıda çok bir fark olmamasına rağmen, iOS bildirim modelinin kendine has avantaj ve dezavantajları ancak ayrıntılara inildiğinde anlaşılabiliyor. ayrıntılar hakkında konuşabilmemiz için de ilk önce iOS bildirim modelinin elementlerini ve elementlerin bir arada çalışma mekaniğini kavramamız yerinde olur diye düşünüyorum. bu yüzden elementleri tanımlayıp mekaniği anlatarak işe başlayacağız.

iOS bildirim modeli elementleri

iOS bildirim modelinin elementlerini iki kategoride toplayabiliriz. birinci kategoride bildirim nesneleri diyebileceğim bildirimlerin maddi içeriğini oluşturan parçalar bulunuyor. bunlar:
1. başlıklar: bildirimlerin içeriği bu element içinde gösterilir. başlıklar, bildirimin bilgi içeriğinin tamamını oluştururlar. örneğin; mesajlar uygulamasından bir bildirim aldığınızda uygulamanın adı, mesajın kimden geldiği ve mesaj içeriğini görürsünüz.
2. sesler: uygulama bildirim gönderdiğinde oynatılan uyarı tonudur. bazı uygulamalarda bu ton değiştirilebilir durumda da olabilir.
3. işaretler: uygulama bildirim gönderdiğinde beliren uyarı simgesidir.
bu üç element bir arada bildirimin uyarı ve bilgi içeriğini oluştururlar. bildirimin içerdiği bilgi bildirim başlığıyla taşınırken; bildirimin kullanıcıyı uyarma gücü de ses ve işaretlerle sağlanır.

ikinci grup bildirim elementleri ise bildirim zemini diyebileceğim; bildirim nesnelerinin görüldüğü ve yönetildiği ekranlardır. bunlarda şu şekilde listelenebilir.
1. uygulama simgeleri: cıhaz kilit ekranında değilken, yani biz cıhazla etkileşim halindeyken başka bir uygulama bildirim gönderdiğinde açılan ekranlardır. bildirim gönderen uygulamanın ayarlarına bağlı olarak bildirim nesneleri bu küçük ekrana düşer. buradan bildirimler yanıtlanabilir, yönetilebilir kapatılabilir vs. bu ekranların varlığının amacı, odaklandığımız işi bölmeden bildirimle etkileşime girmemizi veya bildirimi göz önünden uzaklaştırmamızı sağlamaktır. önceki yazımızda bu konsepti detaylıca anlattığımızdan uzatmıyorum.
2. bildirim merkezi: uygulama bildirimlerinin toplandığı akış görünümündeki ekranlardır. bu ekranlar vasıtasıyla kullanıcı tüm bildirimleri toplu olarak görüp aksiyon alabilir. bu konsepti de önceki yazımızda tartışmıştık.
3. kilit ekranı görünümü: cıhaz kilitliyken gelen son bildirimlerin listelendiği ekranlardır. bu ekranlar cıhazla etkileşim halinde olmadığımız sürede düşen bildirimlerden bizi haberdar edebilmek için düşünülmüştür. ayrıca kilit ekranından bildirim merkezine ulaşmak da mümkündür.

bahsi geçen bildirim elementleri dışında; bu elementlerin davranışlarının yani bildirim ayarlarının yapılandırıldığı bir ekran daha vardır. bu ekrana ayarlar-bildirimler yolunu izleyerek ulaşılabilir. kullanıcı bu kısımda hangi uygulamaların bildirim gönderebileceğini; bildirimlerin hangi ekranlarda gösterileceğini; ses ve uyarı simgelerinin görülüp görülmeyeceğini; bildirim önizlemelerinin hangi uygulamalar için hangi ekranlarda görülebileceğini ve uygulama bildirimlerinin gruplandırılıp gruplandırılmayacağını belirleyebilir.

görüldüğü gibi, iOS bildirim modeli oldukça basit görünen bir mekanikle işliyor. bildirim nesneleri arayüzün çeşitli ekranlarına düşüyor; düşen bildirimlerle etkileşime geçmek ve daha sonra kaldığımız yerden yaptığımız işe dönmek için çalışan bir mekanizme var ve tüm bu işlev ve mekaniğin ayrıntılarının yapılandırılabildiği ayarlar mevcut. ama modelin göründüğünden çok daha ince ve çok boyutlu bir denge üzerine oturduğunu mobil bildirim modellerini incelediğimiz yazıyı okuyanlar hatırlayacaklardır. iOS bildirim modeli elementlerini gördüğümüze göre artık bu ayrıntılara eğilebiliriz.

iOS bildirim modelinin temel meseleleri

bir bildirim modelinin başarısı esneklikle otomasyon arasında kurduğu dengeyle ve uygulama bildirimlerini kullanıcıyı rahatsız etmeden, hızla etkileşime geçilebilecek şekilde sunmasıyla yani, o hassas formülü doğru uygulamasıyla ölçüldüğüne göre; bizim de iOS bildirim modelini değerlendirirken bu meseleleri ön plana almamız gerekiyor. bu bağlamda, iOS'in genel arayüz ve işlevsellik özelliklerinin bildirim modelinde de birebir uygulandığını; iOS bildirim modelinin işletim sisteminin diğer bileşenleriyle işlev ve arayüz tutarlılığı bakımından tamamen uyumlu olduğunu görüyoruz. bu örtüşmenin sonucu olarak karşımıza gayet stable, basit, hızlı ve vadettiği işi aksamadan yerine getirebilen bir model çıkıyor. evet: iOS bildirim modeli arayüz bakımından akıcı, işlevler arasındaki geçişler pratikk; beklenmedik tatsız süprizlerle karşılaşmıyoruz. yani söz konusu olan kullanıcı etkileşiminin sorunsuz sürdürülebilmesi ve bildirimlerin akıcı biçimde takip edilebilmesi olduğunda iOS kusursuz görünüyor. ama acaba bu kadarı yeterli mi? bu model standartlaştırılmış bir senaryoda sonsuza kadar saat gibi çalışacakmış gibi görünebilir ama, başka senaryolar altında farklı kullanıcı beklentilerini aynı oranda tatmin edebiliyor mu? daha basit söylersem: model ne kadar esnek? bu sorular malesef iOS bildirim modelinin zaaflarına işaret ediyor. biz de öncelikle bu zaafın kaynağına bakacağız.

problem basit aslında. iOS hızlı, sorunsuz, minimalist, kolay kullanılabilir, kullanıcı mahremiyetinin korunduğu, uygulama güvenliğinin üst düzey olduğu, rakiplerine oranla daha erişilebilir, cıhazlar arası senkronizasyonun göz kamaştırdığı konforlu bir işletim sistemi olmasına rağmen artık can sıkıcı hale gelmiş işlev eksiklikleri, kısıtları ve yetersiz özelleştirme seçenekleri yüzünden benim gibi iOS sever kimseler tarafından dahi ağır eleştirilir hale geldi. kolay kullanılabilir ve kafa karıştırmayan bir işletim sistemi için esneklikten feragat edilmesi önceleri göze bu kadar batmıyordu. daha doğrusu; özelleştirilebilirlik sorunları işletim sisteminin sağladığı konforla kıyaslandığında tölare edilebilir durumdaydı. fakat mobil cıhaz başında geçen sürenin artmasıyla farklı senaryoların oluşması ve yeni beklentilerin ortaya çıkması tabloyu değiştirdi. artık, benim de aralarında bulunduğum bir grup kullanıcı daha kişiselleştirilebilir bir kullanıcı deneyimini yüksek sesle talep eder oldu. talebin kapsamı çok daha geniş olmakla birlikte en görünür olduğu kısımlar da doğal olarak ana ekran ve bildirim modelleri.

problem basit dedim ama çözüm göründüğü kadar kolay değil. Apple, artık iOS'in imzası haline gelmiş bulunan kolay kullanılır işletim sisteminden sapmadan; aynı arayüz altında daha gelişmiş kişiselleştirmeyi nasıl sunacağına hala karar verememiş durumda. iOS 10'dan beri bildirim ve kilit ekranlarıyla oynanmasının altında bu yarı gönülsüz
ikircikli tavır yatıyor.. gönülsüz v ikircikli tavır diyorum zira; 3 sürümdür kişiselleştirme adına eklenenler, android içinde bulunan özellik ve ayarların kısıtlı ve sınırlandırılmış halinden fazlası değil. bununla birlikte, Apple'in temel prensibi olan fazla karışık olmayan, otomatize görevlerle donatılmış ve kullanıcıyı arka plandaki işlere çok bulaştırmayan arayüz tercihini sürdürürken, Android'e yakın bir kişiselleştirme sunabilmek için de bir yol aradığı açık. iOS 13 ile tutumun netleşeceğini, tam olarak ne yapmak istediklerini anlayabileceğimizi sanıyorum. o zamana kadar biz de elimizdekilerle yetineceğiz. açıklamalarımızı son 3 sürümde bildirim modelinin geçirdiği değişime bakarak yapacağız. analizimizin daha açıklayıcı olması bakımından bildirim ayarlarıyla bildirim ekranlarını ayrı ayrı değerlendireceğiz.

iOS bildirim ayarlarının değerlendirilmesi

bildirim ayarları noktasında özellikle iOS 11 ve 12 sürümleriyle yol katedilmeye çalışılıyor. iOS 11 ile, bildirimlerini kilit ekranında görmek istediğiniz uygulamaları sınırlayabilmeye başladık. ama en önemlisi, daha önceki sürümlerde mesajlar ve whatsap gibi uygulamalarla sınırlı bir kullanım alanı olan önizleme gizleme özelliği iOS 11 ile tüm uygulamalarda çalışır hale geldi. yani artık, herhangi bir uygulamanın bildirim önizlemelerini kilitli ekran için veya tamamen gizleyebiliyoruz. dilersek de, tek bir hamleyle tüm uygulama bildirimlerinin önizlemelerini kapatabiliyoruz. önizlemelerin kapatıldığı durumda, ekranda sadece bildirimin hangi uygulamadan geldiği görülecek ve içeriği görmek için kullanıcının ilerlemesi istenecektir. önizleme gizlemeyi bizler çok kullanıyorduk, zira körlerin bildirim önizlemelerini gizlemesini gerektiren pek çok senaryo olabiliyor. bu bakımdan, önizleme gizlemenin genişlemesi hoş bir iyileştirme oldu.

iOS 12 sürümü ile de apple çok eleştirildiği bildirim grupları meselesine el attı. bu sürümle bildirimler uygulamalara göre gruplanabiliyor. böylece aynı uygulamadan gelen tüm bildirimler tek bir bildirim gibi görünüyor. kullanıcı, bildirimleri genişleterek diğer bildirimlere ulaşabiliyor. bu geliştirmenin amacı; bildirim merkezinin dağınık ve kalabalık görüntüsüne son vermek. eski düzende bir uygulamadan gelen her bildirim ayrı ayrı görünüyordu. bu da Apple'a yakışmayan korkunç bir kullanıcı deneyimi anlamına geliyordu. hatırlayacaksınız; whatsapp gibi bir sohbet uygulamasından gelen tüm mesaj bildirimleri ayrı ayrı görünüyor; kullanıcı bildirimler arasında kayboluyordu. bu tatsız durumu bir de sisteminde yüzlerce uygulama olan insanlar için tekrar hayal edin. işte, bildirimlerin uygulamalara göre gruplanmasıyla artık bildirim merkezi daha derli toplu görünüyor.

son 2 sürümdür yapılan taze geliştirmeler dışında, her uygulama için ekranda görünmesini istediğimiz bildirim nesnelerini belirleyebiliyoruz. yani her uygulama için ayrı ayrı ses, uygulama işaretleri ve bildirim başlıklarını görüntüleme konusunda tercihte bulunabiliyoruz. ek olarak bildirim başlığının kalıcı veya geçici olmasını da sağlayabiliyoruz. bu yöntemle, oluşturduğumuz bildirim nesnelerini kilitli ekran, bildirim merkezi ve başlıklar görünümleri için sınırlayabiliyoruz. bildirim elementlerini bu şekilde sınırlayarak birkaç farklı konbinasyona ulaşmak mümkün oluyor. bu da kısmen daha esnek bir kullanıcı deneyimi sağlayabiliyor.

yukarıdaki paragraflarda, 11 ve 12 sürümleriyle eklenen özellikler için fazlaca pembe bir tablo çizdiğimi meselenin içinde olanlar hemen farkedecektir. eklenen özellikler oldukça yarım yamalak, kırpılmış ve alternatif senaryolar hiç hesaba katılmadan sunulmuş intibası uyandırıyor. çünkü; bildirim elementlerinin yapılandırılması olsun, bildirim önizleme ve gruplama ayarları olsun kendi içinde bir dizi problem ve özelleştirilebilirlik eksiği barındırıyor. bu halleriyle işlevsel özellikler olmaktan ziyade arayüz makyajı gibi görünüyorlar. önizleme gizleme ve gruplama çözümünü gerektiren senaryolar üzerinde çok düşünülmediği, işlev çeşitliliğine değil arayüz görüntüsüne odaklanıldığı çok açık. bu da malesef Apple'in genişletilmiş işlevler konusundaki muhafazakar tutumuyla paralel bir tercih. bu konuda çok katı davranılıyor; ısrarla alternatifli kullanımlara uyum sağlayacak esnek ayarlar sunulmuyor. bunun yerine meselenin etrafından dolaşılarak arayüz rahatlatılmaya çalışılıyor. Apple, işletim sistemi ve güvenlik politikası gereği kişiselleştirilebilirliği üçüncü parti uygulamalara devretmeyeceğine göre kendisi bir adım atmalı. takip eden başlıklarda bu konudaki önerilerimi okuyacaksınız. fakat bu önerilerin optimum durumu temsil ettiklerini ve tam kişiselleştirilebilirlik bakışıyla sunulduklarını unutmamalısınız. dolayısıyla bu özelliklerin hepsinin iOS'e gelmesini beklemiyorum. buna karşın önerilerimi okuduğunuzda mobil işletim sistemlerinin yaratıcılık ve işlev genişliği bakımından hala olgunlaşmamış ürünler olduklarını farkedeceğinizi umuyorum. hakkaniyetli bir değerlendirme için şunu da eklemeliyim; bir işlevin bir işletim sistemine entegre edilmesini etkileyen fazlaca faktör vardır ve bunlar çoğu durumda yazılımsal kısıtlarla ilişkili değildir. kullanıcı deneyimini tasarlamak başlı başına bir kıvam meselesidir.

bildirim elementleri ile ilgili sorunlar

kanımca; iOS bildirim ayarlarının temel sorunu, bildirim ekranlarında görüntülenecek bilginin sınırlarını belirlemeye yeterince imkan vermemesi. hal böyle olunca bildirim modeli farklı senaryolar için yeterince genişleyemiyor; çok kısıtlı bir kullanım alanına sıkışıyor. oysa, kullanıcı deneyiminin dallanıp budaklandığı bir dünyada bildirim modelinin çok daha esnek olması gerekiyor. aşağıda, bildirim elementleri, önizleme gizleme ve bildirim gruplamaya ilişkin eksiklikler ile daha esnek bir model için bu eksikliklere önerdiğim çözümleri bulacaksınız.

ilk meselemiz bildirim elementlerinin yeterince esnek olmaması ve önizleme gizleme sorunları olacak. başlıklar, sesler ve uygulama simgeleri gibi bildirim nesnelerinin birden çok katmanlı ve detaylı yapılandırılabilmesi gerekiyor. örnek olarak bildirim başlıklarına bakalım. bildirim başlıkları, bildirimlerin bilgi içeriğini taşıyan tek element olduğundan tüm bilgileri barındırmak zorunda. bu durum ilk bakışta farkedilmese dahi bir dizi pratik probleme sebep oluyor. özellikle önizlemenin gizlendiği durumlarda ve kilit ekranında başlığın taşıyacağı bilgiyi miktar ve kategori olarak sınırlayamamak can sıkıcı. meseleyi somutlamaya çalışalım. mesaj bildirimlerini düşünün. her bir mesajlar bildiriminin: mesajın hangi uygulamadan geldiği=mesajlar bildirimi, mesajı kimin gönderdiği=mustafa ayçelik ve mesaj içeriği=iOS bildirim modeline detaylı bakış şeklinde üç farklı katmanda bilgi taşıdığını farkediyoruz. kullanıcının, hangi katman bilginin hangi ekranda=bildirim merkezi+kilit ekranı+uygulama simgeleri gösterileceğini belirlemesi gerekiyor. zira, kişisel mahremiyetten tutun çalışma konforuna kadar bir çok sebep bildirim içeriğinin çeşitli senaryolarda kullanıcı denetiminde sınırlandırılması ihtiyacını doğurmuş durumda. bizler de özellikle mahremiyet kaynaklı ihtiyaçlar sebebiyle senaryonun içindeyiz. . ayrıca, giderek daha çok bildirimle muhattap olduğumuz mobil işletim sistemleri dünyasında içeriğin süzülmesi ve filtrelenebilmesi zamanla daha yüksek sesle istenir olacak.

bildirim elementleriyle alakalı ikinci problem, modelin ses ve titreşim modelleriyle yeterince bütünleşik olmaması. bazı uygulamalar bildirim seslerini özelleştirmeye imkan verseler de, bildirim ayarlarında standart olarak uyarı tonlarını yapılandırabildiğimiz bir yöntem yok. Apple bu sorunu çözmeli ve tüm uygulamaların bildirim tonunun değiştirilebileceği bir mekanizma oluşturmalı. bu iyileştirme sayesinde örneğin: bildirim başlık ve simgesini gizlediğimiz bir uygulama bildirim gönderdiğinde, uyarı tonundan bildirimi hangi uygulamanın gönderdiğini anlayabileceğiz. böylece hem mahremiyet ve kontrol konusunda avantaj sağlayacağız, hem de VoiceOver bildirimi okumak için odaklandığımız işi bölmeyecek. bu konforun sağlayacağı rahatlığı hayal etmenizi rica ediyorum. hatta, biraz daha ileri giderek her bildirim için titreşimlerin dahi özelleştirilebilmesi beklenebilir. hâli hazırda iOS titreşimleri özelleştirilebiliyor. gereken bu işlevin tüm bildirimleri kapsayacak şekilde genişlemesi. özellikle titreşim modelinin güncelleneceği bir iPhone serisi ile birlikte çok hoş olacaktır.

yazıyı uzatmamak adına bazı küçük pürüzlerin nasıl çözümlenebileceğine ve daha hassas ayrıntılara değinmedik. örneğin: bildirim içeriği katmanlarının tüm uygulamalar için geçerli genel ve evrensel şekilde nasıl tasarlanacağı meselesi gibi. fakat emin olabilirsiniz, hepsinin bir çözümü var. bu özellikler tek başlarına dahi bildirim yönetimi konforunu daha üst seviyeye çıkarabilir. ama özellikle aşağıda tartışacağımız bildirim kanalları özelliğiyle birleştirildiğinde çok etkileyici sonuçlar ortaya çıkacaktır.

gelelim bildirim kanalları özelliğine: iOS 12 ile gelen bildirim gruplama özelliği bildirim merkezindeki kalabalığı azaltmış olsa da hala yetersiz ve açık söylemek gerekirse çok basit ve ilkel. yapılması gereken, android'te olduğu gibi uygulamaların birbirinden farklı içeriklerinin bağımsız bildirim kanalları şeklinde dağıtılabilmesı. ne demek istiyorum? twitter uygulamasını örnek olarak alalım. uygulama içindeki bildirim ayarlarında da gördüğümüz üzere, twitter birbirinden farklı içerik kategorileri için bildirim gönderiyor. takip ettiğimiz kişiler tweet attığında, kendi tweetlerimize biri yanıt yazdığında, retwitt ettiğinde, tweetimiz beğenildiğinde, bizi biri takip ettiğinde, rehberimizdeki bir kişi twitter'a katıldığında vs... tüm bunlar, tek bir uygulamadan yani twitter uygulamasından geliyor. oysa, uygulama içinde hepsi ayrı birer bildirim kanalı olarak çalışsa, her bir kanal için bildirim elementleri yapılandırılabilir olsa ortaya her senaryoya uyum gösterebilecek kusursuz bir model çıkardı. bu konsept, yukarıda bildirim elementleri için önerdiklerimle birlikte kullanıldığında kullanıcıya eşsiz bir deneyim sunma potansiyeli taşıyor. konseptin mesajlaşma uygulamalarından haber uygulamalarına, sosyal medya uygulamalarından oyunlara kadar çok geniş bir kullanım alanı var. örneğin bu konsept ile bir haber uygulaması size son dakika haberlerini ayrı, ekonomi haberlerini ayrı, canlı yayın uyarılarını ayrı kanallarda iletebilir. böylelikle örneğin ekonomi haberleri için, belirlediğiniz bildirim sesini duyar ama başlık görmezken, canlı yayın duyurularını yayın başlığınıda içerecek şekilde yapılandırabilirsiniz. ya da x haber uygulamasından gelen ekonomi bildirimlerini tamamen kapatabilirsiniz. hatta, istediğiniz bildirim kanalını bildirim ekranı bazlı da ayarlayabilirsiniz. örneğin, spor haberleri cıhaz aktifken görülürken bildirim merkezinde görüntülenmez veya tam tersi...

olası senaryoları hayal etmeye devam edelim. kullandığınız alışveriş uygulamasının istek listenize eklediğiniz ürünün fiyatında değişiklik olduğunda sizi güçlü şekilde uyarmasını istersiniz. ama, ne biliyim ayakkabıda %20 indirim şeklindeki bildirimler çok da ilginizi çekmeyebilir. bildirim kanalları sayesinde bu iki farklı içeriği kendi önceliklerinize göre yapılandırma şansınız oluyor.

senaryo ve konbinasyonlar çok çok fazla. ama meselenin merkezinde içeriğin istenilen şekilde, istenilen ekranda, hem kullanıcıyı boğmadan hem de yeterince dikkat çekecek şekilde kullanıcı denetiminde yapılandırılabilmesi yatıyor. biraz rss deneyimine benzese de çok daha farklı ve esnek bir model. tamamen kullanıcı odaklı. zira, hangi uygulamadan hangi tür bildirimi hangi şekilde alacağınıza tamamen siz karar vermiş oluyorsunuz. tabi, uygulamalar onlarca farklı bildirim kanalı oluşturmayacaklardır pratik sebeplerle. fakat geliştirici için de konseptin avantajları var. ayrıca bu konsept Apple'in reklam ve cıhaz kullanım süresi politikalarıyla da tamamen uyumlu.

tüm bunlara karşın uygulama içi bildirim kanalı özelliğinin kafa karıştıracağını düşünebilirsiniz. bu sorun da varsayılan olarak bildirim kanallarının kapalı olmasıyla çözülebilir. kaldı ki, konsept hiç bir karmaşa içermiyor. standart bildirim yöntemlerine ek olarak, uygulamalar içeriklerini bağımsız üniteler olarak dağıtıyorlar.

bildirim ekranlarının değerlendirilmesi

bildirim ekranları derken;elementleri ayırırken de vurguladığım üzere bildirim nesnelerinin düştüğü ekranları kastediyorum. bunlar, cıhaz aktif durumdayken açılan bildirim ekranları, kilit ekranında bildirimler ve bildirim merkezi olarak ayrılabilir. bu ekranları değerlendirirken; yapılandırılan işlevlerin ilgili ekranlarda ne kadar pürüzsüz gerçekleştirildiği, mekaniğin hızı ve sorunsuzluğuyla elbet erişilebilirliğe bakacağız. şimdi sırasıyla bu ekranlara bakalım.

cıhaz açıkken açılan bildirim ekranları, bildirim mekanizmasının en işlek olarak kullanıldığı ve kullanıcı etkileşimine en açık ekranlar olarak karşımıza çıkıyor. bir uygulamayla çalışırken başka bir uygulamadan düşen bildirimleri bu ekranlar vasıtasıyla karşılıyor ve etkileşime geçiyoruz. mekanizmanın temellerini önceki yazıda çok tartıştığımızdan temel meseleler üzerinde durmayacağım. özetle şunu söyleyebilirim; bu mekanizma genel olarak iOS üzerinde oldukça pratik şekilde çalışıyor. özellikle bildirim nesneleri ve bildirim kanalları özellikleri geliştirildiğinde daha pürüzsüz bir deneyime ulaşılacak. fakat erişilebilirlik konusunda aynı ölçüde tatmin olmadığımı da eklemeliyim. körler, mekanizmayı çok kısıtlanmış şekilde kullanıyorlar. mekanizmanın sezgisel temelleri malesef sadece görenlere hitap ediyor. bir bildirim sesi duyurmak ve VoiceOver'ın odağı bölerek bildirimi okuması şeklinde bir kullanıcı deneyimimiz var fakat bu oldukça kısıtlı bir tecrübeye karşılık geliyor. aslında bildirim düştüğünde ekranın üstünden bildirime ulaşmak mümkün. ama burada da şöyle bir sorunla karşılaşılıyor; bildirim başlığı stili eğer geçici olarak ayarlanmışsa bildirime hakim olup etkileşime geçecek kadar vaktimiz olmuyor. bildirim ayarlarıyla ilgili beklentilerimiz karşılanırsa bu sorunlara da dolaylı bir çözüm bulunmuş olacak.

ikinci bildirim ekranımız kilit ekranı. burada gördüğümüz bildirimler, cıhazın başında değilken alınan son bildirimlerden ibaret. buradaki mekanizma da oldukça pratik olarak kullanılabiliyor. fakat bu ekranlar söz konusu olduğunda üzerinde durulması gereken başkaca meseleler var.

kilit ekranları son bildirimler hariç widget ekranını ve kamera ekranını dakapsıyor. bu ekran, başlı başına bir model olduğundan arayüz bakımından ayrı bir değerlendirmeye ihtiyaç var. yani buraya düşen bildirimleri bildirim modeli kapsamında tartışmak pek isabetli değil. ayrı bir yazıyla kilit ekranının da inceleneceği sözünü vererek devam edelim.

son ekranımız bildirim merkezi. bu ekranın işlevi üzerinde daha önce çokça durduğumuzdan tekrara luzum yok. daha ziyade, iOS özelinde oluşan problemlerden bahsetmeye çalışalım.

bildirim merkezi, kanımca iOS işletim sisteminin yumuşak karnı=zayıf noktası olmaya devam ediyor. sorunun merkezinde iOS bildirimlerinin kullanıcı tercihlerine dayalı olarak gruplanıp sıralanamaması yer alıyor. iOS 12 sürümüne gelinceye kadar bildirim merkezi her açıldığında tarih sırasına göre dizilmiş yüzlerce bildirimle karşı karşıya kalıyorduk. bu da haliyle pek pratik bir çözüm olmuyordu. o haliyle bildirim merkezi bir takvim görüntüsündeydi ki, iOS 10 öncesi merkezin işlevi buna yakındı zaten. iOS 12 sürümü ile sonunda bildirimlerin uygulamaya göre gruplanması özelliği geldi. fakat yukarıda da uzun uzun tartıştığımız gibi, bu özellik şu an için çok yetersiz. android bu sorunu bildirim kanalları özelliğiyle tamamen çözmüş görünüyor. erişilebilirliği konusunda benim yorum yapmam mümkün olmasa da, kağıt üzerinde çok hoş bir fikir. yukarıda önerdiğim bildirim kanalları özelliği de zaten buna dayanıyor.

ayrıca bildirim gruplamanın şu haliyle VoiceOver kullanıcılarının kullanım deneyimine olumlu bir katkısı olduğu da söylenemez. zira, bildirim gruplarının genişletip daraltılmasına yarayan mekanizma erişilebilirlik bakımından çok zevksiz tasarlanmış. bir bildirim grubunu genişletmek için çift dokunma ve ardından bildirimi bulma mekaniği çok zaman kaybettiriyor ve genişletip daraltma etkisini yaşatmaktan çok uzak. son tahlilde bildirim gruplama özelliği bildirim merkezini daha pratik yapamamış gözüküyor.

bildirim merkezindeki bir diğer problem bildirimlerin arşivlenememesi ve saklanma sürelerinin ayarlanamaması. bazı durumlarda bildirimi silmek yerine, arşivleyip göz önünden kaldırmaya ihtiyaç oluyor. yine aynı biçimde, bildirim merkezi 1 haftadan fazla bildirim saklamaya izin vermiyor. bunlar da bildirim merkezinin kusurları olarak dikkatimi çekiyor.

sonuç yerine

bildirim ayarları ve bildirim ekranlarını detaylıca incelediğimizi düşünüyorum. vardığımız sonuç, iOS bildirim modelinin sorunsuz bir kullanıcı deneyimi sunmakla birlikte esneklik bakımından daha çok yol katetmesi gerektiği oldu. iOS 13 ile beklentilerimizin ne denli önemseneceğini, Apple'in esneklik konusunda kararlı olup olmadığını anlayacağız. biz de 13 sürümü öncesi iOS kullanıcı deneyiminin kalbindeki yolculuğumuza devam edeceğiz. tabi bunu yaparken romantik bir kâşif olmaktan ziyade soğuk kanlı bir cerrah olmayı tercih ediyorum.("yoksa katil mi demeliydim")! bir sonraki yazımızın konusu kilit ekranı ve widget sistemi olacak. o zamana kadar kalın sağlıcakla...

Kategori: