2 puan yazan GN⁺ 2023-10-14 | 1 yorum | WhatsApp'ta paylaş
  • Kaydırma çubukları giderek küçüldükçe veya gizlendikçe, yalnızca kaydırma tekerleği ya da dokunma hareketlerini kullanmakta zorlanan kullanıcılar için değil, belge içinde hızla konum değiştirmek isteyen kullanıcılar için de gerçek bir kullanılabilirlik sorunu haline geliyor
  • İnce motor kontrolünde zorlanan veya göz izleyici gibi hassasiyeti sınırlı işaretleme aygıtları kullanan kullanıcılar için 8 piksel genişliğindeki kaydırma çubuğunu tutturmak zor; sesle kontrol kullanıcıları da tekrar tekrar kaydırmak yerine istedikleri konumu doğrudan tıklamak istiyor
  • GTK, Qt, Firefox, Chrome ve Electron’da kaydırma çubuğu genişliği ve gösterim biçimi ayarlanabilse de bunlar CSS düzenlemesi, gsettings, about:config, temayı yeniden derleme veya uygulama bazlı ayarlar gibi sıradan kullanıcıların erişmesi zor yöntemlere dayanıyor
  • Eskiden basılı tutulduğunda azar azar hareket ettiren kaydırma düğmeleri vardı, ancak sessizce ortadan kalktılar; ok tuşları bazı işlevlerin yerini alabilse de davranışları odak durumuna göre değişiyor
  • Belge minimap’i gibi, içeriği görerek büyük bir tıklama alanı üzerinden hareket etmeyi sağlayan arayüzler, göz izleyici ve tablet kalemi kullanıcıları için de yararlı bir alternatif gezinme yöntemi olabilir

Küçülen ve gizlenen kaydırma çubukları

  • Kaydırma çubuğu, tıklayıp sürükleyerek kaydırılabilir bir alan içindeki mevcut konumu değiştirmeye yarayan temel bir kullanıcı arayüzüdür
  • Son dönemde kaydırma çubukları o kadar küçüldü ki ekran görüntüsüyle göstermek bile zorlaştı; onları daha da küçültme veya gizleme eğilimi kullanılabilirliğe zarar veriyor
  • “Kaydırma tekerleği kullanılsın” yaklaşımı, tüm kullanıcıların kaydırma tekerleği ya da dokunmatik ekran kaydırma hareketi kullanabildiği varsayımına dayanıyor
  • Kaydırma tekerleğini iyi kullanan kullanıcılar bile bazen belirli bir konuma hızla atlamak isteyebilir

Erişilebilirliğe etkisi

  • İnce motor kontrolünde zorluk yaşayan kullanıcılar, ince kaydırma çubuklarını doğru şekilde yakalamakta zorlanır
  • Göz izleyici gibi işaretleme aygıtları etkileyici olsa da 8 piksel genişliğindeki bir kaydırma çubuğunu kararlı biçimde hedeflemek için yeterli değildir
  • Bilgisayarı sesle veya komutlarla kontrol eden kullanıcılar, Talon Voice gibi araçlar kullansalar bile scroll down komutunu tekrar etmek ya da otomatik kaydırma yerine, kaydırma çubuğunda istedikleri konumu görüp tıklamayı tercih edebilir
  • 2015’te de GTK3 kaydırma çubuğu genişliği sorunu tartışılmıştı; ince kaydırma çubukları teknik olmayan kullanıcılar ile el kullanımı veya görme sorunları yaşayan kullanıcılar için yük oluşturuyor

Kaydırma çubukları nasıl daha az kullanılabilir hale geldi

  • Bazı durumlarda kaydırma çubuğunun genişliği piksel bazında aynı kalsa da monitör çözünürlükleri arttıkça gerçek etkileşim hedefi küçülüyor
  • Diğer durumlarda ise kaydırma çubuğunun kendisi gerçekten küçülüyor
  • Geçmişte Ubuntu’nun denediği çok ince kaydırma çubuğu örneğinden de söz ediliyor
  • Kaydırma çubukları küçülürken, basılı tutulduğunda azar azar hareket ettiren kaydırma düğmeleri de ortadan kalktı
    • Ok tuşları bazı işlevlerin yerini alsa da şu anda hangi içeriğin odakta olduğuna bağlı çalışır
    • Düğmeler odak durumundan bağımsız olarak kullanılabiliyordu
  • Genel olarak kaydırma çubukları daha az işe yarar hale geldi; bunu düzeltecek kullanıcı ayarları ya yok ya da sıradan kullanıcıların bulması zor teknik yığınların içine gömülü

GTK ayarlarının engelleri

  • GTK2’de gtkrc içinden kaydırma çubuğu genişliği doğrudan değiştirilebiliyordu ve bunun için GUI programları da vardı
  • GTK3’te ayarlama CSS ile yapılmalı; temayı anlamıyorsanız kullanıcı dostu ayar yöntemi eksik kalıyor
  • Bir Reddit başlığında, GTK3 ve GTK4’ün gtk.css dosyasına slider { min-width: ...; min-height: ...; } ekleyen, ayrıca Flatpak override’larını ve overlay scrolling ayarını da ele alan bir betik tanıtılıyor
  • Flatpak uygulamaları ayrı override gerektirdiğinden sistem teması olduğu gibi uygulanmayabilir
  • GTK varsayılan olarak kaydırma çubuklarını gizleyip fare ilgili konuma getirildiğinde görünür hale getiren bir yöntem de kullanıyor
    • GTK3’te aşağıdaki komutla her zaman görünür yapılabilir gsettings set org.gnome.desktop.interface overlay-scrolling false
    • Dconf Editor’da da bulunabilir, ancak konumunu bilmek gerekir
  • GTK4’te bu ayarın genel olarak yapılamadığını belirten GNOME Bugzilla başlığı alıntılanıyor
    • Tartışmada, her uygulama için non-overlay scrollbar seçeneği istemek zorunda kalınmasının sorun olduğu belirtiliyor

Qt ayarlarının engelleri

  • Qt kaydırma çubuğu genişliği, kullanılan Qt widget stili eklentisi tarafından belirleniyor
  • /u/cfeck_kde, r/kde yanıtında bildiği kadarıyla yalnızca Skulpture stilinin boyut ayarına izin verdiğini; Breeze gibi diğer stillerde C++ kaynak kodunu değiştirip yeniden derlemek gerektiğini açıklıyor
  • Qt stil eklentileri gerçek kod olduğundan güçlü kontrol sunabilir, ancak istediğiniz ayarı sağlayan eklentiyi bulmanız gerekir
  • Kvantum içinde kaydırma çubuğu genişliği ayarını bulmak zor, ancak “Transient scrollbars” adlı kaydırma çubuklarını kaybettirme özelliği kapatılabiliyor
  • Skulpture denenmeye değer, ancak KDE Plasma olmadan GUI üzerinden ayarlama yöntemi doğrulanamadı
  • Tek bir tema motoruna bağımlı kalmak gerekiyorsa, Qt geliştirmesi sürerken bunun korunup korunmayacağına dair endişe kalıyor

Firefox, Chrome ve Electron’daki durum

  • Firefox da çok küçük kaydırma çubukları kullanıyor, ancak şu anda about:config üzerinden ayarlanabiliyor
    • Adres çubuğuna about:config yazın
    • widget.non-native-theme.scrollbar.size.override değerini istediğiniz sayıyla değiştirin
    • Görünümü değiştirmek için widget.non-native-theme.scrollbar.style değerini düzenleyebilirsiniz
    • 4 değeri kalın dikdörtgen bir biçime ayarlar
    • Normal ayarlar penceresi olan about:preferences içinde “Always show scrollbars” açılabilir
  • Örnek olarak Firefox kaydırma çubuğu boyutu 50 yapılabilir; gerçekte o kadar büyük kullanmak istemeseniz bile büyütebilmek bir avantajdır
  • Athena Lilith Martin’in Firefox kaydırma çubuğu ek ayarları yazısı, web sayfası CSS override’larını devre dışı bırakma gibi ek iyileştirme ayarlarını ele alıyor
  • Chrome için yararlı ayarlar beklemenin zor olduğu değerlendiriliyor
  • Electron uygulamalarında da ayar yapmak zor; özel CSS enjekte ederek düzeltmenin mümkün olup olmadığı bilinmiyor, ancak kesin bir çözüm sunulmuyor

Daha iyi bir gezinme yöntemi: minimap

  • Minimap, içeriği görmeyi, içeriğe tıklamayı ve tıklanan içerik konumuna gitmeyi sağlar
  • Tıklama hedefi çok büyük olduğundan göz izleyici kullanıcıları ve tablet kalemi kullanıcıları için de yararlıdır
  • Yaygın “modern tasarım ilkeleri”, kaydırma çubukları ve bilgisayarı farklı şekillerde kullanan insanlar aleyhine işliyor

1 yorum

 
GN⁺ 2023-10-14
Hacker News yorumları
  • Sorun yalnızca kaydırma çubukları değil. Pencere kenarlıklarının kaldırılması yüzünden, arka plandaki benzer renkte pencerelerden ayırt etmek de zorlaşıyor; kenardan tutup pencere boyutunu değiştirmek de neredeyse imkânsız hale geliyor.
    Başlık çubuğuna arama kutusu ve gereksiz düğmeler yığılmış olduğundan, pencereyi taşımak için tutacak yer neredeyse kalmıyor; metin kutuları arasında Tab ile geçiş de beklendiği gibi çalışmıyor ya da hiç çalışmıyor.
    Araç ipuçları arayüzü bölüyor ve karmaşıklaştırıyor; çoğu zaman görmek istediğiniz içeriğin üstünü kapatıyor ve %95’i tekrar eden ya da işe yaramaz bilgilerden oluşuyor.
    Son 10 yılda kargo kültü UI/UX anlayışı, onlarca yılda birikmiş kullanılabilirlik ilkelerini çöpe atıp yalnızca iyi görünen ama birçok insan için düzgün çalışmayan sonuçlar üretti.
    Postman, Teams, günümüzdeki Microsoft uygulamalarının çoğu, Chrome ve Insomnia gibi uygulamalar, masaüstü yazılım arayüzünün nasıl yapılmaması gerektiğine örnek olarak kullanılmalı.
    Daha büyük günah ise şu: Bu öğeler pencere sistemi düzeyinde ayarlanabilir olup uygulama geliştiricileri bunların üzerine yazamasaydı sorun olmazdı; ama Windows ve Gnome/GTK tam tersine mevcut seçenekleri kaldırma yönünde ilerliyor.

    • “Aptal” ifadesinin yerinde olduğunu düşünüyorum. Durduk yere çalışan insanlara hakaret etmek istemem ama artık bir pencereyi taşımak için başlık çubuğu mu yoksa düğme mi olduğunu anlamaya çalışarak aptal gibi oraya buraya tıklamak gerekiyor.
      “New Teams”i her başlattığımda Old Teams’e dönmek isteyip istemediğimi soruyor; Dosya Gezgini’nde New Teams ile bir PDF açınca da dosya sistemi konumunu kaybetmeden PDF’yi nasıl kapatacağım açık değil.
      Üstelik her şey korkunç derecede yavaş. Microsoft/Apple/Google’da çalışan epey çok kişi işini iyi yapmıyor ve bundan utanmaları gerekir.
    • Windows XP’nin kullanılabilir arayüzün zirvesi olduğunu ve orada durulması gerektiğini düşünmeye başladım. Tabii belki de sadece yaşlanıp çocuklara çimlerimden defolun diyen birine dönüşmüşümdür.
      Windows söz konusu olduğunda bunun kesinlikle böyle olduğunu düşünüyorum; sonraki tüm Windows sürümlerinde kullanıcı deneyimi daha da kötüleşti.
    • Hakarete gerek olmadığını düşünüyorum. HN’yi sevmemin nedeni de, başka platformlardaki nefret dolu üsluba kıyasla nazik tartışmanın öne çıktığı az sayıdaki yerden biri olması.
      Kullanılabilirliğin estetikten önemli olduğuna temelde katılıyorum; ama “kargo kültü UI/UX aptalı”nın tam olarak kimi ifade ettiğini bilmiyorum.
      20 yılı aşkın süredir UX/UI lideri olarak çalışmış biri olarak, kullanılabilirliği bozan başlıca tarafın tasarımcılardan çok iş liderleri ve pazarlamacılar olduğu durumları daha sık gördüm.
      Elbette biçimin işlevden önemli olduğunu düşünüp küçük kaydırma çubuklarını dayatan tasarımcılar da var; ama sorun anlatıldığında çoğu zaman geri adım atıp kullanılabilir tasarımlar üretiyorlar.
      C-seviyesi yöneticiler, pazarlama liderleri ve müdürler UI konusunda bilgisiz olmalarına rağmen güçlü fikirlere sahip oldukları için daha tehlikeliler; “bu web sitesinin kaydırma çubuğu güzel”, “tasarım modern görünmüyor” gibi taleplerle geliyorlar.
      Kullanılabilirliği ve erişilebilirliği korumak için mücadele etmek çok acı verici; bazı pozisyonlardakiler daha profesyonel davranmalı ve uzmanlara güvenmeli. Tasarımcıların da kullanılabilirliği öncelemesi gerektiği doğru.
    • Daha büyük sorun, artık bilgiyi yapılandırmaya yönelik neredeyse hiç çaba gösterilmemesi.
      Ayarlar menüleri, listelerin üstüne listeler yığılmış bir kâbus; her uygulamada menü yapısı tamamen rastgele ve yerel olarak ayarlanabilecek şeyler bile çoğu zaman dış bir site bağlantısına gönderiyor.
      Tasarımcının niyetini anlamak gerçekten zor; ayarı ben mi bulamıyorum, yoksa en başından bu menüde olmayacak şekilde mi tasarlanmış, ayırt edemiyorum.
      Varsayılan bir ayarı değiştirmek için Google’da arama yapmak zorunda kaldığım o kadar çok oldu ki; deneyimin ürün değerinin yarısı olduğu oyunlarda bile durum aynı.
      CS2’nin ayarlar menüsünde üstteki metin düğmeleri sekme gibi görünüyor ama aslında yalnızca uzun ayar listesindeki rastgele noktalara kaydırıyor; bu yüzden her düğmenin ne anlama geldiğini zihinde ayrı ayrı konumlandırmak zorlaşıyor.
      Kavramların anlamları birbirine bağlanmıyor ve yapılandırılmıyor; bu yüzden bilgisayar kullanımında gezinmek gereksiz yere çok zor hale geldi.
      Macromedia Flash’in UI’ını özlüyorum; çok kullanmadım ama gerçekten basit ve kullanımı kolaydı.
      Gizlilik ve kendi yaptığım çözümlere yönelmemin büyük motivasyonlarından biri de bugün gördüğümüz deneyim ve bilgi kirlenmesinden kaçmak istemem.
    • Boyutlandırma kutusunun var olma nedeni tam da buydu. Bugün ise pratikte kenar boşluğu olmayan sürüklenebilir kenarlar var; 1 piksellik bir öğeye aşırı rol yüklenip çakışmalar yaratılmış oluyor.
      Eskiden boyutlandırma kutusu, dikey kaydırma çubuğunun en altında, aşağı ok düğmesinin hemen altında, pencere boyutunu değiştirmeye ayrılmış ayrı bir tutamak olarak bulunurdu.
      İlk ekranda görünmeyen içeriği görmek için kullanılan kaydırma düğmelerinin hemen yakınında olduğu için, viewport ile etkileşime geçmenin doğal bir başlangıç noktası ve referans noktası sayılırdı.
      İronik biçimde uygulama UI’larında çoğunlukla ortadan kalktı; ama web tarayıcıları, textarea gibi kaydırma çubuğu ve resize açık öğelerde bunu hâlâ render edebiliyor. Yine de çoğu UI’da ilgili kaydırma düğmeleri artık yok.
  • Geçenlerde komik bir farkına varış yaşadım. Meğer görme yetim kötüleşmemiş, UI kötüleşmiş
    Gülünç derecede düşük kontrastlı, minicik kaydırma çubukları kimse için erişilebilir değil
    Son zamanlarda KDE’yi Oxygen temasıyla kullanmaya başladım; göz yorgunluğu olmadan kullanması güzel olduğu için keyif alıyorum
    Bu tür kaydırma çubukları, özelleştirme imkânı bile olmayan acınası şeyler; kilitli uygulamalara tema uygulamaya çalışıyorsanız bol şans
    UI tasarımcılarının kullanıcı ihtiyaçlarını umursamadığı fazlasıyla bariz ve FOSS dünyası da bunun istisnası değil
    Güzel görünen, işlevsel, erişilebilir ve hızlı yazılımların olduğu dönemden, kilitli ve temalandırılamayan Electron çöplüğüne gerilemiş olmak üzücü
    UI’da yeterli kontrast ve okunabilirlik olsaydı “karanlık mod” gibi şeylere de gerek kalmazdı

    • Karanlık modu kontrast yüzünden değil, birçok yazılımın aydınlık modu düpedüz bembeyaz olduğu için kullanıyorum. Ekranlar giderek daha parlak ve güçlü hale geldi
      Beyaz modu olmayan bir yazılım kullandığımda, çoğu zaman o kadar parlak oluyor ki yakındaki duvar el feneri tutulmuş gibi aydınlanıyor
      Bu yüzden ekran parlaklığını düşürünce de renkler ve kontrast berbatlaşıyor, yine hiçbir şey görünmüyor
      Win 9x döneminin gri arayüzlerini özlüyorum; güzel değillerdi ama gerçekten görülebiliyorlardı
    • Kontrast da bir etken, ama düz UI modası orta gri ve açık gri tonlarını ortadan kaldırıp yerlerine bembeyazı ve neredeyse beyazı koyunca, aydınlık mod eskisine göre çok daha göz alıcı hale geldi
      Göz alan düz UI egemen olduktan sonra insanların karanlık mod istemesi hiç de şaşırtıcı değil
    • Dijital dünyada daha fazla analog kontrol olmasını isterdim. 10 kademeli yukarı/aşağı düğmeleri yerine döner düğmeler olsa
      Menüden kolayca çıkıp gitmek, geri dönmeye çalışırken bambaşka bir şeyi ayarlamak gibi dijital manuel kontroller fazlasıyla dijital ve zahmetli hale geldi
      Eskiden ekranın kontrastını ve parlaklığını, amfi sesini, analog TV’yi, termostatı, araba radyosunu vb. ayarlamak kolaydı
      Henüz birçok analog kontrolü geri getiren bir akım yok ama sonuçta dünyamız analog. Girdiler konuşma, kas hareketleri vb. ile analog; çıktılar da ışık ve titreşim gibi duyulara temas eden analog şeyler
      Kontrollerin neden daha analog olmadığını bilmiyorum; muhtemelen maliyet meselesidir
      Analog kontrolleri olan bir ekran ya da dizüstü bilgisayar olsa hemen alırdım. Gerçekte 16 milyon kademeli bir kadran bile olsa, tepkisi anlık ve gerçek bir değişken direnç gibi hissettirdiği sürece yeterli
      Duruma göre şiddeti hızla değiştirebilen ya da seçenekler arasında dolaştırıp okumayı ve dinlemeyi kolaylaştıran bir düğme olsa güzel olurdu
      Bugün yaptığımız işlerin %90’ı tarayıcı içinde gerçekleştiğine göre, tarayıcının erişilebilirlik API’si sunup Bluetooth’lu olsun başka türlü olsun bir döner düğmeyle kontrol edilebilmesi güzel olurdu. Kaydırma tekerleğinin güçlendirilmiş hali gibi
    • Özellikle yeni çıkan “don’t theme my app” akımı üzücü. GTK’nin CSS stil sayfası sorunu, CSS’i daha iyi bir stil tanımlama teknolojisiyle değiştirerek çözülmeli; her şeyi çöpe atıp kullanıcının kendi temasını kullanmasını engelleyerek değil
    • Kullanılabilirliğin yaklaşık 20 yıl önce, Windows 2000 döneminde zirveye ulaştığını düşünüyorum. Yazıdaki ekran görüntüsü de aslında o dönemdeki erken OS X 10.x’lerden, muhtemelen 10.3 civarından görünüyor
  • Kaydırılabilir popover’ları ya da tuhaf iç çerçeveleri olan web siteleriyle sık sık karşılaşıyorum; küçük iç çerçevenin kaydırma çubuğu gizlendiği için daha fazla içerik olup olmadığını anlayamıyor ve sitenin tamamen bozulduğunu düşünüyorum
    Gerçekten öfkelendiriyor; bu çılgınlığı teşvik edip yaygınlaştıran iOS ve macOS’u suçluyorum. Neyin ne olduğunu tahmin etmeyi zorlaştıran “düz” UI modasını iten taraf da dolaylı olarak sorumlu
    UI iletişimdir; UI tasarımcıları ise mırıldanmanın havalı olduğuna karar vermiş gibi

    • Aslında iPhone bağlamında, kaydırma yapılmadığı sırada kaydırma çubuğunu gizlemek bir ölçüde mantıklı. Ekran 3,5 inç ve hedef masaüstü düzeyinde içerik göstermekse, kaydırma çubuğuna ayrılacak pek yer yok; çoğu kişi de kaydırma çubuğunun kendisiyle etkileşime girmeyecek zaten
      Buna karşılık masaüstü işletim sistemlerinde kullanılan en küçük ekranlar bile çok daha büyük olduğu için, kaydırma çubuklarını gizlemek için pek iyi bir neden yok
    • Bu şikâyet başlığını daha da alevlendirecek şekilde kaçırma riskini göze alırsam, belki de günümüz film ve TV dünyasını taklit ediyorlar
      Çocuklar sessizken, uyurken ya da okuldayken bile günümüzde pek çok film ve diziyi altyazısız izlemek zor
    • Bu düz UI’ın nasıl moda olduğunu bile anlamıyorum
  • Firefox’un about:config içinde böyle şeyleri kapatmaya yarayan bir araç sunmasını bir kez daha övmek gerek. En iyi ihtimalle sevimli bir süs, en kötü ihtimalle sinir bozucu ve istismara açık
    Tarayıcı UI’ı, web sitelerinin değiştirebildiği alanın neredeyse tamamen dışında tutulmalı; kaydırma çubukları da buna dahil

    • Buna karşılık Chrome tarafında, “Chrome’da yararlı bir şeyi ayarlayabildiğini hayal et” noktasında epey güldüm
      Yazının tamamı çok iyi yazılmış; yazarı kutlarım
      Ben de Edge’in Bing aramayı ve başka özellikleri sürekli dayatmasından, üstüne sekme geri yükleme istemlerinin de aşırı can sıkıcı olmasından dolayı yeniden Firefox’a geçtim. Sadece susup bıraksa artık
    • 2000’lerin başındaki forumlarda IE6’nın kaydırma çubuğu stillendirme özelliğini inatla savunduğumu çok net hatırlıyorum. O dönemde Mozilla tarafı bunu iğrenç bir şey diye niteliyordu
      Yaşlanmış halimle, geriye bakma gücüne ve kötüleşen görme yetisinin zayıflığına aynı anda sahip biri olarak, yanıldığımı kabul edebilirim. Fazla kolay kötüye kullanılabiliyor
    • Yumuşak kaydırma da o listeye eklenmeli. İster fare tekerleğiyle kaydırırken olsun, ister Ctrl-F ile bulunan kelimeler arasında gezinirken
      Neyse ki uBlock Origin ile üzerine yazılabiliyor
    • Eklenti yazarlarının geniş ekosistemi de övgüyü hak ediyor. Yazar sonda mevcut kaydırma çubuğunun yükseltilmiş hali olarak minimap kenar çubuğunu övüyor; gerçekten de böyle bir şey var
      https://addons.mozilla.org/en-US/firefox/addon/minimap-scrol...
    • Mobilde de çalışıyor ama bunun üzerine yazan tam büyülü komutu bulmak gerek
      Sanırım doğrusu bu
      <https://www.makeuseof.com/change-firefox-scrollbar-style/>
  • Yazar, sorunun yarısını görüp çözümün kötü yarısını öneriyor
    Kaydırma çubuğu yalnızca bir kontrol aracı değil, aynı zamanda konum göstergesidir. Uzun bir liste gibi daha büyük bir görünüm içinde mevcut viewport’un nerede olduğunu gösterir
    macOS gibi bazı GUI’lerde olduğu gibi kaydırma çubuğunu gizlemek, düğmeleri metinden ayırt edilemez hâle getirmek ya da açık gri bir arka planın üstüne açık gri yazı koymak kadar kaba bir davranış
    Çözüm zaten var ve neredeyse evrensel olarak uygulanmış durumda: farenin kaydırma tekerleği ve trackpad’in kaydırma hareketleri
    Kaydırma çubuğuyla kaydırılabildiği hâlde standart trackpad hareketiyle ya da fare tekerleğiyle kaydırılamayan görünümler çok nadirdir. Benim farem tekerlekle yatay kaydırma da yapabiliyor; TrackPoint kontrolleri de öyle
    Bu tür kaydırmada imlecin kaydırma çubuğunun üstünde olması da gerekmez; istediğiniz görünümün/kontrolün/widget’ın üstünde durması yeterlidir
    Hassas olmayan giriş aygıtlarıyla, titreyen ellerle, kötü görmeyle bile bunu yapmak çok kolaydır
    Ama böylesine doğal ve kolay bir kaydırma yöntemi varken, kaydırma çubuğunun gösterge rolü daha da çok özleniyor
    Mini harita bazen yararlı olabilir ama çoğu zaman değildir; kişisel olarak metin düzenlemede sadece yer kaplayan ve pek yardımcı olmayan bir şey gibi geliyor. Elbette sevenler için bir seçenek olarak bulunmasına karşı değilim

    • Kaydırma tekerleği ve hareketler sayfa hareket ettirme araçlarıdır; kaydırma çubuğu da bunu yapar ama aynı zamanda “beni belgenin ortasına götür” diyen bir kontrol aracıdır
      Belgenin düzgün tepki verdiği varsayımıyla, özellikle büyük belgelerde kaydırma çubuğuyla geniş aralıklar arasında kolayca gezinebilirsiniz. Gerçi günümüz web’inde bu varsayıma güvenmek zor
      Bağlantıları olmayan ve “B-29” gibi bölüm sayfa numaraları kullanan eski, büyük PDF’lerde, gömülü kalmış bir sayfayı bulmak için kaydırma çubuğuyla fiilen ikili arama yaptığım sayısız kez oldu
      Elbette modern web, lazy loading ve sonsuz kaydırmanın aşırı kullanımıyla kaydırma çubuğunu gösterge olarak kullanma olasılığını neredeyse yok etti
      Mac’te Cmd-aşağı ok ile belgenin sonuna atlayıp gerçekten bir son olmasını umduğum ve biçimi bozan embed’lerin hepsinin yüklenmesini beklediğim çok oldu
      Ama sonunda, sonu görünmeyen bir trenin üstüne binmiş gibi, ne kadar geldiğinizi ve ne kadar kaldığını bilemezsiniz
      Bu yüzden kaydırma çubuğu fiilen işe yaramaz hâle geldiğinden, yüksek hızlı doom scrolling için tasarlanmış, rulmanlı ve ağırlıklı bir fare tekerleği kullanıyorum
    • Yazıyı okumamış gibisiniz. Daha ilk paragrafta “bunun kaydırma tekerleğinin amacı olduğunu söyleyebilirsiniz, ama herkes kaydırma tekerleği ya da dokunmatik ekran kaydırma hareketi kullanamaz” diyor
      Hemen sonraki paragraf da küçük/gizli kaydırma çubuklarının göz izleyici gibi başka giriş yöntemleri için yarattığı zorlukları ele alıyor
    • Doğru. Sonunda kaydırma çubuğunun ne işe yaradığını anlayan biri çıktı
      Kaydırma çubuğunun birincil görevi, belgenin pencereden büyük olduğunu kullanıcıya göstermektir; ikincil görevi ise belgenin hangi bölümünün görünür olduğunu göstermektir. Kullanıcının kaydırmasını sağlamak ana işlevi değildir
      Apple, macOS’te kaydırma çubuklarını varsayılan olarak gizlemeye başladığında gerçekten şaşırmıştım. Apple’ın UI tasarımcıları, temel UI kontrollerinin gerçekte ne yaptığını bilmiyor gibi
    • Kaydırma giriş aygıtları evrensel olarak sunulmuyor
      Wacom/kalem kullanıcılarının kaydırma tekerleği yok
      Birçok trackball’da da kaydırma tekerleği yok; bazılarında topun etrafında bir kaydırma halkası bulunuyor
      Kaydırma yapan parmağımda tekrarlayan zorlanma yaralanması oluştuğu için fareden kaydırma tekerleğini çıkardım. Fare kullanan kolumu fazla zorlayıp birkaç hafta boyunca diğer elimle trackball kullanmak zorunda kaldığım da oldu
    • Çok uzak mesafeler kaydırmanız gerekiyorsa fare tekerleği çöker
  • Pencere kenarlıklarından da bahsetmek gerekiyor. Siyah arka planlı ve siyah kenarlıklı birkaç VS Code penceresini üst üste açmışım, gölge de yok
    Bir pencerenin çerçevesinin/kenarlığının diğer pencerenin üzerinde nerede olduğunu hiç göremiyorum. Bu işletim sistemi düzeyinde bir sorun olmalıydı ama apparently uygulamanın sorunuymuş
    Üstelik VS Code, kenarlık ayarı desteğini “geri çekti”: https://github.com/microsoft/vscode/issues/160159

    • Kenarlıklar ve başlık çubukları hakkında daha fazla içerik burada
      https://news.ycombinator.com/item?id=37865824
      Benim teorime göre tasarımcılar, aynı anda yalnızca tek bir tam ekran pencere gören kullanıcıları hedefliyor
      Onların model kullanıcısı, ideal aydınlatmaya ve yansımasız bir odaya sahip, 13 inçlik bir dizüstünün önünde oturur; pencereleri taşımaz ya da yeniden boyutlandırmaz ve günde 3’ten fazla sekme/belge açmaz
  • Bu tür yazıları ya da UX bloglarını her okuduğumda erişilebilirliği ne kadar az önemsediğimiz fazlasıyla ortaya çıkıyor
    Erişilebilir “iyi” tasarım, modern web uygulamalarından beklenenden epey daha sıkıcı ve sade
    Adam Silver’ın formlar hakkındaki kitabını okuyunca erişilebilirlik açısından tamamen yanlış yaptığımızı fark ettim, ama erişilebilirlik öncelik değil

    • Bir yorumun erişilebilir olması için okuyucunun a11y’nin “accessibility” anlamına geldiğini araştırmak zorunda kalması ironik
    • İş açısından bakınca bu mutlaka yanlış değil. Şirketler erişilebilir bir web sitesi yapmak için yapamayacakları şeyleri yaptıklarında, hesap çoğu zaman onlar için daha iyi çıkıyor
      Özellikle dark pattern’lar erişilebilirliğin tam karşısında duruyor
      Bu yüzden erişilebilirliği zorunlu kılan yasalara ihtiyaç var
  • 40 yaş ve üzerindeki birçok kişi için erişilebilirlik sorunu olan şeyin ne olduğunu biliyor musunuz? Koyu arka plan üzerinde beyaz metin
    Benim yaş grubumdaki insanların web sayfalarını okuyabilmesini sağlayalım diye savunan yazıları okumaktan hiç bıkmayacağım sanırım
    Geliştirici araçlarını açıp yazarın CSS’ini değiştirince okuyabildim, ama bu kez shell script okunamaz hale geldi

    • 40 yaşın altında olmama rağmen bu kombinasyon gözlerime muazzam yük bindiriyor. Birkaç paragraf okuyup duvara baktığımda 30 saniyeden fazla görüşümde hayalet yazı kalıyor
      O kadar rahatsız edici ki, tüm metni seçtiğimde bile koyu arka plan/beyaz metin kontrastı yumuşamıyorsa o sayfayı hiç okumuyorum
    • Ne yazık ki erişilebilirlik ihtiyaçları çoğu zaman birbiriyle çakışıyor ve web sayfası yapan kişinin herkes için seçenekleri garanti edecek sınırsız zamanı da yok
      CSS’i tamamen kapatmayı da düşünebilirsiniz
    • Henüz 40 değilim ama bende durum tam tersi. Şiddetli göz uçuşmaları yaşıyorum; beyaz arka planda bunlar çok belirginleşiyor
      Son 5 yılda gerçekten iyi olan şey, başlıca kullanıcı arayüzlerinin çoğunun artık hem karanlık modu hem de aydınlık modu sunması
    • Tarayıcıda Dark Reader eklentisini kurcalamak iyi olabilir. Genelde global karanlık mod için kullanılır ama site bazında ya da global olarak beyaz modu da ayarlayabilirsiniz
    • Tam olarak aynı sorun değil ama açık ya da orta gri arka plan üzerinde koyu ya da orta gri metinleri sık sık görüyorum
      Benim çözümüm şu
      https://addons.mozilla.org/en-US/firefox/addon/font-contrast...
      En azından metni siyaha zorlar. Oldukça kararlı çalışıyor ve arada sırada gereken istisna ayarlarını yapmak da kolay
  • Kaydırma çubuklarının ölmekte ve kullanılamaz hale gelmekte olduğuna katılıyorum. Kaydırma çubukları geniş, açıkça görünür ve hedeflemesi kolay olmalı
    Belgenin o anda görünen oranını gösterecek şekilde orantılı boyutta olmalı; hareket eden parça da kayganlığı değil sürtünme hissini çağrıştıran özelliklere sahip olmalı
    Ok düğmeleri karşılıklı uçlarda değil, birlikte konumlandırılmalı; hover ve fareye basılı durumları renkle göstermeli
    Burada yer alan klasik kaydırma çubukları içinde https://scrollbars.matoseb.com/ Nextstep’in bu koşullara en yakın olduğunu, Mac OS 8’in de genel olarak en güzel göründüğünü düşünüyorum

    • Buna ek olarak, belge destekliyorsa tek bir araç çubuğu widget’ı üzerinden iki yönde pan yapabilme seçeneği de olmalı. Böyle bir uygulama gördüm, ama ok düğmelerinin iki uçta değil de birlikte olduğu bir biçim hiç görmedim
      Eskiden insan-bilgisayar etkileşimi diye bir araştırma alanı vardı; Fitts yasasını ve ekran kenarlarının fiilen sonsuz büyüklüğe sahip olduğu için özellikle değerli olduğunu öğrenmiştik
      OS X’te ceza gibi MS Teams’i açık tutuyorum; pencere ekranın sağına yapışık ve sağ kenarda bir kaydırma çubuğu var
      Fareyi sağa itip, mouseover ile genişleyerek kenar pikseline kadar ulaşan kaydırma çubuğunu tutmak için tıkladığımda tüm pencere sürükleniyor
      Buraya nasıl geldik bilmiyorum. İyi kullanıcı arayüzünün ne olduğu üzerine aktif olarak araştırma yapılan bir dönem vardı; bu araştırma gerçek kullanıcı deneyimine yansıyordu ve sonuçlarda görülüyordu
    • Ok düğmelerinin karşı uçlarda değil de yan yana yerleştirilmesi gerektiğini hiç düşünmemiştim ama mantıklı
      “Hep böyle yapıldı” dışında bunun neden bu kadar nadir olduğunu merak ediyorum
  • “Tasarımcılar teknik olmayan kullanıcılarla kullanılabilirlik testi yapmıyor” deniyor ama yapsalar da pek fark etmez
    Neredeyse 25 yıldır web geliştiricisi olarak çalışıyorum ve birçok tasarımcıyla işbirliği yaptım; onların önemsediği şey, kendi “vizyonlarıyla” uyumlu piksel mükemmelliğinde yerleşim. UX akıllarının ucundan bile geçmiyor

    • Tüm tasarımcılar böyle değil ama çoğu gerçekten böyle. Gerçek kullanıcılarla yapılan bir UX araştırmasından çıkıp “bu yalnızca tek bir veri noktası ve biz o kullanıcıların haksız olduğunu düşünüyoruz” diyen tasarımcı gördüm
      Böyle durumlarda ikna işe yaramıyor