[HN Gopher] An experiment in UI density created with Svelte
___________________________________________________________________
An experiment in UI density created with Svelte
Author : 11001100
Score : 792 points
Date : 2024-07-27 17:23 UTC (1 days 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?
| arendtio wrote:
| It doesn't seem to work in Firefox, or is it just me?
| karaterobot wrote:
| I'm on FF, and it works for me. :shrug:
| 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.
| localfirst wrote:
| It loaded a lot slower than OP's website which btw the helix
| tab is just mind blowing.
| 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
| not_really wrote:
| > ...pioneered by Solid
|
| Excuse me what?
| Mathnerd314 wrote:
| it is specifically the signals-based approach pioneered
| by Solid, https://youtu.be/82dzMKZzHrY?t=12314
| moritzwarhier wrote:
| The browser can take very long to layout and draw a page with
| a huge number of DOM elements.
|
| Hardware starts to mask a lot of these issues, but even a
| table with 1000 to 10,000 rows will already cause issues. And
| table layout is very optimized (for this reason, there are
| plenty of CSS gotchas around tables). So a 10,000 row plain
| HTML table still is rendered relatively fast, but not
| practical for an interactive UI.
|
| But for "snappy" UI and more involved CSS + many nested DOM
| elements, you'll need to start to consider viewport
| virtualization a lot earlier.
|
| This is independent of JS UI frameworks though.
|
| HTML+CSS rendering is an expensive, blocking operation. CSS
| even requires multiple passes for rendering nowadays AFAIK.
| Of course this is optimized to hell by browsers too.
|
| But you still need "viewport virtualization" in markup+CSS,
| or switch to canvas rendering, which does away with the
| markup and CSS entirely.
| selvan wrote:
| VS Code Editor which is based on Electron, is really fast,
| even with large codebase & many open tabs. Their monaco
| engine (https://microsoft.github.io/monaco-editor/) uses
| custom, virtual code processor that is optimized for
| surgically updating underlying DOM. It also uses WebGL +
| canvas rendering to show minimap of the file.
|
| Similar approach (custom virtual processor) is leveraged by
| Google docs/sheets.
|
| Canvas rendering may be the last resort when nothing
| worked.
| moritzwarhier wrote:
| As far as I know, VSCode/Monaco does use viewport
| virtualization
|
| > Canvas rendering may be the last resort when nothing
| worked
|
| For the minimap, yes. But AFAIK, for text rendering, it's
| not really a goto solution. Text wouldn't look crisp
| enough, apart from the fact that text layout is a science
| in itself.
|
| Basically you can get away with a debounced and cached
| canvas version of the full rendered DOM for that minimap,
| but you cannot use a huge DOM representing the full
| source for the actual editor.
|
| Docs afaik implements an expensive custom text rendering
| engine, similar to Flutter.
|
| Monaco doesn't.
|
| Take it with a huge grain of salt, I haven't researched
| this really and generally am not very familiar with the
| Monaco or VsCode source. I'm on mobile, so not inspecting
| a Monaco instance either.
|
| The Monaco repository seems to contain some files only in
| minified form, and refers to the VsCode repo.
|
| Skimming through the interfaces there, it definitely
| seems to have hints for viewport virtualization.
|
| https://github.com/microsoft/vscode/blob/2c46cf10d6773e69
| 0cb...
|
| Apart from that, WebWorkers seem to be used heavily to
| move the language server logic out of the main thread
| (completely different topic).
|
| What I wanted to say is that "surgical DOM updates" might
| be good, but DOM _size_ is the main issue for rendering.
|
| Sure, heavy-handed DOM updates have an effect too (it's
| the same as rendering a new large DOM tree).
|
| But keeping DOM elements consistent instead of replacing
| large subtrees is without alternative anyway, regardless
| how optimized browser rendering and parsing will ever be,
| because of focus states for example.
|
| Also worth noting that querying layout via JS is
| similarly expensive (not related to Svelte either).
|
| Back to your comment:
|
| React might be less performant than Svelte, but a React
| "render" is not as expensive as a browser rendering the
| changed DOM.
|
| And Svelte's main differentiation is that it doesn't need
| a runtime in the browser and instead directly produces
| DOM-API code.
|
| The difference is not on the number of updates (React,
| Vue etc are "surgical" there too). It's how the required
| DOM API calls are computed.
| 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.
| d13 wrote:
| You can combine Svelte with an excellent WebGl framework like
| Phaser for blindingly fast graphics rendering:
| https://phaser.io/news/2024/03/official-phaser-3-and-svelte-...
| 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.
| solardev wrote:
| Heh, I have the opposite problem as Mr. Tiny Hands. I wish
| I could get a smaller phone with good cameras. Apple had
| the smaller iPhone, SE maybe, for a while (maybe they still
| do?). But all the Pixels are humongous and I miss being
| able to operate it with one hand.
|
| Seems like there's way more huge phones (especially folding
| ones) than small ones these days.
| 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?
| hombre_fatal wrote:
| Maybe the design that addresses accessibility is better for
| most people, and the high density crowd for most types of
| apps is tiny.
| Mindwipe wrote:
| Google's design frameworks for the last five years have been
| completely unaccessible for those of who need concise and
| compact UIs.
| 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.
| localfirst wrote:
| i actually just came here to comment on helix tab and how
| fcking amazing this is. For example, I can use this view to
| chart out volatility of stocks and other instruments especially
| derivatives I'd imagine.
|
| Having a super natural way to peer into the past as much as
| possible while the more recent data are larger is pure fcking
| genius. I can't believe why I never thought of this.
| 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 was leaving this temp gig I showed this solution to
| some guy in accounting, whose life was basically opening
| these dropdowns all day long.
|
| Lol, that is such a tragic story that must happen
| millions of times across the world today. At a previous
| job, one department was spending 3-4 hours a day manually
| copying & pasting customer contacts from emails into
| their CRM. This was in an org with tens of developers,
| but nothing was done about it for years until my manager
| happened to catch wind of it and asked me to take a look
| in my spare time. I wrote an integration in a few hours
| and those ~40 lines of code have probably saved thousands
| of hours and dollars by now.
|
| As programmers, we're allergic to manual repetition, but
| so much of the world runs on that...
|
| > As per PS, have you ever tried to really personalize PS
| UI to your liking?
|
| When I was young, I used to spend hours doing that,
| iterating on PS UI configurations, testing them,
| rearranging and retesting... these days I'm just too old
| and curmudgeonly to do anything about it except whine,
| lol. But you're right, I should probably just bite the
| bullet and do that once and sync it to my account.
| 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
| solardev wrote:
| You can fiddle with the interface and tweak some layout
| parameters in the sidebar somewhat.
|
| By the time I got it to something I liked, it severely
| violated the spirit of the experiment, lol (was too big and
| sparse, with lots of padding between items - the opposite of
| what it was trying to show):
| https://share.cleanshot.com/0xD9bPcWD1CL5wDvlVhB
|
| And I still don't know how these numbers are used. I wouldn't
| be able to keep track of even 3-4 numbers at once, much less
| the dozens here.
| 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.
| hombre_fatal wrote:
| You usually can't viewport zoom non-web UI.
| 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
| Nathanael_M wrote:
| I suspect it would also fail if you tried it on Internet
| Explorer 6.
| perching_aix wrote:
| probably, although i feel keeping js turned off by default
| when browsing random sites is infinitely better motivated
| than using internet explorer 6
| 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.
| 01HNNWZ0MV43FF wrote:
| just make a responsive design that allows you to either drink
| from a fire hose or a coffee stirrer
| Waterluvian wrote:
| "Responsive design" is basically couched language that hides
| that you're either designing it twice or are making
| compromises to one or both aspects/sizes.
|
| There isn't really any other choice. It's reality. But it's
| just sometimes quite frustrating.
| solardev wrote:
| It's half the fun!
|
| I'm biased, but as a frontend dev and sometimes-UI guy,
| responsive design is one of my favorite parts of the job. It
| forces me to think creatively (and scientifically, whenever we
| can actually afford to do testing) on how to present
| information and create controls for everything from a small
| iPhone to a giant ultrawide monitor.
|
| I mean, even in the Windows days (as in when most apps were
| still desktop Windows apps), basic responsiveness was already a
| thing, since even then you had no guarantee your app was going
| to be running in fullscreen at 1024*768 only. How your main
| windows, toolbars, etc. scale to different screen widths &
| orientations is a fun challenge to solve. Even in gaming, it's
| fun to see how desktop games (like Terraria) scale their
| controls down to a phone.
|
| Anyway, for me it usually ends up being about 1.5x the work
| compared to a single viewport, since most components can still
| be reused in slightly different arrangements. Menu navigation
| and information architecture can be tricky though, switching
| from "broad but shallow" organization to "narrow but deep"
| hierarchies.
| 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.
| Dalewyn wrote:
| I think your trouble with the table has far more to do with the
| design (specifically color) choices made by the author.
|
| 1. You mentioned this in passing, but I'll repeat for emphasis:
| The contrast between a hovered/highlighted table row and ones
| that are not is too low. I have decent eyes and I also have a
| hard time seeing it.
|
| 2. Table rows (and/or columns) should be striped between two or
| more high contrast colors for better legibility. White, black,
| white, black for example. This table is all black through and
| through.
|
| 3. The table borders' contrast is way too low, it's hardly even
| visible. This combined with the singular row/column color makes
| legibility even worse.
|
| TL;DR: Table itself is actually fine, the colors are terrible.
| mrtobo wrote:
| Yes.
| 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.
| LoganDark wrote:
| Honestly this doesn't even sound like a particularly bad
| thing. Sort of like how Houdini has literally no
| competition whatsoever. Like it's actually hilarious how
| nothing even comes close. It just works so well that nobody
| can really hope to ever do better, and there is nearly 0
| enshittification happening, so its existing users have no
| reason to ever switch.
| mst wrote:
| Having found more than one thing called that, could you
| enlighten me as to which Houdini you're referring to,
| please?
| malkia wrote:
| Assuming it's the SideFX product -
| https://www.sidefx.com/ - it's simply the best in it's
| class.
| LoganDark wrote:
| Yep, sorry, that is indeed what I meant; I had originally
| said Houdini FX but I couldn't tell if that was the true
| product name or not since there are non-FX versions.
| Bleh.
| __jonas wrote:
| I'm not super familiar with 3D stuff, but I'm curious
| what the "class" here is, is it specifically procedural
| sort of effects creation mainly for film?
|
| I'm assuming for 'regular' 3D modelling people still
| prefer other software like blender/max right?
| reaperman wrote:
| Definitely not a bad thing.
| halfcat wrote:
| _"90% of the features I ever want"_
|
| What's in the other 10%?
| reaperman wrote:
| Honestly just UI tweaks to make the density higher,
| especially for controls. I could do this myself with
| mostly CSS if I wasn't incredibly lazy.
| dr_dshiv wrote:
| Conditional formatting to indicate magnitude via color?
| sgt wrote:
| I remember delaying my upgrade to Catalina because I worried
| that iTunes.app would disappear. It was completely underrated.
| I was so happy to find out that Music.app is pretty much the
| same app and the migration was easy.
| 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.
| wruza wrote:
| >1.
|
| This is not true. Mobile platforms _do_ help with tapping on
| small elements. E.g. HN isn 't mobile friendly "as is", but I
| have no issues with tapping any of the links. I've also used
| Exante mobile trading terminal for some time and had no
| issues with it either.
|
| I agree that accessibility still is the concern, but watching
| my grandma struggle with her tablet, it's mostly the fact
| that buttons aren't buttons and everything jumps around like
| clowns in circus and cannot stop, instead of being a proper
| user interface. I bet she'd have similar issues with
| appliances if their design was just random flat symbols on
| white surfaces that randomly disappear.
| Aeolun wrote:
| > I bet she'd have similar issues with appliances if their
| design was just random flat symbols on white surfaces that
| randomly disappear.
|
| That sounds like the control panel for my fridge :)
| g15jv2dp wrote:
| > This is not true. Mobile platforms do help with tapping
| on small elements. E.g. HN isn't mobile friendly "as is",
| but I have no issues with tapping any of the links. I've
| also used Exante mobile trading terminal for some time and
| had no issues with it either.
|
| Good for you, maybe your phone screen is huge. I routinely
| tap on the wrong element when using HN on mobile. Even on
| desktop I have to set the zoom level to 125%.
| wruza wrote:
| 4.7" iphone. They enlarge tap regions for tappable
| elements since forever, so you can't miss.
| prometheon1 wrote:
| You can miss quite easily if there is another tappable
| element right next to the one you are trying to click
| zo1 wrote:
| This is why I miss resistive screens on phones where you
| had to actually use your fingernail or stylus and it
| bloody worked so well. Instead, everyone wanted to get
| rid of buttons for screen real estate and make phones
| "sexy" and screens should "swipe it up and down Iphone
| mega mega smooth swipe pinch swipe, magic gestures, etc".
| And then that drove an entire industry and it's direction
| for two decades after that, now we're all complaining
| because we let the designers drive functionality and
| usability.
|
| Either way, mobile browsers do allow one to "zoom" in
| into the UI for smaller elements, it's just we're all
| lazy and don't want to do that.
| Bluestein wrote:
| > Iphone mega mega smooth swipe pinch swipe, magic
| gestures, etc"
|
| Ghost of Jobs still haunts ...
| ra1231963 wrote:
| > starting with (now Google-dead) "Material Design"
|
| I thought it was still actively developed. Are you saying this
| has been killed by Google?
|
| https://m3.material.io/
| SushiHippie wrote:
| No Material 3 (Material You) is the design that stock android
| uses for all its UI components, and more and more third party
| apps start using it.
|
| Though I haven't seen Material Design Website in a while.
| whilenot-dev wrote:
| At least the web components are in maintenance mode[0].
| Google seems to focus on a new framework called Wiz now.
|
| [0]: https://github.com/material-components/material-
| web/discussi...
| Bluestein wrote:
| I seem to recall an announcement a while back about it having
| been sunset.-
| pb060 wrote:
| I think it started with Apple when switching from OS 9 to OS X,
| I couldn't explain it at the time and still feel disappointed
| with so much waste of expensive screen estate.
| Bluestein wrote:
| You might very well have a point there.-
| anton96 wrote:
| It's a weird turn of event that OS X stayed a much more
| classic os than what Windows 8 was becoming. I remember that
| for a long time OS X was wasting less screen estate than
| Windows 8 and all that mix that was Windows 10.
|
| But since Big Sure it means that it got even worse than what
| It was with the first version of OS X. I remember how crazy
| it was it setup a mac emulator, set it's resolution to my
| mac's resolution, full screen mode, and see how much space
| you could have with classic Mac OS, it's just crazy and
| everything remains legible.
|
| Suddenly the windows desktop metaphor makes more sense
| because you can actually have many windows next to each
| other. OS X has almost always tried to diverge from than,
| that lead to great things like expose, spaces and then
| mission control but it looks like they never considered to
| reduce elements size.
| 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.
| mhh__ wrote:
| I work have built some dense UI for certain types of fixed income
| (bonds and swaps) trading, looking to move it all to svelte
| because react cannot handle the quantities of data (and if even
| if it could the code is unbelievably ugly).
|
| Something I've been banging on about for a while is the
| following: Programmers and designers keep trying to rebuild
| instagram in every domain, pretty UIs, regular UIs, "simple" UIs.
|
| This is great when every interaction might be an onboarding, but
| can be really limiting and stupid in an environment where people
| are actually paying attention.
|
| A proxy I like to use for the above distinction is whether the
| users are paid more than the programmers
| ChrisMarshallNY wrote:
| I suspect Bloomberg terminals fit that bill.
| mhh__ wrote:
| avg salary of a bloomberg user is lower than some people
| might think because there are a lot of support staff who have
| bloomberg.
|
| As for the UI: I wish more things were like bloomberg, but
| bloomberg itself can be slightly hobbled by wanting to lay
| everything out as a table all the time when a custom chart
| designed by a creative domain-expert would be almost as
| useful.
| defrost wrote:
| There's two clear points to be made:
|
| * Why change to something that's "almost as useful" ..
| that's a downgrade.
|
| * Pretty is often the enemy of Consistent.
|
| On that second point, it doesn't _have_ to be .. _but_ it
| can take a great deal more effort to have data presentation
| that 's both creative _and_ consistent and dense.
|
| The domain goals here are rapid navigation of dense
| infomation across tens of thousands of companies,
| timespans, portfolios, groupings, comparisons, etc. With a
| good interface the user quickly finds the desired scope and
| view and automatically eye tracks to the wanted figures.
|
| It's not an interface for pretty board room presentations
| (although in an organisation that promotes based on merit
| in the ditches most senior staff would be familiar with a
| Bloomberg Board) - it's a daily driver for engine room.
|
| I'm not defending this specific interface, just
| highlighting what is common to many similar domain tools.
| mhh__ wrote:
| > Why change to something that's "almost as useful" ..
| that's a downgrade.
|
| To clarify: There would be two modes, for example, when
| looking at the prices of options you might want to see
| the _shape_ of the smile (e.g. equivalent to the markets
| view of a certain probability distribution), but when
| trading a specific option you want to know everything
| about it down to exact prices.
|
| it's not about pretty-ness, indeed some of these charts
| can be completely incomprehensible, but rather density.
|
| Our UIs should be more than just Excel-but-not-in-Excel!
| throwaway2037 wrote:
| > there are a lot of support staff who have bloomberg.
|
| Much less than people think. It costs about 25K USD per
| year per terminal. There might be _one_ shared terminal in
| a whole middle or back office.
| solardev wrote:
| I'd never heard of those until your post, and had to look up
| a Youtube about what they were:
| https://www.youtube.com/watch?v=2ee-x6IXWK8
|
| That's super fascinating. There's an entire industry that
| runs off these things, on their totally custom UI, showing
| everything from stock tickers to news headlines to maps? That
| must be a fun project to work on (except probably the finance
| users don't like random UI changes, lol).
| pokepim wrote:
| lol this is probably most famous financial tool on the
| market. No wonder we have so many new software tools being
| created daily since some people don't do basic market
| research.
| solardev wrote:
| I work in UI, but never in finance. I don't even own a
| stock (is that even the right word?) and have never
| invested.
|
| Anyway, I wish I got to encounter this system earlier in
| my career... would've loved to experiment with a UI like
| that! News ticker under a real time map that you can use
| to drill down to specific regions to see what's going on?
| It's fascinating.
|
| And it looks like their map is using some sort of
| serverside raster tiling where even simple arrows have to
| be redrawn on different zoom levels... just random things
| I'd be eager to try to improve.
| tionate wrote:
| A bit off topic but it may be worth looking into
| investing a little (maybe basic index ETFs as suggested
| by the FIRE movement).
|
| You can fairly quickly get to a point where your
| investments go up (or down, but more often up) more in a
| day than your monthly income.
| solardev wrote:
| Yeah, at 40, it's probably (way past) time I start
| looking into things like that, lol. But first I have some
| massive debts to pay off first :(
| mhh__ wrote:
| The real reason to have bloomberg, other than data, is
| actually the chat.
|
| OTC (things that don't trade on exchanges) markets are a
| lot closer to ebay or facebook marketplace than many
| realise, for example, e.g. you ask for a price, possibly
| haggle a bit, say you want it, behind-the-scenes people
| scurry off and actually make it happen.
|
| When you first activate your terminal bloomberg send you an
| email congratulating you on joining "the exclusive club"
| (this is exaggerated, they want you to feel special, but
| there's truth to it).
|
| As well as all that bloomberg is technically also still
| (iirc) one of the largest private computer networks.
|
| > That must be a fun project to work on
|
| Unfortunately possibly quite the opposite for many,
| although no first-hand experience.
| solardev wrote:
| > The real reason to have bloomberg, other than data, is
| actually the chat.
|
| Wait, so inside Bloomberg there's like a huge IRC/Discord
| chat room for all the world's finance people? How does
| anyone keep up with that kind of volume? I can't even
| stay on top of my own company's Slack.
| mhh__ wrote:
| No it's more like whatsapp i.e. DM and group chats.
| ChrisMarshallNY wrote:
| I'll lay odds the core language is FORTRAN or COBOL.
| fourthark wrote:
| Famously huge FORTRAN code base going back to the 80's,
| although they were wrapping it in C++ and Javascript when
| I worked there in the aughts.
| funcDropShadow wrote:
| > except probably the finance users don't like random UI
| changes, lol
|
| I have bad news for you, nobody who works with a system
| more than casually, likes random UI changes. NOBODY.
| Younger people are often more tolerant to these
| distractions, because they are often more curious. But when
| you have used a tool for some longer time, and suddenly it
| looks or behaves different, that erodes trust. That forces
| the user to turn of the mental autopilot and to proceed
| with care. Which A/B tests will report as increased
| engagement of the users. And there is our vicious cycle.
|
| Note, how a scheduled update with release notes does the
| opposite. It increases trust, because it tells you what is
| going to happen and then it happens. (Hopefully)
| andrewstuart wrote:
| >> react literally cannot handle the quantities of data
|
| Presented at fact but I'm not sure this is universally correct.
|
| I don't see why the application that is linked here couldn't be
| done in react.
| moomoo11 wrote:
| Yep not true at all lol. I've built extremely complex UIs
| with react with solid performance. Just need to know react
| better, I guess.
| mhh__ wrote:
| Would you say all that useMemo (et al) was a productive use
| of your time? One of the things I like about svelte is that
| it seems to encourage code to be naturally fast rather than
| deal with a load of abstraction leakage (very productive
| abstraction leakage, but still) everywhere
|
| Dan Abramov's favourite UI is apparently spotify, I think
| it shows in the things react seems to be designed for.
|
| I dropped the word "literally" from my original comment as
| I didn't think before I wrote (classic), now I think it's a
| fair comment.
| moomoo11 wrote:
| I was using mobx at the time. It was a very complex app
| UI with lots of data and streams. This was like 4+ years
| ago.
|
| I mean I don't personally care about the semantics that
| much as much as the business results. The commenter said
| react isn't a good choice and that was my disagreement.
|
| And Spotify isn't exactly a "tough" UI compared to
| something data intensive.
| mhh__ wrote:
| The main reason why I want to stop using react is
| actually precisely that I feel massively distracted from
| delivering business value when using it (although still
| better off than without it entirely obviously). JSX is
| quite fantastic for some things but I have found it to be
| fairly annoying when it comes to laying out data that has
| a very clear pattern to it (personally not a huge fan of
| functional style here)
|
| As for spotify, that was also the point I was trying to
| make i.e. React was made so facebook can ~~poison the
| minds of the youth~~ help people share stories, Svelte
| being made by someone who did dataviz for NYT really
| shows.
|
| Should say at this point that despite my love of Svelte
| in principal I still would actually probably build an app
| that used a react-like framework to glue svelte
| components together as I'm not a huge fan of a lot of the
| aspects of svelte that have scope wider than a component.
| moomoo11 wrote:
| I also like svelte. I've not used it for anything serious
| yet though for one reason: lack of libraries.
|
| What you describe is a valid concern. I like keeping it
| more "vanilla" with svelte but any time I run into an
| issue of "Do I spend the next 2 hours building this, or
| just vet and pull in a library?" I'm left with the former
| option.
|
| At this point in my life I'm not that interested in
| spending more time than I have to get something done.
|
| So.. I just use react. No customer cares about 35kb vs
| 8kb or whatever people seem to optimize for. Even
| businesses in a developing country have 50-100mbps
| connection, and honestly most customers (even tech corps)
| don't care about this stuff.
| d13 wrote:
| You can use any vanilla HTML/css/js libraries with
| Svelte, and those far outnumber React's.
| cageface wrote:
| React can handle dense interfaces with a lot of elements
| but you have to be very careful with memoization and it's
| extremely easy to accidentally introduce significant
| performance regressions if something in your memoization
| chain breaks.
| solardev wrote:
| The application linked here is only showing 270 cells at
| once. I think even the slowest framework can handle that...
|
| It's when you get to thousands/tens of thousands of data
| points that things can really slow down without good
| optimizations, especially if you're modifying the DOM or
| manipulating SVGs (as opposed to drawing to Canvas,
| typically).
| funcDropShadow wrote:
| But isn't that exactly the point of such UI libraries? To
| provide those optimizations. Because the easy case, I can
| do myself.
| solardev wrote:
| Yes...? I think maybe there are some threads getting
| mixed up here? There are some sibling/cousin threads
| discussing performance more in depth. My post you replied
| to is just pointing out that 300 cells isn't really
| enough to measure any sort of meaningful performance.
| mhh__ wrote:
| Removed the word "literally" (riffed too enthusiastically
| there) because my point was that's its already a bit slow,
| will only get slower as more things are added, and the code
| is already ugly despite being basically conventional/boring
| react.
|
| The data I'm displaying also is quite deep and results in the
| creation of a lot of DOM elements (i.e. its visual rather
| than tabular). It noticeably chugs a bit even when the actual
| changes to be displayed are relatively small.
| solardev wrote:
| > looking to move it all to svelte because react literally
| cannot handle the quantities of data
|
| I have nothing against Svelte, but how much data are you
| showing on screen, exactly?
|
| Here's an example table with 100,000 cells (100 rows * 1000
| columns per row) that seems fine, from a common React UI kit:
| https://mui.com/x/react-data-grid/virtualization/#column-vir...
|
| It seems fast on my computer normally (M2 Max), slow but usable
| when the CPU is throttled down 4x, and too slow after that. But
| that's a lot of cells.
|
| Here's a performance comparison, btw:
| https://krausest.github.io/js-framework-benchmark/2024/table...
|
| Or filtered down to just Svelte vs some common React libs:
| https://share.cleanshot.com/LlFXtNx9p6y4kMvqXgc7 (lower numbers
| are faster; React is generally just a little slower than
| Svelte, except when it's swapping 2 rows in a big table... then
| it's 8x slower)
| mhh__ wrote:
| Amongst other things, the primary expense is lot of visual
| elements in a very dense chart that ideally would be ticking
| with the market in ~real time and allow more than one on the
| screen.
|
| A lot of it probably should be a canvas but there's a good
| amount of interactivity on the chart itself so moving it all
| over might be expensive.
|
| You obviously can bludgeon that into react but it's at the
| point where the diffing does seem to be non-trivially
| expensive and requires a bunch of nursing in the code which
| is frankly an insane waste of time in 2024.
|
| React is completely fine for big tables, especially if they
| don't actually change very much.
|
| I will also note that in turn this started out as a d3
| project, react was much much faster than d3.
|
| Edit: Completely forgot to mention memory consumption. We
| have beefy machines so it's not really a critical problem but
| think of the poor caches!
| solardev wrote:
| (Not that you're asking for advice, but hope you don't mind
| me sharing some anecdotal experience...)
|
| When we had to do similar things, we found that it was much
| much much faster to take all that sort of stuff out of the
| DOM and put it into Canvas. You can still wrap React around
| it for the UI and controls and data passing and all that,
| but the actual rendering need not involve the VDOM or even
| the real DOM at all. With ChartJS we were able to get it to
| show tens of thousands of individual data points in a time-
| series scatterplot, each datapoint interactive and real-
| time, with no noticeable lag. And it was super easy to
| integrate into our React app. https://www.chartjs.org/
|
| If it's not just charts, here's another canvas-based
| drawing lib:
| https://konvajs.org/docs/sandbox/20000_Nodes.html (and its
| React tie-in: https://konvajs.org/docs/react/Intro.html)
|
| Not trying to discourage you from exploring Svelte if you
| want to, but it might be less work to just use an existing
| optimized drawing lib. Regardless of the JS framework used,
| the DOM is going to be much slower than a Canvas.
| mhh__ wrote:
| > Not that you're asking for advice,
|
| The cunningham's-law-optimal way is to not ask, surely.
| Either that or the some programmers equivalent of the
| "death drive".
|
| > canvas
|
| Indeed, the canvas is basically inevitable, but it's a
| bespoke chart that has both temporal and non-temporal
| data in it (not sure what the terminology should be, but
| imagine plotting market expectations of interest rates in
| future _and_ what expectations were historically
| displayed relative to current levels - but repeated ~200
| times), so the existing chart libraries aren 't
| particularly helpful and can get in the way of being able
| to click on stuff.
|
| Anecdotally I find that programmers are very good at
| writing charts for the kinds of data they understand
| (time series, time series of their stock options, etc),
| but even the "generic" (e.g. grammar of graphics)
| libraries can still struggle with simple combinations of
| those domains.
|
| Obviously you can just treat the charting library as a
| black-box for which you derive coordinate transformations
| and make things appear in the right place but not a great
| bus-factor for that kind of code.
|
| I use https://github.com/leeoniya/uPlot for sparklines
| and so on, very fast.
| solardev wrote:
| > It's a bespoke chart that has both temporal and non-
| temporal data in it
|
| Cool. That sounds like a fun project to work on! If it's
| not super secret stuff, I hope your company will do a
| write-up about it afterward.
| mhh__ wrote:
| I could see it happen as a carrot-and-stick for hiring
| perhaps, let's see.
| cageface wrote:
| React is also considerably slower than svelte in this
| benchmark in selecting, clearing, adding and creating rows
| and also uses a lot more memory.
|
| For a lot of apps React is fast enough but you're definitely
| starting at a non-negligible performance disadvantage
| compared to faster frameworks.
| solardev wrote:
| I don't know that a 15 millisecond difference in rendering
| performance is going to matter to anyone =/ The memory
| usage is in megabytes too. It's not much. For sure React is
| slower on paper, but in most cases it's a non-issue. Nobody
| chooses React for its performance benefits anyway, but
| because of its huge ecosystem of libs and developers. In
| most cases it's fast enough.
| cageface wrote:
| I agree that React is fast enough for a lot of things
| without worrying too much about performance.
|
| I've also worked on several apps where we had to work
| really really hard to get decent performance out of React
| and the resulting code was ugly and brittle.
| LtWorf wrote:
| The fact that it's fast enough on your 2000$ machine
| doesn't really tell us much.
| solardev wrote:
| I was using the numbers from the benchmark, which wasn't
| my machine, and was sometimes throttled down.
| treyd wrote:
| I don't know what GitHub projects uses but we have ~200
| tickets in it and it absolutely _chugs_. Even typing text
| into new entries will regularly hang for multiple seconds
| every few words.
| funcDropShadow wrote:
| > Here's an example table with 100,000 cells ...
|
| > It seems fast on my computer normally (M2 Max), slow but
| usable when the CPU is throttled down 4x, and too slow after
| that. But that's a lot of cells.
|
| No, it is not a lot of cells in a table. It is something a
| Windows95 era PC had no problem doing in something like
| Delphi Builder. And you find it acceptable that it slows
| down, if an M2 Max throttles down? Even a throttled down M2
| Max is supposed to be 1000x (obviously an exageration,
| because I am to lazy to apply Moore's Law more rigorously on
| a Sunday morning) faster than an Intel 486DX. Where did all
| the compute power go? Are we really using the right tools for
| our jobs?
| pfix wrote:
| In general I agree with your sentiment. But here we are in
| a browser environment so we should compare performance to a
| raw HTML table. And then complain if the raw HTML is still
| slower than Delphi on win95 because HTML tables have been
| around since back then :D
| solardev wrote:
| I think all software is a balance of factors, from
| performance to ease of use to DX to maintainability, cost,
| etc.
|
| I don't think most tables need to be as peformant as
| possible, especially when a slow render is still measured
| in sub-seconds.
|
| That level of performance is totally fine for many use
| cases. If you have a special need for large datasets, yes,
| you should pay more attention to how that's optimized.
|
| But for your average bog standard web app, I think any
| framework will be just fine, performance wise, on any 10
| ish year old device. If it's slow, it's more likely because
| of ads, tracking, large media, poor caching, distance from
| a CDN, etc. Especially since React these days is typically
| rendered to HTML during the build anyway and then
| rehydrated for interactivity later.
|
| React isn't a performance optimization to begin with, but a
| DX improvement and architecture abstraction lib (vs vanilla
| or jQuery). It makes some apps much easier to write and
| maintain across generations of low cost developers. The
| performance is a small sacrifice, but it's usually not even
| noticeable.
|
| For performance critical apps, probably you'd just bypass
| the DOM anyway and draw to canvas instead, and offload all
| the heavy processing to wasm.
|
| Yeah, compared to the 90s, our computers and modems are
| much faster and used less efficiently. But there are
| billions more users and millions more developers of various
| skill levels now, and that's just a tradeoff we get for
| mass adoption. It's no longer just a tool for elites, but
| just another tool in the office, and often times a race to
| the bottom like anything else in business (in terms of
| React devs being low cost commodities). A small React team
| can put together a functional app much quicker and cheaper
| than with vanilla, at the cost of some usually negligible
| performance. Probably a good tradeoff for most apps.
|
| If you're talking about web apps in general, compared to
| desktop or CLI apps, then yeah, I agree that it's a bit of
| a shame this is what won the desktop platform wars. At
| least on mobile we have native apps (which often feel much
| faster than anything web based), so there's that at least.
| rtpg wrote:
| > It is something a Windows95 era PC had no problem doing
| in something like Delphi Builder.
|
| I would recommend you actually try this, because it's not
| as true as you would like to believe.
|
| I am very much pro-"make things fast" but let's not pretend
| that old machines didn't randomly hiccup on things all the
| time as well.
| stoperaticless wrote:
| Well. If it was bearable then, with 2x powerful pc, it
| should be much better.
| anonymoushn wrote:
| It's defective because the browser's find feature does not
| work.
| solardev wrote:
| Good catch! I didn't realize that about this lib. It has
| some consideration for what it calls "overscanning", but
| that only extends a little bit past the current view.
| doctorpangloss wrote:
| > Programmers and designers keep trying to rebuild instagram in
| every domain, pretty UIs, regular UIs, "simple" UIs.
|
| Well, Instagram is basically the only application people use,
| along with e-mail, YouTube and TikTok. Some people use Spotify,
| and fortunately no one is trying to copy its design, so I feel
| like the programmers and designers are onto something.
| funcDropShadow wrote:
| > Well, Instagram is basically the only application people
| use, along with e-mail, YouTube and TikTok
|
| No, those people are not using email, they are using what
| Google tells them what email is. A poor imitation of email.
| The_Colonel wrote:
| * basically the only people from your bubble use
| steve_taylor wrote:
| I love Svelte and agree with you about performance, but its
| built-in CSS management has some showstopper bugs that are more
| likely to become apparent the bigger your app gets. If you use
| :global to target elements in child components (which is
| inevitable), you'll run into specificity issues caused by
| Svelte not removing CSS after components stop rendering.
| Apparently it's "by design", i.e. it's too hard for the Svelte
| maintainers to figure out and/or cleaning up would hurt them in
| benchmarks.
|
| I guess it's OK if you use something else for CSS such as
| Tailwind.
| candu wrote:
| It's always worth thinking about who the audience / userbase of
| your UI is, and whether they'd benefit from an expert user
| interface [1] or not.
|
| Sometimes, they would (e.g. the "users paid more than the
| programmers" rule of thumb, but also: various technical
| disciplines, most anything used for professional-grade work).
| Sometimes, they wouldn't - or perhaps some would and some
| wouldn't (so perhaps you're looking for a simple base UI with
| some accelerators [2]).
|
| IMHO the issue is that many products fall into this last camp -
| where a well-designed simple UI is called for, but _also_
| accelerators could greatly help a small but important subset of
| power users - but we treat the power users as though they don
| 't exist.
|
| [1] https://www.nngroup.com/articles/testing-expert-users/ [2]
| https://www.nngroup.com/articles/ui-accelerators/
| art0rz wrote:
| At $dayjob I work on a very dense UI for a financial
| institution. Think Bloomberg terminal in React and RTK. It's
| extremely customizable and had lots of elements updating
| multiple times per second (charts, graphs, enormous tables,
| etc.) with realtime data coming through over a websocket. We do
| very little actual performance tuning and mostly just follow
| best practices.
|
| I don't think React is to blame for your performance issues.
| korm wrote:
| If seeing how common `eslint-disable-next-line react-
| hooks/exhaustive-deps` is any indication, people just don't
| bother with best practices. Not to mention the majority of
| people I interview or hire don't know anything about CSS
| performance, they learn on the job. They'll happily add 1000
| box shadows in a view if it's in the design.
|
| Also OP is looking to move an existing React UI to Svelte,
| why not try Preact first instead of an entire rewrite? Or
| even Inferno or million.dev? If they did and they're
| insufficient, I don't even believe the browser's DOM is the
| right technology for that UI then.
| dhruvrajvanshi wrote:
| Instead of a rewrite, why not try using AgGrid? It's a pure JS
| grid library that's really fast and it's got react bindings.
|
| It's even got a batch update API.
|
| I doubt that naively rewriting the app in Svelte is gonna give
| you the perf boost you're looking for.
| devjab wrote:
| I'm not going to discourage your move to svelte, but we do
| solar data from over a thousand plants and over a million
| inverter datapoints supplying literal fuckton of data every
| minute. We combine this with financial data from over 20
| countries and budgeting from so many companies we've had to buy
| so many BC365 instances it's ridiculous that we even use BC365.
| We present all of it, along with hundreds of tools in a react
| frontend. It has various backend services, from external to
| internal in c++, C#, Go, Typescript and Python
|
| We don't have performance issues with react. I'm not sure I'd
| really recommend react as such, with the way the ecosystem is
| leaning more and more into Next, but I doubt that its react
| itself which is giving you performance issues. I think you
| should look into how you're loading and unloading data.
| mst wrote:
| May also be worth a look at Solid and things the same author
| has built on his dom-expressions library (I've been thinking
| about using his mobx-jsx for example) - a more React-ish
| experience but with a compilation strategy that seems to've
| been written with a similar aesthetic and set of trade-offs in
| mind to Svelte.
|
| (Svelte is awesome, mind, I compare the two to compliment them
| both)
| andrewstuart wrote:
| Here you go I hacked the page into React so you can see
| performance.
|
| https://static.crowdwave.link/index.html
|
| And the source: https://static.crowdwave.link/sveltetest.zip
| ChrisMarshallNY wrote:
| I'm in the final release phase of an app that I have developed
| over the last month, but it builds on a test app that I wrote, a
| couple of months ago, and that had multiple screens, showing
| tabular data, in various forms (and ways to sort and filter said
| data). Fairly similar process to this, but on a more humble
| scale.
|
| I tested for a while, settled on one form, and made an app for
| that.
|
| It's not the most exciting variant, but it seems to work very
| well, and the reception in the public beta has been quite
| positive (one problem is that it's not an app that I would use,
| personally, so I had to rely a lot on the feedback of others).
| ChrisMarshallNY wrote:
| Just to expand, I have found that the best UI, is the UI that
| no one notices, appreciates, or compliments.
|
| Bit humbling, but there you have it.
|
| Case in point: I have a fancy "prize wheel spinner" for UIKit,
| that I wrote, a few years ago[0]. I started working on a
| SwiftUI version of it, but stopped.
|
| The reason was, because I kept _not_ using it, in my shipping
| projects. It's too "in your face."
|
| Some of the UI approaches that I tried, in my test app, were
| "sexy," but I didn't use any of them. The one I ended up using,
| was a bit pedestrian.
|
| [0] https://github.com/RiftValleySoftware/RVS_Spinner
| MOARDONGZPLZ wrote:
| This is slick. Does anyone have recommendations for high density
| real world maps with tracks like FlightRadar or similar do?
| FpUser wrote:
| Love it
| electroly wrote:
| One thing I especially like about developing data-heavy financial
| apps in Windows Forms is the DataGridView control. High density
| and high performance with filtering, sorting, and drag-and-drop
| column reordering and resizing. No paging required; if you want
| to stick 10,000 rows in there, that's fine. Most of the UIs we
| write are screens full of DataGridView panes. Ugly? Yes. Fast?
| Also yes.
|
| My attempts to write similar UIs in React have mostly been
| failures due to poor performance. I resorted to bypassing React
| entirely for data tables in order to get acceptable render
| performance. Even then, I have to minimize the number of DOM
| elements per row so that the browser rendering itself isn't
| unacceptably slow.
| mystified5016 wrote:
| WinForms is still probably my favorite UI framework. It's
| absolutely a blunt tool but by god can you swing it around.
| Incredibly flexible, reasonably easy to use, pretty fast, and
| ugly as all hell.
|
| Hell, you can even throw arbitrary Objects at it and it will
| just work. You can nest PropertyGrids within PropertyGrids,
| extend them to collections of objects, build arbitrarily deep
| nests of controls. All without touching or even caring about
| the underlying structure of the objects your UI connects to
| (within limits).
|
| WinForms is my platonic ideal of a UI framework. It's exactly
| how I would design things.
| squarefoot wrote:
| Well done. Tables are very dense, still easy to read. Proof that
| information hidden behind empty screens with tons of blank space
| has never been the way to go.
| chrisstanchak wrote:
| Love this. Amazing work.
| tengbretson wrote:
| The mini-map/scrub view in the table seems to suspend the drag
| motion if you target outside that vertical element with the
| mouse. Intuitively I would assume it would just let you drag
| until mouse release.
| felipefar wrote:
| Low UI density is the new emperor's clothes in modern UI design.
| It's being actively promoted by companies in order to cut design
| costs, but the truth is that it's only reasonable on touch
| interfaces or casual apps.
|
| Mouse interfaces are fundamentally different, because you have
| much more pointing precision, so it pays off to show more data on
| the screen. You don't have to cram your interface with with
| spaces to make it scan-friendly, you just use heterogeneous
| elements and colors. Look at Blender and you'll know it can be
| done.
|
| I'm designing a desktop reference manager
| (https://getcahier.com), and one of its aims is to provide a UI
| with high information density. The mobile version will be able to
| adjust the experience, replacing desktop-only interaction
| patterns with mobile ones, and the UI elements that are shared
| will be somewhat bigger, so that users are able to interact them
| with touch.
|
| Apart from that, it seems that the whole industry is confused
| regarding UI styles. UI frameworks are either favoring touch
| interfaces and degrading the experience on desktop, or vice-
| versa. Even Windows 10 released certain parts of the control
| panel with desktop look and feel and others with touch-friendly
| but desktop-antagonistic screens. It's time we realize that both
| platforms are different and we shouldn't degrade one in favor of
| the other.
| cageface wrote:
| This is because mobile is where all the money is. All the
| vendors have neglected their desktop SDKs to such a degree that
| Flutter is now in many ways the best desktop UI stack.
|
| Even Apple has sorely neglected their desktop APIs. Play around
| with SwiftUI on the Mac for more than a few hours and this will
| become glaringly apparent.
| asoneth wrote:
| > It's being actively promoted by companies in order to cut
| design costs
|
| I'm curious why you think it reduces design costs to put less
| information on the screen? My experience has been the reverse
| -- the companies that chase trends (including but not limited
| to low-information-density screens and using mobile-first
| designs for desktop applications) also tend to spend more money
| on UI design compared to other companies.
| funcDropShadow wrote:
| > I'm curious why you think it reduces design costs to put
| less information on the screen?
|
| The question is for whom it saves costs? For the developers
| of UI framework it certainly saves cost to treat the desktop
| as a second rate platform and to focus just on mobile.
|
| Developers of desktop applications have to pay the price, by
| working around libraries and frameworks that do not consider
| them as a first tier clients.
| sulandor wrote:
| maybe oversimplified:
|
| things on screen take effort. less things, less effort
| dagw wrote:
| Deciding what not to put on the screen takes at least as
| much effort as adding things to the screen.
| stoperaticless wrote:
| I sense that you have in mind something like
|
| > Perfection is achieved, not when there is nothing more
| to add, but when there is nothing left to take away.
|
| That is the right reaction to over-complicated baroque
| creations.
|
| Important to note, that oversimplification is possible.
| (There is point at which removal is no longer benefitial)
| sulandor wrote:
| rhetorical relation but i agree that minimalism is a
| worthy goal.
|
| though, excessive white-space does not really scratch the
| "efficient interface" itch
| elschneider wrote:
| I think there is a fundamental difference depending on what
| kinds of users you are targeting and how often they're using
| your app. Blender is a prime example of software for
| professionals, that are also willing the spend a considerable
| amount of time on learning the UI. A lot of software is not
| targeting a similar audience and should limit cognitive
| overload.
| panta wrote:
| I'm constantly frustrated by software that tries to limit
| cognitive overload. Stop treating your users as if they were
| cognitively impaired. In other words, write a software that
| also an idiot can use, and only idiots will want to use it.
| hk__2 wrote:
| > I'm constantly frustrated by software that tries to limit
| cognitive overload. Stop treating your users as if they
| were cognitively impaired. In other words, write a software
| that also an idiot can use, and only idiots will want to
| use it.
|
| I disagree. I've been using IntelliJ for a few years now,
| and the new, simplified interface has made my experience a
| lot better. IMHO you should limit the cognitive overload
| but enable power users to increase it. See also Wikipedia,
| where the main editor is basic but if needed you can switch
| to the code editor and/or add plugins to make the interface
| a lot more powerful.
| KronisLV wrote:
| > I disagree. I've been using IntelliJ for a few years
| now, and the new, simplified interface has made my
| experience a lot better.
|
| I work on a bunch of enterprise projects and therefore am
| sticking with the old design, because having more
| features available at a glance while also fitting as much
| of the code on screen as possible is definitely nice to
| have, in addition to my already established habits and
| knowledge of the UI.
|
| But the new UI? It's also really sleek and pleasant, and
| a joy to use in the cases where I've toggled over to it.
| Plus, the fact that they worked on adding a compact mode
| to the new UI is also great to see! Definitely a good
| experience in my eyes.
|
| I think the trick is in giving the user the choice on
| what to use, if there's no horrible incompatibility
| between the various iterations of something. For example,
| the day when the old Reddit UI (old.reddit.com) stops
| working is also the day when a bunch of people will stop
| hanging around the place. The problem is that companies
| often find the additional support needed to be a hassle
| and just optimize for the majority of users, not all of
| them - much the same how many games out there don't even
| have a Linux or Mac release, even in cases where the
| popular game engines make having one pretty easy!
|
| The parent comment above yours is perhaps a bit more mean
| than it should be, though.
| zo1 wrote:
| I literally have the opposite experience as a dev. The
| new interface is horrible, and it's not just the layout.
| They subtly somehow changed the borders and their color.
| I now officially can't delineate and know which part of
| the UI is for what.
|
| I had to fiddle with color schemes, add-ons for updated
| icon colors, etc. It's a mess.
|
| And even if it's about reducing cognitive overload. The
| old interface had plenty of "features" and
| "configuration" to reduce the cognitive load as much as
| you wanted with both presentation mode and the ability to
| change the UI however you wanted.
|
| My cynical take is that we just had two giant camps
| promoting this. One was the designers that wanted to have
| something to do. And the other camp was the VSCode
| pushers that just couldn't stand that a glorified (and
| order of magnitude inferior) text-editor is maintaining
| user-counts.
| Ygg2 wrote:
| I'm calling bullshit on this one. In more ways than one.
|
| 1. Stuff that benefits imparied users benefits others.
| Subtitles help both. You'll never operate always at peak
| capacity either.
|
| 2. You can design UI to be layered. Easy mode for beginners
| and more advanced options for advanced users.
|
| 3. Software that's easy to use sees bigger audience.
| Period.
| llm_trw wrote:
| A bigger audience isn't a better audience.
|
| A violin solo in a football stadium with the usual
| football audience is not an improvement over one in a
| recital room with the usual audience.
| juliushuijnk wrote:
| Depends on your goals
| jorvi wrote:
| I have had the (dis)pleasure of watching my 60yr old mother
| having to re-learn the entire administrative part of her
| healthcare job three times over and deeply struggle because
| the insurance suits decided a new software package was
| needed.
|
| Nothing humbles you more as a dev than seeing a layman
| struggle through an interface, getting increasingly
| frustrated and desperate because she can't find the button
| she needs due to complexity and sensory overload due to a
| million tabs, buttons and text fields.
|
| The worst of it is, you can see that she knows what she
| wants to do, but can't translate that into the steps needed
| to get the computer to "understand" that, effectively
| making it feel as if it is trying to sabotage her.
| Something that would have taken 20 minutes with pen & paper
| suddenly takes 40 minutes digitally. Weren't computers
| supposed to make us _more_ efficient?
|
| Considerately, screw your attitude. Eat some humble pie.
| SanderNL wrote:
| This anti-learning attitude is common, but I don't find
| it admirable.
|
| To me this is like a dev saying "screw Git, I just want
| to do console.log(). All this complexity is sabotaging my
| productivity."
|
| Modern jobs, even health care, require learning about and
| managing complexity. It's not just "taking care of
| people". Throwing your hands up and saying "I'm old",
| which is a lousy excuse because I know plenty able old
| people and completely digitally illiterate young people,
| is not a viable solution.
|
| Now, whether we want that as a society is another topic.
| But for the foreseeable future adapting to complexity and
| actually taking the time to sit down and learn this shit
| is IMO the only way forwards.
| wakeupcall wrote:
| This is not anti-learning. This would be akin to git
| changing command names and flags doing exactly the same
| stuff. After a couple of times happening, even if the
| changes are somewhat ok, you too would start to be
| frustrated.
|
| I've seen healthcare management software evolution due to
| my partner working with it. As in the worst management
| story, it's pitched to a boss that doesn't need or want
| to use it, offered to generally the lowest bidder, and
| then immediately outsourced in parts that rarely work
| well together taking years to develop.
|
| The UI and workflows are designed by people that will
| never use it and are just plainly bad. The software/UI
| takes years to stabilize and reach feature parity to the
| same level it was before. During that time, it's pretty
| common to see staff having to use both systems and
| perform double data entry.
|
| You're not learning to improve anything here. You're
| substituting a [shitty] tool with another one which does
| _exactly_ the same.
|
| Sadly in IT this is pretty common. There's nothing
| special about healthcare.
| treyd wrote:
| Both of your and the parent's points are true at the same
| time.
| petre wrote:
| They're the ones asking for it. Release an application with
| dense UI today and the clients will quickly dismiss it
| because the market wants to do things as easily as possible
| with a few clicks - instant gratification. They want a
| language - computer interface, like Google's Assistant, but
| one that works. This is why everybody pushes AI features:
| the promise of Clippy doing the work for you.
| LtWorf wrote:
| That usually just results in an excessive amount of clicks to
| get anything done.
| zozbot234 wrote:
| Touch interfaces have less pointing precision, but _more_
| swiping precision compared to mouse interfaces. The optimal
| touch interface probably involves lots of pie menus and /or
| drag-and-drop gestures that ought to easily compensate for the
| somewhat increased size of initial touch targets. (Note that,
| by contrast, these gestures tend to be quite awkward when using
| mouse or touchpad input.)
| LtWorf wrote:
| Ah, the always easy to discover (only in the mind of the
| designer) gestures.
|
| Let's not forget that with the current gigantic size of
| phones, I can actually easily reach less than 50% of the
| screen. The top part is completely out of reach.
| mst wrote:
| Because I tend to hold it with my left hand and tap with my
| right, I've deliberately moved icons around until my most
| commonly launched apps are as close to the bottom right
| corner as possible.
|
| I've actually stopped using the 'switch between running
| apps' UI almost entirely now because with that done, it's
| faster for me to tap to the home screen then on the icon of
| the app I want to switch to.
| nsonha wrote:
| gestures are the time wasting way of doing a click
| Eudaimion wrote:
| Is Cahier built on top of Zotero? It looks very similar.
|
| Good notetaking support is something Zotero lacks, so I see the
| appeal for an alternative that focuses more on it.
| felipefar wrote:
| Cahier is built from scratch with native tech. Besides more
| comprehensive notetaking support, I also want to provide
| support for synchronization with existing cloud providers
| (Dropbox, iCloud, etc.).
| jwr wrote:
| > Low UI density is the new emperor's clothes in modern UI
| design
|
| I design, develop and maintain an ERP-style application with
| lots of tables. The fashions in UI design have made my life
| much more difficult over the last decade.
|
| The problem is that designers tend to follow fashion trends.
| And the trend over the last decade has been "lightweight!
| clean! lots of space!". This is great if you are making a
| landing page, not so great if you need to display lots of data.
|
| Google made things worse with its terrible UI design, which
| people accepted as mantra. Yes, there is lots of white. Your
| screen will mostly display... space. But just try using the
| Google Ads interface: it doesn't even fit in a normal browser,
| you need to have an extra-wide window just to see stuff in the
| tables. Not to mention they keep redesigning it, and every new
| update is hated by the customers, as well as by Google people
| (I've been told by Google ads consultants how to switch to the
| older interface, "which they all use because the new one is
| worse").
|
| Another problem which compounds the situation for me is that
| designing tables is not cool. So, UI designers (and self-
| proclaimed UX experts) will "obsess" over every pixel in iOS-
| style switches that for some reason have replaced checkboxes,
| writing blog posts about how things are misaligned, while
| tables are left as an afterthought. Take a look at all modern
| UI toolkits: you will find very few with good tables, and
| likely not a single one with dense tables.
|
| Oh, and on the functionality front: JavaScript libraries like
| DataTables are great for simple things, but are nowhere near a
| complete solution for complex apps.
| danielvaughn wrote:
| I should add that I think Tailwind, much as I love it, has been
| responsible for much of this problem. Tailwind's creator, Adam
| Wathan, wrote a book called Refactoring UI. It's a book that
| teaches you how to design, and one of the things it explicitly
| states is that you should add generous spacing around elements.
|
| If you look at Tailwind UI, which is clearly governed by the
| principles laid out in Refactoring UI, you can pretty much see
| the blueprint behind 95% of websites today.
| shit_game wrote:
| > Mouse interfaces are fundamentally different, because you
| have much more pointing precision, so it pays off to show more
| data on the screen. You don't have to cram your interface with
| with spaces to make it scan-friendly, you just use
| heterogeneous elements and colors.
|
| Another massive consideration is that a mouse (and a keyboard,
| if you want to expand from UI to UX) pairs that precision with
| significantly more available control actions - LMB, RMB, MMB,
| scrolling, and hovering.
|
| With a mouse, the edges and corners of the screen are the
| easiest and most reliable areas to interact with; this is the
| inverse of touchscreen UIs, in which the center of the screen
| is the most ergonomic area of the screen to use, and edges and
| corners are practically unusable, leading to large margins in
| almost every UI targeting them.
|
| With controls like LMB/RMB, you can also have functionality
| _immediately_ available wherever the pointer is located, which
| is now quintessential for practically all desktop applications,
| and which can't be faithfully emulated with touchscreen UIs.
| hliyan wrote:
| One thing we may still haven't realised is that UI designs are
| subject to fashion cycles, just like clothing. Except enough time
| hasn't elapsed for us to observe a full cycle similar to peak-
| bell-bottoms or peak-low-riders or peak-sideburns. We may be in a
| low-contrast / low-density peak, but we won't know until we pass
| it. However, looking back, we did seem to have passed at least
| one peak-skeuomorphic cycle (remember all the toolbars, icons,
| drawers and Microsoft Bob?). We may see another high contrast
| monochrome text-heavy cycle yet.
| tgtweak wrote:
| This is surprisingly fast. A really impressive showcase of the
| design philosophy of Svelte. Even loads and renders fast on
| mobile!
|
| DOM Loaded: 134ms
|
| FCP/FP: 163ms
|
| LCP: 218ms
|
| TTI: 1826ms
| rkagerer wrote:
| It's a thing of beauty
| bowsamic wrote:
| You could make it far far denser than this
| pavlov wrote:
| In my opinion this experiment is missing a key element of
| designing for UI density: typography.
|
| These screens use a fixed-width font at a single size. It's a
| retro 1980 text-mode UI look, and it's fine if that was the
| design constraint they wanted.
|
| But you can squeeze a lot more information on screen if you can
| have a proper hierarchy of typefaces and sizes.
|
| (As a basic example, the "About" box now consumes almost a
| quarter of the screen on a phone. A change to a smaller
| proportional font could fit this information in half the space
| and still remain readable on a phone.)
|
| If you look at the works of an accomplished information designer
| like Edward Tufte, he often obsesses about getting the typography
| right. His books use many typographic elements and scales even
| for the body text, outside of the visualizations.
| cranberryturkey wrote:
| svelte 4 is handsdown the best framework out there. I really am
| disappointed svelte5 is turning into react-ish framework. That
| was the main reason I used svelte was because it was NOT react.
| jbrimble wrote:
| Is there a code repo for this site? I can't seem to see one, and
| I'm curious to see the svelte source.
| gorgoiler wrote:
| I absolutely love it, very intelligently put together. The gold
| standard for this in the terminal is btop. Check it out if you're
| into this sort of thing:
|
| Example: https://terminalroot.com.br/assets/img/cpp/btop.png
|
| Repo: https://github.com/aristocratos/btop
| squigz wrote:
| I prefer atop, personally. https://www.atoptool.nl/
| andrewstuart wrote:
| https://static.crowdwave.link/index.html
|
| Above is the evidence that react can handle this sort of thing
| just fine.
|
| I hacked/converted the page in question to React to show
| something similar.
|
| Its randomly generating updates to the table and then resorting
| the table and repeating.
|
| You can grab the source here but I warn you it's hacked together
| in less than an hour:
|
| https://static.crowdwave.link/sveltetest.zip
| perdomon wrote:
| I've heard that the DX with Svelte is among the best out of all
| web libraries/frameworks. Curious how it went creating this UI.
| PaulHoule wrote:
| That Helix reminded me of this old game
|
| https://en.wikipedia.org/wiki/Tempest_(video_game)
|
| except it really is a helix and not a cylinder like a Tempest
| level. Still would be fun to fight bugs in.
___________________________________________________________________
(page generated 2024-07-28 23:10 UTC)