Low density UIs specifically happen when you attempt to present the amount of information a 7" screen can display onto a 27" screen.
Low density UIs specifically happen when you attempt to present the amount of information a 7" screen can display onto a 27" screen.
The issue I have is that the mobile app is already so dumbed down that it's pointless and I don't use it. When you have limited screen space you need to decide what to show first. For my bank it's the status of a MasterCard credit card I don't own on the first screen of the mobile app. Next is some pointless overview of my accounts. I say pointless, because all context has been removed, in favor of massive amounts of white space.
Now they want to replicate this interface, but for larger screens. Most of the screen is white space and you have to click on everything to get details, details that would fit perfectly well, even on a small laptop screen. Also nothing is obviously click-able, because why would you add visual clues that just taints their beautiful white space.
For the most part I think that companies would love to ignore desktops and large screens. In some sense they may also be afraid of presenting users with details overviews, either is to make everything seem more friendly, or to discourage usage.
There's an accessibility element here as well. It's not possible for everyone to use a touch screen.
One interesting usage I've seen is especially younger people, who have a debit card which doesn't allow an overdraft. They then keep their account at or around zero and only transfer the amount they need to the card account before every purchase. That usage is supported way better than my attempts at managing saving, paying large bills or keeping track subscriptions and other spending for the past week.
Most people have at least two. One of their incoming paycheck and one for their debit card. Most have more.
I also have a separate savings account, and one for my cottage, both which get scheduled transfers from my "main" account.
When my debit account is low I transfer $100 or so. Allows me to have a sense of spending that cash gave me.
This is possible by abstracting the layout engine (generally to match a web browser) and having UI control running in transpiled JavaScript.
In more practical terms, this means its easier to have one team managing your website and mobile app, reducing the number of specialist roles and minimising feature disparity. Generally it saves on duplicate work as well and makes timelines easier to manage.
For banks specifically there are a bunch of wins with respect to only having to ensure legal compliance of one application; this applies to banking laws - where certain information must be communicated at certain points, and to public accessibility laws. Most of these frameworks have a lot of tooling around language support and accessibility integrations.
So even if these experiences are inferior, it is very much worth it to the providers.
That was the brief moment when the iPhone was the only smartphone to target and was 320x640. Or when the majority computer screens where 1080p at most and the browser would be on more than half the screen estate.
But for your bank for instance, if their UI is optimized for a 6" diagonal window, they'd probably expect you to adjust for that instead of them trying to be perfect on every screen combination that could happen on earth.
That's also how I see many support chat apps' choices of spawning a popup when running on a desktop, to reset any browser size the user was trying to use in the first place (users are still free to do whatever they want with the popup, but it's a good indication of what size it's supposed to be)
* Size elements relative to the size of the viewport, some things should be smaller on little viewports, some things should be a little bigger, the CSS units for this are still just coming together. Use formulas and percentages, not pixels.
* Think about the correct layout direction for everything on a portrait vs landscape orientation, should those items be in a row or a column? This often requires only one CSS property to change
* Hide information density behind an accordion or modal if you need to on small viewports, don't just remove the functionality for all versions of the application. When people strip away functionality, I find design is rarely the true justification -- more commonly they no longer want to pay the maintenance cost of the feature and are using a redesign as an excuse.
Absolutely. We finally just got container queries! Responsive design using screen width was always a sham. A stop gap to all the work the browser devs and standards bodies had to do to figure out what worked.
Pretty much every single responsive design I ever worked had either the mobile or desktop version as an afterthought. The mobile was just a "scaled down" version that was done last-minute, or vice versa.
Is there a sidebar? Hamburger menu it is. Is there a list? Well just put every row on top of each other.
Sure, this makes things easier for the both the designer and the developers, but putting just a bit more effort in the "secondary" version would be enough to make both versions better.
We now exactly what works. UI didn't suddenly appear in 2024 out of nowhere.
What you need are actual tools to build UIs, and not a hodge-podge of hacks thrown in together with no long-term planning, and aimed at displaying only text and a couple of images.
Just giving the ability to get an element's size without causing a full-page re-flow and re-layout would give much more power to UIs than any number of relative sizes and container queries.
Well, there are a few standalone examples here or there, but "flexbox is enough" is verifiably false.
Here's an actual app and not the anemic crap that people call "apps" on the web: https://x.com/dmitriid/status/1424052288205856773
Yes, yes it would. That is why I wrote this: "Just giving the ability to get an element's size without causing a full-page re-flow and re-layout would give much more power to UIs than any number of relative sizes and container queries."
Because on the web you can barely make custom widgets and it's almost impossible to do custom layouts.
Unless, of course, you use the equivalent of early 2000s Windows GDI in the form of Canvas, or a limited subset of OpenGL in the form of WebGL etc. And yes, people end up resorting to that. Look at what Figma wrote: https://www.figma.com/blog/building-a-professional-design-to... "Pulling this off was really hard; we’ve basically ended up building a browser inside a browser"
To repeat my statement: UI didn't suddenly appear in 2024 out of nowhere. We know what an app UI looks like. And the anemic "flexbox is good for most apps" is verifiable bullshit. This is the constructive criticism.
Edit. Also the sibling comment: https://news.ycombinator.com/item?id=40440939
Me in the year 2000 with a 1024x768 17" CRT would be flabbergasted at the amount of wasted/underutilized space that exists today.
Vertical space is precious, and it's why I paid more to have those 1600 pixels. And then Microsoft decides to not only enlarge the taskbar, but to not provide an option to turn it back to normal. I have to resort to hacks to wrangle MS Windows (primarily a Desktop OS the last time I looked) back down to size and reclaim my vertical space.
Serious point: a secondary 1080P display in portrait orientation is actually quite fabulous. Documentation gets parked on the secondary display. Line lengths remain readable, and you get lots of vertical space.
Not Much Ink / Nothing else.https://en.wikipedia.org/wiki/Chartjunk
which relates to a strong preference to use whitespace as a tool for visual organization. If you could separate two areas of the plot by drawing a line with them, Tufte would have you use whitespace instead.
Tufte certainly loves complex charts based on complex data, drawn as economically as possible. He'd also recognize that there's a time for a simple chart based on simple data and that such a chart should be as simple as possible: if you want to make a bar chart with Excel with the last 12 quarters of revenue for your business for instance he'd accept that, but insist that you turn off as much chartjunk as you can.
Business decided it would be mobile only, web support is 2 years away at least.
There's been a lot of issues because, A, nobody wants to install their previous employeer's spyware app, B, nobody wants to do job applications on a tiny screen, and C, a lot of the step up authentication requires the web browser, but is explicitly disabled for these folks meaning lots of them can't complete login.
It's completely bonkers.
The worst part of it all is the mobile app requires authentication for everything, including resolving tracking links and shortened urls. These people HAVE to go to the webpage to sign up and get the mobile app, but then can never visit the webpage again.
Just because someone experiences a less than ideal experience of RWD in one or more places doesn't mean to group all RWD UI experiences together as bad.
It's more practical spend less time developing and testing one global component than more than one.
Could there be improvements? Absolutely, and that's where we get to have a voice.
You point out web vs mobile, but of course as you probably use "web" as a shortcut for "PC", web also applies to mobile. Then on a 27" screen you might have one window full screen or 20 windows overlapping and an actual 7" browser to display the site. And others will be on PC, but with a 13" touch screen. And others on a 10" phone but split in half.
Then some people will increase text size and your design will need to deal with it.
Before you realize it you have dozens of constraints and requirements to think about, start dropping some to satisfy others, and inevitably people will be pissed at the result.
The big problem is catering to different input methods. A mouse has far greater accuracy than a touch display. You can put two links mere pixels apart on a desktop interface and that is fine because a mouse is more than accurate enough. The smallest interactive element a keyboard-and-mouse user can hit is probably about the size of a single period in a font. There are other issues with doing that, I'm trying to highlight the sort of accuracy you have with a mouse. A mobile user could never hit such a small target.
On PC, you can enter text and show the full content of the website at the same time. You can search in the page with a keypress. You can open multiple web pages at the same time. That is not possible on mobile.
As more and more countries have aging population I'd expect these kind of accessibility issues to be more prominent. Sometimes I feel like using modes (vim style) could help, with the user getting different tradeoffs when "reading" and "manipulating", if there was an easy enough way to switch between one mode and the other.
At the end of the day people want magazine layouts, newspaper splash styles, postcard type areas etc. I think even novel writers/editors have a "best viewed at" size and layout in mind that gives a perfect pace to their story.
Html/css gives the tool to switch layouts and potentially adjust to make the best of the area offered, but it will probably always be a compromise in the eyes of the more opiniated designers, and auto-reflowing content would be more of a necessary evil.
Even in our field we have traces of that with our recommended line length, method length, bracket styles etc.
Imagine a current era designer trying to design Photoshop without just copying an existing system. It would be useless.
Designing for skill curve evolution is rare, but Webflow is another product that has achieved it.
How do you reconcile this with the fact that you need almost double the effort for 2 separate designs? I'd say you need at least 2x of Designer work and at least 1.5x of front-end Dev work to achieve this.
Where will additional resources to support this come from?
If anything, having two designs that look and function well is less work than having one design that looks and functions well on two disparate platforms with completely different affordances.
That's what you tell your customers at least :)
And having both is not really 1.5x to 2x the work, in my experience. Maybe more like 25% to 30%. A lot of components and widgets can be reused, the typography and colors can be similar, and certain screens can keep their layout with just small tweaks.
Sure, maybe the initial design takes a bit longer since each screen needs several breakpoints. But that's only a small part of the overall design work anyway. Then on an ongoing basis, your previously established patterns (and components in code) can largely be reused with small tweaks, easily done with modern toolkits like Tailwind or MUI.
I don't think it's that big a deal. Web devs have been doing mobile designs for more than a decade now, and the tools have gotten better and better. Honestly, it's way less wasteful than Agile ceremonies or endless meetings. If you want to stay lean and cut cruft, take it from places that don't directly affect the user, not the one place where they actually use your product all day.