Svelte ile Yapılmış UI Yoğunluğu Deneyi

 (cybernetic.dev)
1 puan yazan GN⁺ 2024-07-28 | 1 yorum | WhatsApp'ta paylaş
  • Grid, kullanıcıların UI yoğunluğunu ayarlamayı denediği bir deneydir; şu anda yeni bir sürümü geliştiriliyor
  • Devam niteliğindeki Matrix, daha yüksek UI yoğunluğunu hedefleyerek S&P 500 ve NASDAQ-100 korelasyon matrisini gösteriyor
  • Veri kümesi olarak S&P500 bileşenleri seçildiğinde, 250 binden fazla hücre ve 30 milyondan fazla veri noktası arasındaki korelasyonları ele alıyor
  • Bazı özellikler alttaki önizlemede yer almıyor; değerlendirmek için Matrix tam ekran UI açılmalı
  • Sitedeki materyaller yalnızca bilgilendirme amaçlıdır; yatırım tavsiyesi veya menkul kıymet alım-satım önerisi olarak görülemez

Grid’den Matrix’e uzanan UI yoğunluğu deneyi

  • Grid, özelleştirilebilir UI yoğunluğunu deneyen bir projedir; yeni bir sürümü geliştiriliyor
  • Matrix, UI yoğunluğunu daha da ileri taşıyan bir deney olarak, büyük ölçekli S&P 500 ve NASDAQ-100 korelasyon matrisi sunar
  • Alttaki önizlemede Matrix’in bir kısmı görülebilir, ancak bazı özellikler yalnızca Matrix tam ekran UI’da sunulur

Matrix’in ele aldığı veri ölçeği

  • Veri kümesi olarak S&P500 bileşenleri seçildiğinde 250.000’den fazla hücre içerir
    • 30.000.000’dan fazla veri noktası için korelasyon hesaplar
    • Matrix deneyinin About sayfasında ek bilgi görülebilir
  • home sayfası, şu anda sunulan tüm veri görselleştirme deneylerine genel bir bakış sağlar

Önizlemede görülebilen kontrol öğeleri

  • Dataset seçeneğinde S&P500 ve NASDAQ100 bulunur
  • Horizon için 1M ve 1Y seçilebilir
  • Veri ön işleme seçeneği olarak Detrend Data onay kutusu bulunur
  • Sıralamayla ilgili seçenekler şöyledir
    • Sort By: Cluster, AvgCorr, MedCorr, Name
    • Cluster Method: Avg, Complete, Ward
    • Sort Direction: Asc, Desc
  • Önizleme UI’sında Minimap, Search, Rolling Correlation Chart, hücre üzerine gelme ve tıklama yönergeleri yer alır
  • Gösterilen durumda Symbols 101, Correlations 5.050, Cells 10.201 olarak görünür

Kullanırken dikkat edilmesi gerekenler

  • Web sitesindeki materyaller bilgilendirme amaçlıdır; yatırım tavsiyesi veya menkul kıymet alım-satım önerisi değildir

İlgili okumalar

1 yorum

 
GN⁺ 2024-07-28
Hacker News yorumları
  • Çok fazla tablo biçimli veriyle çalıştığım için, tek ekranda mümkün olduğunca çok şey görmeyi tercih ediyorum. Rapor tasarımlarım üzerinde en büyük etkiyi şaşırtıcı biçimde iTunes yaptı: gerektiği kadar boşluk, zebra satırlar, hızlı ve kolay sıralama, mümkünse sütun tarayıcı benzeri bir yapı. DataTables'ı yıllardır memnuniyetle kullanıyorum
    Bu aralar sıralama ile gösterim arasındaki dengeyi deniyorum. Jira'dan alınan bir issue bloke durumdaysa, sıralama/filtreleme için ayrı bir boolean sütunu gerekip gerekmediğini, yoksa başka bir sütuna (ör. geçen süre) sadece stil vermenin yeterli olup olmadığını düşünüyorum. 100'den fazla satırı olan tablolarda, tek bir hücredeki turuncu, kırmızı veya kalın kırmızı değere bakarak şu an işlemem gereken öğeyi anlayıp anlayamayacağıma bakıyorum
    Bu deneyin tablo görünümünde hoşuma giden şeyler; gerçek zamanlı güncelleme, birden çok sütunda kararlı sıralama, mouse over sırasında satır vurgulama, sondaki 0'ların soluklaştırılması, aşırıya kaçmayan renkler (temelde yaklaşık üç çift) ve 24H Low/High sütunundaki sparkline benzeri grafikler. Eksik bulduklarım ise neredeyse görünmeyen yatay kaydırma çubuğu, grafik eklenmiş geniş dikey kaydırma çubuğu, 24H Low/High'ın gerçekte nasıl sıralandığının belirsiz olması ve filtrelemenin olmaması. Ayrıca kendi raporlarımla karşılaştırınca, değer genişliklerindeki değişkenliğin çok büyük olmadığını fark ettim. Sayısal ağırlıklı olmaktan çıkıp metin karıştığında sütun genişliğini yönetmek daha zor oluyor
    • Catalina'ya yükseltirsem iTunes.app kaybolacak diye ertelediğimi hatırlıyorum. Tam anlamıyla kıymeti bilinmeyen bir uygulamaydı; Music.app neredeyse aynı uygulama çıktı ve geçiş de kolaydı, bu yüzden buna gerçekten sevindim
    • DataTables harika. Bir üründe 10 yıldan uzun süredir kullanıyoruz. Sürekli daha yeni ve daha iyi bir alternatif arıyorum ama hâlâ bulamadım
    • Jira veya asenkron yürüyen başka işler ile entegre olan Mac uygulaması geliştirme üzerine de denemeler yapıyorum. Veri görünümünün kendisinden çok, ne hakkında ne zaman bildirim alacağımı kontrol etmekle ilgileniyordum; ama bu yorum ve UI'yi görünce ana veri ekranında tıkandığım başka fikirleri denemek istedim
    • Büyüklüğü renkle gösteren koşullu biçimlendirmeden mi söz ediyorsun?
  • Tablo kaydırma çubuğunun, kod editöründeki minimap gibi genişletilip ek bilgi taşımasını epey beğendim. Ekrandaki verinin, daha büyük veri kümesi içinde yaklaşık nerede olduğunu tek bakışta anlamaya yardımcı oluyor
    Helix bana okunması zor ve çok faydalı olmayan bir şey gibi geldi. Bu tür grafikler, periyodu tüm veri aralığından çok daha kısa olan periyodik veriler için daha uygun
    Küp merak uyandırdı ama ne işe yaradığını pek göremedim. Genelde 3D görselleştirmeler, aynı bilgiyi üç 2D grafikle (burada üç saçılım grafiğiyle) göstermeye göre daha az etkili oluyor. Çünkü 3D'den 2D'ye izdüşüm sırasında bozulma oluşuyor ve insanın konum karşılaştırmasına dair temel sezgisi de zayıflıyor. Burada hedeflenen etkinin ne olduğunu merak ediyorum
    • Net olayım, ben bu güzel projenin yapımcısı değilim
    • Aslında Helix sekmesi o kadar etkileyiciydi ki bunun için geldim. Örneğin hisse senetleri ve diğer emtiaların, özellikle de türevlerin volatilitesini çizmekte kullanılabilir gibi görünüyor
      Geçmişe olabildiğince doğal biçimde bakarken yakın dönem verilerini daha büyük göstermesi gerçekten dahiyane. Bunu daha önce kimsenin düşünmemiş olmasına inanmak zor
  • Umarım bu tür projeler, iyi tasarlanmış ama aynı zamanda bilgi yoğunluğu yüksek ve alanı verimli kullanan arayüzlere geri dönüşün işaretidir
    Google'ın fiilen gömdüğü "Material Design"dan beri şişkinlik, beyaz boşluk, aşırı aralıklar ve "hava" hissi gibi israf fazla arttı
    İnsan hayal kurabiliyor
    • Mobilde dokunma hedeflerinin parmak boyutunda olması gerektiği için, bir ölçüde geniş UI gerekiyor
      Şirketler platforma göre çok farklı iki UI tasarlamak istemiyor ve kullanıcılar da genelde bir platformda öğrendikleri kullanım biçiminin diğerine taşınmasını istiyor
      Erişilebilirlik de tasarımda büyük yazı tiplerine yer olduğunda ve hassas motor kontrol gerektirmediğinde daha kolay oluyor. Babamın gözle görülür şekilde yaşlandığını izlerken, bana geniş gelen uygulamaların bile bu açıdan yeterli olmadığını fark ediyorum
      Bizi baştan bu yöne iten güçler değişmedikçe, yüksek bilgi yoğunluklu tasarımlara nasıl geri dönebileceğimizi pek bilmiyorum

    • starting with (now Google-dead) "Material Design"
      Hâlâ aktif olarak geliştiriliyor sanıyordum. Google'ın bunu öldürdüğünü mü kastediyorsun?
      https://m3.material.io/

    • Sanki Apple tarafında OS 9'dan OS X'e geçişte başladı. O zaman bunu ifade edemiyordum ama pahalı ekran alanının bu kadar israf edilmesi hâlâ üzücü geliyor
  • Bana göre bu deneyde, UI yoğunluğunu tasarlarken kilit unsur olan tipografi eksik
    Bu ekranlarda tek boyutlu sabit genişlikli bir yazı tipi kullanılıyor. 1980'lerin metin modlu UI'larını andıran retro bir his veriyor ve eğer amaçlanan kısıt buysa sorun değil
    Ama yazı tipi ve boyutta düzgün bir hiyerarşi kurulabilirse, ekrana çok daha fazla bilgi sığdırılabilir
    Basit bir örnek olarak, "About" kutusu şu anda telefon ekranının neredeyse dörtte birini kaplıyor. Daha küçük orantılı bir yazı tipine geçilse, telefonda hâlâ okunabilir kalırken bu bilgi yarı alana sığabilir
    Edward Tufte gibi büyük bilgi tasarımcılarının işlerine bakınca, tipografiyi doğru ayarlama konusunda adeta takıntılı olduklarını görürsünüz. Kitaplarında, görselleştirmenin dışındaki gövde metninde bile birden fazla tipografik öğe ve ölçek kullanıyorlar
    • Bu konuda özellikle önerilecek bir Edward Tufte çalışması var mı?
  • Doğrudan bir karşılaştırma noktası olarak Perspective gibi bir şey düşünülebilir mi? (https://perspective.finos.org/)
    Odağın performans, görselleştirme ya da yoğunluğun başka bir boyutu olup olmadığını merak ediyorum
    • Yüklenmesi orijinal siteden çok daha yavaştı. Bu arada orijinaldeki Helix sekmesi gerçekten şaşırtıcı
    • İlk açtığımda bunun Perspective ile yapıldığını sandım
      Kesinlikle ondan çok etkilenmiş gibi duruyor
  • Windows Forms'ta çok verili finans uygulamaları yaparken özellikle sevdiğim şey DataGridView kontrolü. Filtreleme, sıralama, sürükle-bırak ile sütun yeniden sıralama/boyutlandırma sunarken aynı zamanda yoğunluk ve performansı da yüksek. Sayfalama da gerekmiyor. 10.000 satır koymak istiyorsanız, koyarsınız. Yaptığımız UI'ların çoğu, DataGridView panelleriyle dolu ekranlardan oluşuyor. Çirkin mi? Evet. Hızlı mı? O da evet.

React ile benzer bir UI yapma girişimleri performans açısından iyi sonuç vermediği için büyük ölçüde başarısız oldu. Kabul edilebilir render performansı elde etmek için veri tablosunda React tamamen baypas edildi. Yine de tarayıcının kendi render işleminin dayanılmaz derecede yavaşlamasını önlemek için satır başına DOM öğesi sayısını en aza indirmek gerekiyor

  • WinForms hâlâ muhtemelen en sevdiğim UI framework’ü. Kesinlikle hantal bir araç, ama onu özgürce savurabiliyorsunuz. İnanılmaz derecede esnek, kullanması epey kolay, oldukça hızlı ve korkunç derecede çirkin
    Rastgele bir Object fırlatın, yine de çalışır. PropertyGrid içine PropertyGrid gömebilir, bunu nesne koleksiyonlarına genişletebilir ve kontrolleri istediğiniz derinliğe kadar iç içe yerleştirebilirsiniz. UI’nin bağlandığı nesnenin iç yapısıyla uğraşmanız ya da onu dert etmeniz gerekmez (bazı sınırlar olsa da)
    WinForms benim için UI framework’lerinin Platonik idealidir. Kendim tasarlasam da muhtemelen tam olarak böyle yapardım

  • Bilgi yoğunluğunu gerçekten seviyorum
    Eski gazeteleri topluyorum; o zamanlar bilgi yoğunluğu çok daha yüksekti. Harika bir coffee table book arıyorsanız "nytimes complete front pages" diye aratmanızı öneririm. Katlanmış sayfanın üst yarısında inanılmaz miktarda temel bilgi vardı
    Yüksek bilgi yoğunluğunu yüksek zekâyla eşdeğer görüyorum. Sıralama önceliklerini doğru kurmak çok değerli ve önemli
    Son birkaç yılda web bunun ters yönüne gidiyor gibiydi ama hâlâ diğer yöne kürek çeken insanlar görmek güzel
    Başka bir örnek olarak, blogumu zoom in/out ile yaklaşık 20 yıllık yazıları tek seferde görebileceğiniz şekilde tasarladım (https://breckyunits.com/)
    Ayrıca bilgi yoğunluğu yüksek cheat sheet’leri tanıtıp üretmeyi kolaylaştıracak bir şey de yakında yayınlayacağım. Adını Leet Sheet olarak netleştirmeyi düşünüyorum (https://pldb.io/blog/leetSheets.html)

    • I think high information density === high intelligence.
      Küçük yazı tipleri ve dar boşluklarla ekrana çok şeyi bir anda sıkıştırmak, zeki insanlar için bile pek çok erişilebilirlik sorunu yaratır
      Google gibi şirketlerin margin ve padding’i artırmasının nedeni, UI’yi daha fazla kişi için erişilebilir hâle getirmektir. Bu yalnızca görme meselesi değil; Parkinson gibi küçük hedeflere doğru şekilde tıklamayı/dokunmayı zorlaştıran fiziksel sorunlar da var, ayrıca ekranda aynı anda çok fazla metin veya öğe bulunması hâlinde bunun miktarı yüzünden yön duygusunu kaybedebilen nöroçeşitlilikle ilgili durumlar da var (ör. epilepsi)
      Çok zeki insanlar bile iyi tasarlanmış ve erişilebilir bir UI’den fayda görebilir. Böyle yardıma ihtiyaç duyan insanların daha az zeki olduğu varsayılmamalı

  • Bu, benim görüşüm ve görsel algım hakkında bir şey kanıtladığı için ilginç
    "Grid" görünümü tamamen sorun değil. "Table" görünümü ise kullanılamaz
    Bu tür uzun satırları yatay olarak tararken hangi satırda olduğumu kaybetme sorunu yaşıyorum. Bunun, bakışım hareket ederken sağ göz baskınlığının biraz sağa kayma eğiliminden kaynaklandığını fark ettim. İki gözümün hizası hafifçe bozuk olduğu için prizma düzeltmesi kullanıyorum ve yakın zamanda yapılan bir prizma düzeltmesi değişikliği bu durumu iyileştirdi
    Bu sunumda low/high sütunlarındaki işaret çizgilerinin konumu, istemsiz satır kaymasını (ki hep yukarı doğru oluyor) daha da kötüleştiriyor
    Benim için çizgi grafiğin hücrenin arka planında ya da hücrenin alt kısmında olması daha iyi olurdu. Satırlarda hafif şeritler de gerekli
    Görsel veya bilişsel engeli olmayan hızlı ve yetkin bir okuyucu olarak çıkardığım ders şu: bu tür tablolarda bilgiyi geniş satırlara yaymanın sorun olmayacağını varsaymayın. Kullanıcı yatay tarama yaparken satırı tutmasını sağlayacak ipuçları vermeniz gerekiyor. İnce ayırıcı çizgiler tek başına yeterli değil ve mouseover ile arka plan değişimi dokunmatik cihazlarda işe yaramıyor
    Şu anda böyle bir şeyle karşılaşınca pencereyi tam ekrandan çıkarıp yüksekliğini azaltıyor, sonra pencerenin alt kısmını ya da başka bir pencerenin başlık çubuğunu tutarlı bir “kenar” olarak kullanarak veriyi okurken kaydırıyorum. iPad kullanırken kâğıt ya da kart da kullandım

    • Tablolarda yaşadığım zorluk, yazarın tasarımıyla, özellikle de renk seçimiyle, çok daha fazla ilgili görünüyor
      Birincisi, belirtildiği gibi hover durumundaki ya da vurgulanan satır ile diğer satırlar arasındaki kontrast çok düşük. Görmesi iyi olan biri olarak benim için bile seçmesi zor
      İkincisi, okunabilirlik için tablo satırları ya da sütunları iki veya daha fazla yüksek kontrastlı renkle şeritlenmeli. Örneğin beyaz, siyah, beyaz, siyah gibi. Bu tablo ise baştan sona tamamen siyah
      Üçüncüsü, tablo kenarlıklarının kontrastı çok düşük, neredeyse görünmüyor. Tek renkli satır/sütun yapısıyla birleşince okunabilirliği daha da düşürüyor
      Özetle tablo yapısı iyi, renkler ise berbat

  • Buradaki UI öğeleri çok hoş görünüyor ama deneyin ne olduğu ve hangi sonuca ulaşıldığı da merak uyandırıyor
    Salt etkileşimli öğe sayısı açısından bakıldığında, benim deneyimimde (Svelte 4) sorun çoğu zaman etkileşimden önce render tarafında çıkıyor. Yani öğelerin etkileşimli olup olmamasından bağımsız olarak, aynı sayıda öğede performans sorunları başlıyor. Bu sayfanın bazı kısımlarında uyguladığınız gibi çözüm canvas’a geçmek oluyor

    • Svelte, render’sız bileşenlerle birlikte kullanılabiliyor. https://imfeld.dev/writing/svelte_domless_components
      Svelte canvas’a da çizebilir. Threlte de var: https://threlte.xyz/
      Svelte’in iç performansı açısından bakarsak, gereksiz rerender’ları önlemek için React’teki kadar Jotai benzeri bir şeye ihtiyaç olduğunu düşünmüyorum

    • you run into performance problems at the same number of elements regardless of whether they're interactive. As you implemented for the some of these pages, the solution is to go to a canvas.
      Şaşırtıcı. Svelte’in avantajının, derleme aşaması ve sanal DOM olmaması sayesinde çok hassas ve verimli DOM güncellemeleri yapması olduğunu sanıyordum. Böyle bir paradigmada bile basit büyük tablolar hâlâ sorun mu? Buradaki öğelerden örneğin hangileri DOM olarak render edilebilirdi ama sırf performans nedeniyle canvas gerekli oldu?

  • Svelte, Phaser gibi harika bir WebGL framework ile birleştirildiğinde çok hızlı grafik render alma mümkün: https://phaser.io/news/2024/03/official-phaser-3-and-svelte-...

  • Şu heliks grafik gerçekten çok çekici. Pratikte kullanılabilir mi pek emin değilim ama görüntüsü inanılmaz havalı.
    Bu bir deneyse, sonuç neydi?

    • Firefox'ta çalışmıyor gibi görünüyor; yoksa sorun sadece bende mi?