Thử nghiệm mật độ UI được xây dựng bằng Svelte

 (cybernetic.dev)
1 điểm bởi GN⁺ 2024-07-28 | 1 bình luận | Chia sẻ qua WhatsApp
  • Grid là một thử nghiệm để người dùng tự điều chỉnh mật độ UI, và hiện đang được phát triển phiên bản mới
  • Matrix, mang tính kế thừa, hiển thị ma trận tương quan của S&P 500 và NASDAQ-100 với mục tiêu đạt mật độ UI cao hơn
  • Khi chọn các mã thành phần của S&P500, hệ thống xử lý tương quan của hơn 250.000 ô và hơn 30 triệu điểm dữ liệu
  • Một số tính năng không có trong bản xem trước bên dưới; để đánh giá đầy đủ, cần mở UI toàn màn hình của Matrix
  • Tài liệu trên trang web chỉ nhằm mục đích cung cấp thông tin và không được xem là lời khuyên đầu tư hay khuyến nghị mua/bán chứng khoán

Thử nghiệm mật độ UI từ Grid đến Matrix

  • Grid là một dự án thử nghiệm mật độ UI có thể tùy chỉnh, và hiện đang được phát triển phiên bản mới
  • Matrix là một thử nghiệm đẩy mật độ UI lên cao hơn nữa, cung cấp ma trận tương quan quy mô lớn của S&P 500 và NASDAQ-100
  • Có thể xem một phần Matrix trong bản xem trước bên dưới, nhưng một số tính năng chỉ có trong UI toàn màn hình của Matrix

Quy mô dữ liệu mà Matrix xử lý

  • Khi chọn các mã thành phần của S&P500 làm tập dữ liệu, hệ thống bao gồm hơn 250.000 ô
    • Tính toán tương quan của hơn 30.000.000 điểm dữ liệu
    • Có thể xem thêm thông tin tại trang About của thử nghiệm Matrix
  • Trang home cung cấp cái nhìn tổng quan về tất cả các thử nghiệm trực quan hóa dữ liệu hiện có

Các yếu tố điều khiển có thể kiểm tra trong bản xem trước

  • Mục chọn Dataset có S&P500 và NASDAQ100
  • Horizon cho phép chọn 1M và 1Y
  • Có hộp chọn Detrend Data như một tùy chọn tiền xử lý dữ liệu
  • Các tùy chọn liên quan đến sắp xếp như sau
    • Sort By: Cluster, AvgCorr, MedCorr, Name
    • Cluster Method: Avg, Complete, Ward
    • Sort Direction: Asc, Desc
  • UI bản xem trước bao gồm Minimap, Search, Rolling Correlation Chart, hướng dẫn hover và click trên ô
  • Ở trạng thái hiển thị, các chỉ số được ghi là Symbols 101, Correlations 5,050, Cells 10,201

Những điểm cần lưu ý khi sử dụng

  • Tài liệu trên trang web chỉ nhằm mục đích cung cấp thông tin và không phải là lời khuyên đầu tư hay khuyến nghị mua/bán chứng khoán

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-07-28
Các ý kiến trên Hacker News
  • Vì thường xuyên xử lý nhiều dữ liệu dạng bảng, tôi thích hiển thị được càng nhiều càng tốt trên một màn hình. Điều ảnh hưởng lớn nhất đến thiết kế báo cáo của tôi, bất ngờ thay, là iTunes: khoảng trắng chỉ vừa đủ cần thiết, các hàng kẻ sọc, sắp xếp nhanh và dễ, và nếu có thể thì cấu trúc kiểu trình duyệt theo cột. Tôi đã dùng DataTables nhiều năm nay và khá hài lòng
    Gần đây tôi đang thử nghiệm giữa sắp xếp và hiển thị. Nếu một issue lấy từ Jira đang bị chặn, tôi đang cân nhắc liệu có cần một cột boolean riêng để sắp xếp/lọc hay không, hay chỉ cần áp dụng style cho một cột khác (ví dụ: thời gian đã trôi qua) là đủ. Tôi đang xem liệu trong một bảng hơn 100 hàng, chỉ bằng giá trị màu cam, đỏ, hoặc đỏ đậm trong một ô có thể nhận ra mục nào cần xử lý ngay hay không
    Điều tôi thích ở chế độ xem bảng trong thử nghiệm này là cập nhật theo thời gian thực, sắp xếp ổn định trên nhiều cột, làm nổi bật hàng khi rê chuột, làm mờ các số 0 phía sau, màu sắc không quá tay (về cơ bản khoảng ba cặp màu), và các biểu đồ kiểu sparkline ở cột 24H Low/High. Điểm tiếc là thanh cuộn ngang gần như không thấy, thanh cuộn dọc rộng có gắn biểu đồ, không rõ 24H Low/High thực sự được sắp xếp như thế nào, và không có lọc. Ngoài ra, so với các báo cáo của tôi, cũng thấy rằng độ lệch về chiều rộng giá trị không lớn. Khi có lẫn văn bản thay vì chủ yếu là số, việc quản lý chiều rộng cột khó hơn
    • Tôi nhớ mình từng trì hoãn nâng cấp lên Catalina vì sợ iTunes.app biến mất. Đó là một ứng dụng bị đánh giá thấp hoàn toàn, và tôi thật sự mừng vì Music.app gần như là cùng một ứng dụng, việc di trú cũng dễ dàng
    • DataTables rất tuyệt. Tôi đã dùng nó trong một sản phẩm hơn 10 năm. Tôi vẫn tiếp tục tìm giải pháp thay thế mới hơn và tốt hơn, nhưng đến giờ vẫn chưa tìm được
    • Tôi cũng đang thử nghiệm phát triển ứng dụng Mac tích hợp với Jira hoặc các công việc khác diễn ra bất đồng bộ. Tôi vốn quan tâm nhiều hơn đến quyền kiểm soát việc được thông báo điều gì và khi nào, hơn là bản thân chế độ xem dữ liệu, nhưng sau khi xem bình luận này và UI, tôi muốn thử một vài ý tưởng khác mà trước đây bị kẹt ở màn hình dữ liệu chính
    • Ý bạn là định dạng có điều kiện biểu thị kích thước bằng màu sắc à?
  • Tôi khá thích cách mở rộng thanh cuộn của bảng như minimap trong trình soạn thảo mã để chứa thêm thông tin. Nó giúp nắm được ngay dữ liệu trên màn hình đang nằm khoảng đâu trong tập dữ liệu lớn hơn
    Helix cảm thấy khó đọc và không hữu ích. Kiểu biểu đồ này hợp hơn với dữ liệu có tính chu kỳ, trong đó chu kỳ ngắn hơn rất nhiều so với toàn bộ phạm vi dữ liệu
    Khối lập phương thì khơi gợi tò mò, nhưng tôi không thấy rõ ưu điểm. Thường thì trực quan hóa 3D kém hiệu quả hơn việc thể hiện cùng nội dung bằng ba biểu đồ 2D (ở đây là 3 biểu đồ phân tán). Vì khi chiếu từ 3D xuống 2D sẽ sinh ra méo mó, và trực giác cơ bản của con người về so sánh vị trí cũng bị nhiễu. Tôi tò mò hiệu ứng được chủ ý ở đây là gì
    • Nói rõ nhé, tôi không phải người tạo ra dự án đẹp đẽ này
    • Thật ra tab helix quá ấn tượng nên tôi vào đây để nói về nó. Chẳng hạn có thể dùng để vẽ độ biến động của cổ phiếu và các hàng hóa khác, đặc biệt là phái sinh
      Cách vừa nhìn về quá khứ một cách tự nhiên nhất có thể, vừa làm dữ liệu gần đây hiện lớn hơn, thật sự thiên tài. Khó tin là sao trước đây tôi chưa nghĩ ra điều này
  • Hy vọng những dự án như thế này là tín hiệu cho thấy các giao diện được thiết kế tốt nhưng vẫn có mật độ thông tin cao và tiết kiệm không gian đang quay trở lại
    Kể từ "Material Design" mà Google về cơ bản đã chôn vùi, sự phình to, khoảng trắng, giãn cách quá mức và kiểu “thoáng khí” đã lãng phí quá nhiều
    Mơ thì vẫn được mà
    • Trên di động, mục tiêu chạm phải có kích thước bằng ngón tay, nên UI rộng rãi ở một mức nào đó là cần thiết
      Các công ty không muốn thiết kế hai UI rất khác nhau cho từng nền tảng, và nói chung người dùng muốn cách sử dụng đã học trên một nền tảng cũng tiếp tục áp dụng được trên nền tảng khác
      Khả năng tiếp cận cũng dễ hơn khi thiết kế có chỗ cho phông chữ lớn và không đòi hỏi điều khiển vận động tinh vi. Nhìn cha tôi già đi thấy rõ, tôi nhận ra rằng ngay cả những ứng dụng mà mình cảm thấy rộng rãi cũng vẫn chưa đủ theo góc nhìn này
      Chừng nào những lực đẩy ban đầu đưa chúng ta theo hướng đó chưa thay đổi, tôi không rõ làm sao có thể quay lại thiết kế mật độ thông tin cao

    • starting with (now Google-dead) "Material Design"
      Tôi tưởng nó vẫn đang được phát triển tích cực. Ý là Google đã khai tử nó rồi à?
      https://m3.material.io/

    • Có vẻ chuyện này bắt đầu từ Apple khi chuyển từ OS 9 sang OS X. Khi đó tôi không giải thích được, nhưng đến nay vẫn thấy tiếc vì quá nhiều không gian màn hình đắt giá bị lãng phí
  • Tôi cho rằng thử nghiệm này thiếu typography, một yếu tố cốt lõi khi thiết kế mật độ UI
    Những màn hình này dùng phông chữ monospace một cỡ duy nhất. Nó mang phong cách hoài cổ như UI chế độ văn bản thập niên 1980, và nếu đó là ràng buộc có chủ ý thì không sao
    Nhưng nếu có thể đặt hệ phân cấp đúng đắn cho kiểu chữ và kích thước, có thể đưa nhiều thông tin hơn rất nhiều lên màn hình
    Ví dụ cơ bản, hộp “About” hiện chiếm gần 1/4 màn hình điện thoại. Nếu đổi sang phông chữ proportional nhỏ hơn, vẫn có thể đọc được trên điện thoại mà đưa thông tin này vào một nửa diện tích
    Nếu xem tác phẩm của các nhà thiết kế thông tin xuất sắc như Edward Tufte, họ thường ám ảnh với việc căn chỉnh typography cho đúng. Sách của ông cũng dùng nhiều yếu tố typography và thang kích cỡ khác nhau cho phần văn bản ngoài trực quan hóa
    • Có tác phẩm cụ thể nào của Edward Tufte đáng đề xuất về chủ đề này không?
  • Có thể lấy thứ như Perspective làm đối tượng so sánh chính xác không? (https://perspective.finos.org/)
    Tôi tò mò trọng tâm là hiệu năng, trực quan hóa, hay mật độ liên quan đến thứ khác
    • Nó tải chậm hơn nhiều so với trang gốc. Nhân tiện, tab helix của bài gốc thật sự đáng kinh ngạc
    • Lúc mới mở tôi tưởng nó được làm bằng Perspective
      Chắc chắn có cảm giác chịu nhiều ảnh hưởng
  • Khi làm các ứng dụng tài chính nhiều dữ liệu bằng Windows Forms, thứ tôi đặc biệt thích là control DataGridView. Nó có lọc, sắp xếp, kéo-thả để đổi thứ tự/đổi kích thước cột, đồng thời có mật độ và hiệu năng cao. Cũng không cần phân trang. Nếu muốn đưa vào 10.000 hàng thì cứ đưa vào là xong. Phần lớn UI chúng tôi làm là các màn hình đầy những panel DataGridView. Có xấu không? Có. Có nhanh không? Cũng có

Nỗ lực tạo một UI tương tự bằng React phần lớn đã thất bại vì hiệu năng không tốt. Với bảng dữ liệu, tôi đã hoàn toàn đi vòng qua React để có được hiệu năng render chấp nhận được. Dù vậy, để bản thân việc render của trình duyệt không chậm đến mức không thể chịu nổi, vẫn phải giảm tối đa số phần tử DOM trên mỗi hàng

  • WinForms có lẽ vẫn là UI framework tôi thích nhất. Rõ ràng là một công cụ thô kệch, nhưng có thể vung vẩy tùy ý. Cực kỳ linh hoạt, khá dễ dùng, khá nhanh, và xấu kinh khủng
    Ném một Object bất kỳ vào là nó cứ hoạt động. Có thể lồng PropertyGrid bên trong PropertyGrid, mở rộng bằng các collection đối tượng, và lồng các control sâu đến mức tùy thích. Không cần đụng vào hay bận tâm đến cấu trúc bên trong của đối tượng mà UI được nối tới (dù có giới hạn)
    Với tôi, WinForms là hình mẫu lý tưởng kiểu Plato của một UI framework. Nếu tôi tự thiết kế thì có lẽ cũng sẽ làm đúng như vậy

  • Tôi thật sự thích mật độ thông tin
    Tôi sưu tầm báo cũ, và thời đó mật độ thông tin cao hơn nhiều. Nếu đang tìm một cuốn sách đặt bàn cà phê hay, hãy thử tìm "nytimes complete front pages". Phía trên nếp gấp có thật sự rất nhiều thông tin cốt lõi
    Tôi cho rằng mật độ thông tin cao cũng giống như trí thông minh cao. Sắp xếp đúng thứ tự ưu tiên là việc rất có giá trị và quan trọng
    Trong vài năm qua, web dường như đã đi theo hướng ngược lại, nên thật vui khi vẫn thấy có người chèo về phía bên kia
    Một ví dụ khác: blog của tôi được thiết kế để có thể xem khoảng 20 năm bài viết cùng lúc thông qua phóng to/thu nhỏ (https://breckyunits.com/)
    Tôi cũng sắp công bố một dự án nhằm quảng bá và giúp việc tạo các cheat sheet có mật độ thông tin cao trở nên dễ hơn. Tôi định chốt tên là Leet Sheet (https://pldb.io/blog/leetSheets.html)

    • I think high information density === high intelligence.
      Nếu nhồi nhét thật nhiều thứ lên màn hình cùng lúc bằng font nhỏ, khoảng trắng nhỏ, v.v., thì ngay cả với người thông minh cũng sẽ phát sinh nhiều vấn đề về khả năng tiếp cận
      Các công ty như Google tăng khoảng trắng và padding là để làm cho UI dễ tiếp cận hơn với nhiều người hơn. Không chỉ là vấn đề thị lực; còn có các vấn đề thể chất như Parkinson khiến việc nhấp/chạm chính xác vào mục tiêu nhỏ trở nên khó khăn, và các vấn đề đa dạng thần kinh, nơi việc có quá nhiều văn bản hoặc phần tử trên màn hình cùng lúc chỉ riêng số lượng đó cũng có thể gây mất phương hướng (ví dụ: động kinh)
      Ngay cả người rất thông minh cũng có thể được hỗ trợ bởi một UI được thiết kế tốt và dễ tiếp cận. Không nên giả định rằng những người cần sự hỗ trợ đó kém thông minh hơn

  • Điều này thú vị vì nó chứng minh điều gì đó về thị giác và khả năng hiểu bằng thị giác của tôi
    Chế độ xem "Grid" thì hoàn toàn ổn. Chế độ xem "Table" thì không dùng được
    Tôi hay bị mất dấu mình đang ở dòng nào khi quét ngang các dòng dài như thế này. Tôi nhận ra nguyên nhân là khi ánh mắt di chuyển, mắt phải có xu hướng hơi chiếm ưu thế hơn. Hai mắt của tôi căn chỉnh hơi lệch nên phải dùng hiệu chỉnh lăng kính, và thay đổi hiệu chỉnh lăng kính gần đây đã cải thiện tình trạng này
    Trong cách biểu diễn này, vị trí của các đường đánh dấu ở cột low/high làm cho việc vô tình nhảy hàng (luôn nhảy lên trên) tệ hơn
    Với tôi, có lẽ sẽ tốt hơn nếu biểu đồ đường là nền của ô hoặc nằm ở phía dưới ô. Các hàng cũng cần có sọc nhẹ
    Bài học rút ra từ góc nhìn của một người đọc nhanh, thành thạo và không có khiếm khuyết thị giác hay nhận thức là: đừng giả định rằng cứ đặt thông tin trải dài ngang qua các dòng rộng trong những bảng như thế này là ổn. Cần cung cấp cho người dùng manh mối để bám theo hàng khi họ quét ngang. Chỉ các đường phân cách mảnh là không đủ, còn đổi nền khi hover chuột thì không dùng được trên thiết bị cảm ứng
    Với trạng thái hiện tại, khi gặp những thứ như thế này, tôi thường bỏ tối đa hóa cửa sổ và giảm chiều cao cửa sổ để vừa cuộn vừa dùng mép dưới của cửa sổ hoặc thanh tiêu đề của cửa sổ khác làm “cạnh” nhất quán để xem dữ liệu. Khi dùng iPad, tôi cũng từng dùng giấy hoặc thẻ

    • Khó khăn gặp phải với bảng có vẻ liên quan nhiều hơn đến thiết kế của tác giả, đặc biệt là lựa chọn màu sắc
      Thứ nhất, như đã nói, độ tương phản giữa hàng được hover/nhấn mạnh và hàng không được nhấn mạnh quá thấp. Ngay cả tôi có thị lực ổn cũng thấy khó nhìn
      Thứ hai, để dễ đọc, các hàng hoặc cột của bảng nên được kẻ sọc bằng hai hoặc nhiều màu có độ tương phản cao. Ví dụ trắng, đen, trắng, đen. Bảng này từ đầu đến cuối toàn màu đen
      Thứ ba, độ tương phản của viền bảng quá thấp nên gần như không thấy được. Kết hợp với việc chỉ dùng một màu cho hàng/cột, nó càng làm giảm khả năng đọc
      Tóm lại, bản thân bảng thì ổn, màu sắc thì tệ

  • Các phần tử UI ở đây trông rất tuyệt, nhưng tôi cũng tò mò thử nghiệm là gì và rút ra kết luận nào
    Nếu chỉ xét số lượng phần tử tương tác thuần túy, theo kinh nghiệm của tôi (Svelte 4), render thường gây vấn đề trước tương tác. Nói cách khác, bạn gặp vấn đề hiệu năng ở cùng số lượng phần tử bất kể chúng có tương tác hay không. Như đã triển khai ở một số phần của trang này, giải pháp là chuyển sang canvas

    • Svelte có thể dùng với các component không render. https://imfeld.dev/writing/svelte_domless_components
      Svelte cũng có thể vẽ lên canvas. Ngoài ra còn có Threlte: https://threlte.xyz/
      Về hiệu năng bên trong Svelte, tôi không nghĩ nó cần thứ như Jotai nhiều như React để tránh render lại không cần thiết

    • 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.
      Thật bất ngờ. Tôi tưởng điểm mạnh của Svelte là nhờ giai đoạn biên dịch và không có virtual DOM nên nó cập nhật DOM rất tinh vi và hiệu quả. Ngay cả trong paradigm đó, một bảng lớn đơn giản vẫn là vấn đề sao? Ví dụ trong các phần tử ở đây, có cái nào lẽ ra có thể render bằng DOM nhưng phải dùng canvas thuần túy vì hiệu năng không?

  • Kết hợp Svelte với một framework WebGL xuất sắc như Phaser có thể cho phép render đồ họa cực nhanh: https://phaser.io/news/2024/03/official-phaser-3-and-svelte-...

  • Biểu đồ helix kia thật sự rất cuốn hút. Không rõ có thể dùng trong thực tế hay không, nhưng nhìn thì cực kỳ ấn tượng
    Nếu đây là một thử nghiệm thì kết luận là gì?

    • Có vẻ nó không hoạt động trên Firefox, chỉ mình tôi bị vậy à?