Live data from Hacker News

An experiment in UI density created with Svelte

cybernetic.dev

111–120 of 267 posts

Re: An experiment in UI density created with Svelte

#111
post #81
post #69

Earlier quoted context omitted.

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 spaci…

>1. This is not true. Mobile platforms do help with tapping on small elements. E.g. HN isn't mobile friendly "as is", but I have no issues with tapping any of the links. I've also used Exante mobile trading terminal for some time and had no issues with it either. I agree that accessibility still is the concern, but watching my grandma struggle with her tablet, it's mostly the fact that buttons aren't buttons and ever…

> I bet she'd have similar issues with appliances if their design was just random flat symbols on white surfaces that randomly disappear.

That sounds like the control panel for my fridge :)

Re: An experiment in UI density created with Svelte

#112
post #100

Earlier quoted context omitted.

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 doe…

(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. Wi…

> Not that you're asking for advice,

The cunningham's-law-optimal way is to not ask, surely. Either that or the some programmers equivalent of the "death drive".

> canvas

Indeed, the canvas is basically inevitable, but it's a bespoke chart that has both temporal and non-temporal data in it (not sure what the terminology should be, but imagine plotting market expectations of interest rates in future and what expectations were historically displayed relative to current levels - but repeated ~200 times), so the existing chart libraries aren't particularly helpful and can get in the way of being able to click on stuff.

Anecdotally I find that programmers are very good at writing charts for the kinds of data they understand (time series, time series of their stock options, etc), but even the "generic" (e.g. grammar of graphics) libraries can still struggle with simple combinations of those domains.

Obviously you can just treat the charting library as a black-box for which you derive coordinate transformations and make things appear in the right place but not a great bus-factor for that kind of code.

I use https://github.com/leeoniya/uPlot for sparklines and so on, very fast.

Re: An experiment in UI density created with Svelte

#113
post #112

Earlier quoted context omitted.

(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. Wi…

> Not that you're asking for advice, The cunningham's-law-optimal way is to not ask, surely. Either that or the some programmers equivalent of the "death drive". > canvas Indeed, the canvas is basically inevitable, but it's a bespoke chart that has both temporal and non-temporal data in it (not sure what the terminology should be, but imagine plotting market expectations of interest rates in future and what expectati…

> It's a bespoke chart that has both temporal and non-temporal data in it

Cool. That sounds like a fun project to work on! If it's not super secret stuff, I hope your company will do a write-up about it afterward.

Re: An experiment in UI density created with Svelte

#114

Earlier quoted context omitted.

I suspect Bloomberg terminals fit that bill.

I'd never heard of those until your post, and had to look up a Youtube about what they were: https://www.youtube.com/watch?v=2ee-x6IXWK8 That's super fascinating. There's an entire industry that runs off these things, on their totally custom UI, showing everything from stock tickers to news headlines to maps? That must be a fun project to work on (except probably the finance users don't like random UI changes, lol).

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.

Re: An experiment in UI density created with Svelte

#115

Earlier quoted context omitted.

I suspect Bloomberg terminals fit that bill.

I'd never heard of those until your post, and had to look up a Youtube about what they were: https://www.youtube.com/watch?v=2ee-x6IXWK8 That's super fascinating. There's an entire industry that runs off these things, on their totally custom UI, showing everything from stock tickers to news headlines to maps? That must be a fun project to work on (except probably the finance users don't like random UI changes, lol).

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.

Re: An experiment in UI density created with Svelte

#116
post #99

Earlier quoted context omitted.

I suspect Bloomberg terminals fit that bill.

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.

There's two clear points to be made:

* Why change to something that's "almost as useful" .. that's a downgrade.

* Pretty is often the enemy of Consistent.

On that second point, it doesn't have to be .. but it can take a great deal more effort to have data presentation that's both creative and consistent and dense.

The domain goals here are rapid navigation of dense infomation across tens of thousands of companies, timespans, portfolios, groupings, comparisons, etc. With a good interface the user quickly finds the desired scope and view and automatically eye tracks to the wanted figures.

It's not an interface for pretty board room presentations (although in an organisation that promotes based on merit in the ditches most senior staff would be familiar with a Bloomberg Board) - it's a daily driver for engine room.

I'm not defending this specific interface, just highlighting what is common to many similar domain tools.

Re: An experiment in UI density created with Svelte

#117
post #99

Earlier quoted context omitted.

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.

There's two clear points to be made: * Why change to something that's "almost as useful" .. that's a downgrade. * Pretty is often the enemy of Consistent. On that second point, it doesn't have to be .. but it can take a great deal more effort to have data presentation that's both creative and consistent and dense. The domain goals here are rapid navigation of dense infomation across tens of thousands of companies, ti…

> 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!

Re: An experiment in UI density created with Svelte

#118
post #112

Earlier quoted context omitted.

> Not that you're asking for advice, The cunningham's-law-optimal way is to not ask, surely. Either that or the some programmers equivalent of the "death drive". > canvas Indeed, the canvas is basically inevitable, but it's a bespoke chart that has both temporal and non-temporal data in it (not sure what the terminology should be, but imagine plotting market expectations of interest rates in future and what expectati…

> It's a bespoke chart that has both temporal and non-temporal data in it Cool. That sounds like a fun project to work on! If it's not super secret stuff, I hope your company will do a write-up about it afterward.

I could see it happen as a carrot-and-stick for hiring perhaps, let's see.

Re: An experiment in UI density created with Svelte

#119

Earlier quoted context omitted.

I'd never heard of those until your post, and had to look up a Youtube about what they were: https://www.youtube.com/watch?v=2ee-x6IXWK8 That's super fascinating. There's an entire industry that runs off these things, on their totally custom UI, showing everything from stock tickers to news headlines to maps? That must be a fun project to work on (except probably the finance users don't like random UI changes, lol).

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.

Re: An experiment in UI density created with Svelte

#120

Earlier quoted context omitted.

>> react literally cannot handle the quantities of data Presented at fact but I’m not sure this is universally correct. I don’t see why the application that is linked here couldn’t be done in react.

Yep not true at all lol. I’ve built extremely complex UIs with react with solid performance. Just need to know react better, I guess.

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.
Post reply on HN