Eksperimen kepadatan UI yang dibuat dengan Svelte

• Grid adalah eksperimen yang memungkinkan pengguna menyesuaikan kepadatan UI, dan saat ini versi baru sedang dibuat
• Matrix, yang bersifat lanjutan, menargetkan kepadatan UI yang lebih tinggi dan menampilkan matriks korelasi S&P 500 serta NASDAQ-100
• Jika memilih saham konstituen S&P500, Matrix menangani korelasi dari lebih dari 250 ribu sel dan lebih dari 30 juta titik data
• Sebagian fitur tidak ada di pratinjau bagian bawah, dan untuk menilainya perlu membuka UI layar penuh Matrix
• Materi di situs ini ditujukan untuk informasi dan tidak dapat dianggap sebagai saran investasi atau rekomendasi membeli/menjual sekuritas

---

Dari Grid ke Matrix: eksperimen kepadatan UI

• Grid adalah proyek yang bereksperimen dengan kepadatan UI yang dapat dikustomisasi pengguna, dan versi barunya sedang dibuat
• Matrix adalah eksperimen yang mendorong kepadatan UI lebih jauh, menyediakan matriks korelasi S&P 500 dan NASDAQ-100 berskala besar
• Sebagian Matrix dapat dilihat di pratinjau bagian bawah, tetapi beberapa fitur hanya tersedia di UI layar penuh Matrix

Skala data yang ditangani Matrix

• Jika memilih saham konstituen S&P500 sebagai dataset, Matrix mencakup lebih dari 250.000 sel
  • Menghitung korelasi dari lebih dari 30.000.000 titik data
  • Informasi tambahan dapat dilihat di halaman About untuk eksperimen Matrix
• Halaman home menyediakan ikhtisar semua eksperimen visualisasi data yang saat ini tersedia

Kontrol yang dapat dilihat di pratinjau

• Opsi pilihan Dataset mencakup S&P500 dan NASDAQ100
• Horizon dapat dipilih antara 1M dan 1Y
• Ada checkbox Detrend Data sebagai opsi prapemrosesan data
• Opsi terkait pengurutan adalah sebagai berikut
  • Sort By: Cluster, AvgCorr, MedCorr, Name
  • Cluster Method: Avg, Complete, Ward
  • Sort Direction: Asc, Desc
• UI pratinjau mencakup Minimap, Search, Rolling Correlation Chart, serta panduan hover dan click pada sel
• Pada status yang ditampilkan, terlihat Symbols 101, Correlations 5.050, Cells 10.201

Hal yang perlu diperhatikan saat menggunakan

• Materi di situs web ini ditujukan untuk tujuan informasi dan bukan saran investasi atau rekomendasi membeli/menjual sekuritas

[GN⁺]

Pendapat Hacker News

• Karena sering menangani data berbentuk tabel, saya lebih suka sebanyak mungkin informasi terlihat dalam satu layar. Yang paling besar memengaruhi desain laporan saya, secara mengejutkan, adalah iTunes: ruang kosong secukupnya saja, baris bergaris selang-seling, pengurutan yang cepat dan mudah, serta struktur seperti column browser bila memungkinkan. Saya sudah memakai DataTables selama bertahun-tahun dengan puas
  Belakangan saya sedang bereksperimen antara pengurutan dan tampilan. Jika isu yang diambil dari Jira sedang terblokir, saya memikirkan apakah perlu kolom boolean terpisah untuk pengurutan/filter, atau cukup memberi gaya pada kolom lain (misalnya waktu berlalu). Saya sedang melihat apakah, dalam tabel berisi lebih dari 100 baris, nilai berwarna oranye, merah, atau merah tebal pada satu sel saja sudah cukup untuk mengenali item yang harus ditangani sekarang
  Yang saya suka dari tampilan tabel dalam eksperimen ini adalah pembaruan real-time, pengurutan stabil untuk beberapa kolom, penyorotan baris saat mouse hover, angka 0 di bagian belakang yang dibuat pudar, warna yang tidak berlebihan (pada dasarnya sekitar tiga pasang), dan grafik seperti sparkline pada kolom 24H Low/High. Kekurangannya adalah scrollbar horizontal yang hampir tidak terlihat, scrollbar vertikal lebar yang disertai grafik, ketidakjelasan bagaimana 24H Low/High sebenarnya diurutkan, serta tidak adanya filtering. Dibandingkan dengan laporan saya, terlihat juga bahwa variasi lebar nilainya tidak terlalu besar. Jika teks bercampur dengan angka, pengelolaan lebar kolom menjadi lebih sulit
  • Saya ingat menunda upgrade ke Catalina karena takut iTunes.app akan hilang. Itu aplikasi yang benar-benar diremehkan, dan saya sangat senang karena Music.app hampir sama dan migrasinya juga mudah
  • DataTables memang hebat. Kami sudah memakainya di satu produk selama lebih dari 10 tahun. Saya terus mencari pengganti yang lebih baru dan lebih baik, tetapi belum menemukannya
  • Saya juga sedang bereksperimen mengembangkan aplikasi Mac yang terhubung dengan Jira atau pekerjaan lain yang berjalan secara asinkron. Awalnya saya lebih tertarik pada kendali atas apa yang perlu diberi notifikasi dan kapan, bukan pada tampilan datanya sendiri, tetapi komentar dan UI ini membuat saya ingin mencoba ide lain yang sempat buntu di layar data utama
  • Maksudnya conditional formatting yang merepresentasikan ukuran dengan warna?
• Saya cukup suka pendekatan memperluas scrollbar tabel seperti minimap pada editor kode untuk memuat informasi tambahan. Ini membantu memahami sekilas posisi data yang sedang ditampilkan di dalam dataset yang lebih besar
  Helix terasa sulit dibaca dan tidak terlalu berguna. Grafik seperti ini lebih cocok untuk data periodik yang periodenya jauh lebih pendek daripada keseluruhan rentang data
  Cube menarik rasa ingin tahu, tetapi kelebihannya tidak terlalu terlihat. Biasanya visualisasi 3D kurang efektif dibanding menampilkan hal yang sama sebagai tiga grafik 2D (dalam hal ini tiga scatter plot). Sebab saat 3D diproyeksikan ke 2D terjadi distorsi, dan intuisi dasar manusia untuk membandingkan posisi juga menjadi kabur. Saya penasaran efek apa yang dimaksudkan di sini
  • Agar jelas, saya bukan pembuat proyek indah ini
  • Sebenarnya tab Helix itu luar biasa, jadi saya datang untuk membicarakannya. Misalnya, sepertinya bisa dipakai untuk menggambarkan volatilitas saham dan komoditas lain, khususnya derivatif
    Cara menengok masa lalu senatural mungkin sambil membuat data terbaru terlihat lebih besar benar-benar jenius. Sampai sulit dipercaya mengapa saya tidak pernah memikirkan ini
• Semoga proyek-proyek seperti ini menjadi tanda kembalinya antarmuka yang dirancang baik, tetapi tetap memiliki kepadatan informasi tinggi dan hemat ruang
  Sejak "Material Design" yang praktis dikubur Google, pemborosan seperti kegemukan UI, ruang putih, jarak berlebihan, dan “rasa lapang” sudah terlalu parah
  Kita boleh bermimpi
  • Di mobile, target sentuh harus seukuran jari, jadi UI yang cukup lega memang diperlukan
    Perusahaan tidak ingin merancang dua UI yang sangat berbeda untuk tiap platform, dan pada umumnya pengguna ingin cara pakai yang mereka pelajari di satu platform tetap berlaku di platform lain
    Aksesibilitas juga lebih mudah ketika desain punya ruang untuk font besar dan tidak menuntut kontrol motorik yang presisi. Melihat ayah saya makin jelas menua, saya menyadari bahwa bahkan aplikasi yang terasa lapang pun belum tentu cukup dari sudut pandang ini
    Selama kekuatan yang sejak awal mendorong kita ke arah itu tidak berubah, saya tidak begitu tahu bagaimana kita bisa kembali ke desain berkepadatan informasi tinggi

  • starting with (now Google-dead) "Material Design"
    Saya kira masih aktif dikembangkan. Maksudnya Google sudah mematikannya?
    https://m3.material.io/

  • Sepertinya ini dimulai dari Apple saat berpindah dari OS 9 ke OS X. Saat itu saya tidak bisa menjelaskannya, tetapi sampai sekarang masih terasa disayangkan karena terlalu banyak ruang layar yang mahal terbuang
• Menurut saya eksperimen ini melewatkan tipografi, salah satu elemen inti saat merancang kepadatan UI
  Layar-layar ini memakai font monospace dengan satu ukuran. Nuansanya retro seperti UI mode teks tahun 1980-an, dan itu tidak masalah jika memang batasan yang disengaja
  Namun jika hierarki jenis huruf dan ukuran bisa diatur dengan baik, jauh lebih banyak informasi dapat dimasukkan ke layar
  Sebagai contoh dasar, kotak “About” saat ini memakan hampir 1/4 layar ponsel. Jika diganti dengan font proporsional yang lebih kecil, informasi ini masih bisa dibaca di ponsel sekaligus muat dalam setengah ruang
  Jika melihat karya desainer informasi hebat seperti Edward Tufte, mereka sering sangat obsesif dalam menyetel tipografi dengan benar. Buku-bukunya juga menggunakan berbagai elemen dan skala tipografi pada teks utama di luar visualisasi
  • Adakah karya spesifik Edward Tufte yang direkomendasikan untuk topik ini?
• Apakah Perspective bisa disebut sebagai pembanding yang tepat? (https://perspective.finos.org/)
  Saya penasaran apakah fokusnya pada performa, visualisasi, atau kepadatan yang terkait dengan hal lain
  • Loading-nya jauh lebih lambat daripada situs asli. Sebagai catatan, tab Helix di situs asli benar-benar menakjubkan
  • Saat pertama kali membukanya, saya kira dibuat dengan Perspective
    Jelas terasa banyak dipengaruhi olehnya
• Saat membuat aplikasi finansial dengan banyak data di Windows Forms, yang paling saya sukai adalah kontrol DataGridView. Ia punya filtering, pengurutan, penataan ulang/ubah ukuran kolom dengan drag-and-drop, sekaligus kepadatan dan performa tinggi. Pagination juga tidak perlu. Kalau ingin memasukkan 10.000 baris, tinggal masukkan saja. Sebagian besar UI yang kami buat adalah layar yang penuh dengan panel DataGridView. Jelek? Ya. Cepat? Juga ya

Upaya membuat UI serupa dengan React sebagian besar gagal karena performanya tidak bagus. Untuk mendapatkan performa rendering yang dapat diterima, pada tabel data React dilewati sepenuhnya. Meski begitu, agar rendering browser itu sendiri tidak menjadi lambat sampai tak tertahankan, jumlah elemen DOM per baris harus diminimalkan

• WinForms mungkin masih menjadi framework UI yang paling saya sukai. Jelas ini alat yang kaku, tetapi bisa diayunkan sesuka hati. Sangat fleksibel, cukup mudah dipakai, lumayan cepat, dan luar biasa jelek
  Lemparkan Object sembarang ke dalamnya dan semuanya langsung berjalan. Anda bisa menumpuk PropertyGrid di dalam PropertyGrid, memperluasnya dengan koleksi objek, dan menumpuk control sedalam apa pun yang diinginkan. Tidak perlu menyentuh atau memikirkan struktur internal objek yang terhubung ke UI (meski ada batasannya)
  Bagi saya, WinForms adalah bentuk ideal Platonik dari sebuah framework UI. Kalau saya yang merancangnya, rasanya akan saya buat persis seperti itu

• Saya benar-benar menyukai kepadatan informasi
  Saya mengoleksi koran lama, dan pada masa itu kepadatan informasinya jauh lebih tinggi. Jika mencari buku coffee table yang bagus, coba cari "nytimes complete front pages". Ada begitu banyak informasi penting di bagian atas lipatan
  Menurut saya, kepadatan informasi yang tinggi sama dengan kecerdasan yang tinggi. Menentukan prioritas pengurutan dengan benar itu sangat bernilai dan penting
  Selama beberapa tahun terakhir web tampak bergerak ke arah sebaliknya, jadi senang melihat masih ada orang-orang yang mendayung ke arah yang berlawanan
  Contoh lain, blog saya dirancang agar melalui zoom in/out, sekitar 20 tahun tulisan bisa dilihat sekaligus (https://breckyunits.com/)
  Saya juga akan segera merilis pekerjaan untuk mempromosikan dan mempermudah pembuatan cheatsheet berkepadatan informasi tinggi. Namanya sepertinya akan saya tetapkan sebagai Leet Sheet (https://pldb.io/blog/leetSheets.html)

  • I think high information density === high intelligence.
    Jika Anda menjejalkan banyak hal sekaligus ke layar dengan font kecil, margin kecil, dan semacamnya, bahkan orang yang cerdas pun akan mengalami banyak masalah aksesibilitas
    Perusahaan seperti Google memperbesar margin dan padding untuk membuat UI dapat diakses oleh lebih banyak orang. Ini bukan hanya soal penglihatan; ada juga masalah fisik seperti penyakit Parkinson yang membuat objek kecil sulit diklik/ditap dengan tepat, serta isu neurodiversitas ketika terlalu banyak teks atau elemen di layar sekaligus dapat membuat seseorang kehilangan orientasi hanya karena banyaknya informasi (misalnya epilepsi)
    Orang yang sangat cerdas pun bisa terbantu oleh UI yang dirancang dengan baik dan aksesibel. Jangan berasumsi bahwa orang yang membutuhkan bantuan seperti itu kurang cerdas

• Ini menarik karena membuktikan sesuatu tentang penglihatan saya dan pemahaman visual
  Tampilan "Grid" sepenuhnya baik-baik saja. Tampilan "Table" tidak bisa dipakai
  Saya sering kehilangan posisi baris saat memindai melintasi baris panjang seperti ini. Saya menyadari bahwa ini disebabkan kecenderungan dominansi mata bergeser sedikit ke kanan ketika pandangan bergerak. Penyelarasan kedua mata saya sedikit meleset sehingga saya memakai koreksi prisma, dan perubahan koreksi prisma baru-baru ini membuat situasi ini membaik
  Dalam representasi ini, posisi garis penanda pada kolom low/high memperburuk perpindahan baris yang tidak disengaja (selalu terjadi ke arah atas)
  Bagi saya, mungkin akan lebih baik jika grafik garis menjadi latar belakang sel atau berada di bagian bawah sel. Baris juga perlu diberi striping yang halus
  Pelajaran yang saya dapat sebagai pembaca cepat dan mahir, serta tanpa disabilitas visual atau kognitif, adalah jangan berasumsi bahwa menempatkan informasi melintasi baris lebar dalam tabel seperti ini akan baik-baik saja. Pengguna perlu diberi petunjuk untuk tetap berpegang pada baris saat memindai secara horizontal. Garis pemisah tipis saja tidak cukup, dan perubahan latar saat mouse hover tidak bisa digunakan di perangkat sentuh
  Dalam kondisi sekarang, ketika menjumpai hal seperti ini, saya biasanya keluar dari mode maksimal pada jendela, memperkecil tinggi jendela, lalu menggulir sambil memakai bagian bawah jendela atau title bar jendela lain sebagai “tepi” yang konsisten untuk melihat data. Saat memakai iPad, saya juga pernah menggunakan kertas atau kartu

  • Kesulitan yang dialami pada tabel tampaknya jauh lebih berkaitan dengan desain pembuatnya, terutama pilihan warna
    Pertama, seperti disebutkan, kontras antara baris yang di-hover atau disorot dan baris yang tidak terlalu rendah. Bahkan bagi saya yang penglihatannya baik, ini sulit dilihat
    Kedua, demi keterbacaan, baris atau kolom tabel harus diberi striping dengan dua atau lebih warna berkontras tinggi. Misalnya putih, hitam, putih, hitam. Tabel ini dari awal sampai akhir semuanya hitam
    Ketiga, kontras border tabel terlalu rendah sehingga hampir tidak terlihat. Dikombinasikan dengan warna baris/kolom tunggal, ini semakin menurunkan keterbacaan
    Singkatnya, tabelnya sendiri baik-baik saja; warnanya buruk

• Elemen UI di sini terlihat sangat keren, tetapi saya juga penasaran eksperimennya apa dan kesimpulan apa yang didapat
  Kalau hanya melihat jumlah elemen interaktif murni, menurut pengalaman saya (Svelte 4), rendering sering lebih dulu menimbulkan masalah daripada interaksi. Artinya, masalah performa muncul pada jumlah elemen yang sama terlepas dari apakah elemen itu interaktif atau tidak. Seperti yang diterapkan pada sebagian halaman ini, solusinya adalah beralih ke canvas

  • Svelte bisa digunakan bersama komponen tanpa rendering. https://imfeld.dev/writing/svelte_domless_components
    Svelte juga bisa menggambar ke canvas. Ada juga Threlte: https://threlte.xyz/
    Terkait performa internal Svelte, saya tidak melihat kebutuhan akan sesuatu seperti Jotai sebesar di React untuk mencegah re-render yang tidak perlu

  • 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.
    Mengejutkan. Saya kira keunggulan Svelte adalah berkat tahap kompilasi dan ketiadaan virtual DOM, ia melakukan pembaruan DOM yang sangat presisi dan efisien. Dalam paradigma seperti itu pun, tabel besar yang sederhana masih menjadi masalah? Di antara elemen-elemen di sini, misalnya, mana yang sebenarnya bisa saja dirender sebagai DOM tetapi membutuhkan canvas murni karena alasan performa?

• Menggabungkan Svelte dengan framework WebGL yang hebat seperti Phaser memungkinkan rendering grafis yang sangat cepat: https://phaser.io/news/2024/03/official-phaser-3-and-svelte-...

• Helix chart itu benar-benar menarik. Saya tidak yakin apakah bisa benar-benar digunakan, tetapi tampilannya sangat keren
  Kalau ini sebuah eksperimen, apa kesimpulannya?

  • Sepertinya tidak berfungsi di Firefox; hanya saya saja?