Experimento de densidad de UI creado con Svelte
(cybernetic.dev)- Grid es un experimento donde los usuarios pueden ajustar la densidad de la UI, y actualmente se está desarrollando una nueva versión
- Matrix, de carácter sucesor, apunta a una mayor densidad de UI y muestra una matriz de correlación del S&P 500 y el NASDAQ-100
- Al seleccionar los componentes del S&P 500, maneja correlaciones de más de 250 mil celdas y más de 30 millones de puntos de datos
- Algunas funciones no están incluidas en la vista previa inferior; para evaluarlas hay que abrir la UI de pantalla completa de Matrix
- El material del sitio es solo con fines informativos y no debe considerarse asesoría de inversión ni recomendación para comprar o vender valores
De Grid a Matrix: un experimento de densidad de UI
- Grid es un proyecto que experimentó con una densidad de UI personalizable por el usuario, y se está desarrollando una nueva versión
- Matrix es un experimento que lleva aún más lejos la densidad de UI y ofrece una matriz de correlación a gran escala del S&P 500 y el NASDAQ-100
- En la vista previa inferior se puede ver parte de Matrix, pero algunas funciones solo están disponibles en la UI de pantalla completa de Matrix
Escala de los datos que maneja Matrix
- Al seleccionar los componentes del S&P 500 como dataset, incluye más de 250,000 celdas
- Calcula correlaciones de más de 30,000,000 puntos de datos
- Se puede ver más información en la página About del experimento Matrix
- La página home ofrece un resumen de todos los experimentos de visualización de datos disponibles actualmente
Controles disponibles en la vista previa
- Las opciones de Dataset incluyen S&P500 y NASDAQ100
- Horizon permite elegir entre 1M y 1Y
- Como opción de preprocesamiento de datos, hay una casilla Detrend Data
- Las opciones relacionadas con el ordenamiento son las siguientes
- Sort By: Cluster, AvgCorr, MedCorr, Name
- Cluster Method: Avg, Complete, Ward
- Sort Direction: Asc, Desc
- La UI de vista previa incluye Minimap, Search, Rolling Correlation Chart e indicaciones para hover y click en celdas
- En el estado mostrado aparecen Symbols 101, Correlations 5,050, Cells 10,201
Aspectos a tener en cuenta al usarlo
- El material del sitio web es solo con fines informativos y no constituye asesoría de inversión ni recomendación para comprar o vender valores
1 comentarios
Opiniones de Hacker News
Últimamente estoy experimentando entre ordenamiento y visualización. Si un issue traído de Jira está bloqueado, me pregunto si necesito una columna booleana aparte para ordenar/filtrar, o si basta con aplicar estilo a otra columna (por ejemplo, el tiempo transcurrido). Estoy viendo si, en una tabla de más de 100 filas, solo con valores en naranja, rojo y rojo en negrita en una celda se puede identificar qué elementos hay que atender ahora.
Lo que me gusta de la vista de tabla de este experimento son las actualizaciones en tiempo real, el ordenamiento estable sobre varias columnas, el resaltado de filas al pasar el mouse, el atenuado de los ceros al final, los colores no excesivos (básicamente unas tres parejas) y los gráficos tipo sparkline en las columnas 24H Low/High. Lo que no me convence es la barra de desplazamiento horizontal casi invisible, la barra vertical ancha con gráficos pegados, que no queda claro cómo se ordenan realmente 24H Low/High, y que no haya filtrado. También noto que, comparado con mis reportes, aquí no hay tanta variación en el ancho de los valores. Cuando se mezcla texto, más que solo números, manejar el ancho de las columnas se vuelve más difícil.
La hélice me parece difícil de leer y poco útil. Este tipo de gráfico encaja mejor con datos periódicos cuyo período es mucho más corto que el rango total de datos.
El cubo me despertó curiosidad, pero no le vi mucho beneficio. Por lo general, las visualizaciones 3D son menos efectivas que mostrar lo mismo con tres gráficos 2D (en este caso, tres diagramas de dispersión). Al proyectar de 3D a 2D se generan distorsiones y también se confunde nuestra intuición básica para comparar posiciones. Me da curiosidad cuál era el efecto buscado aquí.
La forma en que permite mirar el pasado de la manera más natural posible mientras hace que los datos recientes se vean más grandes es realmente genial. Me cuesta creer que no se me haya ocurrido antes.
Desde "Material Design", que Google prácticamente enterró, hubo demasiada hinchazón, espacios en blanco, separaciones exageradas y desperdicio de “aire”.
Se vale soñar.
Las empresas no quieren diseñar dos UI muy distintas para cada plataforma y, en general, los usuarios quieren que lo aprendido en una plataforma se traslade a otra.
La accesibilidad también es más sencilla cuando el diseño tiene margen para fuentes grandes y no exige control motriz preciso. Al ver a mi padre envejecer de forma notoria, me doy cuenta de que incluso apps que me parecen espaciosas no son suficientes desde esta perspectiva.
Si no cambian las fuerzas que nos empujaron en esa dirección desde el principio, no sé bien cómo podríamos volver a diseños con alta densidad de información.
Estas pantallas usan una fuente monoespaciada de un solo tamaño. Tiene un estilo retro, como una UI en modo texto de los años 80, y si esa era la restricción intencional, está bien.
Pero si se pudiera establecer una jerarquía adecuada de tipografías y tamaños, cabría mucha más información en pantalla.
Como ejemplo básico, el cuadro “About” ocupa ahora casi 1/4 de la pantalla de un teléfono. Si se cambiara a una fuente proporcional más pequeña, seguiría siendo legible en el teléfono y esa información cabría en la mitad del espacio.
Si miras el trabajo de grandes diseñadores de información como Edward Tufte, suelen obsesionarse con ajustar bien la tipografía. Sus libros usan varios elementos y escalas tipográficas incluso en el texto principal fuera de las visualizaciones.
Me pregunto si el foco está en el rendimiento, la visualización o la densidad relacionada con alguna otra cosa.
Definitivamente se siente muy influenciado por él.
Los intentos de crear una UI similar con React en general fracasaron por su mal rendimiento. Para lograr un rendimiento de renderizado aceptable, en las tablas de datos se evitó React por completo. Aun así, para que el renderizado del navegador en sí no se volviera insoportablemente lento, había que minimizar la cantidad de elementos DOM por fila.
WinForms probablemente siga siendo mi framework de UI favorito. Sin duda es una herramienta torpe, pero se puede blandir con total libertad. Es tremendamente flexible, bastante fácil de usar, bastante rápido y terriblemente feo.
Le puedes pasar cualquier Object arbitrario y simplemente funciona. Puedes anidar un PropertyGrid dentro de un PropertyGrid, expandirlo con colecciones de objetos y anidar controles hasta la profundidad que quieras. No tienes que tocar ni preocuparte por la estructura interna del objeto al que se conecta la UI (aunque tiene sus límites).
Para mí, WinForms es el ideal platónico de un framework de UI. Si yo lo diseñara, creo que lo haría exactamente así.
Me encanta la densidad de información.
Colecciono periódicos antiguos, y en esa época la densidad de información era mucho mayor. Si buscas un gran libro de mesa de centro, prueba buscar "nytimes complete front pages". Había muchísima información clave en la parte superior, arriba del doblez.
Creo que una alta densidad de información equivale a alta inteligencia. Acertar con las prioridades de ordenamiento es algo muy valioso e importante.
En los últimos años la web pareció ir en la dirección contraria, así que me alegra ver que todavía hay gente remando hacia el otro lado.
Como otro ejemplo, mi blog está diseñado para permitir ver unos 20 años de escritos a la vez mediante zoom (https://breckyunits.com/).
También pronto voy a publicar un trabajo para promover y facilitar la creación de cheat sheets de alta densidad de información. Creo que me voy a quedar con el nombre Leet Sheet (https://pldb.io/blog/leetSheets.html).
Esto es interesante porque me demuestra algo sobre mi visión y mi comprensión visual.
La vista "Grid" está perfectamente bien. La vista "Table" es inutilizable.
Tengo muchos problemas para no perder la fila en la que estoy cuando recorro líneas largas de este modo. Me di cuenta de que se debe a una ligera tendencia a desplazar la dominancia ocular hacia la derecha cuando la mirada se mueve. Tengo una alineación binocular sutilmente desajustada y uso corrección prismática; un cambio reciente en esa corrección mejoró esta situación.
En esta representación, la posición de las líneas indicadoras en las columnas low/high empeora el desplazamiento accidental de fila (que siempre ocurre hacia arriba).
Para mí, probablemente sería mejor que el gráfico de líneas estuviera como fondo de la celda o en la parte inferior de la celda. Las filas también necesitan un rayado sutil.
La lección, desde la perspectiva de alguien que lee rápido y con soltura y que no tiene discapacidad visual ni cognitiva, es no asumir que está bien colocar información a lo largo de líneas anchas en este tipo de tablas. Hay que dar al usuario pistas para aferrarse a la fila mientras recorre horizontalmente. Las líneas divisorias finas no bastan, y cambiar el fondo al pasar el mouse no sirve en dispositivos táctiles.
Tal como está, cuando me encuentro con algo así suelo quitar la maximización de la ventana y reducir su altura para mirar los datos mientras hago scroll, usando la parte inferior de la ventana o la barra de título de otra ventana como un “borde” consistente. En el iPad, también he llegado a usar una hoja de papel o una tarjeta.
Primero, como se mencionó, el contraste entre una fila con hover o resaltada y una que no lo está es demasiado bajo. Incluso para mí, que tengo buena vista, es difícil de ver.
Segundo, para mejorar la legibilidad, las filas o columnas de una tabla deberían estar rayadas con dos o más colores de alto contraste. Por ejemplo: blanco, negro, blanco, negro. Esta tabla es negra de principio a fin.
Tercero, el contraste de los bordes de la tabla es tan bajo que casi no se ven. Combinado con el único color de filas/columnas, reduce aún más la legibilidad.
En resumen, la tabla en sí está bien; los colores son pésimos.
Los elementos de UI aquí se ven muy bien, pero también me da curiosidad saber cuál era el experimento y qué conclusiones se obtuvieron.
Si hablamos solo de la cantidad de elementos interactivos puros, según mi experiencia (Svelte 4), el renderizado suele causar problemas antes que la interacción. Es decir, los problemas de rendimiento aparecen con la misma cantidad de elementos independientemente de si son interactivos o no. Como se implementó en algunas partes de esta página, la solución es pasar a canvas.
Svelte también puede dibujar en canvas. También existe Threlte: https://threlte.xyz/
En cuanto al rendimiento interno de Svelte, no creo que se necesite algo como Jotai tanto como en React para evitar rerenderizados innecesarios.
Combinar Svelte con un excelente framework WebGL como Phaser permite un renderizado gráfico muy rápido: https://phaser.io/news/2024/03/official-phaser-3-and-svelte-...
Ese gráfico de hélice es realmente atractivo. No estoy muy seguro de si se podría usar en la práctica, pero se ve increíble
Si esto es un experimento, ¿cuál fue la conclusión?