Sadece Sıradan Web Özellikleri
(heather-buchel.com)- Yeni sosyal medya platformları, istemciler, uygulamalar ve React Native tabanlı web portları arttıkça, web sitelerinin kullanıcıların beklediği temel web davranışlarını kaybettiği örnekler de çoğalıyor
- Bunun başlıca nedenleri arasında hızlı yayın baskısı, UI mühendisi eksikliği, mobilde önce dokunma odaklı tasarım ve tarayıcının varsayılan davranışlarını JavaScript ile değiştiren uygulamalar gösteriliyor
- Metin kopyalama, bağlantıda sağ tıklama ve
ctrl + click, tarayıcı yakınlaştırma, duyarlı yerleşim,:hoverve:focus, URL ve geçmiş güncellemeleri, kaydırma çubuğu,ctrl + fgibi tarayıcının yerleşik işlevleri olduğu gibi çalışmalıdır - Tıklanabilir kartlarda
pointer-eventsözelliğini kaldıran ya da katmanları üst üste bindiren uygulamalar ile, anchor yerinedivveon-clickkullanarak gezinme sağlayan uygulamalar normal bağlantı deneyimini bozar - Erişilebilirlik ihlalleriyle örtüşen birçok nokta olsa da, web uygulamaları mobil uygulama gibi görünmektense kullanıcıların beklediği sıradan web özelliklerini korumalıdır
Web sitelerinin kaybettiği varsayılan davranışlar
- Web projeleri giderek daha sık şekilde kullanıcıların beklediği sıradan web özelliklerini engelliyor
- Yeni sosyal medya platformları arttıkça farklı istemciler ve uygulamalar geliştiriliyor; React Native gibi platformlar arası kod paylaşımını hedefleyen girişimler de yaygınlaşıyor
- Bu çabaların kendisi olumlu olsa da, görseller için
altmetni gibi temel erişilebilirlik gereksinimlerinin yanı sıra webin olağan etkileşim biçimleri de çoğu zaman gözden kaçıyor - Nedenler arasında şunlar öne çıkıyor
- Test edilebilir bir düzeye hızla çıkma baskısı
- Projede UI mühendisi bulunmaması
- Mobil dokunmatik girişi önceleyip diğer giriş yöntemlerini ve cihazları görmezden gelen tasarım
- Tarayıcının varsayılan davranışlarını JavaScript ile baypas eden veya değiştiren uygulamalar
Korunması gereken sıradan web özellikleri
- Metin kopyalama mümkün olmalıdır
- Tıklanabilir kart bileşenlerinde
pointer-eventskaldırılırsa veya tıklama hedefi için katmanlar üst üste bindirilirse, metin seçme ve kopyalama engellenebilir
- Tıklanabilir kart bileşenlerinde
- Bağlantı gibi gezinen öğeler bağlantı işlevini aynen sunmalıdır
- Sağ tıklamayla bağlam menüsü açılabilmeli ve bağlantı metni ya da adresi kopyalanabilmelidir
- Windows'taki
ctrl + clickgibi yeni sekmede açma kısayolları çalışmalıdır - Gezinme için
divüzerineon-clickeklemek yerine anchor öğesi kullanılmalıdır
- Tarayıcı yakınlaştırıldığında yerleşim bozulmamalı; kullanıcı okumak için sayfayı büyütebilmelidir
- Duyarlı web tasarımı, genişlik 1200px'in altına düştüğü anda basit bir mobil yerleşime çökmeden, dar görünüm alanlarında da alanı uygun şekilde kullanmalıdır
- Mastodon ve Twitter, tarayıcı genişliği daraldığında arayüzün tanıdık kaldığı ve alanın genel olarak iyi kullanıldığı örnekler olarak görülebilir
- Web uygulamaları
:hover,:focus,:activegibi etkileşim durumlarını doğru şekilde sunmalıdır- React Native uygulamalarının web'e taşındığı bazı örneklerde
:hoverveya:focusstilleri hiç yoktur ya da garip biçimde devre dışıymış gibi görünen:activestilleri ortaya çıkar
- React Native uygulamalarının web'e taşındığı bazı örneklerde
- Tıklamadan sonra arayüz tamamen yeni bir sayfaya geçmiş gibi değişiyorsa, tarayıcı geçmişi ve URL de buna eşlik etmelidir
- Bağımsız sayfa gibi görünen bir UI durumuna bağlantı verilememesi ve gezinmeden sonra durumun kaybolması kullanılabilirliği düşürür
- Kaydırma çubukları gizlenmemelidir
- Kullanıcı kaydırma çubuğunu tıklayıp sürüklemek isteyebilir
- Genel tarayıcı kısayolları uygulama içi işlevler için ele geçirilmemelidir
ctrl + fkısayolunun özel bir uygulama içi arama kutusunu açacak şekilde değiştirilmesi, sayfa içi aramanın alışıldığı gibi çalışmamasına yol açabilir
- Bunların çoğu erişilebilirlik ihlali sayılabilecek konularla örtüşse de, asıl odak web uygulamalarının kullanıcıların temel tarayıcı beklentilerini bozmamasını sağlamaktır
- Atlanmış örnekler Mastodon üzerinde konuşulmaya devam edilebilir
3 yorum
Gövde içeriği yanlış görünüyor.
Aa, ilginçmiş. Görünüşe göre ilgili blog yazısının kendisi biraz garip şekilde crawl ediliyor.
Crawler kısmına bir göz atmak gerekecek gibi görünüyor.
Hacker News yorumları
Web’i önce React ile öğrenip HTML’i sonra öğrenince, bağlantıların varsayılan davranışını umursamamaya başlamak gibi şeyler olabiliyor
Ekibe katıldığımda tüm bağlantılar ya butondu ya rastgele öğelerdi ya da
onClickile işleniyordu; kimse şikâyet etmiyordu amaCtrl+tıklamaişe yaramaz hâle gelmişti ve sağ tık menüsü de beklenen seçenekleri sunmuyorduBağlantılar söz konusu olduğunda pazarlığa yer olmadığını düşünüyorum
YC yatırımı almış archbee adlı dokümantasyon platformunda bile arama sonuçlarını yeni sekmede açamıyorsunuz; mevcut sekmede birini açıp olmazsa geri dönerek tekrar arama yapmanız ve sonraki sonucu açmanız gerekiyor
Örneği burada görebilirsiniz: https://docs.sparklayer.io/
Bu kadar büyük bir internet servisinin böylesine bariz bir erişilebilirlik sorununa sahip olması gerçekten tuhaf ve insanı çıldırtıyor
Hesap gerektirmemesi de var ama tweet dizilerine sağ tıklayıp yeni sekmede açabiliyorsunuz
Twitter konuşmalarının doğası gereği, özgün sayfadaki konumumu korurken birden fazla diziyi yeni sekmede açıp bakmak istiyorum; gerçek Twitter arayüzü ise bunu çok zorlaştırıyor
Bundan daha sinir bozucu pek az şey var; illa bir şey seçeceksem tarayıcı geçmişini bozmak olabilir
Geri gitme anında ve akıcı çalışsaydı bir nebze affedilebilir olurdu; ama gerçekte içerik yeniden yüklenirken bekliyor, kaydırma konumunuzu da kaybediyorsunuz
Daha da kötüsü, Facebook gibi aynı sohbet açılır penceresi durumunu birden fazla sekmede zorlayan siteler de var. Bir sekmede kapatırsanız diğer sekmede de kapanıyor; oysa birden fazla sekme açık tutmamın ayrı bir nedeni var
Yerleşik davranışlara dokunduğunuz anda bunun sorumluluğunu da üstlenmiş olursunuz diye düşünüyorum
Yarattığınız “özellik”, tasarımcının niyet ettiği dar kapsamda kalmaz; ziyaretçinin fiilen yaşadığı tüm deneyime dönüşür
Geri düğmesinin mantığını değiştirirseniz, o sitede geri gitmenin taşıdığı anlamı da değiştirmiş olursunuz; bunun sonucunda kafası karışan ve öfkelenen kullanıcıların “bozuk site” diye söylenmesinin sorumluluğunu da almalısınız
Kaydırma çubuğu gibi tarayıcıdan tarayıcıya ve işletim sisteminden işletim sistemine değişen davranışların sorumluluğunu gerçekten üstlenmeye hazır olup olmadığınızı düşünmelisiniz
Sonuçta web sitesini bir tür kreol dil konuşur hâle getiriyorsunuz; ziyaretçinin o dili anlamamasına ya da “yanlış yorumlamasına” şaşmamak gerekir
Bu tür özellikler, ziyaretçilere iyi davranmak için kaçınılması gereken şeyler olmanın ötesinde; getirisi sınırlı, zararıysa neredeyse sınırsız görünüyor
Bu deyimleri yok sayan siteler, kullanıcının aşina olduğu dili konuşmadığı için kullanımı daha zor hâle geliyor
Tasarım deyimlerinin kaybı üzerine uzun bir yazı da var: https://loeber.substack.com/p/4-bring-back-idiomatic-design
Bunu web sitelerinin uygulamalaştırılması olarak görüyorum ve artık durması gerekiyor
Web siteleri sunucu tarafı işlemeye dönmeli ve yalnızca gerektiği kadar JavaScript eklemeli
Buna karşılık web uygulamaları, kullanıcı için değeri varsa UX’i biraz daha ele alabilir; ancak tarayıcının içinde oldukları sürece temel ilkeler hâlâ geçerli
Web uygulamalarını, uygulama mağazalarının duvarlarının dışında herkesin erişebildiği bir geliştirme platformu oldukları için destekliyorum; ama tüm web sitelerine uygulama gibi davranmayı bırakmalıyız
Arama motoru sonuçlarında görünmesini istediğiniz bir sayfaysa, bu bir web uygulaması değil web sitesidir
Accept: text/markdowngönderebilmesi güzel olurdu ama CSS ortaya çıktığı anda o geminin kalktığını düşünüyorumNeyse ki React Server Components gibi şeyler sayesinde web sitelerine JavaScript’i parça parça ekleme yönüne geri dönülüyor gibi görünüyor; bu iyi
Yeterince zaman ayrılırsa çözülebilecek bir mesele
Banka web siteleri neden yapıştırmayı engelliyor, anlamıyorum
Yapıştıramayacağımı fark ettiğimde metni zaten kopyalamış oluyorum
Elle girince hata yapma ihtimali daha yüksek; pano zaten kirlenmişse de yapıştırma yasağını fark ettiğim anda kopyalama işlemi çoktan bitmiş oluyor
İnsanlar bunu bir güvenlik önlemi sanıp gönüllü olarak kopyalar hâle gelmiş gibi
En başta kullanıcının yapıştırmasını engellemenin nedenini anlamıyorum
O “parola” topu topu 6 haneli bir sayı ve kendim de belirleyemiyorum. Sanki 6 hane, parola yöneticisinin ürettiği 16 karakterlik rastgele dizgeden çok daha güvenliymiş gibi
Sayfanın içindeki rastgele konumlu düğmelerle giriş yapmaya zorluyor; cihaz zaten tuş vuruşları ve tıklamalar kaydedilecek kadar enfekte olduysa saldırganın parolayı tarayıcı belleğinden de okuyabileceğini düşünüyorum
Güvenlik açısından gerçekten inanılması güç derecede kötü bir karar
Botları zorlaştırmak için çeşitli şeyler deniyorlar ve bir gün orta kademe yöneticinin dürtmesiyle geliştiriciler giriş sayfasında kopyala-yapıştırı engelleyince botlar kısa süreliğine duruyor
Birkaç gün sonra botlar bunu aşıyor ama önceki “düzeltme”, “bazı botları engelleyebilir” düşüncesiyle kalıyor
Böylece yaklaşık 10 satırlık JavaScript, rewrite v6’ya kadar hayatta kalıyor; baştan yazıldıktan birkaç ay ya da yıl sonra da aynı yasak tekrar ekleniyor
Kesinlikle deneyimden konuşmuyorum
https://techcrunch.com/2018/07/03/new-malware-highjacks-your...
Belki bu tür şeyleri düşünmüş olabilirler
Gösterişli JS geliştiricilerinin, kimsenin istemediği karmaşıklığı ve özellikleri yerel HTML gibi görünen select menülerinin arkasına saklaması sinir bozucu
Bunu şehir ve eyalet girişlerinde sık görüyorum: şehir metin alanı, eyalet ise açılır/select menüsü oluyor
Teksaslı olduğum için şehri girip Tab ile eyalet seçimine geçiyor, sonra
t,ttuşlarına basıp sonraki form öğesine geçiyorumAma artık çoğu zaman açılır menü gibi süslenmiş bir metin arama girişi oluyor;
t,tTennessee’den sonra Texas’ı seçmek yerine kelimesi kelimesinettaraması yapıyorYalnızca fareyle üçgene tıklayıp eyalet listesini kaydıran kişiler için beklendiği gibi çalışıyor
Bozuk değilse düzeltmeye çalışmamak gerekir
Tarihsel olarak gerçek
<select>öğesinin stilini değiştirmek veya davranışını genişletmek çok zor ya da imkânsızdı; bu yüzden birçok uygulama onu kendisi yeniden uyguladı ve genelde sonuç berbat olduGörünüşe göre artık stili değiştirilebilir yerleşik alternatifler geliyor
Ayrıca uygulamalar, framework’ler ve şirketler arasında kod paylaşımı zor olduğu için; tam özellikli, erişilebilir ve özelleştirilebilir yerleşik bileşen alternatiflerini ancak büyük şirketler yapabiliyordu
Web Components,
<select>gibi yaygın uç bileşenlerde dünya çapında işbirliğini mümkün kılarak bu sorunu çözebilirİlgili yazı: https://blogs.windows.com/msedgedev/2022/05/05/styling-selec...
Bozuk bağlantı davranışlarının önemli bir kısmının, varsayılan bağlantı davranışının üzerine yazacak üst seviye yöntemlerin eksikliğinden kaynaklandığını düşünüyorum
Örneğin bir bağlantıyı modal olarak açmak için tıklama olayı dinleyicisi eklemek istemem. Tıklama olayı fazla düşük seviyeli; değiştirici tuşları kendin kontrol etmen gerekiyor
Asıl istediğim şey, tarayıcıya “bu anchor öğesi yüzünden mevcut pencere URL’si değişmek üzereyse bunun yerine bu işlevi çağır” diyebilmek
Böylece kullanıcı bağlantıyı yeni pencere veya yeni sekmede özgürce açabilir ve o durumda benim kodum çalışmaz
CSS için de aynı şekilde her öğe ve pseudo-class için imleç görseli belirtmek istemiyorum. “Varsayılan el/bekleme/yeniden boyutlandırma imlecini kullanacağın yerlerde bu özel görseli kullan” demek istiyorum
Böylece yeni öğeler veya UI’lar ortaya çıksa bile kod geleceğe dayanıklı olur
Bazı tarayıcı API’leri zaman zaman XY problemi yaşıyor gibi
Etikete
onclickkaydedip olay işleyicisinde varsayılan gezinme davranışını iptal etmek yeterliKullanıcı JavaScript’i kapatsa bile site düzgün çalışmaya devam eder; sağ tık bağlantı menüsü veya
Ctrl+tıklamagibi yerleşik tarayıcı davranışları da aynen çalışırYine de oldukça obscure bir “numara”; DOM API’nin bunu kolaylaştırması iyi olurdu
Bunun Navigation API için bir kullanım senaryosu olduğunu düşünüyorum
Tıklama veya pointer olayı değil, üst seviyeli bir visit olayı gerekiyor
Flutter Gallery’yi ilk gördüğümde web tarayıcısında her şey bozulmuş gibi hissettirdiği için şaşırmıştım: https://gallery.flutter.dev
Özellikle Reply örneği sanırım öyleydi
Bağlantılarda
Ctrl+tıklamaveya farenin orta düğmesi çalışmıyor, sağ tık çalışmıyor, metin seçme ve kopyalama çalışmıyor, teknik yapısı gereği öğe inceleme de çalışmıyor, sayfayı yakınlaştırmayı denediğinde de hiçbir şey olmuyorduO deneyimi ve daha geleneksel teknolojilerle yapılmış bazı SPA uygulamalarını düşününce bu yazının haklı olduğu hissi doğuyor
Web olsun mobil olsun, hiçbir Flutter demosu kullanılabilir bir UX sunduğuna beni ikna etmedi
Flutter’ın vaadi her yerde aynı olmaksa, bu demo masaüstünde de aynı derecede kötü olacaktır
Kaydırma davranışının da üzerine yazılmamasını isterim
Kaydırmayı “daha akıcı” yapacağım diye iyileştirmeye çalışmamak gerekir
Windows’ta iyi görünebilir, ama Mac’te Apple giriş aygıtları kullanıldığında trackpad ya da fare üzerinde parmağınızı hareket ettirmenizle kaydırılan hedefin hareketi 1:1 eşleşir
Bu tür “iyileştirmeler” çoğunlukla pekmezin içinde kaydırıyormuşsunuz hissi verir
Genel olarak tarayıcının varsayılan davranışını iyileştirmeye kalkışmamak gerekir
Berbat modern web’de sevmediğim şeylerden biri History API ile oynanması
HN gibi bir yerde ilginç görünen bir bağlantıya tıklayıp sayfaya giriyor ve kaydırmaya başlıyorsunuz; her başlık ya da pek önemli olmayan öğe bile geçmişe bir kayıt ekliyor
Asıl siteye geri dönmek için geri düğmesine yaklaşık bir milyon kez basmanız gerekiyor
Bunu yapan herkesten nefret ediyorum
Sadece sayfalama kullanılsa yeter
Bağlantı verilebilir, aranabilir, gezilebilir ve geçmişle de düzgün çalışır
Sonsuz kaydırma, pek bir sebep yokken bunların hepsini bozar
Burada aslında web kadar eski iki sorun var: düşük beklentiler ve insanları ya da pratikleri tanımlayan standartların/ölçütlerin yokluğu
Bugünlerde iş ilanlarına bakınca hepsi “Senior Fullstack Engineer”; ama içine girince gerçekten istenenin çoğu zaman Java ya da Python, R, Spring, SQL kombinasyonu olduğu görülüyor
Bu full-stack değil; böyle yazmak insanların zamanını boşa harcar ve teknolojiye dair anlamadığınız ya da önemsemediğiniz sinyalini kamuya verir
Programlamada buna “X/Y problemi” denir. İstenen nihai durum X’i çözmek gerekirken, bunun yerine yalnızca izlemek istediğiniz yaklaşım Y’den söz eden bir anti-pattern’dir
Bu yüzden işverenler tek bir ilana 500 özgeçmiş alıp yine de kimsenin uygun olmadığını hisseder
Başlangıç noktası hedef olmalı: “Şu tür bir istemci/sunucu uygulaması geliştirmek için işe alım yapıyoruz; adayın X, Y, Z özelliklerini yazıp desteklemesi gerekiyor ve kısıtlar A, B, C” gibi yazılmalı
Şirketlerin bunu yapamamasının nedeni çoğunlukla gerçekte ne yaptıklarını bilmemeleri ve zaten pek çok yanlış yoldan geçip bozulmuş teknolojiyi sırtlanmış olmalarıdır. Buna da teknik borç denir
Hedef bu şekilde net olursa, mülakatta hem şirket hem de aday neyi doğrulaması gerektiğini bilir ve birbirini uygun biçimde eleyebilir. Aksi halde süreç, görücü usulü buluşmayla yarışma programının karışımı gibi korkunç bir şeye dönüşür
Örneğin, yüksek derecede dağıtık bir medya konferans uygulaması geliştirmek için işe alım yapıldığını; geliştiricinin TypeScript yazacağını, soketlerden gelen akış verilerini pipe edeceğini, hem tarayıcı hem de sunucu tarafında çalışacağını ve test otomasyonu yazacağını açıkça belirtebilirsiniz
Operasyonel kısıtlar WCAG AA uyumluluğunu, hukuk ekibinin hazırladığı gizlilik uyumluluk kontrol listesini, yürütme hızı ve ağ gecikmesini hedefleyen performans değerlendirmelerini içerebilir; ideal adayın da mülakatta ağ gecikmesi, tarayıcı uygulama mantığı ve akış verisi durum yönetimi çözümlerini göstermesi gerekir