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.
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.
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.
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.
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.
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?
It's for procedural effects and simulation, yeah. Stuff like fluid and gas simulation, interactions between them, surface deformation from stuff like footprints or tire treads or whatever. In those areas Houdini can't be beat.
> I’m assuming for ‘regular’ 3D modelling people still prefer other software like blender/max right?
It depends. I'm not sure if Houdini has modeling stuff, it's been a while since I used it. Houdini is only one element of a complete workflow, that's why it has so many importers and exporters.
I've also been experimenting with mac app development for interfacing with Jira and other work that's ongoing but async. Less so on the data viewing side, and moreso on having agency over what I'm alerted to and when, but your comment and this UI has inspired me to try other ideas, since I kind of got stuck on a main data view
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?
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.
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.
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.
> 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%.
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.
I'm not vision impaired (I actually have very good vision), and I also zoom HN way in (150%) on desktop. Just feels uncomfortably small and the lines of text are way too long.
If you have 3 tap regions already adjacent before enlargement, how does enlarging them help? Like the w, a and s keys on a keyboard. Making the regions larger will just make them overlap.
Idk how apple does that exactly. I’d just voronoi it if they intersect and tap outside-ish, just like I do with hn vote arrows.
Anyway my point is that you can design interfaces denser than three buttons per screen and they will work. Not that a 5mm block with 8 links in it is a good button bar.
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.
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.
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 exposé, spaces and then mission control but it looks like they never considered to reduce elements size.
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.
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.
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.
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)
> 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.
> 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?
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.
Font too small? Just ctrl +. Raw data with huge padding is inaccessible to literally everyone who's trying to do work (the intelligence framing of the other user was stupid) and it's meant to look pretty, not be accessible. If you're genuinely concerned about accessibility, the computing world is a never ending world of inaccessibility, but this ain't it.
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.
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.
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.
> 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?
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.
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.
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.
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.
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:
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.
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:
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.
Of course React can handle complex and large scenarios. And those scenarios aren't even large. It's good that you created that proof. Still, Svelte is much easier while more performant, even if that extra performance is most often not needed. Large amounts of data can be managed by react-virtualized in React. IME Svelte (and Vue) can handle more without virtualization, but for really large data sets you need it anyway. The downsides of React are not performance IMO, but DX.
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.
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.
“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.
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.
I beg to differ. The most useful kind of zoom zooms the entire UI and this is straightforward to do on Windows and ChromeOS in increments of 25%. It is possible in Gnome, too, (again in increements of 25%, at Settings > Displays > Scale), but it is not straightforward because before you can do it, you have to say, `gsettings set org.gnome.mutter experimental-features "['scale-monitor-framebuffer']"` once per install of the OS.
None of them exhibit the wonky behavior of zooming a web page described above.
Yes, an iPhone. As an occasional writer of CSS, I assume the behaviour is the result of using font-size as the basis for sizing elements. As the font-size increases due to various media breakpoints triggering, so too do the elements on the page.
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).
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.
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.
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.
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
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
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?
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.
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).
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.
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+)?
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.
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.
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.
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.
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
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.
Svelte 5 has change its reactivity model to signals. I anything, it's became similar to SolidJS. All other changes are minor but make Svelte even simpler to use.
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.
> 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.
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.
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.
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 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.
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.
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.
> 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.
> 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.
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.
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.
> 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.
> 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.
I've been a designer for a long time, and none of my contracts have ever paid based on the number of things I put on the screen. The design effort required to make a grid or list of data dense or sparse is pretty much identical.
(At least in enterprise software the data density typically depends on who makes the purchasing decisions. If novices and/or business folks are the ones making the pick then the software will look sparse. If technical and/or experts pick their own tools then it'll be dense and efficient.)
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.)
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.
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.
> 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.
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.).
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.
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
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)
> 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?
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
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.
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.
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.
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.
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.
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!
(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/
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.
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’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.
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.
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.
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.
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.
> 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.
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).
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.
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.
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.
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.
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.
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.
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.
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).
> 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)
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.
> 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.
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.
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.
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.
* 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.
> 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!
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)
More information, yes, not density. Same for pagination. Information density = amount of information you can gather at once within a space, before any interaction.
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.
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.
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.
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?)?
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.
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.
> 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.
> 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.
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.
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.