Kontrollerimi Gizlemeyin: Gizli Arayüz Kontrolleri Kullanılabilirliği Etkiliyor

• Gizli kontroller, kullanıcı arayüzünün kullanılabilirliğini düşürüyor
• Geçmişte ekranda görünen menüler, kullanılabilirliği büyük ölçüde iyileştiren bir dönüm noktası işlevi gördü
• Son dönemde mobil ve çeşitli cihazlarda yeniden hafızaya dayalı kullanım gerektiren bir yöne dönüş yaşanıyor
• Arayüz tasarımındaki karmaşıklık ve estetik unsurlar, gizli kontrollerin artmasının temel nedenleri
• Tasarımcıların artık tüm ana işlevleri görünür kılarak kullanıcıların keşfedebilmesini sağlayacak şekilde yapıyı yeniden düşünmesi gerekiyor

---

Giriş: Bilginin Yeri ve Arayüz

• 1960'larda Douglas Engelbart, “bilgi dünyada mı, yoksa zihnin içinde mi” kavramını ortaya koydu
• “knowledge in the world”, kontrol ve kullanım öğelerinin arayüzde görünür olduğu, kullanıcının ezberlemeden doğrudan bulup kullanabildiği durumu ifade eder
  • Örnek: Açılır menüleri olan grafik arayüzler
• “knowledge in the head”, kullanıcının tüm kontrolleri ve komutları ezberlemek zorunda olduğu ortamı ifade eder
  • Örnek: DOS komut isteminde komutları (DIR gibi) bilmiyorsanız hiçbir işlem yapamazsınız

Gizli Kontrollerin Artma Nedenleri ve Ters Etkileri

• Arayüz karmaşıklığı arttıkça daha fazla kontrol görsel olarak gizleniyor
• Dışarıdan daha sade görünebilir, ancak acemi kullanıcılar için kullanım çok daha zor hale geliyor
• İlk dönemlerde açılır menü gibi “görünür kontrollerin” ortaya çıkışı, bilgisayarların yaygınlaşmasını ve üretkenliği çarpıcı biçimde artırdı
• Ancak mobil cihazlar ve yeni elektronik ürünlerde yeniden “hafıza haritasına dayalı” kullanım gerektiren durumlar çoğalıyor
  • Örnek: iPhone'da el fenerini açma, bildirimleri görüntüleme, Apple Pay'i çalıştırma gibi işlemlerde, uygun bir “ipucu” olmadan gizli hareketleri veya belirli jestleri bilmeniz gerekir

Günlük Hayatta Gizli Kontrol Örnekleri

• Araba anahtarlıkları, kapı kolları gibi nesnelerde de gizli kontroller bulunur; nasıl kullanılacağını bilmiyorsanız temel erişim bile zorlaşır
  • Örnek: İç anahtarın yeri, gizlenmiş anahtar yuvası veya belirli düğme sıraları
• Araç navigasyon sistemleri (CarPlay üzerinde Apple Maps gibi) de haritayı daha geniş göstermek için gerekli kontrolleri gizleme eğilimindedir; bu yüzden belirli bir alana dokunmanız gerektiğini bilmeden işlevleri kullanamazsınız
• Zamana bağlı kontroller de gizli kontrol türü olarak çalışır
  • Örnek: Bilgisayarın güç düğmesi yalnızca uzun basıldığında düzgün kapanır; elektronik kapı kilidinde kilitleme için ayrı bir tuş veya uzun basma gibi özel bir kullanım gerekir

Gizli Kontrollerin Yarattığı Genel Sorunlar ve Uzman Kullanıcılara Etkisi

• Ses seviyesi 0 olsa bile uygulamanın keyfi olarak ses çıkarması gibi durumlarda, “gizli ayarlar” kullanıcının doğrudan verdiği komutları geçersiz kılar
• İleri düzey kullanıcılar bile komut tabanlı arayüzlerde (ör. R, DOS penceresi) ciddi bir “knowledge in the head” bağımlılığı yaşar
• Arayüzlerin giderek daha ilkel bir yapıya geri döndüğü görülüyor

Gizli Kontroller Neden Artıyor?

• İşlev sayısı aşırı arttığı için hepsini ekranda göstermek mümkün olmuyor ve görünürlük azalıyor
• Sistem modları arasındaki etkileşim, artan karmaşıklık ve tasarımcıların estetik ya da uygulama kolaylığını öncelemesi nedeniyle kontroller sık sık gizleniyor
• Gerçekte bunun nedeni çoğu zaman kullanıcıyı düşünmekten çok tasarım hedeflerinin (ör. estetik bütünlük) öncelik kazanması

Başarılı Örnekler ve Görev-Kritik Sistemlerin Farkı

• General Motors navigasyonu gibi bazı sistemlerde gerekli tüm kontroller her zaman açıkça görünür; bu da yeni başlayanların bile kolayca keşif yapmasını sağlar
  • Örnek: Buick LaCrosse'ta fiziksel bir kadranla yakınlaştırma işlevi
• Görev-kritik sistemlerde (uçaklar, fabrikalar vb.) tasarım neredeyse her zaman kalıcı olarak görünür kontroller etrafında yapılır
  • Hiç kimse gizli kontroller yüzünden hızlı müdahalenin sekteye uğraması riskini kabul etmez

Gizli Arayüz Savunusu ve Sınırları

• Gizli kontroller, kuşaklar arası bir yakınma konusu değil, gerçek bir kullanılabilirlik sorunudur
• Bazıları “gizli işlevleri” keşfetmeyi bir avantaj gibi sunsa da, gerçekte erişilebilirliğin düştüğü açıktır
• Kullanıcı açısından bulunamayan bir kontrol, var olmayan bir kontrolle aynıdır

Yaygın Bilişim ve Kontrollerin Otomatikleşmesi/Şeffaflaşması

• Mark Weiser ve Donald Norman, teknolojinin “şeffaf” biçimde arka plana çekilip çalıştığı bir gelecek öngördü
  • Örnek: Otomobil motor kontrolü, kullanıcının müdahalesine gerek kalmadan tamamen arka planda otomatik olarak ayarlanır
• Otomasyon nedeniyle kontrollerin tamamen gizlendiği örneklerde ihtiyaç ve bağlam nettir
  • Ancak kullanıcının işlem yapması gereken durumlarda mutlaka açık ve görünür kontroller gerekir

Sonuç ve Arayüz Tasarımcıları İçin Yönelim

• Arayüz tasarımcıları, gizli kontrollerden kaçınmalı ve tüm işlevleri “dünyada görünür bilgi” temeline dayalı hale getirmelidir
• Kontrol keşfedilebilirliği (discoverability) hâlâ temel bir tasarım ilkesidir
• Modern arayüzlerde keşfedilebilirliğin azalması, aslında bilgisayarların ilk dönemlerine doğru bir gerilemedir

Kaynakça

• Engelbart, D.C. (1962) ve benzeri temel literatür
• Apple Macintosh, The Psychology of Everyday Things, The Invisible Computer gibi ilgili kitap ve makalelere atıf

Yazar Bilgisi

• Philip Kortum: Rice University Psikoloji Bilimleri Bölümü profesörü; kullanılabilirlik ve güven değerlendirmesi, küresel sağlık ve mobil sistemler gibi çeşitli alanlarda kullanılabilirlik odaklı sistem geliştirme üzerine çalışıyor

[GN⁺]

Hacker News görüşü

• Son zamanlarda kaydırma çubuklarını gizleyen tasarımlarda rahatsızlık yaşandığına dair kullanıcı deneyimleri paylaşılıyor; yazıdaki bazı sezgisel fiziksel düğme örneklerinin de maliyet ve pratiklik açısından sınırları olduğu belirtiliyor; etiketinin mevcut durumu değil de geçilecek durumu ifade ettiği toggle switch deneyimlerinin kafa karıştırıcı olduğu söyleniyor
  • Gerçek toggle switch'lerin de muğlak olduğu için sevilmediği, checkbox'ların ya da basılı duran düğmelerin çok daha açık olduğu ama modernleşme akımında bunların feda edilmesinin üzücü olduğu görüşü
  • Avusturya'daki tren bileti otomatında anında doğrulama toggle switch'inin kafa karıştırdığı anı hatırlatılıyor; kaydırma çubuklarının da fazla ince olduğu, neredeyse FPS oyunu becerisi gerektirdiği; yatay kaydırma çubuğunun bazen daha kullanışlı olduğu ve Firefox ile CSS standartlarına laf çakılıyor
  • macOS'ta sistem ayarları veya terminal komutuyla kaydırma çubuklarını her zaman görünür yapma imkânı olduğu belirtiliyor
  • Eğer toggle bir eylemi ifade ediyorsa mutlaka fiil kullanılması gerektiği ("TURN ON") ve durum gösterilecekse bunun da "IS ON" gibi açık bir biçimde yapılmasının önerildiği; bağlam gereği karışabilecek çok az durum dışında fiil kullanımının neredeyse her şeyi netleştirdiği düşünülüyor
  • PgUp ve PgDn desteği de isteniyor
• Eski bir Toyota kullandığını, tüm kontrollerin her zaman görünür, net biçimde etiketli ve parmak ucuyla ayırt edilebilir olduğunu; bunun kopyalanmasının da kolay ve asgari mühendislik gerektiren bir şey olduğunu, fakat bugünkü otomobil üreticilerinin çoğunun bunu bile yapamadığını ve bunun da yetersizlik olduğunu söyleyen bir yorum
  • Buna kısmen katılmakla birlikte, "tüm kontroller görünmeli" demenin tasarımcıları küçümsemek olduğu; pratikte sürüş sırasında gerçekten gerekli olan kontrollerin görünür olduğu, geri kalanların ise küçük, karmaşık ya da gizli ama erişilebilir olduğu; koltuk yükseklik kolu, kaput açma kolu gibi örneklerin gizli olsa da erişilebilir olduğu ve bu ayrıntıları düşünerek tasarlamanın ne basit ne de trivial olduğu, bunları basite indirgemesinin bugünkü UX'in kötüleşme sebeplerinden biri olduğu görüşü
  • Bunun beceri değil maliyet meselesi olduğu; bugün çok sayıda düğme ve fiziksel çevirmeli parça üretip monte etmektense dokunmatik ekranların daha ucuz ve üretiminin daha kolay olduğu yorumu
  • ABD'li otomobil üreticilerinden sistem geliştirici pozisyonları için çok sayıda teklif geldiği, ancak Hacker News topluluğunda “akıl sağlığını korumak istiyorsan uzak dur” görüşünün yaygın olduğu deneyimi paylaşılıyor
  • Mekanik parçaların, örneğin çevirmeli düğmelerin, farklılaştırılmasının özel kalıplar gibi üretim maliyetlerini artırdığı; bunları ekrana koymanın maliyet açısından çok daha verimli olduğu açıklanıyor
• Ekran alanı verimliliği için UI öğelerini gizlemeyi anlaşılır bulan ama kullanılan alanı boş bırakıp yine de öğeleri gizlemenin kabul edilemez olduğunu söyleyen yorum; IntelliJ'de proje ağacının üstündeki ikonların fare üzerine gelince görünmesinin gerçekten gerekli olup olmadığı sorgulanıyor
  • Mobil, masaüstü ve dizüstü ekranlarının hiç olmadığı kadar büyüdüğü bir dönemde ekran öğelerini gizlemeyi meşrulaştıran gerekçenin sorgulandığı; 1984 Macintosh'un küçük siyah-beyaz ekranında bile açıklık ve görünürlük için ekran oranından fedakârlık edilerek düğmelerin yerleştirildiği hatırlatılıyor
  • Bazı kullanıcıların görsel "gürültü"nün odağı bozduğundan şikâyet ettiği, bazılarının ise bir gösterge paneli gibi tüm kontrolleri ve göstergeleri her zaman görmek istediği; IDE varsayılanlarının bu iki uç tercih arasında denge kuran bir uzlaşma olduğu, bazı araçların da "no distractions mode" gibi ayrıntılı ayarlar sunduğu belirtiliyor
  • IntelliJ Windows sürümündeki menünün de hamburger ikonunun içine gizlenmesi nedeniyle boş alanın arttığı, neyse ki ayarlardan eski hâline getirilebildiği ama varsayılanın anlaşılmaz olduğu söyleniyor
  • Bir düğmenin varlığını ve nasıl göründüğünü bildiği hâlde bazen onun nerede olduğunu unutup boş boş ekrana bakakalma deneyimi anlatılıyor
  • Bazı uygulamalarda ise ek düğmelerin gizlenmemesinden yakınılıyor; hatta gizleme seçeneği olsa isteneceği belirtiliyor ve Google Maps anılıyor
• Otomobil akıllı anahtarlarında gerçek anahtarın gizlenmesi, hatta anahtar deliğine ulaşmak için kapı kolunu sökmek gerekmesi gibi örneklerin kullanıcıya karşı çok kaba bir mühendislik olduğu eleştiriliyor
  • Benzer bir durumu kiralık araçta yaşadığını; uzaktan kumandalı anahtar bozulunca tüm eşyalarının araçta kilitli kaldığını anlatan biri, fiziksel bir anahtar olduğunu bildiğini ama daha önceki kullanıcıların açmaya çalışırken bıraktığı çizik izlerinden anahtar deliğinin yerini hemen anladığını söylüyor
  • Buna karşılık, böyle şeylerin kullanıcının zaten bilmesi gereken temel bilgiler olduğu ve Google gibi kaynaklardan bulunabileceği; yeni bir araba alınca yedek seçenekleri ve nasıl çalıştıklarını hemen kontrol ettiğine dair örnek verilerek sahip olunan ürünü temel düzeyde tanımanın önemi vurgulanıyor
• iPhone'da ana ekran düğmesinin kaldırılmasının, Android'e geçme nedenlerinden biri olduğu; ailedeki yaşlı kullanıcılara anlatmanın ve kullandırmanın zorlaştığı söyleniyor; yeni Pixel telefonda ilk iş olarak 3 düğmeli gezinmenin etkinleştirildiği ama güncel uygulamaların alt gezinme çubuğunu varsaydığı için 3 düğmenin içeriği kapatabildiği eleştiriliyor
  • Temel UI öğelerinin mutlaka görünür olması gerektiği savunuluyor; Apple'ın da bunu bazen ihlal ettiği ama çoğu zaman buna direndiği değerlendiriliyor; ana ekran düğmesinin kaldırılmasının UI öğesini gizlemekten çok etkileşimi dönüştürmek olduğu, bunun sezgiselliği ve kalitesi tartışılabilse de alışınca kullanım sürtünmesinin çok azaldığı belirtiliyor; iOS'ta ekranda sürüklenebilen küçük yuvarlak bir kısayolun (metin etiketiyle) bulunduğu erişilebilirlik özelliği de hatırlatılıyor
  • Genel yazılımlarda menü öğelerinin sessizce ortadan kaybolmasının da benzer olduğu; örnek olarak MS Word'de salt okunur dosya kaydetme ikonunun tamamen kaldırılması veriliyor; bunun yerine devre dışı bırakılmış görünmesi, kaydetmeye çalışınca nedeninin söylenmesi ve çözüm yolunun sunulmasının daha iyi bir deneyim olacağı öneriliyor
  • Uzun süredir Android kullanan birinin, ara sıra iPhone ödünç aldığında sezgisel olmayan ya da hiç olmayan etkileşimler yüzünden bunaldığını; Pixel ve Samsung kamera kalitesinin de artık çok iyi olduğu için Apple ekosistemine geçmek için bir sebep görmediğini söylediği aktarılıyor
• Yazının, UI'nin kaybolmasının tesadüf ya da hata değil, kullanıcıyı içeride tutma stratejisi olabileceği noktasını yeterince işlemediğini söyleyen bir görüş; büyüme sınırına ulaşmış yazılımlarda mevcut kullanıcıların ayrılmasını önlemek için arayüzün sezgisel olmayan biçimde değiştirildiği; cihazın sadece "kullanılan" bir şey değil, "içselleştirilmiş" bir varlık hâline getirilerek geçiş maliyeti yaratıldığı; yeni ürüne geçiş korkusunun da UI öğrenme süreci üzerinden üretildiği ve büyük yazılım şirketlerinin çoğunun bu yöntemi kullandığı öne sürülüyor
  • Bu hipotezin parçalı olarak bakıldığında doğru görünebileceği ama gerçekte "karmaşık ve kalabalık arayüz"e karşı da ciddi bir tepki olduğu; minimalizm akımının ve /r/unixporn gibi toplulukların da kendi istekleriyle kontrolleri gizlemeyi tercih ettiği; GNOME gibi ortamlarda da minimal arayüzün baskın hâle geldiği; birçok kullanıcının gerekli olduğunda işlevleri bulup kullanabildiği için bunun bir tercih meselesi olarak da okunabileceği söyleniyor
  • Bunun iki ucu keskin bir kılıç olduğu ve yabancı kullanıcıların sisteme girmesini de zorlaştırdığı; Apple'ın her şeyi tek bir düğme etrafında toplamasının sevilmediği ve bu yüzden Android'in daha doğal geldiği örneği veriliyor; Apple'a yönelik başka hoşnutsuzluk nedenleri de olduğu ekleniyor
  • Kâr amacı gütmeyen açık kaynak yazılımların bile bu trendlere eleştirmeden kapıldığı; Firefox'un tekrar tekrar yaptığı tasarım değişiklikleriyle GNOME'un da aynı çerçevede değerlendirildiği belirtiliyor
• "Sanatçı" tipindeki tasarımcıların UI kararlarını ele geçirdiğinde temizliğe takıntılı olup sezgisel kullanım ipuçlarını (affordance) ve öğrenme fırsatlarını görmezden geldikleri; uçak kokpitinin buna karşı klasik örnek olduğu, uzman olmayanlar için bunaltıcı olsa da uzmanlar için her şeyin etiketli olduğu söyleniyor
  • Buna karşı, sıradan ev musluğuna bile yön etiketi koymanın gereksiz olacağı; uçak kokpitinin acemiler için zaten aşırı bunaltıcı bir örnek olduğu; arayüz tasarımcılarının neyin sezgisel olduğunu iyi bildiği ve karmaşık işlevleri sade form faktörlerine iyi sıkıştırabildiği; tasarım eğitimi olmayan kişilerin daha iyi sonuç çıkaracağını düşünmenin kibir ve küçümseme olduğu; çok sayıda kullanıcının hiçbir eğitim almadan modern akıllı telefonları ustalıkla kullanabilmesinin önemli bir başarı sayılması gerektiği vurgulanıyor
• Hacker News bağlantılı masaüstü yazılım tiradı ve mevcut duruma dair soru
• Kendi şirketlerindeki UI tasarım ilkelerinden birinin, klavye kısayollarının ve bağlam menülerinin mutlaka açıkça görünen bir düğme ya da menü üzerinden de erişilebilir olması gerektiği; bunun biraz eski usul görünse de önemli olduğu belirtiliyor; ekranın dört köşesinin farenin hızla götürülebildiği UI açısından kritik alanlar olduğu, Windows 11'de Başlat menüsünün ortaya taşınmasının da kullanıcıyı zorlaştıran bir örnek olduğu; bunun mobil değil dokunma öncelikli bir yaklaşım olabileceği söyleniyor
• Erişilebilirlik ve UI'deki sezgisellik kaybının engelli bireyleri ve yaşlıları ciddi biçimde etkilediği vurgulanıyor; dokunma ve jestler baskın hâle gelse de ilk mobil UI'ların aslında daha erişilebilir olduğu; aşırı minimal ve düzleşmiş tasarım eğiliminin temel neden olduğu; palm, compaq pilot, iPod ve ilk iPhone UI düzenlerinin olumlu biçimde hatırlandığı, sonrasının ise gerileme olarak görüldüğü söyleniyor
  • Buna karşılık, HN yorumlarını telefondan okurken olduğu gibi çok sayıda UI kontrolünün gizlenmesinin içeriğe odaklanmayı kolaylaştırdığı ve daha estetik, daha rahat hissettirdiği de belirtiliyor; palm pilot döneminde düğme ve kontrollerin ekranın yarısını kapladığı ve içerik alanını daralttığı hatırlatılıyor; gizli kontrollerin her zaman kötü olmadığı, bir kez öğrenildiğinde uzmanlar için güçlü bir araç olabildiği savunuluyor; kullanıcıdan bir miktar UI öğrenmesi beklemenin bir ölçüde kaçınılmaz olduğu, kod editörü ve git gibi yüksek işlevli araçlarda sadelik ile güç arasında bir takas bulunduğu; ancak son dönemde her uygulamanın kendi özel kontrollerini üretmesi nedeniyle UI öğreniminin uygulamalar arasında aktarılamamasının sorun olduğu, palm pilot platformundaki gibi bir kez öğrenilip tüm uygulamalarda aynı şekilde kullanılabilen yapının ideal olduğu söyleniyor