1 puan yazan GN⁺ 1 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • (L)ots of (L)ittle ht(M)l page(s) yaklaşımı, JavaScript tabanlı sayfa içi etkileşimi birçok küçük HTML sayfası arasında geçiş yaparak değiştirmeyi öneriyor
  • Etkileşim, HTML sayfaları arasında gezinme olarak kurgulanıyor; modern ortamlarda CSS view transitions ile iyileştiriliyor ve yalnızca gerektiğinde biraz JavaScript ekleniyor
  • Blogdaki Menu, JavaScript ile açılan bir arayüz değil; <a href="/menu/"> bağlantısını izleyerek menüye ayrılmış bir sayfaya gitme yöntemi
  • Menüyü kapatma da varsayılan olarak / adresine giden bir bağlantı; ancak document.referrer varsa JavaScript ile history.back() çalıştırılarak geçmişte menüyü açma-kapama kayıtlarının birikmesi engelleniyor
  • Tarayıcının yerleşik özelliği olan bağlantı ile gezinmeye dayanmak, eski cihazlarda, eski tarayıcılarda ve JavaScript’in devre dışı olduğu ortamlarda da çalışmayı sağlıyor; ayrıca sayfa boyutu küçük tutuldukça etkileşim daha hızlı ve daha sağlam oluyor

Menü uygulama biçimi ve tasarım sonucu

  • Açma ve kapamanın ikisi de bağlantı olarak ele alınıyor

    • Normal sayfada menü sayfasına giden bir bağlantı var; menü sayfasında ise bu bağlantı “X”e dönüşerek menüyü kapatma işlevi görüyor
    • Kapatma eylemi de varsayılan olarak / adresine giden bir bağlantı; ancak document.referrer varsa JavaScript ile history.back() çalıştırılarak tarayıcı geçmişine menüyü açma-kapama kayıtlarının eklenmesi önleniyor
    • Basitleştirilmiş uygulama şu şekilde
      <!-- Normal page -->
      <nav>
        <a href="/menu/">
          <svg>...</svg>
        </a>
      </nav>
      
      <!-- Menu page -->
      <nav>
        <a href="/" onclick="document.referrer ? history.back() : window.location.href = '/'; return false;">
          <svg>...</svg>
        </a>
      </nav>
      
  • Doğrudan ziyaret ile site içi geçiş ayırt ediliyor

    • document.referrer ile menü sayfasına blog içindeki bir geçişle mi gelindiği, yoksa URL yazmak gibi doğrudan bir ziyaret mi olduğu ayırt ediliyor
    • Site içi geçişse anlamlı bir history.back() çalıştırılabiliyor; doğrudan ziyarette ise / adresine gidiliyor
  • Yaklaşım tasarımı şekillendiriyor

    • Basit görünen bu çözümde; gezinmenin özü, birden çok sayfaya yayılan etkileşim ve sayfa boyutunu küçük tutma yöntemi birlikte düşünülmek zorunda
    • Sayfa boyutu küçük tutulmalı ki etkileşim hızlı, sağlam ve sezgisel kalabilsin
    • Tarayıcıyı keyfi kod çalıştırıp indirip derleyerek gösteren bir çalışma zamanı olarak değil de belgelerde gezinme aracı olarak görmek, araçların yönlendirdiğinden çok daha basit web siteleri kurmayı mümkün kılıyor

1 yorum

 
GN⁺ 1 시간 전
Lobste.rs görüşleri
  • Genelde her zaman HTML ile yanıt verme yaklaşımını seviyorum, ama menü gibi durumlarda emin değilim
    Açılıp kapanabilen öğeler ile menüyü açmak için tam sayfa geçişi arasında hangisinin daha iyi olduğu konusunda erişilebilirlik uzmanlarının görüşünü merak ediyorum
    Burada Popover API daha iyi bir çözüm gibi geliyor. Çünkü tam bir gidiş-dönüş isteği olmadan JavaScript'siz bir menü sunabiliyor
    Bunun dışındaki çoğu noktada, sayfa geçişlerinden korkmamak gerektiğine katılıyorum. Artık SSR/statik sitelerde bile SPA benzeri gezinmeyi erişilebilir şekilde kurmak neredeyse her zaman zor değil

    • Erişilebilirlik uzmanı değilim ama web geliştirme için NVDA kurmuş biri olarak, kullanıcı deneyimi açısından büyük bir fark hissetmiyorum
      Sayfa geçişi mevcut konumu sıfırlıyor, ama amaç menüyü açmaksa ve gerçekten menüye ulaşıyorsanız ikisi oldukça benzer
      Yine de, ekran okuyucu kullanıcısı olmasanız bile, menü açarken yeni bir sayfaya gitmek oldukça tuhaf hissettiriyor
    • Buradaki ana kelime should değil, can. Etkileşim için HTML sayfaları uygunsa onları kullanın, başka bir yöntem daha uygunsa onu kullanın
      Örneğin bir bileşenin açık/kapalı durumunu iki farklı HTML sayfasıyla mı yapalım, yoksa <details> etiketi mi kullanalım diye sorulsa, elbette ikincisi
      Aynı şekilde Popover API kullanmak da tamamen makul. Mesele sayfa içi etkileşimlerde JavaScript zorunluluğundan kaçınmak; çok sayfalı HTML gezinmesini dayatmak değil
  • Önerilen yöntem, menüyü JavaScript ve onclick ile dinamik olarak yüklediği için gecikme yaratıyor ve kullanıcı yolculuğuna bir veri noktası daha ekliyor
    Bunun yerine menü her sayfaya konulup <details> öğesi veya :focus-within CSS seçicisiyle gösterilip gizlenebilir
    https://nlnet.nl bu şekilde çalışıyor

  • Anlatılan yaklaşım pratikte düzgün çalışmıyor. JavaScript'i kapatıp bir blog yazısı açtıktan sonra menüyü açıp kapatırsanız, asıl yazıya değil ana sayfaya (/) gidiyorsunuz
    Kapat düğmesine doğru bağlantıyı koymak için menünün backend tarafından dinamik olarak render edilmesi gerekir; ancak o zaman bu yaklaşım tutarlı olur
    Benim tercihim, mümkünse Popover API. Böylece backend olmadan her şeyi statik olarak render etmek mümkün olur

    • Menüdeki X ikonunun bağlantısı https://blog.jim-nielsen.com/ adresini gösteriyor, ama JavaScript açıkken onclick işleyicisi gezinmeyi ele geçiriyor gibi görünüyor
      document.referrer  
        ? history.back()  
        : window.location.href = '/';  
      return false;  
      
      href'de yazandan farklı bir sayfaya gönderdiği için kötü bir kullanıcı deneyimi. Bağlantının nereye gittiğini görmek için sık sık üzerine geliriyorum; böyle kandırılma hissi hoş değil
  • Bir yandan bunu gerçekten çok beğendim. Sadece HTML ile, JavaScript'ten daha akıcı ve daha basit şekilde pek çok şey yapılabiliyor
    Öte yandan bu yaklaşım bana daha çok mobilde uygun gibi geliyor. Masaüstünde bir sayfadaysam menünün her zaman görünmesini ya da pop-out olmasını beklerim; sayfa geçişi istemem
    O zaman şimdi tarayıcıya göre iki ayrı sayfa seti mi gerekecek diye düşünüyorum

    • Tersine, mobilde bağlantı dengesizse önce menüye gidip sonra hedefe gitmek gerekir
      Sürtünme iki katına çıkar
    • Sanırım nispeten gençsin. 20-30 yıl önce tüm web siteleri böyle çalışıyordu ve HTML de kısmen bunun için tasarlanmıştı
      JavaScript daha çok sonradan ortaya çıkmış bir şeydi
      Bunun herhangi bir JavaScript çözümünden daha zor ya da daha karmaşık geldiğine şaşırıyorum. Web sitesi yapmanın en basit ve en kolay yolu olduğu açık
  • Gezinme şekli pek hoşuma gitmedi ama geçiş efektini beğendim; bunun mümkün olduğunu bilmiyordum
    Kendi C++ statik üreticim ve şablon kütüphanemi kullandığım siteme de ekledim: https://vittorioromeo.com/
    Özellikle koyu/açık tema değiştiriciye çok yakıştığını düşünüyorum

  • Masaüstünde “menu”ya tıklayıp başka bir sayfaya gitmek hoş hissettirmiyor. Tam sayfa yenilemesi oluyor ve beklentinin tersine oldukça rahatsız edici
    Bana göre okuma akışını ve düşünce akışını bölüyor. Başka bir siteye giden bağlantıya tıklayınca odadan çıkıyormuşum gibi hissedip önceki odayı bırakıyorum; ama menüde böyle olunca kapıya gitmişken kendimi bambaşka bir odada bulmuş gibi oluyorum ve bu rahatsız ediyor
    Fikir dürüst olmak gerekirse güzel, ama kullanım hissi iyi değil
    Ayrıca hangi geçiş efektinden söz edildiğini de anlamıyorum. Benim ortamımda Menu düğmesine basınca sadece her zamanki gibi Menu sayfası yükleniyor

    • Belgeler arası view transition Firefox'ta henüz çalışmıyor
      Diğer tarayıcılarda da çalışmıyor olabilir, ama ana tarayıcım olarak Firefox türevi Librewolf kullanıyorum
      Chromium'da geçiş efekti görünüyor
  • İlginç bir fikir ama masaüstünde nasıl işleyeceğini merak ediyorum
    Tam sayfa menü biraz fazla geliyor; tüm sayfayı değiştiren yaklaşım pek uygun görünmüyor

  • Menü sayfasının yüklenme gecikmesini azaltmak için preloaddan söz edilmemiş
    Bununla ne kadar iyi çalışacağını merak ediyorum

    • Doğru cache header'larını da eklemek gerekir. Burada yalnızca basit bir expires header bile yeterli olabilir
      Böylece göstermeden önce doğrulama için sunucuya gitmesi de gerekmez ve çok hızlı hissettirir
  • Birkaç yıl önce @misty'nin yaptığı bir metin oyunu görmüştüm; basit bağlantıları etkileşim olarak kullanarak bir seçim yanılsaması yaratıyordu
    Sade HTML ve güçlü anlatı çok etkileyiciydi