Toast bildirimleri kötü UX’tir

 (maxschmitt.me)
2 puan yazan GN⁺ 2024-08-21 | 2 yorum | WhatsApp'ta paylaş
  • Toast bildirimlerinin temel zayıflığı, kullanıcının mevcut dikkat noktası ile geri bildirim konumunun ayrılması; bu yüzden az önce yapılan eylemin sonucunu hemen ilişkilendirmenin zorlaşmasıdır
  • YouTube’un kaydetme akışında bakış, sağdaki Save düğmesinden ortadaki modala, ardından sol alttaki toast’a taşınır; etkileşim kesintiye uğrar ve gecikme sırasında yükleme göstergesi de yoktur
  • Onay kutusu değiştirildikten sonra, en güncel onay mesajını görmek için önceki toast’ın kaybolmasını beklemek gerekir; toast’taki Undo düğmesi de onay kutusuna tekrar basmanın yeterli olduğu durumlarda gereksizdir
  • Daha iyi yöntem, geri bildirimi eylemin gerçekleştiği konumun içine koymaktır; çalma listeleri düğmenin altında gösterilebilir ve onay kutusu değişirken ilerleme durumu yükleme göstergesi ile belirtilebilir
  • Toast’tan daha kötüsü hiç geri bildirim olmamasıdır; bu nedenle daha iyi bir geri bildirim tasarlamak veya uygulamak için zaman yoksa toast, hiç olmamasından iyidir

Toast’ın temel sorunu

  • Toast bildirimleri genellikle kullanıcının dikkatinin yöneldiği konumdan uzakta görünür
  • Geri bildirim, az önce basılan düğmeden veya düzenlenen alandan farklı bir yerde ortaya çıktığında, kullanıcının eylem ile sonucu ilişkilendirip anlaması zorlaşır

YouTube kaydetme akışının sorunu

  • YouTube örneğinde kullanıcı, ekranın sağındaki Save düğmesine tıkladıktan sonra sırasıyla ekranın ortasındaki modali ve sol alttaki toast’ı görür
  • Bu akış bakışı birden çok konuma taşır ve geri bildirimin de hemen anlaşılmasını zorlaştırır
    • Toast, yükleme göstergesi olmadan gecikir
    • Modal içinde onay kutusu açılıp kapatıldığında, en güncel onay toast’ını görmek için önceki toast’ın kaybolmasına kadar birkaç saniye beklemek gerekir
    • Toast’taki Undo düğmesi gereksizdir; çünkü kullanıcı onay kutusuna tekrar tıklayabilir

Toast olmadan çözme yöntemi

  • Basit bir yeniden tasarımla aynı geri bildirim toast olmadan da ele alınabilir
    • Çalma listelerini modal yerine düğmenin hemen altında gösterme
    • Onay kutusu açılıp kapatılırken yükleme göstergesi gösterme
    • Yükleme göstergesi kaybolduğunda eylemin tamamlandığını doğal biçimde anlama
  • Geri bildirim kullanıcının işlem yaptığı konumda kaldığı için ayrı bir toast’a gerek yoktur

Gmail ve kopyalama geri bildirimi örnekleri

  • Gmail’de bir e-posta arşivlendiğinde onay toast’ı görünür
    • Ancak e-postanın listeden kaybolması bile arşivlemenin başarılı olduğunu zaten gösterir
    • Yine de geri alma işlevi ve klavye kısayolları kullanıldığında toast geri bildirimi faydalı olabilir
  • Panoya bir şey kopyalandıktan sonra toast gösterilen örnekler de vardır
    • Örnekte düğmenin kendisi zaten onay durumunu içerdiği için toast tamamen gereksizdir

Yine de geri bildirim gereklidir

  • Toast’tan daha kötüsü hiç geri bildirim olmamasıdır
  • Daha iyi bir geri bildirim mekanizması tasarlamak veya uygulamak için zaman yoksa toast, hiç olmamasından iyidir

Cakedesk’in toast’tan kaçınma yöntemi

  • Cakedesk, çevrimdışı öncelikli, abonelik ücreti olmayan bir fatura uygulamasıdır ve uygulama içinden e-posta gönderilebilir
  • E-postanın Send düğmesine basıldıktan sonra toast ile geri bildirim vermek yerine, durum değişiminin aynı akış içinde devam etmesi sağlanacak şekilde tasarlanmıştır
    • Gönderilmemiş faturaların listesinde Send düğmesi bulunur
    • E-posta gönderimi sırasında modal açık kalır ve gönderim düğmesinde gönderiliyor durumu gösterilir
    • Gönderim başarılı olduğunda e-posta ekranın dışına doğru animasyonla çıkarak gönderimin tamamlandığını belirtir
    • Listedeki Send düğmesi Paid onay kutusuna dönüşür; böylece e-postanın gönderildiği doğrulanır ve bir sonraki yararlı eyleme geçilir
  • Kullanıcı, bağlam düğmesine basarak e-postanın gönderilip gönderilmediğini de kontrol edebilir

İlgili okumalar

2 yorum

 
wkang586 2024-08-26

Yani kötü olan şey kötü toast'lar, öyle mi??
 
GN⁺ 2024-08-21
Hacker News yorumları

  • https://en.wikipedia.org/w/index.php?title=Toast_(computing)

  • İkna olmadım. Argümanın çoğu, yinelenen UX kötü UX'tir gibi görünüyor.
    Bir e-postayı arşivleyince listeden kaybolduğu için zaten başarılı olduğunu ima ettiği ya da düğmede onay işareti olduğu için toast'ın gereksiz olduğu örneklerine güçlü biçimde katılmak zor. Aynı içeriği aynı anda farklı yollarla iletmek bir hata değil, bir özelliktir; insan dilinin genelinde de vardır. Çünkü ideal olmayan koşullarda bile mesajın iletilmesini sağlar.
    Toast, her eylemin durumunu tek bir standart yolla bildirir ve mümkünse geri alma da sunar; böylece kullanıcı kalıbı hızla öğrenebilir. Eylemin yakınındaki ek göstergeler de değerlidir, ancak çoğu zaman toast ile birlikteyken anlamı netleşir. Toast'ı kaldırıp yerine birden çok somut gösterge koyarsanız, kullanıcı yalnızca bağlamdan “artık bitti” anlamına gelen çeşitli ifadeleri öğrenmek zorunda kalır. Yaşlılar, görme engelliler ve çocuklar için özellikle iyi olmayabilir.
    Gerçekten engel olmadığı sürece toast kötü UX değil, yinelenen UX'tir; UX tasarımcıları da yinelenmeyi ortadan kaldırmaya takıntılı olmamalı.

    • Ne yazık ki ikisi aynı şeyi iletmiyor.
      YouTube örneğinde onay kutusu %100 iyimser güncellemedir; toast bildirimi ise arka uca asenkron gönderilen isteğin başarılı olduğu anlamına gelir. E-posta arşivleme de aynı şekilde: mesaj iyimser biçimde listeden kaldırılır, toast ise gerçekten arşivlendiğini gösterir.
      Değişikliği commit etmek başarısız olduğunda toast almayı tercih ederim. Genelde toast'ın bir anda belirmesi yapmakta olduğum işten dikkatimi koparıyor; eylemin gerçekleştiği yerden ekranda uzaktaysa daha da dikkat dağıtıcı oluyor.
    • Hayır, toast kötüdür. Görüş alanımın ya da dikkatimin çevresinde yer alan mesajlar, örneğin geniş monitörün bir kenarında beliren mesajlar, aktif olarak kafa karıştırır. Ben burada bu sorunu hallediyorum, öte yanda bir şey parlıyor. Okumak için odağımı kaydırırken yarısı kaybolup gidiyor.
      Mesajı kullanıcının dikkatinin zaten yöneldiği yere koymak gerekir. UI bakışımı oraya yönlendirdiyse, orada gösterin demek bu.
    • Bilgisayarı çoğunlukla metni ve fare/parmak imlecinin çevresini büyüten bir büyütme aracı ile kullanıyorum. Toast'lar ve bildirimlerin çoğu çalıştığım yerde olmadığı için neredeyse hepsini kaçırıyorum. Benim kullanım biçimimde yalnızca etkileşimde bulunduğum öğenin yakınındaki geri bildirim değerli.
    • “İletişimde yineleme bir özelliktir, hata değil” deniyor ama gürültü niteliğinde bilgi çok fazla olursa kullanıcı bunları görmezden gelmeyi öğrenir; araya bazen gerçekten önemli bilgi karıştığında sorun çıkar.
      Çıkarılacak ders şu: kesin olarak gerekli olmayan bilgiyi kullanıcıya göndermeyin.
      Daha fazla okuma:
      https://en.wikipedia.org/wiki/Banner_blindness
      https://en.wikipedia.org/wiki/Alarm_fatigue
      https://en.wikipedia.org/wiki/Inattentional_blindness
      https://en.wikipedia.org/wiki/Habituation
    • Önerilen iyileştirmenin kastettiği şeyin şu olduğunu düşünüyorum: Kullanıcının etkileşimde bulunduğu UI öğesinin mevcut durumu yeterince aktarmadığından endişeleniyorsanız, kullanıcının dikkatini bölen ve hızlıca okuyup doğrudan ilişkilendirmesini gerektiren ikinci bir öğe eklemeyin; o öğenin kendisini iyileştirmelisiniz. Başarısızlığı, kullanıcının etkileşim kurduğu öğenin bağlamı içinde iletmek gerekir ki bağlantı açık olsun.
      Toast, en kötü durumda, bağlam olmadan kullanıcıya iletilmesi gereken son çare olarak mantıklı olabilir. Örneğin kullanıcı bir oynatma listesi işaretini kaldırıp kayıt sırasında oynatma listesi listesini kapattıysa ve kayıt başarısız olduysa, eylemin bağlamı kaybolduğu için ekranın herhangi bir yerinde bilgiyi gösteren bir toast anlaşılabilir.
      Yine de kullanıcının hatayı doğru anlamasını istiyorsanız toast büyük olasılıkla en iyi seçenek değildir. YouTube gibi kullanıcının ürün olduğu reklam tabanlı uygulamalarda kullanıcının bu tür hataları kaçırması çok umursanmayabilir, hatta istenebilir; ama iş uygulamalarında kullanıcının toast'ı kaçırmasına ya da başka bir hatayla karıştırmasına bel bağlamak istemezsiniz. Genelde kullanıcı için ilgili öğeyi yeniden açıp hatayı bağlam içinde göstermek daha yardımcı olur. Oynatma listesi listesini açıp değişikliğin kaydedilmediği gerçeğine dikkat çeken bir animasyon verebilirsiniz. Sistematik olarak uygulaması zor bir ideal olabilir ama idealde her zaman bağlam içindeki hatayı görmek gerekir.

  • En kötü yanı, toast’ların çok hızlı kaybolması ve zaten başarılı olması beklenen işlemlerde bile gereksiz yere dikkat çekmesi. İkisi birleşince özellikle sinir bozucu oluyor. Dikkatiniz gereksiz yere dağılıyor ama mesaj çok hızlı kaybolduğu için gerçekten önemli bir şey olup olmadığını anlayamıyorsunuz. Tersine, çok uzun süre kalıp hemen bakıp kullanmak istediğiniz arayüzün bir bölümünü kapatan türleri de var.
    Geleneksel masaüstü yaklaşımı daha iyi. Hata mesajlarını kaçırılmaması için modal olarak göstermek, başarı mesajlarını ise süre sınırı olmadan sürekli görünen durum çubuğunda, rahatsız etmeyen düz metin olarak sunmak. Hata modali yoksa kullanıcı işlemin başarılı olduğunu varsayabilir; doğrulama gerekiyorsa zaman baskısı olmadan durum çubuğundan kontrol edebilir. Ek bilgiler de içerebilir.
    Bazı uygulamalar durum çubuğu mesaj geçmişini pop-up olarak da gösterir. Bu yaklaşımda durum çubuğu, komut satırı terminalinin son çıktı satırı gibidir; önceki çıktılar da geri çağrılabilir.

    • Ek olarak, bazı toast’lar kullanıcının ihtiyaç duyduğu önemli bilgileri gösterir ama çok hızlı kaybolur; toast boyut sınırlaması yüzünden içerik de eksik kalır.
      Kaçırdığım içeriği görmek için sık sık bildirimlere giriyorum. Önemli görünmüştü ama tamamını okumaya zamanım yetmemişti. Orada kesilmiş bir mesaj gibi görünen öğeye dokunduğumda tam bağlama götürmesini bekliyorum; ama gerçekte bildirim kayboluyor, yalnızca uygulama açılıyor ve ilgili soruna deep link yapılmıyor. Sonra uygulamanın standart arayüzünde görünür de olabilir, görünmeyebilir de; o sorunu arayıp durmak gerekiyor.
      Bunu sayısız kez yaşadım ve her seferinde böyle bir sistemi tasarlayan kişiye öfkeleniyorum.
    • Toast’lar, sonradan ne olduğunu geriye dönük görebileceğiniz bir olay günlüğü bir yerlerde varmış hissi veriyor. Gerçekte erişilebilir bir olay günlüğü yok; toast mesajı zaman aşımına uğrayıp kaybolduğunda sonsuza dek kayboluyor.
    • Bir düşünce deneyi olarak: toast ekranda ne kadar süre kalmalı? Kullanıcıya okuması için zaman tanımalı, ama kullanıcının ne zaman ekrana bakacağını ve okuma hızını bilmediğiniz için güvenli bir üst sınır yok.
      Bugün oğlumla bu sorunu yaşadım. Okuma hızını geliştirmeye çalışıyor; birlikte yeni bir uygulama kullanıyorduk, toast’lar sürekli çıkınca takip etmekte zorlandı ve dikkati dağıldı. Sonunda benim sesli okumam gerekti. Mesajlar daha uzun süre kalsaydı ek yardım olmadan da başarabilirdi.
    • Daha iyi çözüm, başarıyı varsaymak ve bu tür mesajları yalnızca hata oluştuğunda göstermektir.
    • En kötü toast uygulaması, arayüz öğelerini gerçekten kapatıp toast kaybolana kadar görünmelerini ve tıklanmalarını engelleyendir.

  • YouTube’da daha iyi bir örnek var.
    https://www.youtube.com/feed/history adresine gidip sağdaki “Comments”a tıklayın ve bir yorumu silin; silinmek üzere olduğuna dair bir toast çıkar, 1-2 saniye sonra silindiğine dair bir toast daha çıkar.
    Birkaç yorumu hızlıca peş peşe silerseniz önce birden fazla silinme bekliyor toast’ı çıkar, 1-2 saniyelik gecikmeden sonra her onay toast’ı sırayla görünür. Gerçek silme işlemi de sıralı ilerlediği için tüm onay toast’larını beklemek gerekir. 10 yoruma 2-3 saniye içinde tıklamış olsanız bile onay 10 saniyeden uzun sürer.
    Canlı sohbet yorumları için de aynı:
    https://myactivity.google.com/page?page=youtube_live_chat&co...

  • “Toast’taki Undo düğmesi gereksizdir, çünkü kullanıcı onay kutusuna yeniden tıklayabilir” kısmına genel olarak katılmıyorum. Yanlışlıkla bir yere tıkladığınızda ama tam olarak nereye tıkladığınızı bilmediğinizde ve yalnızca mesaja bakıp kolayca geri alacak kadar uygulamayı iyi tanımadığınızda geri al çok iyidir.

    • Bu somut örnekte geri alma düğmesi zaten var: bizzat onay kutusu. Sorun, onay kutusunun göstermesi gereken kesin durumla uyuşmaması. İşaretlediğinizde birkaç saniye boyunca işaretli görünüyor ama video henüz kaydedilmiş olmuyor; işareti kaldırdığınızda da toast çıkana kadar henüz kayıttan çıkarılmış olmuyor. Tekrar tekrar işaretleyip kaldırırsanız nihai durumun ne olduğunu bilemezsiniz.
    • Bunu bazı sistemlerde yaşadım. Az önce yanlış öğeyi değiştirdiğinizi biliyorsunuz ama hangi öğe olduğunu bilmiyorsunuz ve elinizde ipucu yok. Hiçbir şey değişmemiş olma ihtimali de var, ama emin olamadığınızda bu özellikle sorun oluyor.
      Uç bir örnek olarak, arkanız dönükken bir topun raftan yuvarlanıp klavyeye çarptığını düşünün. Bir şey değişti mi? Ne değişti? Nasıl düzeltilir?

  • Toast’ın anlamlı olduğu tek durum vardır: kullanıcının o anki eylemiyle ilgisi olmayan bir bildirim olduğunda. Artık ortadan kalkmış Growl’un ortaya koyduğu OS türü bildirimlere benzer durumlar
    Kullanıcı eylemine verilen geri bildirim, o eylemin bağlamı içinde gerçekleşmelidir. Asenkron bir eylemse bunun açık olması gerekir; geri bildirim de ilgili işin işleme kuyruğuna alındığını hemen göstermelidir. Bu durumda geri bildirim, iptal etme ve kuyruğa erişim; daha da iyisi ilerlemeyi görebilme seçenekleri sunmalıdır

    • Bir senaryo daha eklemek istiyorum. Genelde geri bildirim verilecek UI öğesinin zaten kaldırıldığı ama yine de geri bildirim göstermek istediğiniz durum
      Bir işi panodan kaldırdıysanız, o işin üzerinde geri alma yöntemini gösteremezsiniz. Klavye kısayoluyla geri alabilirsiniz ama kullanıcı bunu görsel olarak nasıl bilecek?
      İş listesinde yalnızca işler olmalı; bu yüzden iş yerine bir not koymazsınız. Sadece mesaj gösteren türetilmiş bir iş gibi bir şey de oluşturmazsınız. Bu, iş bileşenine işlevsiz bir niyet enjekte etmek olur. Kullanıcıya hiç haber vermemek de istemem. İşin kaldırıldığı açık olsa da tek tıklamayla gerçekleşen, tedirgin edici bir eylemin nasıl geri alınacağı açık değildir. Öte yandan her iş silme işleminden önce can sıkıcı biçimde onay da istemem. İş listesinin temel işlevi olduğu için anında yapılabilmeli ve anında geri alınabilmelidir
      Bu tür küçük özel durumlar çok olacaktır. Toast’lar bir nedenle icat edildi. İnsanların onları sevimli bir şekilde kötüye kullanmış olması, belirli senaryolarda somut olarak yararlı olmadıkları anlamına gelmez
    • Kullanıcı bir işi başlattıktan sonra vakaların %99’unda o işi arka plana gönderip başka bir şey yapmak istediği modal işlemlerde, böyle bir geri bildirim nereye verilmeli?
    • Mevcut kullanıcı eylemiyle ilgili olan ama o anda görünen ekran alanının dışında kalan örnekler de var. USB bellek takmak veya donanımla ilgili başka bir işlevi çalıştırmak gibi
      Bu tür eylemlerin ekranda bir bağlamı yoktur ve çoğu zaman ek işlem gerektirir. Ek işlem olmasa bile, kullanıcının eyleminin algılandığını doğrulamak kesinlikle faydalıdır
    • OS türü bildirimleri Growl’un icat ettiğini söylemiyorum. Growl 2004’te çıktı; Windows XP’de ise 2001’de bildirimler vardı. Clippy’nin mesajlarını bildirim sayarsak en azından Microsoft Bob’a (1995) kadar geri gidebiliriz

  • Kafası karışanlar için: Bu yazı kızarmış ekmek [1] hakkında değil, bir UI widget türü [2] hakkında
    [1] https://en.wikipedia.org/wiki/Toast_(food)
    [2] https://en.wikipedia.org/w/index.php?title=Toast_(computing)

    • Kötü iletişim paradigmasını ele alan bir yazının, burada toast kelimesinin ne anlama geldiğini açıklamamış olması ironik
      Sayfadaki en önemli kelime bu; teknik okurlar arasında bile bu terimi anlamayanların olduğu belli
      Yine de fırıncılık ve kahvaltı tarifleriyle ilgilenen okurlar sayesinde etkileşim daha da artmış olabilir

  • “Toast’taki Undo düğmesi gereksiz, çünkü kullanıcı checkbox’a tekrar tıklayabilir” iddiasına gelirsek, bu özelliği özellikle takdir ediyorum. Bir e-postayı arşivlediğimi sanarken toast’ın bana spam bildirme düğmesine bastığımı söylediği sayısız kez oldu. Yoksa hiç fark etmeyecektim
    Asıl metnin gözden kaçırdığı toast’ların bir başka temel meselesi de web işlemlerinin asenkron olması. İşlemin başarılı mı, başarısız mı olduğunu, hatta sunucuya kaydedilip kaydedilmediğini bile bilemezsiniz. Toast, sunucu durumuna dair asenkron güncelleme verir
    Elbette bazı toast’ların sinir bozucu olduğuna, önemli UI içeriğini kapattığı ve kapatılamadığı durumlar olduğuna katılıyorum

    • Asıl metin toast’ın amacını tamamen ıskalamış. Bazı kullanıcı eylemleri 1) yanlışlıkla yapılabilir ve 2) sık sık tekrarlanır; bu yüzden onay kutularıyla iyi uyuşmaz
      Bu nedenle yanlışlıkla bir şeye bastığınızda e-posta birden gelen kutusundan kayboluyorsa, geri alma düğmesi olan bir toast’a ihtiyaç vardır. Hiçbir şey yapmadan dururken yanlışlıkla bir düğmeye yaslanıp toast birden görünürse, onun orada olmasına sevineceksiniz. Mümkünse yapılan eylemin açıklaması ve geri alma düğmesi olmalı
      Gimp’te Tab’a basınca tüm UI gizlenir ve kısayolu bilmiyorsanız geri getirmenin yolu yoktur. Görsele odaklanmak isteyen sanatçılar için iyi bir özelliktir. Ama yanlışlıkla bastıktan sonra “gimp how to fix interface disappeared” diye aramak zorunda kaldığım anda, undo düğmesi olan bir toast’ı ne kadar çok istediğimi anlatamam. Bilgisayara alışkın olmayan birinin nasıl tepki vereceğini hayal bile edemiyorum

  • Toast’lar kötü UX olabilir. Genelde tek geri bildirim olduklarında böyledir; ama başka öğelerle birlikte kullanıldıklarında harikadırlar
    Sayfa yönlendirmesiyle birlikte çıkan onay toast’ı, gönderimin başarılı olduğuna dair ek bir gösterge olarak iyidir
    Standart form doğrulama göstergeleriyle birlikte çıkan uyarı veya hata toast’ı, kullanıcının bir şeyi değiştirmesi gerektiğine dair mükemmel bir ikincil gösterge olur
    Belirtilmemiş hatalar için genel bir yakalama mekanizması olarak uygulanırsa, kullanıcıyı hata sayfasına göndermeden sayfa durumunu koruyabilir
    Tek araç olarak değil, araç kutusundaki araçlardan biri olarak kullanıldığında iyi bir seçenektir

  • Toast bildirimlerinden daha kötüsü de var: gizli kayan paneller. Temelde varsayılan olarak gizli bir toast gibi; bazı işlemler için gerekli ama hiç sezgisel değil, bulunamıyor da keşfedilemiyor da. En kötü deneyimi, başka birinin telefonunda Waze kullanırken yaşamıştım. Bir şey yapmam gerekiyordu ama ne olduğunu hatırlamıyorum; ekrana boş boş bakıp ne yapmam gerektiğini tahmin etmeye çalıştım. Sonunda o kişi telefonu alıp sağdan gizli paneli kaydırarak gösterdi.
    Yer kazandırdığını anlıyorum ama gerçekten saçmalık. Bir UX uzmanı kullanıcının bunu tahmin etmesini nasıl bekler? Günümüzde arayüzler, çocuk gibi her yere dokunup kurcalayarak keşfeden insanları varsayarak mı yapılıyor?

    • Kullanıcı bunu biliyorsa ve ana panel 1, kenar çubuğu 2'den fazlası yoksa, sağa/sola kaydırarak kenar çubuğunu açan UX'in iyi olduğunu düşünüyorum.
      Discord mobil uygulaması eskiden hem sol hem sağ kenar çubuğu için bu yöntemi kullanıyordu; sonra bir noktada birileri “kaydırarak yanıtla” hareketinin uygulama içinde gezinmeden daha önemli olduğuna dair harika bir fikir buldu ve artık sağ kenar çubuğunu görmek için küçük, belirsiz bir düğmeye basmak gerekiyor.
    • Snapchat'i kurar kurmaz ne kadar berbat olduğunu hemen anladığımı hatırlıyorum. Farklı köşelerde farklı işlevler vardı. Böyle şeyler yasa dışı olmalı.
    • Tamamen katılıyorum. iOS zaten doğal olarak bunlarla dolu; ekran alanı bol olan tabletlerde bile böyle.
    • Çoğu “toast” için artık terimi biliyorum ama bunların gereksiz tekrar olduğunu ve işe yaramadığını düşünüyorum. Genelde tamamen kaçırıyorum. Genel olarak zararsız olduklarını düşünüyorum ama önemli bilgileri iletmek için kullanılmamalılar.
      “Gizli panel” konusunda ise bunu hep bir hata sanmıştım; ama birileri bunun iyi bir fikir olduğunu düşünmüş olabilir.
      App Store'da uygulama yönetmek için Apple Connect uygulamasını sık kullanıyorum. iPad Mini'yi dikey modda kullanırken uygulamalarımdan birini seçtiğimde, geri düğmesi sık sık kayboluyor. Bu durumda başka bir hesap seçemiyor ya da mevcut hesap içindeki başka bir uygulamayı seçemiyorum.
      Ta ki iPad'i fiziksel olarak yatay konuma çevirene kadar. O zaman solda gezgin beliriyor ve başka bir uygulama seçebiliyor ya da hesabı değiştirebiliyorum.
      Açıkçası Apple App Store arka ucunun genel UX'inden epey hayal kırıklığına uğradım. Ön ucunu da pek sevdiğim söylenemez ama sürekli kullandığım yer arka uç. Platformun geri kalan kullanıcı deneyimine bu kadar özen gösterildiği düşünülünce oldukça şaşırtıcı.