Not a better phrase to describe a Bloomberg Terminal. Everything is there, mainly data, quick charts, Messenger and with it 'social' (yes, Bloomberg Support do make restaurant recommendations if asked), quick facilitation to sometimes complex questions through these services, handy linking to Excel, and where data quality was questionable a quick response.

I think what Bloomberg did/do was/is listen to their customers. A Bloomberg today is much like when I first touched it 20 years ago, but it isn't. It feels the same, or similar, the screens are vastly larger, does what it has always done, scales. There are no redesigns that stop a user doing what they've done before, yet allow them to do more. It is what is expected and surprises, sometimes frustrates, but a learning curve and pleasure comes from learning.

The colour scheme also looks good. A black background gives you many more high contrast choices. Try using yellow or cyan on a light background. It seems most of the colours are based on the old 8-bit selection; red, green, blue, cyan, yellow, white and black. Orange seems to have been added as well.

It's funny how little credit we give to business users these days, and how much marketing UX there can be.

There was a time when business students attending college and their crufty professors could manage using email by telneting into the mainframe to use Pine. And the technology was a wonderment to them.

It's an attractive font.

Me too! I wonder if it was the same company?

> Our app was probably the anti-thesis to the Bloomberg Terminal in almost everyway: “modern” design, tons of white space

It was not.

Also how are monospaced fonts "the right decision"?

GUIs generally represent the sacrifice of power and automation for approachability by the lowest common denominator.

I think this is a big factor in what killed slashdot. They did a big redesign years back that added a lot of whitespace but actually made it incredibly difficult to easily browse comment threads and see quality comments. Similarly, despite the old Reddit interface having a reputation as being "ugly", I hate the new interface and always browse on old.reddit.com, mainly because of the higher density of information that makes it easier for me to scan for posts I want to read.

But my only lasting memory of that app is that it probably didn't increase productivity as much as I thought it did when I looked at how they used it day to day, and only succeeded in giving them carpal tunnel syndrome due to all the extra mouse-clicking. The final conversation I had with those users is how their wrists were starting to hurt so much. But hey, I was moving on to another project. Hey, sorry to hear, here are some exercises for your wrists, see ya. Oh, by the way, did you ever try Powerball? Supposed to do wonders to make your wrists stronger.

I try not to be so narrow-minded about app design after that. Pretty does not necessarily equal functional, useful, or value-adding.

edit: In retrospect, those users grocked that terminal interface with all their key shortcuts the way a seasoned developer or sysadmin would grock emacs. Imagine forcing such a guy to use point and click instead for everything. You'd have a riot. I can't believe I didn't see it at the time. Young and naive, and now also regretful for all those people's wrists.

>Are there things my users really don’t need to see right now? If you don’t know, ask!

ASK! ASK! ASK!

For the love of god please ask your users. I worked for a company with a big clunky enterprise app. It got redesigned numerous times and rolled out with big fanfare.

Nobody who used for any significant amount of time was involved in any of the redesigns. It was horrible every time with numerous changes just to get it not to be a huge pain point.... and then a new overhaul would come again.

I changed jobs to web development recently and really the first questions are to define the problems we're solving, and find out from folks using it day to day what their pain points are and how they work. I'll make some mvp type stuff for say a given function and then show them and get more feedback, the important thing is to get it from the end user, not their boss, not their VP, but the end user (boss and VP have to be involved too of course, just in other ways, distract them with fun control panels and such....).

I ended up working for a very small company, handful of people, me and one senior programmer, the product doesn't dominate the market but time and again customers just love that we call, ask, and do stuff and don't dictate how they work (within reason).

You can still make things clean, but when removing things you have to ask, communicate, you'd be surprised how much you can change if it is part of a conversation, and how little you can change if you just force it on them.

This same exact story of a UI disaster happened at a Fortune 100 company I was at in 2005. They had a legacy app (think DOS character mode talking to a mainframe) for entering accounting documents.

To replace it, a high-priced consulting firm installed a "web portal" technology. (Unifying a company's various enterprise applications behind a single web portal was a hot endeavor back then.)

When it was rolled out, the accounting department fell behind on their work. Nobody noticed that the constant UI banner at the top of the of the web portal browser window was forcing users to always use the mouse to scroll up and down to look at information. In the old DOS system, they could just enter info from invoices quickly without even looking at the screen. But the new system broke the users' fluid familiarity.

The UI disaster was so bad that the consulting company had to have their consultants come in on Saturday to help the client's workers catch up on all their data entry. Imagine an army of $150k consultants doing the work of $10/hour clerks because the web portal's UI was never really field-tested with a real-world workload! If just one UI web developer actually shadowed one of their users for a day, they would have noticed the usability problem.

My goodness, Flintones even. The fashion chase is becoming obsessive and wasteful. As I've ranted about many times on HN, UI faddism is a huge time and resource drain and the industry should just say no or see a therapist.

It sounds strange, but desktop UI's around 2000 pretty much reached the pinnacle of business UI's. The web slid us downhill with its stateless ways, unpredictable layout results, and now wasting screen space while copying touch-screen-oriented design for mouse users who don't need swollen boundaries. Use 5-pixel lines to visually segregate panels, saving you about 20 pixels of width versus white space. ("Web" pixels, not nec. actual pixels.)

(The only exception is perhaps drill-down link-heavy lists/reports/charts. The web served these well.)

That aside, the Freshbooks redesign last year pushed me to switch to QuickBooks for exactly this reason. The new design had the stereotypical "modern app" design, but every common task required 5x more time than before.

For example, just to change the category of an expense you have to 1) click on the expense, wait for the detail page to load, 2) click on the category, 3) click "Change Category" and wait for the dropdown to load, 4) click on the new category, wait for it to apply, 5) click "Save", 6) click "Back to expenses." And every interaction takes a second or two to register, so imagine a delay between every step. Now imagine doing this 50 times every month when you're doing bookkeeping.

... In the previous version this took two clicks: 1) In the expense listing screen, click on the category, a drop down instantly appears, 2) click on the new category, it instantly applies.

They also took away the feature to add an accountant to your account. Imagine if GitHub took away the option to add "member" users.

I'm not sure this is about whitespace or information density.

I think that users, especially users using something as part of their job on a regular basis ("enterprise"), hate change. Any change. If they know how to use the thing as part of their job now, it is very difficult to make a significant change that they won't (at least initially) say they hate and want the old thing back. Even if the change would have been liked better by more new users/customers. Even if they hated the old thing too!

And aside from just change-aversion, of course, there may have been lots of knowledge/decisions about what users actually needed to do to do their jobs "encoded" in the old UX, as a result of lots of changes over time, that can be lost when creating a brand-new-from-scratch UX -- especially if you aren't doing a lot of (or any? it wasn't mentioned in the post) UX research in advance of the re-design.

I think this story may be about change, without necessarily being able to conclude anything about the factors of the change/design, such as whitespace, or any other design elements.

If you're doing UX design, you should be doing UX research. And not assuming any universal principles about whitespace or information density from this blog post.

And think of the color blind. Especially dark red shouldn't be the only way this information is highlighted. 8% of men are the kind of red-green colorblind, where dark red and black is not easily distinguishable.

If 8% of men don't see your error notifications, maybe that shouldn't be the only kind of highlighting (or choose a color that is less likely to affect so many people, like orange).

>Let users export data, instead

And maybe even import. I have a lot of administrative tasks I could script easily, if I had more direct access. But writing a python script using a headless browser, which breaks every time they update, doesn't sound as attractive.

And a point they kind of forgot: Make it perform well. There are so many enterprise apps where you need to click a lot and wait so much time in between you start doing something else, which reduces your flow.

A second point: Give people keyboard shortcuts, and make them apparent through tooltips. Your power users will highly appreciate if they can do things more quickly with the right shortcuts.

Too often I see UX issues blamed on visual choices — the whole everything must be flat movement of 2013-2018 is one example — when there are deeper issues that can't be extracted into a pithy recommendation.

For instance, when I log into the Chase website, there's 8 UI updates (i.e. 8 sets of loading bars/HTTP requests; see below) that have to load before I can see the recent transactions on my account. Each chunk of requests must finish before the following chunk can start. All in all, it takes ~7.1 seconds for the page/recent transactions to load.

---

The 8 UI updates the Chase website goes through before it finishes loading/you can see your recent transactions:

1. Initial blue loading screen with a spinning loading icon

2. Tan colored background color replaces screen #1

3. Header loads

4. The blank outlines of the main UI components loads (without any data in them/with placeholder loading bars)

5. All of my Chase account metadata (account type, current balance, and last four digits of the account number) loads

6. More in-depth data of the first account on the list loads (available credit, payment due date, minimum payment due, etc.)

7. Recent transactions panel starts to load (with no data/with only a placeholder loading bar)

8. Recent transactions are shown

At this point, the page is finished loading.

As a domain expert, I was for a sparse UX that emphasized the awesome just-works power of the product. I'll never forget how one bank IT director customer said, "I just can't pay for something with this little on the screen. Can you add more stuff?"

I think the key PM-fail on my part was privately scoffing to the architects afterwards that while we reduced the whites pace, we should also implement the ruby acts_as_enterprisey module to make the product seem crappier. This lack of people insight (and downside of visionary personality type attitude) pretty much summarized my limits as a PM.

Real lesson for us was: enterprise users trade on demonstrating their value by performing complex work. It's job security. The stakeholders you need to close an enterprise sale include those users. If your product or UX trivializes someone's job, they are going to fight you.

When they say they don't want your UX but they want your data, what they are really saying is, they don't need the problem you think you are solving solved, they are indexed on finding a way to demonstrate their value.

I"m learning this the hard way now with a product that doesn't quite close the knowledge gap for non-experts, but am finding it's simplicity is undermining to the authority of experts. Solving problems and demonstrating value are very different things. It's like building a tools vs. building instruments.

The UX question I need to answer is, does my product solve a problem, or help a problem solver demonstrate value? If a) then the end user is not my customer, if b) it's going to need a lot more knobs and whistles.

White space isn't just white space, it represents the expression of functionality to the customer.

The UX design question always takes you back to first principles, who is your customer and what do they need?

I prefer Foobar2000 over Apple Music. Give me dense, logical and flat layout over 50 page long hierarchical layout full of whitespace. Whitespace is tiring when used extensively.

It finally pushed me over the edge to use user stylesheets. A bunch of "margin: 0 !important" and "display: none" and I get twice as much information on my screen at the cost of... looking polished I guess?

I see this problem all the time when I talk to companies. They hire a big agency expecting big results and the agency rolls out the red carpet and does everything they are asked. Both parties fail. The first question I ask when someone asks me to design something for them is “why?” Most of the time the response is way out of touch with the actual reason why you should ever consider design. A real UX consultant will do 70% research, 30% design if they offer that portion of the service which I do. Please don’t make the mistake of assuming you know what you need. Find a UX designer not a UI designer and listen for the hard questions- who is your customer? What problems are they complaining to you with? What do you think this redesign will do for you? These are just some of the basic questions you’ll be asked. Your consultant will know your customer better than you when they are done before they touch any designs, if they don’t do any of these things then walk away.

To this day I am still astounded that more than one person thought #BFBFBF is a perfect colour for text on a white background.

I want to wake up from this nightmare. Software like Bloomberg Terminal and CATIA doesn't need to be beautiful web apps with clean, !minimal! Material design, they need to tear through the issues they're meant to solve as quickly and easily as possible, even the reality of that is a little ugly.

For what it's worth, I found the blue table easier to spot the red numbers. I'm red/green colorblind and I could not differentiate the red from the grey table coloring very well. With the blue it stood out.

I worked on a potential redesign of the US Navy's medical appointment booking application and the data entry rate and responsiveness of their "ancient" system was far superior to the newly proposed solution (web based).

I feel like this is a universal absolute, doubly so when it comes to enterprise apps (the lone exception being when we switched from Lotus Notes to Gmail -- then only half the company hated the change).

I would've liked to know how long the changes were in place and how it affected productivity metrics, especially the amount of training time spent on new users. As is, the article seems kind of obvious. Enterprise users abhor change; who knew?

> Just like you wouldn’t appreciate a dictionary with only 10 words per page (so many pages to flip through!)

This also makes me question the veracity of the article. It's a really terrible metaphor that makes me wonder if they were _solely_ concerned with pretty design on the outset.

I want a dictionary that shows me 1 word per page, with a search bar. The page flipping functionality is useless and can be removed entirely. It's a bad workflow.

I can definitely say that over the past 20 years, our in-house LoB app has developed some really bad workflows as well (business changes a lot over 20 years). Removing these bad workflows would give us back a ton of screen real estate without losing productivity.

The causality is backwards. I don't want to create whitespace by changing the design and ruining the functionality. I want to change the functionality which will create more whitespace and allow room for beautiful design.

It's not "function over form, always"

It's function with form, always. They're properly inseparable when building a product. They aren't separate things such that one should ever be over another, or that one should ever suffer to the other. You consider the product and match the function and form together to that product's needs.

It should never be function over form, or form over function. They work together in unison to be one: simpatico. The function isn't separate from the form, the form isn't separate from the function. The necessary end result product can only exist with both, as such they necessarily inform and cooperate with each other at all times.

The flawed approach described in the article, was form over function, which is the identical conceptual mistake to function over form. It's the mistake of ever considering the two to be separate or to ever elevating one over the other.

If a high density information presentation approach is the best form, that's not function over form. That's the proper form for the function of the product. That means the two are working together - neither is elevated - to deliver the best combined form + function for the product in question and its specific needs.

Instead, I have found much success in slowly deprecating these applications and, instead, giving these users direct read-only access to the database and teaching them SQL. SQL is not a tool only for 'technical' people. Most of these users have mastered the 'dark arts' of Excel so they are capable of learning other tooling. These users can then query the data in any way they want and export it in any way they want. There is more to this, like ensuring to only give them access to reporting databases. The application then can focus on being an interface for updates / writes and not for data exploration.

I have several scratch-my-eyes-out sites I use every week for fodder and am sure you would never lack for suggestions.

> A large business by its nature has massive-scale data and usually thousands of users who directly interact with it—searching, manipulating, reporting, and more. They need to move through that data quickly, without a lot of digging around in the interface.

The lesson here is actually that the designer didn't understand the context in which customers were using the app.

It sounds like s/he didn't talk to customers about how and why they use the app, or show wireframes to them, or even sit and watch them use it for an hour.

If they had done any of the above, they would have had a lot more context about what a good solution looked and felt like.

Except users lie all the time. They don't know what they need or want. People are horrible at being logical about what will actually help them.

Watch them work. Watch a bunch of people work. Test and prototype changes and watch more people work. And watch them work at their desk or where ever they work.

- the boss of the boss of the representative of the customer company

- the boss of the representative of the customer company

- the representative of the customer company

- my line manager's boss

- my project manager's boss

- my line manager

- my project manager

- me and my team

- the user

Any of these people might of might not have been ever in contact with the elusive "user".

Yes, we know, THE DESIGN IS BROKEN.

And then, nothing. New features come out though, most of which aren't needed or deprecate features that we actually like. So I'm sure some Project Manager is being paid handsomely.

When I was working on a reimplementation of an existing web app I had several team members watch how users were using the application. A mixture of sitting next to them and quietly watching (not interrupting their workflow) and remote watching via shared desktop (which we also recorded to refer to later).

Watching (in person and remotely) was without question more valuable. We could go back and replay what they were doing and why (we had copies of the worksheet they were working from for each use). Without it we wouldn't have delivered about 30% of what they were looking for and would have had to redo a load of work compared to if we had just gone by how they said they were using the system.

The new system rolled out and we had a total of two post-launch changes to make. Both of which were very simple changes. So don't just ask but watch how the users who use the system actually use it.

I think the proper thing here is for the purse string holders to defer to the views/feedback of the every day users.

The article has an example of customer records where the name fields are merged, same with the address fields. I know that would be hell for my friends in customer service wanting to find a customer by postcode or just their first or last name. Sometimes people are insistent they have complained before and you have ignored them, or you get scam artists. In these scenarios the team have to do detective work and they rely on having a decent sortable grid of customer records so they can find what they want if given incomplete information. Incomplete information comes from telephone messages made by cover staff, poor quality handwriting and a multitude of other sources. Since the staff stare at the same screen all day they know their way around it and simplifying the layout helps nobody.

Even in terms of the "recommendations" in the article, I can see all sorts of red flags. Group addresses? What if I needed to see what state it is at a glance? Now the state alignment is off. Or if I needed to sort by state?

All of this could have been avoided by sitting down with users of the existing system, watch how they interact, and then put together a revised version, and watch how they interact/where they have trouble/etc before doing a wide release.

The fact that user testing wasn't done, especially on an internal application where the users are right there available for it, is the real story here.

The problem is, the arrogance of the designer. Who would ever redo something without talking to the user?

I feel like there is an opportunity to make a graphical user interface framework that mimics old terminals. Full screen apps that leverage use of the keyboard shortcuts or hell even a custom keyboard specifically made for industrial use. Basically a IBM 400 system but running on modern software stack. Airlines have stuck with their UI and for good reasons.

And it’s always for goofy vague reasons: “It looks dated!” “It needs more pop!” “It’s not fresh enough!” (What are we making? Software or food?) Nobody is willing or able to prove with numbers or measurement that the old UI is bad and the new UI is better. It’s usually just the designer’s hunch! Yet if I want to change the search algorithm we are using I have to prove the new one is faster with research...

And remember to use Angular or React... actually, now you must use Vue. And create polyfills for your webpacks (and vice versa).

White space is great for new users to help not overload them, but after a few weeks of use, most should be able to go to their options and change the layout to save all this pointless mouse wheel scrolling.

I am impressed at the responses in this thread - I honestly thought I was in the minority about this, but hopefully the fashion moves a little more towards functionality

If you make something that is valuable but doesn’t give the users a power trip, it will fail. This is just how people work.

I find that kind of arrogant. In a lot of cases, the UX designers simply underestimate the real complexity of a task.

So, I used a nifty service (http://soundiiz.com) to sync my artists across multiple services. I hate the idea of paying for Yet Another Service, especially because I'm paying for one (Youtube Premium) that's useless for music because Google won't respond to bug reports, but I started to spend some time in Spotify.

Spotify is uglier than Youtube Music, but a thousand times more useful. Part of that is the more active community (artists that I like which have 0 followers on Youtube Music will have hundreds or thousands of followers on Spotify) and more engaging playlists, and part of it is that I was able to "get" Spotify features and navigation quicker than Youtube Music... which is still feature poor as they migrate from Play Music to Youtube Music.

So, to me.. Spotify is uglier and far more useful.

A lot of good design is minimalist. I don't know if it has to be. Sometimes it makes sense to present a lot of information in a dense block

As a trend I can't wait for it to die in fire.

But imagine staring at Foobar2000 all day as if it is your primary work. You probabbly are looking for just some of the data most of the time and filtering the rest... so in that case maybe less would be better.

On the other hand if you glance at it and want lots of data without clicks, then dense is great.

But your point about "logical" is the key for dense stuff, and getting to what is "logical" can be hard.

There's a great series by Jensen Harris, Office Program Manager, about how they designed the Ribbon: https://blogs.msdn.microsoft.com/jensenh/2005/09/26/the-why-... (you can find the rest in his blog archives, unfortunately the images are gone)

It was an incredibly complex undertaking, Microsoft did many studies, had focus groups and the whole thing (Office after all, is a major business to them, worth billions of dollars).

The end result was demonstrably better for the vast majority of users (Microsoft had hard numbers to back their design decisions).

And yet if you read many of the comments on tech forums you'd think Microsoft killed the users' puppies.

That something I didn't realize until lately but aesthetics is hugely important. We once updated our internal issue tracker and everyone raved about how better it is now. The thing is: absolutely nothing changed for the average user besides the style. Things like more tasteful color choice, a more modern look with square corners, etc... nothing practical.

Also, from some guys at Microsoft: if you didn't change the UI, from the user point of view, you didn't do anything.

The problem with modern UIs for beginners is that too much is hidden. Panels that only appear when swiped from the side, parts that give no indication of being clickable, highly abstract icons, lack of consistency (ex: the "hamburger" menu can be anywhere, or not be present at all).

I think the underlying thing is that simple UIs sell better because you're usually presenting it to someone that can't visualize their complex workflow needs up front. The number of times I've seen requirements that are basically sales enablement features that customers would rarely use is not insignificant. Similar to focusing on usability for low-res displays, when the only time the app would be used on a low res display is when hooking it up to a projector in a demo.