iOS kullanıcı deneyimine bir bakış2: mobil bildirim modellerine genel bir giriş

merhabalar. iOS kullanıcı deneyimini tartıştığımız yazı dizimize birbirini takip edecek iki yazılık bir seri ile devam ediyoruz. serinin bu ilk yazısında, modil işletim sistemlerinin çok önemli bir parçası olan bildirim modellerini geniş şekilde ele alacağız. takip eden yazıda ise, iOS bildirim modelini inceleyeceğiz. yazı dizimizin misyonu gereği, bildirim modelinin adım adım nasıl çalıştığını anlatan bir kılavuzdan ziyade ilgili alanın genel iOS kullanıcı arayüzündeki yerini, erişilebilirlik tutarlılığını ve gelecek sürümlerde neler olabileceğini tartışacağız.

ilk sözler

hatırlamaya çalışalım; doksanlar ve iki binlerin ilk yarısında bilgisayar kullanım deneyimimiz nasıldı? masa üstü ve sistem tepsisi neleri içeriyordu? bu sorulara, windows merkezli bir bakışla windows 10 öncesi sürümler üzerinden cevap vermemiz mümkün. o dönem kullanıcı deneyiminin şimdiye kıyasla en ayırıcı vasfı durağanlığıydı dersem sanırım hata yapmış olmam. kullanıcı etkileşimi gerektiren uygulamalar çoğu zaman aktif pencerede çalışırdı, arka plandan uygulama çağırmaktan anladığımız ise sistem tepsisindeki ikona tıklamaktan ibaretti. fakat bu uygulamaların hemen hepsi işlemek için bizim o pencereyle ilgilenmemizi gerektirirdi; hatta arada fırlayan ipucu balonlarının daha sonra tekrar görülmesi de olanaksızdı. kısacası, aktif pencerede olmayan bir uygulamadan gelecek bir bilgi olacağı pek düşünülmezdi. bunun doğal sonucu olarak, özellikle bilgisayarına yeterince hakim olmayan kullanıcılarda, tek bir sistem tepsisi uyarısının aylarca değişmeden durduğu olurdu. son kullanıcı müdahalesi gerektiren bir çok uygulama hemen hemen böyle çalışırdı; gerçi, kullanıcıyı taciz eden, birden bire açılan pencereler ve onay ekranları hala tercih edilebilir olmasa da, bildirim nosyonunun özellikle windows tarafında konsepti zorladığını unutmamak lazım.

peki ne oldu? pc'de ihtiyacımız olmayan bildirim konsepti neden mobil tarafta vazgeçilmez oluverdi? kavrayabildiğim kadarıyla, birbirini zincirleme etkileyen bir dizi olay zaman içinde böyle bir dönüşümü zorumlu kıldı. neydi bunlar: en başta, mobil işletim sistemlerinin hızlı gelişimi ile uygulama kullanım alışkanlıklarımız değişmeye başladı. daha önce makinanın başına oturup yaptığımız sabit, görece uzun süreli ve az sayıdaki işler, en azından oransal olarak yerlerini hareket halinde yapılan, daha dinamik ve kısa süreli işlere bıraktı. bunu sosyal medya uygulamalarıyla başlayan başka bir çığır takip etti. web arayüzlerinden mulhem yeni bir uygulama konseptiyle karşılaşmaya başladık. çoklu platform uygulama geliştirmenin bol alternatifli yollarının çoğalması da bu süreci izledi. sürecin sonunda, eskiden kendilerinden web sitesi olarak söz edilen bir çok yapı birer modern uygulama oldular. bu uygulamalar kendileriyle teknik profesyonel işlerimizi halletiğimiz uygulamalardan ziyade, çok dinamik olan, dolayısıyla da düzenli düzensiz aralıklarla içeriklerini yenileyip etkileşimimize sunan uygulamalardı. dolayısıyla bu dinamik içeriği bir biçimde kullanıcıya sunmak gerekiyordu; mobil kullanım deneyimi bu merkezi ihtiyaç gözetilerek gelişti. tabi, bu yeni konseptin kendine has problemleri de vardı; hangi içerik, ne sıklıkta ve ne şekilde gösterilecekti? kullanıcının mobil cıhazla çok vakit geçirmesini mi, yoksa işini halledip bir kenara koymasını mı istiyorduk? yukarıdaki sorulara paralel olarak hangi seviyede bir arayüz esnekliğine ihtiyacımız vardı? bu ve benzeri sorular günümüzde modern mobil işletim sistemlerinin meşgul olduğu meseleler olarak canlılığını muhafaza ediyor. ilerleyen bölümlerde bu sorulara ve daha fazlasına yanıt arayacağız.

mobil bildirim modellerine giriş

bildirim modeli dendiğinde, uygulama bildirimlerinin bize gösterilme ve onlarla etkileşime geçme mekaniğimiz, bildirimlerin toplandığı arayüz parçaları ve bildirim ayarlarının toplu yönetimi gibi konuların bütününü anlıyoruz. kısaca, bir mobil işletim sisteminin bildirimleri gösterme, yönetme, gruplama yöntem ve mekanikleriyle tüm bunların sunumu bir bütün olarak bildirim modeli kapsamına giriyor. tanımın kapsamının genişliğinin de sezdirdiği üzere, mobil bildirim modelleri geliştirilirken çok fazla unsurun kaliteli ve dengeli bir bileşimine ulaşılmaya çalışılıyor. şimdi söz konusu unsurlara daha yakından bakalım.

bildirim modelleri geliştirilirken ilk bakışta birbiriyle çelişir gibi görünen beklentilerin aynı anda karşılanması temel bir zorumluluk olarak beliriyor. mobil bir bildirim modeli hem kullanıcıyı boğmamalı, hem de hiç bir uygulama bildirimini kaçırmayacağı şekilde tasarlanmalı. sürekli biçimde onay ekranları göstererek kullanıcıda tedirginlik uyandırmamalı ve işini bölmemeli; fakat buna karşın bildirim sayısından bağımsız olarak kolay yönetilebilir ve ulaşılabilir olmalı. ayrıca kullanıcılarda zamanla kökleşmiş davranışlarla uyumlu olmalı, kullanıcıyı iradesi dışında yönlendirmemeli, cıhazla etkileşime geçip geçmeme tercihini kullanıcıya bırakmalı ve kullanıcıya tercihini yapabilmesi için yeteri kadar özelleşmiş bilgiyi karmaşa oluşturmaksızın sunabilmeli. peki ama mobil bildirim modelleri böylesine farklı beklentileri nasıl uzlaştırıyor? elbette işlevleri arayüz parçalarına yayarak ve özelleştirilebilir ayarlar sunarak. yazması kolay! uygulamada durumun nasıl olduğuna bakalım.

arayüz parçaları derken, mobil işletim sistemlerinde hemen hemen birbirine benzer yapılarla karşılaşıyoruz. pratik kullanımda bir ayrım kolay olmasa da, bildirim modeli ihtiyaçlarını düşündüğümüzde modelin sınırlarını 3 basamakla ifade etmek mümkün. öyle bir model olsun ki:
1. kullanıcı, bildirimi atlamak isterse bildirimi görmeye zorlamayan bir arayüz düzeniyle hızlıca ana ekrana dönebilsin; aynı zamanda bildirimle anlık etkileşime geçip tekrar önceki uygulamaya dönmek kolay olsun.
2. bildirimlerin ekrandaki davranışları, ayrıntı düzeyleri ve gösterilecek içerik ayarlanabilsin. böylece, kullanıcı ulaşmak istediği bilginin türü ve sınırını belirleyebilsin ve kendi senaryosuna uygun olarak aygıtla etkileşime girip girmeyeceğine karar verebilsin. burada tabi, güvenlikten tutun kullanıcının özel tercihlerine kadar birden çok faktör devreye giriyor. mobil işletim sistemleri sundukları ayarlarla, birbirinden çok farklı profildeki kullanıcıların farklı senaryolar altındaki ihtiyaçlarına cevap vermeye çalışıyorlar.
3. bildirimlerin toplu görülebileceği bir merkez olsun. böylece, kullanıcılar gerek kaçırdıkları gerek tekrar görmeye ihtiyaç duydukları bildirimleri toplu halde görebilsin ve yönetebilsin. şöyle düşünün: eğer aygıtınızda 350 uygulama varsa, mail/mesajlaşma/web tarayıcı/haber/spor/oyun/çeşitli hava durumu ve konum uygulamaları/üretkenlik ve takvim uygulamaları, sağlık uygulamaları gibi..., bu kadar fazla uygulamadan gelen bildirimleri belirli zamanlarda kontrol etme ihtiyacı duymanız kaçınılmaz. tüm bu ihtiyaçları mobil bildirim modeli arayüzüne dağıttığımızda ise 3 arayüz modülüne ulaşıyoruz. şimdi bunların her birine ayrıntısıyla değinelim.

mobil cıhazla etkileşim halindeyken uygulama bildirimlerini ekrana taşıyan mekanizma: mobil bildirim modellerinin en görünür parçası bu, zira bizim müdahalemizle değil diğer uygulamaların tetiklemesiyle çalışıyor. geliştiriciler modelin bu parçasını tasarlarken hassas ayrıntıları gözetmek zorunda kalmışlar; gelen bildirimin çalışmamızı bölmemesi öte yandan gerekirse hızlıca bildirimle etkileşime geçilebilmesi için esnek ve pratik bir mekanizma geliştirmek gerekmiş. bu yüzden, bildirimin ekranın neresine konumlanacağı, rengi, uyarı sesi, bildirim içeriği, ekranda kalma süresi ve etkileşim mekaniği gibi ayrıntılar dikkate alınmış ve mobil işletim sisteminin tarzına uyumlu olacak şekilde ilgili ayrıntıların bir çoğunun denetimi kullanıcıya verilmiş. alt tarafı ekrana bildirim düşüren bir mekanik için bu denli hassas bir düzen kurulmasının sebebi elbet yukarıda da sıkça lafı geçen kullanıcı beklentileri. kendi deneyimimizden de aşina olduğumuz üzere, kullanıcı, uygulamalardan gelen bildirimleri anında görüp aksiyon almayı önemsiyor. fakat bunu yaparken taciz edilmekten, baskı altındaymış gibi hissetmekten, çalışmasının bölünmesinden de hoşlanmıyor. ve elbette bu işler için kullanacağı arayüz ve aayarların anlayıp uygulaması kolay şeyler olmasını istiyor.

bildirim merkezi: burası isminden de anlaşıldığı üzere, uygulama bildirimlerinin toplu bir akış halinde görülüp etkileşime geçildiği bir merkez. bu ekranlar mobil bildirim modelleri için çok önemli bir işlev icra ediyorlar. zira, her an mobil aygıtla etkileşim halinde olmadığımızdan, olsaktaa o anda başka uygulamalarla meşgul olmnak isteyebileceğimizden sistemde kurulu uygulama sayısına da bağlı olarak yüzlerce uygulamadan gelebilecek bildirimleri zamanında yakalayıp harekete geçemeyebiliyoruz. buna karşı şöyle bir itiraz öne sürülebilir; "her bildirim, uygulama ayarlarına da bağlı olarak bize gösteriliyor ise, neden bildirim merkezine ihtiyaç duyuyoruz!" bildirimlerin toplandığı ikinci bir ekranın işlevi ne? bu sorunun cevabı çok basit aslında, insan zihninin de bir öncelik sırası var ve telefonu elimize aldığımızda hızlıca önceliğimiz her ne ise ona odaklanıyoruz. bildirim eğer bizim için önemli bir uygulamadan gelmemişse göz ucuyla kontrol edip geçiyoruz, çoğu zaman onu dahi yapmıyor hemen ana ekrana düşüyoruz. ayrıca, gelen bildirimlerin kaybolmadığından yani arşivlendiğinden, dolayısıyla da istediğimiz zaman bu bildirimlere düzenli bir şekilde ulaşabileceğimizden de emin olmak istiyoruz. arayüz tutarlılığı için çok önemlidir bu. bildirim merkezinin akış görünümünde olmasının bir sebibi de budur. bu yolla geliştirici, gün içindeki tüm uygulama aktivitelerinin dökümünü önümüze koyarak, kendimizi daha düzenli hissetmemizi, yapılması gereken bir şey var ise yapmamızı, ve hepsinden önemlisi kontrolün bizde olduğu hissini duyumsamamızı ister.

bildirim ayarları: bu kısım tahmin edilebileceği gibi, yukarıda teferruatıyla deyindiğimiz işlemlerin ayrıntılı ayarlarını içeren arayüz parçasıdır. bu bölümde genel olarak hangi uygulamaların bildirim gönderebileceği, bildirim önizleme ayarları, bildirimleri gruplandırma, bildirim stili gibi ayarlar bulunur. söz konusu ayarlar, mobil bildirim modellerinin özelleştirilebilirlik-otomasyon dengesini temsil ederler. kullanıcı bu bölümde, işletim sisteminin sunduğu oranda ve sayıda ayarı kendi beklenti ve tercihlerine göre yapılandırır. bu bağlamda, işletim sistimine hakim yaklaşım elbet ayar çeşitliliğini belirleyen birincil unsurdur. örneğin, android esneklik tarafına daha yakınken; iOS otomasyon yaklaşımına yakındır. bu genel belirlemeye karşın, son 3 4 yıldır aradaki farkın ayırıcı vasfını kaybettiğini; android ve iOS arasındaki yaklaşım farkının törpülendiğini söylemek yerinde olacaktır. bu kısımda sunulan ayarların çeşitliliği dışında, ilgili ayarların kolay ulaşılabilir ve yapılandırılabilir sunulması da önemlidir. kullanıcıya ayar ekranlarında fazla zaman kaybettirilmemeli; seçenekler anlaşılabilir ve açık sunulmuş olmalıdır. günümüzde hem iOS hem de android bu konuda iyi noktadadır; yediden yetmişe her seviyedeki kullanıcı bildirim ayarlarını hızlıca yapılandırabilmektedir.

yukarıdakilere ek olarak, mobil bildirim modelinin kalitesini ve tercih edilebilirlik koşullarını etkileyen başkaca unsurlardan da bahsedilebilir. örneğin, her mobil bildirim modeli, tıpkı ana ekran modellerinde olduğu gibi parçası olduğu işletim sisteminin genel arayüz ve işlevsellik yaklaşımının bir ürünüdür. arayüzün diğer unsurları için yapılmış tercihler, bildirim modeli tasarlanırken de sürdürülür. sonuç olarak ortaya tutarlı ve bütüncül bir arayüz çıkar. bu sayededir ki biz bugün bir android ve ios kullanıcı deneyiminden bahsedebiliyoruz. daha basit bir ifadeyle, işletim sisteminin ruhu mobil bildirim modelinde kendini hissettirecektir. bu durumu daha iyi anlayabilmeniz için, iOS ve android kullanan kişilere neden o işletim sisttemlerini kullandıklarını sorduğunuzda aldığınız cevaplara bakmak yeterlidir. kuvvetle muhtemel verilen cevaplar arayüzü bir bütün olarak değerlendirecektir, arayüz elementlerini parça parça düşünen kullanıcılar sayıca çok azdır. çünkü, yukarıda da söylediğimiz gibi kullanıcı deneyimi çoğu kullanıcıda tek ve bütüncül bir deneyim olarak hissedilmektedir. "iOS kullanımı kolaydır; android esnek ve özelleştirilebilirdir" vs... bunlar ilk bakışta önyargı gibi görülseler de, arayüzün kullanıcıda oluşturduğu algıyı temsil ettiklerinden önemsenmelidirler.

buraya kadar denilenlerden anlıyoruz ki: iyi bir mobil bildirim deneyimi, dinamik uygulama içeriklerini kullanıcıya hızlıca ulaştırıp pürrüssüz şekilde etkileşime sokabildikçe ve bunu yaparken özelleştirilebilirlik ile otomasyon arasında bir kıvam tutturabildikçe farkını hissettirebiliyor. formül doğru uygulandığında, ortaya ya esneklik etkisiyle kontrolün kullanıcıda olduğu hissi ya da otomasyon etkisiyle her şeyin yolunda, yani doğal akışında gittiği hissi çıkıyor. sonuç olarak, her halikarda tüm uygulama bildirimlerini takip edebilir ve yönetebilir oluyoruz.

tüm bu yazılanlar meselenin çok boyutluluğunu ortaya koyabilmek içindi. elbette, son kullanıcı cıhazı kullanırken hadiseye her zaman böyle bakamayabilir. mobil bildirim modellerini değerlendirirken daha özet ölçütlere hepimizin ihtiyacı var. benim önerim, cıhazlarınızı kullanırken kendinize şu soruları sormanız.
1. mevcut bildirim düzeni yapmak istediğim görevi istediğim anda gerçekleştirmeme ne kadar yardımcı oluyor? yani çalışmamı bölmeden ve bildirimleri kaçırmadan görevler arası geçişler ne kadar pratik? çalışmam, uyarılar ve etkileşim gereken ekranlarla ne kadar bölünüyor?
2. mobil işletim sistemi ilk maddedeki şartları dengeli biçimde sağlamak için ne ölçüde esneklik sunuyor? kontrol ne kadar bende veya tam tersi ayarlar ne kadar otomatize? bu sorular, bu yazıda hayli genişlettiğimiz bildirim modeli meselesini son kullanıcı için pratik şekilde değerlendirmeye yardımcı olacaktır sanıyorum.

mobil tarafta bildirim modeli nosyonuna neden ihtiyaç duyulduğunu yazının buraya kadar olan kısmında sezdirmeye çalıştım, şimdi ise günlük hayattan bir senaryoyla durumu somut hale getirip çeşitli pratik problemleri ön plana çekmeye gayret edeceğim. bir mobil cıhaz kullanıcısı olarak kendinizi düşünün: sıklıkla kullandığınız mesajlaşma uygulamalarınız var ve bu uygulamalardaki kişi ve gruplarınızla günlük olarak belkide yüzlerce mesajı bulan bir sohbet trafiğine sahipsiniz. mesajlaşma uygulamaları yanında birden fazla sosyal medya hesabınız var ve bu uygulamalarda da kendi ilginize göre geniş bir alanda içerik takip ediyorsunuz. eh heralde en az bir mail hesabınız da vardır! oradan da sürekli bir içerik akışı söz konusu olmalı. ya standart internet kullanımınız? takip ettiğiniz bloglar, forumlar, özel amaçlı siteler!...aynı zamanda takip ettiğiniz haber ve spor kaynakları, ekonomi ve teknoloji haberi veren kaynaklar da var. bunlar için de ayrı ayrı bir çok uygulama kullanmanız muhtemel. durun daha bitmedi: kullandığınız banka uygulamalarıyla da günlük finansal işlerinizi hallediyorsunuz. bu kadarla da kalsa iyi: günlük işlerinizi planladığınız, notlar aldığınız, hatırlatmalar oluşturduğunuz takvim ve yapılacaklar listesi uygulamalarınız var. bununla da bitmiyor: kullandığınız ofis uygulamaları, çizim, müzik, fotoğrafçılık gibi yaratıcı işler için de uyggulamalar kullanıyorsunuz. biraz oyun oynamak herkese iyi gelir! merakınıza göre en az bir oyun oynuyorsunuz ve bu oyun da sizin için günlük içerik üretiyor. yazarken ben sıkıldım ama hala bitmedi! kullandığınız bulut uygulamaları, dosya yöneticileri, adres defteri uygulamaları, kitap okuduğunuz uygulamalar, metin editörleri, navigasyon uygulamaları, alışveriş uygulamaları, özel amaçlı bir çok uygulama ve dahası... tüm bu uygulamaların gün içerisinde sürekli ama sürekli ürettikleri içerikle nasıl başa çıkacaksınız? zaman kaybetmeden, iş akışınız aksamadan ve o anki çalışmanızı, odaklanmanızı bölmeksizin; istediğiniz zamanda bu içerikle nasıl etkileşime geçeceksiniz?

mobil bildirim modelleri dediğimiz sihirli icat tam olarak bu sorunu çözüyor. eğer bildirim modelleri varolmasa yahut çalıştıkları gibi verimli çalışmasa mobil kullanıcı deneyimi çok büyük yara alırdı, işler yetişmezdi. sabah işe geç kalır, bugün yetiştireceğimiz raporu yetiştiremez, bize yazılan mesajlara asla zamanında dönemez, arkadaşlarımızın doğum günlerini kaçırır, filanca üründeki %20'lik indirimden haberdar olamaz, gündemdeki en sıcak gelişmeleri en son öğrenir, takip ettiğimiz bir dizi, film veya podcastın yayınlandığından haberdar olamaz, hasılı günlük hayat aktivitelerinde hep geride kalırdık. dahası, böyle bir senaryoda işlerimizi tam zamanında yapmanın tek yolu mobil cıhazı elimizden hiç düşürmemek olurdu. hatta 24 saat cıhazla etkileşimde bulunmak yine de yetmeyebilirdi; çünkü işlerimizi bir öncelik sırasına koymak mümkün olmadığından hiç bir işe tam odaklanamaz, sürekli bölünürdük. abartıyor muyum? kısmen... ama mobil işletim sistemlerindeki bildirim modellerinin hayati önemde olduğunu tam kavrayabilmemiz için böyle bir senaryoya ihtiyacımız vardı.

sonuç

mobil işletim sistemlerindeki bildirim konsepti kullanım esnekliğini arttırmak, cıhazın kontrolünü bize vermek ve alternatifli bir tecrübe sunabilmek için geliştirildi-geliştiriliyor. bu yazıda modeli genel olarak tartıştık. bundan sonraki yazıda sistemin iOS için ne anlama geldiğini, esnekliğini, avantaj ve dezavantajlarını ve elbet erişilebilirliğini inceleyeceğiz. tabi, fal bakmayı da ihmal etmeyecek; yapılabilecek geliştirmelere dair de kelam edeceğiz.

Kategori: