I have the highest regard for these terse, but information-dense displays that enable humans to quickly grasp all information they need to do their jobs, and nothing more. This is also something avionics provide - a modern cockpit displays are a work of art in layering needed information for what is happening at the time, both the dense PFD and the much specific that communicate aircraft status.
I know it's impossible, but I've always loved to get a hands-on demo... I'd love to learn the UI patterns involved, for example. I can always make my Emacs faster to interact with, dammit!
I had occasional access to a Bloomberg terminal 20 years ago and I still miss it. I miss it a lot. I wish they offered a cheaper option for users who only need to use it infrequently. I mean, $25,000 annually is brutal if you're not a broker-dealer.
What does the terminal really give you that you can't get from various other data sources scattered around the Internet, like your brokerage's own API, third-party data sources, various forums and subreddits, ...? Is it just the real-time firehose nature of the thing?
I love displays from space vehicles and nuclear plants for the same reason. Data and controls organized in a dense but presumably highly usable manner. And it covers the more specific view of an expert in a particular subsystem, as well as the higher level view of those responsible for the whole system.
Yeah, I think this is something a lot folks miss when doing UI/UX these days. There’s an immense focus on new users, not on folks who rely on it day in and day out for actual work. I’ve seen loads of old, incredibly “ugly” UIs that absolutely mog newer friendlier attempts at the same. They’re absolutely intimidating to new users, but once folks learn it they’re indispensable and obviously intentional.
I really wish there was a resurgence of information dense UIs and tools, optimizing for people who use them daily and not “use it once.” It really reminds me of the hate folks have for things like Eclipse or IntelliJ which are daunting at first but once you get over the shock and learn them really are amazing tools.
The difference is that Costco pays their employees well enough to keep them around (notice that Costco prints the start year on each employee badge- average retail length of service is 1 year, Costco keeps people around for decades) and so they can learn to use this older software and master it. Most retail operations optimize their inventory management for new people, because they don't expect someone to stick around long enough to master it.
My wife worked at a small regional chain of pharmacies that had an ancient MS-DOS based EHR system. And she mastered that system to the point where people would call her when she was home with me and ask her how to do something, and she would walk them through "okay, hit tab three times then shift-F12 then enter the frabble and then alt-F3 to go to the next screen and enter the drabble." It was difficult to learn it, but if you mastered it you could do everything you needed to do from just muscle memory while you were on the phone arguing with the doctor's office that their prescription was not correct and needed to be changed.
Then the small chain got bought by a national player and their brand new GUI system was brought in. It was a lot easier to learn- discoverability was a lot higher with menus and drop-downs and all of that. But if you stuck around to master it, you could never be as fast as you could with the older system. And that emphasis on quickly integrating new employees- but lower payoff for experience in employees- was clear in every choice that national chain made. They wanted their employees to be completely interchangeable, which meant that they didn't care if you had six months of experience or four years of experience or three decades of experience.
Same story at my bank. Tellers used to speed run through a TUI, hitting tab and other key combos to accomplish things. Now it's a long wait with them mousing around.
Agreed. Also, you can try to satisfy both new and expert users. It take more thought and design, but that principle is in both Nielsen's Heuristics and Shneiderman's Golden Rules.
I think that's the 'push/pull' problem though. Information dense UI that takes months or years to learn, or something that may be less information dense, but a monkey can learn it in minutes.
For me, it's typically a balance between speed and efficency of data to help you make decisions quickly, but should be able to be used by anyone with technical experience.
So less of both. Less 'pretty UI' and less "omfg here is every piece of information shoved together and you need to be a wizard to understand it"
You’re reminding me of this thread I found a long time ago where someone was talking about the old amber-screen library computers that felt FAST. The gif here shows what it would look like to read Twitter in that manner… https://x.com/apaprocki/status/1230241842928791552
The modern Terminal is based on a private fork of Chromium to give it the look and feel of a VT100 terminal, and integrate their private networking and security technologies. The BBT predates HTTP, and backwards compatibility is hugely important to the company- they have a museum where a second-generation Terminal from ~1985 shows the current news, because they are so dedicated to backwards compatibility that they still can support the 1985 hardware.
This isn’t really true. The old terminal monitors are essentially dumb CRTs and the the museum pieces are just displaying the output from a regular PC running the modern app converted to an appropriate signal + BNC connectors so you see something and not just a black screen.
The old terminal hardware communicated over dedicated serial lines and worked in conjunction with many other “server-side” pieces of software that no longer exist, so it would be impossible to make one function as it did back in the day.
I would love to learn the specs of the original 1983 terminal. By the look of it, it's NTSC timings, so 200-ish lines, but it shows text and graphics, so it must have some bitmap capability. If I were to replicate the look, I'd use something that can display ReGIS or NAPLPS.
They ran iRMX on an 8080 variant and had graphics card that handled the A/V aspects. I suspected the displays could have actually been PAL because it had slightly higher resolution, but I haven’t been able to confirm that yet. I have one of those “Smithsonian” pieces on my desk waiting for me to have to some free time to try to repair the CRTs when I someday have more free time than I do now (any good resources for that??).
Love how those dense screens make numbers checkable at a glance. Tiny shops still live that gap—bank lumps vs invoice lines—just without a dedicated terminal.
The article has an image of terminal keyboard used by a legendary trader... the key-caps are immaculate; the letters haven't faded at all. Amazing. I wonder if they were double-shot...
On one hand, at the price point of >$10000 for the whole terminal, it's quite possible that >$100 went into the keyboard.
However, I suspect you're coming at this from the perspective of a coder or a gamer or some other category who types thousands of keystrokes per day (tens of thousands?). With the assortment of special-function keys that enabled the user to execute common tasks with only two or three keystrokes, I suspect that even actively-used Bloomberg terminals may see an order of magnitude less keystrokes.
(On the third hand... I seem to remember reading that the Bloomberg system included chatroom functionality, which may increase keystroke count)
From memory when I worked there 10 years ago, all the Javascript based stuff was pretty slow in a very noticeable way. They've likely gotten better as they are using a well known Javascript and rendering engine, so they're getting many optimizations for free.
I really wish there was a resurgence of information dense UIs and tools, optimizing for people who use them daily and not “use it once.” It really reminds me of the hate folks have for things like Eclipse or IntelliJ which are daunting at first but once you get over the shock and learn them really are amazing tools.
The difference is that Costco pays their employees well enough to keep them around (notice that Costco prints the start year on each employee badge- average retail length of service is 1 year, Costco keeps people around for decades) and so they can learn to use this older software and master it. Most retail operations optimize their inventory management for new people, because they don't expect someone to stick around long enough to master it.
My wife worked at a small regional chain of pharmacies that had an ancient MS-DOS based EHR system. And she mastered that system to the point where people would call her when she was home with me and ask her how to do something, and she would walk them through "okay, hit tab three times then shift-F12 then enter the frabble and then alt-F3 to go to the next screen and enter the drabble." It was difficult to learn it, but if you mastered it you could do everything you needed to do from just muscle memory while you were on the phone arguing with the doctor's office that their prescription was not correct and needed to be changed.
Then the small chain got bought by a national player and their brand new GUI system was brought in. It was a lot easier to learn- discoverability was a lot higher with menus and drop-downs and all of that. But if you stuck around to master it, you could never be as fast as you could with the older system. And that emphasis on quickly integrating new employees- but lower payoff for experience in employees- was clear in every choice that national chain made. They wanted their employees to be completely interchangeable, which meant that they didn't care if you had six months of experience or four years of experience or three decades of experience.
For me, it's typically a balance between speed and efficency of data to help you make decisions quickly, but should be able to be used by anyone with technical experience.
So less of both. Less 'pretty UI' and less "omfg here is every piece of information shoved together and you need to be a wizard to understand it"
The old terminal hardware communicated over dedicated serial lines and worked in conjunction with many other “server-side” pieces of software that no longer exist, so it would be impossible to make one function as it did back in the day.
https://www.reddit.com/r/wallstreetbets/comments/8aiz67/how_...
https://news.ycombinator.com/item?id=17079033 (104 comments)
A look back: The Bloomberg Keyboard (2017) - https://news.ycombinator.com/item?id=20742329 - Aug 2019 (55 comments)
A look back: The Bloomberg Keyboard (2017) - https://news.ycombinator.com/item?id=17079033 - May 2018 (104 comments)
However, I suspect you're coming at this from the perspective of a coder or a gamer or some other category who types thousands of keystrokes per day (tens of thousands?). With the assortment of special-function keys that enabled the user to execute common tasks with only two or three keystrokes, I suspect that even actively-used Bloomberg terminals may see an order of magnitude less keystrokes.
(On the third hand... I seem to remember reading that the Bloomberg system included chatroom functionality, which may increase keystroke count)
Some people like it and projects like this have appeared: https://github.com/dchest/bergoom
I'd love to know how they make frontends as responsive as possible. To the engineering blog!