[HN Gopher] An experiment in UI density created with Svelte
___________________________________________________________________
An experiment in UI density created with Svelte
Author : 11001100
Score : 349 points
Date : 2024-07-27 17:23 UTC (5 hours ago)
(HTM) web link (cybernetic.dev)
(TXT) w3m dump (cybernetic.dev)
| karaterobot wrote:
| That helix chart is very sexy. I'm not really sure I could use
| it, but danged if it isn't cool looking.
|
| If this is an experiment, what were your conclusions?
| encodedrose wrote:
| Would an accurate comparison be something like perspective?
| (https://perspective.finos.org/)
|
| Is the focus on density around performance, visualization, or
| something else?
| sbarre wrote:
| When I first loaded this, I assumed it was built with
| Perspective..
|
| It definitely feels very influenced by it.
| zongitsrinzler wrote:
| Reminds me of the Tron Legacy boardroom scene UI!
| woodsie wrote:
| I'm guessing it's an experiment on whether it's possible to make
| a human nauseous with a UI.
| wiseowise wrote:
| Not enough useless whitespace for your taste?
| daemonologist wrote:
| Some very cool looking UI elements here, but I'm also wondering
| what the experiment was and what conclusions you drew from it.
|
| On sheer number of interactive elements, my experience (Svelte 4)
| is that the rendering usually starts to cause problems before the
| interactivity, i.e. 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.
| jonahx wrote:
| > 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.
|
| That's surprising. I thought Svelte's whole selling point was
| ultra-targeted and efficient DOM updates as a result of the
| compilation step and not having vdom. Are simple large tables
| still a problem within that paradigm? Which of the elements
| here, eg, could have been rendered via DOM but needs canvas
| purely for perf?
| Mathnerd314 wrote:
| > Svelte's whole selling point was ultra-targeted and
| efficient DOM updates as a result of the compilation step and
| not having vdom
|
| Going by performance (https://krausest.github.io/js-
| framework-benchmark/), Svelte 4 is essentially vdom, Svelte 5
| is ultra-efficient based on the direct-DOM approach pioneered
| by Solid. Svelte 5 is currently a release candidate, API
| stable but also not necessarily production ready.
| https://svelte.dev/blog/svelte-5-release-candidate
|
| Disclaimer: I haven't actually looked at Svelte 4 to see why
| it is so much slower than Svelte 5
| jonahx wrote:
| > Svelte 4 is essentially vdom
|
| I can't speak to perf differences between 4 and 5
| specifcally, but I'm pretty sure Svelte's mission has been
| "no vdom" from the start. Here's a 2018 article, eg:
|
| https://svelte.dev/blog/virtual-dom-is-pure-overhead
| ricardobeat wrote:
| Svelte first came around in 2015-2016, and never had a
| virtual DOM - it was actually the one that introduced
| compiler-based optimizated DOM updates. This is mentioned
| in the Solid.js documentation [1].
|
| Svelte itself is a successor to Ractive.js which already
| existed in 2013 [2] with similar ideas, but before JS
| transpilers came into the picture.
|
| [1] https://www.solidjs.com/guides/comparison#svelte
|
| [2] first npm release:
| https://www.npmjs.com/package/ractive/v/0.2.0
| benatkin wrote:
| Svelte can be used with renderless components.
| https://imfeld.dev/writing/svelte_domless_components
|
| Svelte can also draw on a canvas. There is Threlte:
| https://threlte.xyz/
|
| As for performance within Svelte, I don't think it needs
| something like Jotai as much as React does to prevent
| unnecessary re-rendering.
| jonahx wrote:
| I love this -- dense but still easy to read.
|
| Also beautiful and polished as a piece of design, apart from the
| dataviz.
| thr0waway001 wrote:
| cool.
| revskill wrote:
| No explanation of "cool" is discouraged in this boring forum.
| yazzku wrote:
| It should have been prefixed with "AI".
| ThinnerHydra wrote:
| Or suffixed with "in Rust"
| sbr464 wrote:
| This is great work.
| jeffbee wrote:
| This obviously does not fit "as much data on a screen as
| possible". My laptop has a 7.7 megapixel display and each pixel
| has 1 billion possible states. This page is putting _maybe_ 10000
| bits of information on the screen, not even scratching the
| surface of machine 's capacity.
| razodactyl wrote:
| I hate that this can be taken seriously even though it's
| obviously a joke. It's a joke right?
| razodactyl wrote:
| Seriously though. I'm finding it increasingly frustrating how
| small the screen is on my iPhone 13. Makes me wonder how the
| hell I managed on the 4. Perhaps I'm just getting old.
| lucianbr wrote:
| If it was about a data structure and how much information can
| be stored in a number of bytes, would a similar comment have
| to be a joke? Seems rather reasonable for HN. If you hate
| this kind of thing maybe you're on the wrong site.
|
| I am more incredulous about the comments saying "I am happy
| Apple takes my freedom away in exchange for security and
| convenience". Of which there are plenty on certain threads.
| And clearly not joking.
| sbr464 wrote:
| Between the redditors and the autistic people, I can't tell
| who's joking any more.
| kristjansson wrote:
| This is the future. Traders staring at 60hz rainbow static
| and making completely grounded, data driven trades.
| layer8 wrote:
| s/as possible/as practical/
| sbr464 wrote:
| I appreciate that you are using this idea, but keeping padding
| and other design in tact, unlike most linux/unix devs that like
| dense ui.
| jbs789 wrote:
| I'm curious about what the objective and conclusion is.
| Admittedly I'm in the "less technical" audience, so less focused
| on the "sexiness" (as I've heard others refer to it).
| stonethrowaway wrote:
| I would assume the objective is to find an approach, or a
| repeatable formula that gives a good trade off between
| readability(visual navigability?) and visual density. More than
| likely it's a search for constraints, and then determining the
| boundaries of those constraints.
| breck wrote:
| I love information density!
|
| I collect old newspapers and back then info density was way
| higher (for an _amazing_ coffee table book, google "nytimes
| complete front pages"). So much critical info above the fold.
|
| I think high information density === high intelligence. Getting
| sort priorities right is very valuable and important.
|
| The past few years the web seemed to be going the other way. Good
| to see people still rowing in the other direction.
|
| Other examples:
|
| I designed my blog to allow one to zoom in/zoom out to see ~20
| years of posts at once (https://breckyunits.com/).
|
| I've got some stuff coming out to promote (and make it easier to
| build) highly information dense cheat sheets (I'm trying to get
| the name "Leet Sheet" to catch on -
| https://pldb.io/blog/leetSheets.html)
| mattlondon wrote:
| > I think high information density === high intelligence.
|
| Just packing loads of stuff on-screen at once, with tiny fonts
| and tiny margins and all the rest presents a lot of
| accessibility issues, even for intelligent people.
|
| Google et al are adding padding and white space to make their
| UIs more accessible for more people. It's not just eye sight
| we're talking here, but also physical issues with
| clicking/tapping small targets accurately (e.g. someone with
| Parkinson's), and also neuro divergent issues where a page full
| of text or whatever can disorient just by sheer amount of stuff
| happening on-screen at once (e.g. epilepsy)
|
| You can be very intelligent, but still benefit from well-
| designed and accessible UIs. Don't assume people who need it
| are less intelligent.
| breck wrote:
| All my stuff is 100% public domain and open source and can be
| piped through whatever people need to make the most custom
| experience.
|
| The default is high information density. This is how they did
| it in the old days. It makes a lot more sense to default to
| high information density with 100% public domain open source
| content in clean code for perfect accessibility.
|
| Anything with a (c) or license has bad accessibility.
| wiseowise wrote:
| > Google et al are adding padding and white space to make
| their UIs more accessible for more people. It's not just eye
| sight we're talking here, but also physical issues with
| clicking/tapping small targets accurately (e.g. someone with
| Parkinson's), and also neuro divergent issues where a page
| full of text or whatever can disorient just by sheer amount
| of stuff happening on-screen at once (e.g. epilepsy)
|
| We're not in a physical world and FAANG is not bound by money
| (no, I don't care about budget allocated to specific teams,
| I'm sure Android team has Pichai's credit card), so why are
| we settling for lowest common denominator instead of creating
| best UIs for every user type?
| btbuildem wrote:
| I quite like how you extended the table scrollbar to carry extra
| information -- akin to a minimap in code editors. At a glance it
| helps orient the data on screen in context of the larger dataset.
|
| The helix I find hard to read and not useful. These types of
| graphs are better suited for periodic data where the period is
| much shorter than the span of the dataset.
|
| The cube made me curious, but I couldn't quite see the advantage.
| Usually using a 3D viz is not as effective as using three 2D
| equivalent graphs (here would be 3 scatter plots) -- simply
| because the projection from 3D to 2D distorts things and messes
| with our innate ability to compare locations (and a bit less so,
| areas). What was the effect you were after here?
| 11001100 wrote:
| To clarify: I'm not the creator of this beautiful project.
| PhilipRoman wrote:
| Love the cube view! Tangentially related - anyone know a linux
| tool which takes a bunch of points/lines/labels as input and
| generates a nice interactive 3d view of it? I've considered using
| .obj file viewers, but it doesn't quite hit the mark. Gnuplot is
| nicer but doesn't have interactive features as far as I can tell.
| kristjansson wrote:
| If you're comfortable in R, rgl was pretty straightforward when
| I used it moons ago:
| https://cran.r-project.org/web/packages/rgl/index.html
| ladberg wrote:
| I love plotly for all my graphics needs (mainly 2D but supports
| 3D too)! Can export to a standalone interactive html file, can
| be used as a pandas plotting backend, can be easily extended
| with some client-side JS if you want to add more interactivity
| to the final result
| rdedev wrote:
| I had initially used plotly to build my dashboard but
| switched over to bokeh mostly because it's really hard to
| make plotly express api work with the graph objects api.
| Bokeh is pretty new though so ymmv but I have been liking the
| apk so far
| solardev wrote:
| This a flashback to the DOS era for me, or CLI utils like 'top'.
| I can't quite express why, but I find it a bit ugly and vaguely
| annoying. Probably reminds me too much of unstyled spreadsheets,
| or maybe I've just been brainwashed by modern trends...
|
| Regardless, I guess my primary gripe with it is the cognitive
| overload. A bunch of numbers (stocks? not sure) and names that
| all look the same, sometimes with different color end digits (why
| is the zero gray sometimes), in a vast sea of information but no
| context. What is the most important item at any given time? What
| do I need to pay attention to? I mostly just glaze over and tune
| it out because there's way too much going on.
|
| I get that it's an experiment (and ultimately a preference). Just
| not my thing, I guess.
| klaussilveira wrote:
| You are thinking about this from a end-user perspective, not a
| power user. It's the difference between eToro and Active Trader
| Pro. Or Fidelity's own app and their Active Trader Pro. There's
| is no right and wrong, they just target different audiences
| with different priorities.
|
| That's why we like btop and htop, but a normal PC user wouldn't
| understand anything.
| gala8y wrote:
| This complexity also shows in 3d software. I love all these
| UIs like 3dmax, SoftImage (!), Blender, Lightwave. Creating
| 3d has so many aspects to it and it shows in complexity of
| these UIs. Generally speaking, I much prefer being able to
| click one of many things shown on the screen than clicking
| through endless sub-menus, which was always a waste of time
| for me.
| solardev wrote:
| It's an interesting question (how much density is "right"
| for productivity apps).
|
| On one hand, I still hate the MS Office "ribbon" UI to this
| day and much prefer the denser and more compact Google Docs
| or even Open Office layout.
|
| On the other hand, Sketchup was hugely popular and very
| easy to use compared to its peers when it was released, and
| quickly became the de facto tool for simple free basic 3d
| modeling, in no small part because of easy and clean it
| was, I think. But they got bought out and then abandoned, I
| think? It doesn't have anywhere near the power of the other
| software anyway.
|
| IDEs are another example. VScode seems a lot cleaner and
| leaner than old IDEs, and Jetbrains ended up copying them
| too (a controversial change, of course).
|
| Photoshop is the one that always gets me. Twenty years of
| using it and I still can't get used to its layout. It's
| just so many different weird widget types mashed together
| in a way you don't see in any other software. I much prefer
| a docked toolbar like in Figma or Paint Shop Pro. I hate
| that I use it... I feel like a hostage every time I open
| it.
| gala8y wrote:
| > It's an interesting question (how much density is
| "right" for productivity apps).
|
| Between extremes of GUI presenting all functions at once
| and accessing all functions through memorized keyboard
| shortcuts, there must lay large lands of possible,
| experimental GUIs which unfortunately never get tested in
| popular software (which defaults to sub-menus + some
| keyboard access). I mean zoomable UIs, radial menus, 3d
| concepts in UIs,... - it's hard to see any of research on
| experimental interfaces make way into actual everyday-use
| apps.
|
| Every standard GUI element could be thought over. Once I
| worked with some standard accounting software, where I
| needed to select some stuff many times during the day
| from a dropdown. I quickly learnt how to move content
| from a dropdown menus into a spreadsheet with some
| formulas which allowed me to paste selection I needed
| back into these dropdowns 10 times faster. When I was
| leaving this temp gig I showed this solution to some guy
| in accounting, whose life was basically opening these
| dropdowns all day long. Regardless that he was really
| mean guy, I showed him the trick. He almost had tears in
| his eyes seeing it. I am not counting muscles strain
| avoided... Multiply by thousands of users everyday...
|
| Not to mention trying to integrate interoperability of
| apps within the OS (e.g. to have one program to check for
| spelling in all apps, across the OS - I cant remember
| name of one such fine try (ages before)).
|
| As per PS, have you ever tried to really personalize PS
| UI to your liking? I remember friends getting really
| opinionated on positioning all those menus perfectly for
| themselves (and for a reason). Personally I feel like PS
| is very intuitive for me, whereas in similar apps I cant
| do simple things, but it's probably because I was kindly
| shown around.
| solardev wrote:
| I'm not familiar with the UI of financial software, sorry.
| But can I ask what a power user in your example would be
| looking for in a screen like this? Like are they watching the
| screen for movement, color, ordering, something else...?
|
| The most similar things I've worked on were dashboards and
| spreadsheets, but in those cases, we put a lot of thought
| into information hierarchy and organization, not just flat
| density.
|
| For example, we'd hide what we could behind traffic status
| lights ; if all systems were green, you're good, and you'd
| only need to dig deeper into ones outside the norm that were
| yellow or red.
|
| Or where the metric itself is important and shouldn't be
| hidden, we'd still try to highlight changes over time with
| sparklines or conditional color scales.
|
| Basically just try to guide the report viewer's attention
| towards the most important things, whether it's "this is
| broken!" or "whoa, this number changed a lot over the last 24
| hours".
|
| Even in a spreadsheet, there'd be sparklines and cell
| formatting and subtotals and totals and such to highlight the
| important stuff.
|
| I can't think of a situation where I'd want to see a bunch of
| peer numbers like this with no hierarchy. I'm not really
| comparing them against each other, am I, but probably trying
| to see change over time...?
|
| But anyway, I honestly don't know (and am curious about) how
| this works in the financial sector. Are traders really just
| manually looking at all these numbers all the time (and doing
| what with them, trying to remember what they were some time
| ago?)?
| layer8 wrote:
| Just a nit, but power users _are_ end users.
| TehShrike wrote:
| I wonder if it would feel less annoying if the majority of the
| text was a bit higher contrast
| klaussilveira wrote:
| I love this, specially the minimap idea on the table. Have you
| considered a different way of adding/removing/moving columns with
| too many columns (100+)?
| ctippett wrote:
| On mobile, if I zoom out to 85% everything gets smaller and more
| things fit on the screen (great!). Zooming out further to 75%
| makes everything larger... 50% and things get larger still (more
| so than they were at their default size at 100%).
|
| The layout works remarkably well on mobile regardless, but I
| wasn't expecting such unintuitive zoom behaviour.
| hollerith wrote:
| >I wasn't expecting such unintuitive zoom behaviour.
|
| Huh. I expect user-interface surprises on web pages.
| Interacting with the other user interfaces in my life is much
| less surprising.
| yazzku wrote:
| I've seen this behaviour on other web pages too, and it also
| occurs on desktop. A mystery of life.
| fitsumbelay wrote:
| the helical visualization is a new one for me and _very_ nice,
| tho I agree with previous commenter about its usability, mainly
| bc of having to zoom in and out. really nice interaction tho
| kibwen wrote:
| Reminiscent of the Bloomberg Terminal:
| https://en.wikipedia.org/wiki/Bloomberg_Terminal
| perching_aix wrote:
| the experiment fails pretty hard on my phone where i have js
| turned off by default :p
| severak_cz wrote:
| DAWs and video editing programs can be very information dense.
| createwith wrote:
| meta: I would have upvoted this post 2x if you did the backend in
| Rust.
| Waterluvian wrote:
| Having to support mobile throws a big wrench in all design. You
| suddenly have to worry about a very different viewport and now
| you're significantly limited or designing two UIs.
| xyst wrote:
| I see you took a page out of the Bloomberg Terminal.
| ecjhdnc2025 wrote:
| This is interesting because it proves something to me about my
| vision and visual comprehension.
|
| The "Grid" view is absolutely fine for me. The "Table" view is
| unworkable.
|
| I have a lot of trouble scanning across lines like this, where I
| will lose which line I am on (when my glance shifts). This, I
| have realised, is due to the tendency to shift eye dominance
| slightly across to the right. (My eyes are subtly misaligned so I
| have some prism correction; a recent change to my prism
| correction has improved this situation for me.)
|
| This particular presentation has the indicator line in the
| low/high column placed so that it makes this accidental row
| shifting (which is always upwards) even worse.
|
| For me, the line graph would be better off either as the
| background to the cell, or towards the bottom of the cell. And
| the rows would need zebra-striping, subtly.
|
| The lesson from me, a fast and able reader who is not vision- or
| cognitively-impaired is: don't assume that you can put stuff
| across wide lines in tables like this. Provide affordances so
| people can hold onto the "row" as they scan across. The keyline
| separators are not enough, and the hover-over background change
| is not usable on a touch device.
|
| As it is, when I encounter stuff like this, I often have to un-
| maximise the window and reduce the window height so I can scroll
| and use the bottom of the window or the title bar of another one
| to provide a consistent "edge" to see the data on. If I am using
| my iPad, I have been known to use a piece of paper or card.
| wiseowise wrote:
| That is just amazing!
| terribleperson wrote:
| Adding a tiny bit of Y-padding made this a lot more readable for
| me. I wish more information display interfaces offered these
| kinds of controls. A thought that occurs to me: does densely-
| packed data get more readable the more experience you have with
| the data in question?
| SloopJon wrote:
| I deal with a lot of data in tabular form, and I like to have as
| much of it in front of me at once as I can. The biggest influence
| on my report design has been, believe it or not, iTunes: no more
| padding than necessary, zebra striping, fast and easy sorting,
| and something like a column browser if possible. I've been using
| DataTables happily for years.
|
| One thing I've been experimenting with lately is sorting vs.
| showing. If I'm pulling data from Jira, and an issue is blocked,
| do I need a separate boolean column to sort or filter, or is it
| enough to style another column (say, age)? In a table with a
| hundred or more rows, will an orange, red, or bold red value in a
| single cell stand out enough for me to recognize something I need
| to address now?
|
| Looking at the table view of this experiment, the things I like
| are:
|
| * live updating
|
| * stable sorting for multiple columns
|
| * row highlight on hover
|
| * dimming the trailing zeros
|
| * colors aren't overdone; basically just three pairs of colors
|
| * graph in the 24H Low/High column, kind of like a sparkline
|
| The things that don't land as well with me:
|
| * horizontal scroll bar is almost invisible
|
| * the wide vertical scroll bar with the graph
|
| * how does 24H Low/High actually sort?
|
| * no filtering (although it may not be essential for this data
| source)
|
| The other thing I notice, comparing this to some of my own
| reports, is that there isn't much variance in the width of the
| values. It's harder to manage column widths with text than a
| bunch of numbers.
| jgalt212 wrote:
| DataTables is great. Been using it for 10+ on a single product.
| We keep looking for a newer and better replacement, but have
| yet to find it.
| reaperman wrote:
| Same, absolutely "stuck" with DataTables. It seems to work
| well even with comprehensive UI frameworks on top of it like
| SB Admin Pro. Just super easy to integrate DataTables and has
| 90% of the features I ever want.
| Bluestein wrote:
| I'd like to think projects like these are somehow signaling a
| return to well designed but _information dense_ , space saving
| interfaces ...
|
| The amount of bloat, whitespace, extra spacing, "air" and other
| such waste - starting with (now Google-dead) "Material Design"
| has been egregious.-
|
| (One can dream ...)
| Spivak wrote:
| 1. Mobile needs to have somewhat spacious UIs to deal with
| touch targets needing to be finger sized.
|
| 2. Companies don't want to design two very different UIs and
| by-in-large users prefer their skills transfer across
| platforms.
|
| 3. Accessibility is easier if the design leaves room for bigger
| font sizes and doesn't require fine motor control. Watching my
| dad start to noticeably age I'm realizing that even spacious
| spacious apps don't go far enough in this regard.
|
| I'm not sure how we get to information dense design without
| something changing the forces that pushed us that way in the
| first place.
| Bluestein wrote:
| I see and understand your well placed and valid examination.-
|
| True. Mobile (and the path from "responsive" to "mobile
| native" - ergo, pre conditioned by everything you well
| mention ...)
|
| ... has led us to a what I think is today's sorry state of
| things.-
| Spivak wrote:
| I think the best we're going to get is some law or other
| that requires services not block 3rd party clients so that
| folks that want hacker-ui-theme, like me, have the ability.
| amelius wrote:
| An infinite scroll would have more UI density.
|
| Or a rich text editor containing 200 pages of text.
| ricardobeat wrote:
| More information, yes, not density. Same for pagination.
| Information density = amount of information you can gather _at
| once_ within a space, before any interaction.
| amelius wrote:
| It depends on definition (a page is still a page, even if not
| everything is visible).
|
| The point is that Svelte may have trouble processing many
| off-screen elements, and those would be good tests.
| ricardobeat wrote:
| _Information density_ is a well-established concept in UI
| design, this experiment is not (just) about performance.
|
| This is a great intro to the topic:
| https://matthewstrom.com/writing/ui-density/
| amelius wrote:
| Yes but if your definition of density mattered here, then
| why did they have to put Svelte in the title? And the
| Helix tab contains a listbox that doesn't fit on the
| screen. This is more about performance than about the
| user.
___________________________________________________________________
(page generated 2024-07-27 23:00 UTC)