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?
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.
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.
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.
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.
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.
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.
> 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?
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.
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.
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
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.
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.
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?)?
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.
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+)?
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.
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
266 comments
[ 2.8 ms ] story [ 265 ms ] threadIf this is an experiment, what were your conclusions?
Is the focus on density around performance, visualization, or something else?
It definitely feels very influenced by 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.
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?
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
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
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
Excuse me what?
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.
Similar approach (custom virtual processor) is leveraged by Google docs/sheets.
Canvas rendering may be the last resort when nothing worked.
> 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/2c46cf10d6773e690cb...
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.
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.
Also beautiful and polished as a piece of design, apart from the dataviz.
Seems like there's way more huge phones (especially folding ones) than small ones these days.
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.
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)
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.
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.
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?
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?
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.
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.
That's why we like btop and htop, but a normal PC user wouldn't understand anything.
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.
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.
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.
Good luck with tuning your PS a bit. It should pay off somehow, me thinks.
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?)?
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.
The layout works remarkably well on mobile regardless, but 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.
None of them exhibit the wonky behavior of zooming a web page described above.