Yes! I hate websites that put useful content in a thin column in the center.
What's worse, formerly normal websites start degrading. Typically, when a new manager is hired and decides to "reimagine" the product with the "mobile-first" vision. The recent Patreon is a good example.
And of course, in some cases normal websites go away entirely, and are replaced with crapps: Venmo, Amazon Alexa, Chamberlain, etc.
It has finally been told! I was crying and talking about making the return of information rich websites, but people were just following trends blindly :(
view point in article mostly from an user perspective, but if same stuff would be reviewed from companies perspectives most of that negatives has positive effects for marketing/sales needs which probably a reason why is so widespread.
It's like: our visitor can't just see our half page table with tech spec to know everything, he should go trough 20 images on 2 long pages and during that we will show him all our 'important' messages that he won't be interested otherwise.
Someone told me that Japanese websites tend to look outdated because all of the tooling and code is itself in Japanese, and since that stuff hasn't been updated in a while, the final products are a bit stuck.
Many websites will completely alter their UI based on resizing your window. Sometimes I want to set a browser to take up half of a monitor so that I can put something else next to it. This often fails on modern websites because the UI becomes unusable after the window is resized
This is the "responsive" part of "responsive design". When done well, it's great, but you're right that many websites are way too aggressive about it, as if they only really tested two size classes.
It makes every window interaction slower when I'm helping them and, I assume, when they're alone. I usually have two panes of code and one or terminals on the side so I don't spend time hunting for windows
I wrote my own window manager that's mostly centred around maximized windows and terminals (it's like a wiling WM but without the tiling, where most things are always maximized).
Guess I must be a junior then.
Stop judging other people's personal preferences. It's their computer and whatever works for them is a good solution.
It depends on your screen size and workflow. I used to have three monitors and now find myself having one monitor, maximize the windows (except for the terminal so that the prompt isn't too far down there) and quickly switch between those windows with CMD + Tab so that I'm not distracted by the multitude of opened windows.
I've never used a window that wasn't maximized. I have focus issues. If there are two windows on the screen it becomes hard for me to concentrate. I have two monitors if I really need two windows (e.g. debugger on one screen). Otherwise it's maximized all day.
For some websites, once you reach a certain width in pixels, the designers assumed you are using a tablet or cellphone instead of a desktop, so they give you the pared down mobile website whether you want it or not.
I'm gonna complain about HN though; while it may not have been intended to be mobile first, it kinda is, leading to overly wide text in comments if using a full screen browser. This is the same issue that the previous iteration of Wikipedia's design had.
As a user, when I set my browser to be full screen, I expect the content to take up the full screen. I bought a nice big 27" monitor, and I want to use it. How dare some UX designer 2,000 miles away from me simply decide that I should only be able to see content on a 5" wide strip down the middle!
The browser should be the User's Agent, not the Web Developer's Agent. If I want to do something with my browser layout that a designer finds appalling, that should not be his concern.
If the web developer and designer really think that text should appear in tiny 5" columns no matter how wide my browser is, fine, then flow your design to display multiple side-by-side columns like a newspaper. Don't just fill my screen with whitespace.
I think multiple side-by-side columns would be great. Actually, do you know of any sites that actually re-flow text like that? It’d love to see it.
I don’t really want text to reflow to be, like 23, inches wide or whatever. Books with 23 inch wide pages are quite rare, because, I think, that is too much horizontal space, scanning that far with you eyes can become a drag. Of course, if a page just uses the whole width uninterrupted for text I can just give it half the screen, so that is fine. But I’m curious, do you actually like the look of a page like that? Or is this just on principle—respect user choice and all that (if so, good principle!)
In general web devs seem to think way too much about the layout of pages, if they would just do the simple thing users could resize the window to their liking.
I think I might have seen the "column-ization" method once and was impressed by it.
HN's handling of different browser widths is... pretty weird, at least on my Desktop Safari browser. Looks like from browser widths of 1920px and greater, HN maintains fixed size whitespace borders and scales the content width. Nice. When you shrink the window past 1600px, it holds the content size fixed and shrinks the borders. I guess the intent is to smoothly transition into a mobile design without the borders. Past 1516px, it removes the borders altogether, and seems to transition into this "mobile" design. Between there and around 610px, it seems to shrink the content width by discrete fixed amounts every 200px or so, to "keep up" with the browser width. Finally, below 610px or so, the site goes back to the non-mobile design, laying out as if the browser was 1600px wide (and actually truncating the right hand side of the text)--totally broken.
All that complexity--for a text only site! When they could just make the text 100% of the browser width and let me as the user decide what is comfortable to view. It's still much, much better than sites that just limit the content width to 600 pixels and fill everything else with whitespace!
Multi-column layouts only work if there's no vertical scrolling, or at least if the layout reflows so that there's no need to keep scrolling down & up & down to read each page of content.
If it's done well, pagination is nice. But (as in my previous post) I'm reminded of PDFs of multi-column articles where the text is tiny and doesn't re-flow when zoomed so you end up zooming in on the page to be able to read it, then scrolling down to read the text that's now off the bottom of the screen, then up & over to the next column, down towards the bottom again, etc. Then finally down to the next page & back across to the first column. That is a much worse experience than just scrolling in a single direction.
It's fixable, of course, by "just" re-flowing the text to match the viewport size. On a desktop, pages of multi-column text at a readable font size are nice. On a phone, multi-column text would be annoying, but a smaller font size can be used because phones are typically held closer to the face than computer monitors. Getting the layout to work correctly like this isn't something I can actually remember ever seeing, but it'd provide a "best of both worlds" way of reading.
Columns that adapt to window height is a solved problem, if you for example check out epub.js [0] or the built in ebook reader in Yandex browser. I'd say this is a "just" problem with no particular difficulties to implement.
Continuing with scrolling as default instead of pagination after the switch to high-res wide screen monitors was a mistake by browser makers. The future of the web - I think - will be with browsers that are real user agents and open every web page in reader mode, with multi-media presented exactly as the user wants. No more letting web-sites control CSS.
As for web-apps, they are not the web, they are programs and should live as PWAs in the OS instead of as bookmarks in the browser.
Like you wrote, there is little reason for column view on phones. Their width is one column and no more. I agree with you that it's strange that we never see this, especially on blogs or newspaper websites, where column view should be used.
You suggest that a site owner should design the page how you want it, not how they want it. But neither is the case. Their task is to design it in a way that is acceptable for many different people. For most users, maximising the browser window does not mean they want text paragraphs to become very wide, it just means they want to block out distractions. And most readers benefit from plenty of whitespace and a conventional line width of 50-70 characters. It’s not that the designer is appalled by your preferences, it’s just that you aren’t the only person who matters.
You say the browser “should” be your agent - but it is. You can use ‘reader’ mode or any number of browser extensions to tailor things for your own tastes, or even copy and paste the article text somewhere else to read it however you want. What you cannot reasonably expect is for every site to be ideal for your personal tastes out of the box.
I guess I just expect the web site to at least not deliberately make itself terrible such that users have to resort to big hammers like extensions, "Disable Styles", "Disable JavaScript" and "Reader Mode".
Web sites are fast, flexible, responsive, readable, scrollable, accessible, and respectful of user preferences... by default, from the moment you add text between <body> tags. Then web developers add code and CSS to make them worse. Sometimes they make it better, but very often it's worse.
It sounds like you prefer that 'academic' style that rests heavily on browser defaults. I personally like that style too, it's not an uncommon preference for HN users. But you must realise it's very niche? Most users of most websites find that kind of design difficult to read and use, so it's rare to see it outside of academic/engineering circles. All you're doing here is asserting your own niche preference, and making out that it's what the majority of people want. It isn't. That's why designers design things the way they do, not (in general) because they are incompetent or malicious. And that's why it's great that you have the option of using extensions/reader-mode/copy-pasting/whatever, so you can effectively redesign anything just for you with a small amount of effort. If you expect everything to already be designed for your own unconventional preferences, at the expense of most other users, then that is unreasonable.
Very wide paragraphs is just bad accessibility. It's harder to read and there are studies on this. You can always just disable the page styles if you hate it.
> As a user, when I set my browser to be full screen, I expect the content to take up the full screen. I bought a nice big 27" monitor, and I want to use it. How dare some UX designer 2,000 miles away from me simply decide that I should only be able to see content on a 5" wide strip down the middle!
I've seen this argument come up before multiple times on HN, and it's wild to me. Having sensible CSS defaults is not a designer dictating that you are only able to see content one way. You might prefer to read text in a giant line spread across a giant monitor, and that's fine, but it's not a freedom thing. It's not denying your browser's role as a user agent that sites have CSS files.
Every single website (HN included) makes CSS decisions for the user. What colors should be used, what is the default contrast. Every single line of CSS on a website is a designer decision by a designer 2000 miles away from you about how they think that content should be presented. And if you don't like that, turn off CSS in your web browser. Assuming you're using Firefox (which you should be using), it's trivial to do.
Of course, browsers should allow overriding CSS, and (imo) they should make it easier to do so and more accessible to non-technical users. And yes, part of making a website that respects the browser as a user agent is shipping HTML that can be viewed unstyled and that is easy to override styles for. Ironically, HN does a horrible job of this -- the HTML is not semantic, the use of tables is so egregious that even stripping the CSS out doesn't really remove all of the styling. The site is really messy if you want to override anything. So that HN uses a design that happens to more closely align with what you want does not make the site more respectful of your browser as a user agent. It just means that you and the designer(s) happen to like the same design.
And in comparison, putting `max-width: 45em` on a text column is not even remotely user hostile, it is a very simple CSS property to override -- especially for designs that use single columns because you can change that CSS property without even worrying about reflow. `max-width` is a default that statistically works better for the majority of users even on large monitors (I use a 32 inch 4K monitor and max-widths make text on that monitor easier to read). But of course, some people are different, and that's fine. Go yell at the browser makers to allow easier CSS overrides, or turn off CSS entirely, or install an extension that lets you add CSS to given pages or spend a weekend building an extension that strips max-width out of stylesheets for every website you visit, or customize Firefox's userContent.css file. There are options here. And if you had made an argument about those options, I'd be 100% on board. CSS for websites should be treated as a default setting instead of as a requirement and browsers should support CSS overrides more easily out-of-the-box.
But the idea that designers are denying user agency by not making a proactive design decision to present by default the specific format you want to read -- it's just ludicrous. You're not asking for user freedom, you're asking for designers to target your preferences instead of other people's. Those two things are not the same.
I fully agree that browsers should take a more active role in enabling the user to easily set his/her preferences, without them having to re-develop the CSS for each site they visit.
Browsers allow you to disable styles altogether, but as you note, most sites are horribly broken in that mode. Even Google's home page, which should be dead simple, is horribly broken with CSS disabled. I think if browsers had spines and enabled users to be more opinionated about styles, web developers would respond by ensuring their sites worked better without them.
That I completely agree with -- I've had a hot-take a couple of times in the past and I still hold to it, that regardless of what HTML was intended to be or not be originally, today it's at its best when it's treated as a user-facing rendering target, and a lot of the criticisms about HTML's ability to handle things like giant virtual lists are missing the point that you shouldn't have giant lists in your UX in the first place, you shouldn't have a DOM tree that lists out 20,000 options in a `ul` if you're treating HTML like it's a user-facing interface rather than an authorship format for the developer alone.
I'm still honestly a firm believer in the design technique of designing the HTML of a website before I start working on the CSS, and I know that a lot of people call that naive or say that it doesn't work... but I'm not saying that you can't revise the HTML later to fit a design, just that first I want to know what the content is and I want to treat the HTML as a primary rendering target, not an authoring language. I think there are a lot of benefits to that (one being that in addition to being more user-controllable and flexible, it also makes it much easier to do responsive design if you approach web design through that lens because page layouts become views of a unified block of content rather than completely separate isolated designs).
But I don't think including the CSS is where that process falls apart or that it's disrespecting the user or denying agency. It's like how if someone hands me a image of a block of text, my problem is not that the contrast in the image is too light or that it's the wrong color; my problem is that they handed me an image of a text document. If someone hands me a website that is so intrinsically tied to CSS that it's impossible for me to easily adjust column widths, that coupling is the problem more than the column widths.
Firefox does have some some great options around CSS control for partial or small adjustments but in typical Firefox fashion its best features are all hidden like Mozilla is embarrassed of them. I didn't bring up userContent.css to be dismissive; genuinely you should take a look at it if you've never used it before. I make heavy use of it for websites, everything from building grayscale modes when I want a website to be less distracting, to swapping layouts around. But it's a valid criticism that it's not user-facing and you need to go into advanced settings to even enable it. Browsers could do more.
Disagree; I don't want to have to resize the window each time I switch browser tabs. Sites should work independent of the amount of real-estate my browser is taking up.
Well, I tried setting `resize = "both"` on everything, but it was a bit of a letdown. It would be a neat experiment to have every element of every webpage be interactable (let's say resizable by dragging edges, and modify colors from the right-click menu) with edits persisting between visits.
Personally, I find HN difficult and frustrating on mobile: It's all tiny text.
Then again, I rarely read HN on mobile. It's just not the kind of stuff I enjoy looking at when I'm "on the go." Perhaps that's why they never tweaked the layout for mobile?
> ...leading to overly wide text in comments if using a full screen browser.
IMO, that's a bug, both with HN, and with the "default" styling in a browser.
PCs and Laptops exist. They have wide, high resolution screens and precision pointing devices. All relevant technologies support changing the rendering based on the display available to the browser. It's not that hard.
The problem starts when designers ignore these facts, and instead pop giant buttons, zero navbars, hamburger menus, and thin columns with low information density into the Webbrowser running on my PC with a 4k screen and a 120$ laser mouse.
Hacker News, old Reddit. Both work fine on both mobile and desktop. (Reddit started breaking features like double tap to zoom though.)
Yes, on a large screen you might have to increase the size. But a mediocre design you can recover from is better then being stuck with some meth addled designer’s unusable one.
Old Reddit doesn't work well on mobile devices at all. While it can scale the user interface, it's designed with a mouse in mind, making everything appear too small. I like using Old Reddit on desktop, but it's not user-friendly on mobile. For example, on HN (Hacker News), it's simpler; there are no images or different-sized icons. Even here sometimes struggle to tap the right links or flags, and I have to manually go to the settings to undo it. I'd prefer this over a poorly optimized mobile UI. However, optimizing the mobile web page would solve these problems.
Rotate your device to landscape and it's fine. I guess part of the problem is sites training everyone not to do that. (Quora's expert designers will happily throw content into the void of the iPhone's notch on landscape, inventing a problem that didn't exist in older designs, despite them having been created before the notch ever came out.)
Rotate isn't good solution it like saying not open site in full screen open it in half screen o is similar to mobile, I use mobile on the go and can't acomodate bad design whit behavior changes you need too change the design, so people can use it whiout needing to change everything.
The links are too close together on a small phone screen and I cannot tap them accurately half the time. This might mean the difference between upvoting/downvoting something, or flagging something instead of clicking on the context option, when I don't mean to.
HN is pretty great when it comes to desktop, though - simple design, no dark patterns, except for maybe the comments with lower score becoming unreadable, which is bad from an accessibility point of view and an odd design choice otherwise.
> old Reddit
Again - by far the best site when compared with the new version, which has bad performance on both desktop Firefox and mobile Firefox; in addition to lots of dark patterns, sometimes refusing you the ability to view a page if you don't sign in, in addition to nagging you to download their app.
It's still bad, though - too zoomed out, can't read anything without zooming in a lot with a phone and when you do, you need to scroll horizontally, which makes reading paragraphs of text a pain. Curiously, they do/did have a version that actually looked okay on phones (i.reddit.com, or something like that), but it doesn't seem to open anymore and redirects to the main site instead.
I think that once you go below ~400px of screen width, designing a decent UI becomes difficult regardless of what you do. It's so much easier to mess around with the meta viewport tag and offer a slightly zoomed out version, but even then you still have the challenge of making something usable across multiple platforms, input methods and so on.
I said that they're fine -- which they are -- not that they do every feature the best possible way. In any case where the initial rendering is bad, it's trivially fixable with your existing browser affordances.
On HN, yes, the arrows are small. And you can trivially zoom in whenever you need them to be bigger and more easily select one over the others. This is worlds ahead of mobile-first designs that lock you into one specific view that you can't modify.
As I said in the other comment: "mediocre design you can recover from" is much more pleasant than meth-addled design you're stuck with -- which about sums up HN/old reddit vs typical mobile first.
>It's still bad, though - too zoomed out, can't read anything without zooming in a lot with a phone and when you do,
Huh? New reddit doesn't do that any better, which can fit only a tiny amount of readable text on the screen as well.
I don't think so. It's strictly more work than designing a good UI for a single device which is hard enough, and usually more work than designing multiple UIs for different devices no matter.
A smartphone, iPad, and ultrawide monitor demand fundamentally different UX considerations. Generalizing across all of them, and in one codebase, demands a certain expertise or else everyone would be doing it.
I don't think it's a question of expertise; it's a question of effort (and cost). So it's a management issue; are we going to put the effort in to support desktops, or are we going to settle for a crap website? Because a website that doesn't support desktop is a crap website.
I always read that as "keep it simpple; stupid" as in: dont try and make the code too smart. Keep it simple and stupid and leave it readable. I never took it as a value judgement agaist the programmer's intellect.
Users on mobile can’t make their screens that big, and the average users on desktops don’t expect a webpage to work when they resize their browsers that small. Trying to make both work with the same design can have a negative impact on your customers, from both a usability perspective and by increasing page weight.
Instead, my advice is to create individual designs for each, share when it makes sense, but actively diverge when it’s good for your customers. There doesn’t need to be a single version of a page.
There are certainly trade-offs to consider which is one of the reasons UX design demands so much expertise no matter how many HNers dismiss it as some trivial practice (that they, conveniently, never want to do).
Maintaining N versions of your application has costs that aren't necessarily great for your customers either. In my experience it usually cashes out into one version (either mobile or desktop) getting all the support and features while they slowly drip down into the other versions. Meanwhile a responsive design can have the upside of forcing support and feature rollout for all devices simultaneously.
In practice, working in small and medium organizations, I have met very few UX designers. Instead I have met plenty of graphical designers that know almost nothing about UX design. I've been at places where I - as a backend developer - know more about practical UX design than anyone on the design team.
I think the reason why we have "bad mobile first design with awful desktop UX" is because very few of the people designing these experiences are UX designers.
I was surprised the article didn't highlight the horror show that is Vector22 at Wikipedia, a design so colossally bad that after three years of suck costs the only path to saving face was to make it the default theme for all users: "Mission Accomplished!"
I read that page, then browsed Wikipedia a little on desktop. It's a site that I use very often and I didn't notice anything weird. I could have sworn that it has been the theme of Wikipedia for at least 10 years.
I also checked if I had created some rules for that site in Stylus and uBlock Origin, nothing. For once I'm lucky that a change didn't destroy one of my workflows. One could say that if I didn't notice the transition they could have spared themselves all the work, or one could argue that they performed a perfect job.
Anyway, I get directly to the page I need from Google. I found several threads on Reddit complaining about the change and this one https://www.reddit.com/r/wikipedia/comments/10g2cir/im_prett... I see a different usage pattern "all I had to do was open the site and use the search bar. And then from there it was easy to get to the main page, current events, etc." The home page, current events? I'm sure I never heard about current events before now and about the home page, I know that there is one but the search bar of my browser is closer to Wikipedia's internal pages.
Agreed. I had the pleasure to work with talented specialist UX designers early in my careers, and their designs were really fantastic. They also worked really closely with the developers, both to understand the medium they were designing for and as a first line of feedback before things got to real users/clients.
Unfortunately some of the designers I've worked with more recently were primarily graphic designers without a UX background, and actually became an impediment to good design because they were given authority over it despite not really know what they were doing.
I think it's probably an unfortunate consequence of there being more demand for UX designers then there are good UX designers, and simultaneously being a lack of jobs available for graphic designers. And a lot of hiring companies not really understanding what makes a good UX designer.
Not getting it. They increased readability, by limiting maximum line length! That is a colossally good thing. Surely, that's like a graphic design 101 kind of decision. (It's a design rule that significantly predates "UX").
The issue at hand is that overly long lines reduce reading speed and comprehension of the content[1]. The optimum length for a digital line of text is somewhere between 66 characters per line and 100 characters per line. I personally use the 100cpl rule. For reference, this HN page has ~185 characters per line on my 1920x1080 display at default scaling.
I do actually remember un-minimizing my browser in order to improve the rate at which I could read the text of ur-Wiki pages.
And then they provided an escape for old men shaking their fists at the sky. Given a choice, I would, without hesitation, choose the new design.
People tend to dismiss UX 'experts' because frequently they end up being the ones who destroy perfectly good interfaces based on trends or similar. The principled ones who adopt a scientific approach are much rarer.
The ones who adopt a scientific approach are by far the worst.
Design is ultimately all about how things ought to be, an act of judgement, meanwhile science is wholly unsuitable for such questions, since it only tells us what is, which following Hume, cannot on its own lead to conclusions about what ought to be.
You get a sort of garbage-in-garbage-out effect if you apply science to a field like design, where it only serves to amplify your own convictions, as what is being fed into the scientific process as unquestioned assumptions inevitably fall out of it as conclusions.
At best you get KPI driven design, which is a vehicle for enshittification, not for building great design.
Can you relate that to specifics from the article? To my (admittedly non-designer) eyes it appears to be a great example of how science can be used to improve design, and I happen to agree with the findings presented, so I'm curious where you see this breaking down.
> The ones who adopt a scientific approach are by far the worst
I strongly disagree.
Design without considering all of the HCI research that has been done is what you call "garbage-in-garbage-out." We already know how humans perceive information, what makes things salient or invisible, and so on, yet the current design trends completely disregard that with flat UIs and trendy designs that have poor usability.
> At best you get KPI driven design, which is a vehicle for enshittification, not for building great design.
No, you just get trendy design, not usable design.
I'm not following. Science gives us good guidance on what works well or will let us achieve our goals, all the time. It's basically the whole point of doing it at all.
I took the poster as meaning UX that considers the results of, and perhaps even performs, actual user testing & observation, to decide what works and what doesn't. Like operating system vendors used to. I'll grant that "scientific" UX that's just incompetent (99% of the time) application of "telemetry" and A/B testing is awful. But that—and the other bad kind that's just trend-following, personal preference, and whatever will get the best reaction in a design presentation meeting full of non-experts—aren't what I understood as being advocated.
The good kind performs & pays attention to science.
What science doesn't give good guidance is how to select those goals in a vacuum. The goals at best end up being a version of someone's personal opinion, since there that's the only form of opinion we have access to.
Any opinions you get out of the scientific method were put in there by the person designing the experiment.
The core of science is iteration based on experiment and hypothesis generation. The scientific approach to UX is simply a hypothesis that a UX change is superior, and an experiment with a measure as to whether or not this is true. Yes, of course you can optimise scientifically for user-antagonistic KPI's (no need to invoke Hume, his point is true and also useless) but the alternative to not adopting a scientific approach is literally just opinion which on the whole is far worse (would you want your airline cockpit's UX to be designed based on a designer's opinion, or real scientific approaches to how people process information and intuit controls?). Of course one would take a good designer's opinion over some MBA-ridden process but a good designer is likely intuiting what would be validated by a more scientific approach anyway.
One, not all Reddit users prefer old.reddit (I do).
Two, Reddit aren't designing for users, they're designing for advertiser's to push adverts at users.
Wrt the second point, this means designers aren't designing to the brief you would give them. Like when engineers design obsolescence into a product (it's purposefully inferior for the end user).
Any idiot can see it's bad user experience to keep forcing a user to a design they don't like, but it's not for UX reasons that they do it. The trick is keeping UX good enough.
> Wrt the second point, this means designers aren't designing to the brief you would give them.
To extend that: note that the very companies that spend most money on UI, that hire the experts and pay them well, that set the trends for entire field of UX - are all companies whose primary business is user abuse - advertising, high engagement, etc. That's what they pay the UI/UX experts to optimize for, and that's what ends up leaking into the wider field - leading astray people who are trying to build things beneficial to their users/customers.
A great recent example is the Slack redesign that didn't improve any user flows and lowers the information density. And that activity badge with sticky notifications. (Shift + ESC is your friend here.)
You can’t even exit a search. And god forbid you click a notification while doing a search and have to click “back” 500 times to get to a useable interface.
I don't think it is an issue of "scientific" versus "unscientific"
It's really an issue that many UX designers don't know how browser rendering works, so they design static pages as if they were printing in a magazine.
Pixel perfect mocks are terrible for designing responsive UIs. Trying to build pixel perfect pages in a browser is impossible. Somehow these designers get through school with zero understanding that designing for web is different from designing for print.
It's 2023, I don't think that's really the case any more. If anything, designing for print is now the part of the discipline that has to suffer through "web-isms".
The reality is just that designers gonna design - and designing is often an unscientific craft, pursuing aesthetic values before practical considerations. Google and Apple designers are well-paid and experienced web-heads, and still they led us into a land of well-padded desperation.
It's 2023 and I am still explaining how responsive design works to new design grads that my company just hired so there's definitely some failure somewhere.
The cost need not be huge. Most of the costs should be content, and just the theme is different. However even ignoring that, two themes can be hard if you do them independently. However often only a few changes to one theme are needed to become acceptable, and that is good enough. This in turns means you can limit costs: spend 1 week on making a good desktop theme will already make a big difference as you get the worst offenders fixed.
People say SSR like it's a new concept, but this was how it worked for a long time.
Guess based on user agent (or other fingerprinting metric of choice), redirect to guessed site, provide user the option to override when the page appears, remember the choice in cookie (or local storage).
Though personally I think you can do a lot with responsive CSS if you try hard enough - that is my preferred option.
Devices should be truthful in the type of content they request. If your phone somehow tells my website that it’s a tablet or a laptop then you should reconsider the intelligence of who has developed your software
My phone often does tell remote sites it is a desktop because as bad as the desktop experience is, often that is the only way to get at something. (I don't want an app for my doctors office - I check it after my yearly physical and the rest of the time it takes up space I could use for another picture)
> Devices should be truthful in the type of content they request.
I think that websites should assume that devices are being truthful. I should be able to request the desktop view on my phone or request the mobile view on my computer. The former I can do sometimes, the latter I can only do with developer tools (and usually doesn't work because the website detects that I'm on desktop!). Browsers could add a header to switch to the mode in which the website dynamically readjusts based on actual device parameters like window size, but by default I need the view to be what I requested regardless of my window size and device type.
You know how Wikipedia has no table of contents on mobile? I made my browser request the desktop site by default so that I could see the table of contents and don't have to tap to open the article sections. (Unfortunately, Wikipedia changed its desktop view UI by moving the table of contents into a hamburger button. On mobile the desktop view forces me to tap the hamburger button to view a blocking popout of the table of contents, while on desktop the contents are automatically opened in a sidebar.) If Wikipedia had forced a dynamic design on me to restrict me to the mobile view on mobile, then I would've wasted time opening article sections to decide whether I wanted to open them in the first place.
One problem with two separate designs is deciding when to show one vs. the other. This gets especially tricky when people share links. Wikipedia, for example, has two different URL's: one for mobile and one for desktop. How often do you get links to the mobile version instead of the other?
And if you keep the URL the same but serve different output depending on the browser, then you get inconsistent behaviour between two different devices.
Nailing the UX for mobile and desktop is actually pretty damn hard.
I split my laptop screen vertical with usually a browser on either side. Occasionally a web page will render itself as if on mobile because it thinks I'm on a narrower screen.
I agree with comment above that it is very hard to make one website responsive to multiple screen sizes.
I think you're trying to make a very nuanced point, and I tend to agree that there are different needs for different viewport sizes. But I think it's important to note the difference between the design and the technology to build it. The technology should, IMO, as much as possible, seamlessly switch between the various layouts when it makes sense from a viewport size perspective. Definitely don't want, IMO, to deliver completely different sites based on device type/site from a technological point of view, we've tried that before and it isn't a good idea.
I also think one of the things good designers do is to take this into account, and make pages that are built up of components that work at various sizes, not just scaled up from mobile. In addition, a good designer will setup the page design such that it can scale up and down nicely from one viewport size to another.
So, while I don't 100% agree that you need "individual" designs for each, I do think you need a designer that takes the different viewport sizes into account and provides the appropriate adjustments for each. And developers that are skilled at then building those pages.
Not really. No media queries, no percent widths or non-pixel units, no margins (everything is padding or gap), no viewport units, etc.
I'm a CSS person who works in Figma every day and Figma absolutely sucks for responsive design and handoff to devs.
I wish I could just design in Framer or Webflow but those tools while being Figma-like are entirely catered to content websites and not to product design.
Design tools should render with HTML and CSS, not make the mistake Figma made in creating their own rendering engine they have to painstakingly recreate CSS from scratch with.
> It actually is very hard to design a responsive UX that can handle anything from the smallest smartphone up to ultrawide monitors.
A motherfucking website made with plain html, no css and no javascript is responsive and works everywhere. Any problems found when you go beyond this are entirely self-inflicted.
And that website does nothing. It’s just text, and it has one image that’s too small on a mobile view.
Now try to do the same thing with a complex app like your bank’s website, which needs to handle every type of account including credit cards, checking accounts, and investment accounts, rewards, and a travel/shopping portal.
> And that website does nothing. It’s just text, and it has one image
Which is pretty much what 99% of websites need to be able to display. That includes many sub-sections of web applications.
> Now try to do the same thing with a complex app like your bank’s website
Fun story, my bank has a website that works great on both my phone and my PC. On the one I can navigate it fully with one thumb, on the other it is information-dense and respects that I have a high precision pointing device available. They also offer different Apps for Phone and Desktop.
Those are the outliers, and winner-take-all ones to boot - they ate most other websites that "primarily deal in video and multimedia". Everything else deals primarily with text.
So what you’re saying is that the websites with the fancy videos and interactive content ate all the text-based websites, but that the customer is wrong and they’re going to the wrong websites?
Sounds like you’re the right person to convince everyone to buy cars with manual transmissions and crank windows. After all, they are more reliable and simple, and everyone is wrong for not buying them anymore.
I’d also like to know how you expect all of our serious business productivity apps to work as text-only or server-side rendered plain HTML web pages without being seriously compromised. Google Docs/Sheets/Slides? Jira? Google Meet? draw.io? Tableau? PowerBI? Gong? Notion? Slack? AWS Console? I honestly don’t even know how I would avoid getting fired if I only used text-only websites.
> So what you’re saying is that the websites with the fancy videos and interactive content ate all the text-based websites, but that the customer is wrong and they’re going to the wrong websites?
No. I'm saying that there are only few websites that "primarily deal in video and multimedia". They may take 9 spots in a top 20 list, but that 9 is like half of all such websites. The rest deal primarily with text (which includes formatted, rich text).
A bank is a bad example. The only thing we use bank websites for is to check our transactions and transfer money.
My business checking account has started offering partner promotions from the transfer screen and I’m tempted to switch to another bank because of it. Their developers and designers were tasked with delivering that component. At the same time they took away their mobile app and mobile check deposit because it was not secured properly.
Most bank websites and apps are examples of teams and organizations focusing on the wrong thing in my opinion.
A text column the whole width of your screen is readable on phones and tablets (portrait) but unreadable on notebooks and desktops. So columns are necessary… Also firm design usually is better if labels and fields are inlined. That’s just the beginning… you can’t avoid design decisions even if you want to favor functionality and content over form.
Really? On every team I've worked since the media query and bootstrap days, it's been normal to have a mobile, tablet, and desktop version at least. Tiny phone and ultrawide were bonuses, but having at least the basic three meant a somewhat usable experience for everyone.
These days it's even easier with MUI and similar UI libs that have responsive components built-in. Tailwind also makes it very easy to build your own.
Technically, that's correct (which means it's the best kind of correct).
But... I'd add that doing that well isn't easy. I frequently find cases where the mobile version simply removes features the desktop version has. And tablet version are very very rare. They tend to be either just the desktop or mobile version. Rarely is someone designing for tablet.
And that makes sense. Designing 3 different sites to all be the same feature-wise isn't trivial. Then you throw mobile apps on top of it, and suddenly it becomes much harder.
Can it be done? Sure. But I wouldn't say it's trivial to do it well.
>> It actually is very hard to design a responsive UX that can handle anything from the smallest smartphone up to ultrawide monitors.
Sure I'll agree it's hard, but don't web designers do their work on desktop machines? It seems like even if they are primarily targeting mobile, they must see the results on desktop right? There have to be some known strategies for dealing with it, and they must be aware of the problems. Right?
Even if we go with the "is not that hard" narrative, is for sure damn laborious. Also let's not pretend that all the intermediate sizes aren't also a requirement as the dynamic adaptation from one to another medium being zero effort in order to "just work".
Is it? CSS Grid and flexbox exist. What I do is design at the smallest screen size first (mobile first), then increase the screen size until it looks bad/breaks, then I set a breakpoint and use CSS to adjust things as needed. Rinse and repeat as many times as needed until it looks good at all screen sizes. It really is not difficult if you know what you are doing.
If you're designing a website to work on the smallest smartphone to ultra wide monitors you need to work on a more serious quality management strategy.
>It actually is very hard to design a responsive UX that can handle anything from the smallest smartphone up to ultrawide monitors.
Maybe the real solution is to treat a wide monitor as multiple mobile screens side-by-side. That is you give your user N-views into your app with no other coupling between them, almost like browser tabs. It sounds silly but I could think of worse solutions. Note: N would be equal to floor(laptop-width/mobile-width).
I'm sorry, if Wix and SquareSpace can figure it out for their templates, a site with dedicated UX designers should be able to figure it out, too. The smartphone is 15 years old, designers know what to expect.
The problem isn’t UX Designers figuring it out, it’s managers not wanting to spend time designing different breakpoints because they want the site delivered ASAP.
A lot of bad UX decisions come from bad management, not necessarily bad designers.
It isn't that hard if you know anything about modern CSS. Sure, for some people that hate writing front-end code, it's going to be a real pain. But for anyone that focuses on front-end, it really shouldn't be difficult at all.
We don't have to touch every class of device with our B2B product, but we do have to support desktop/tablet/etc. We decided to make a tradeoff in terms of aesthetics and keep the overall design as simple as possible. When you don't plan to test the dimensions between iPhone and iPad or concern yourself with foldable/esoteric devices, you should probably not get too elaborate with your design language.
Our app has 1 simple breakpoint @ 960px. Below this, we assume we are on smartphone and run with one column layouts. Above, we display the full width view. We combine the media query with CSS grid layouts to swap between modes. The specific number was chosen to allow full-size presentation in side-by-side window arrangement on a 1080p desktop (our most typical power user scenario).
Again, we are B2B and only have to tolerate US audiences. So, we have the ability to get away with far more than developers who have to polish B2C experiences with international audiences.
If I had to do B2C web properties and ideally support as many devices as possible, I would be more amenable to that adjective. Otherwise, I would say it is a normal amount of "hard".
How do you solve non-layout issues while keeping the site fast? Maybe you want your site to functionally behave differently, but don't want to implement client-side rendering.
Same effective functionality between touch-enabled and desktop devices. The main differences are in certain edges. For example, on devices with integrated cameras we present extra options for acquiring photos whereas on the desktop w/out camera, you get a file/browse option instead. 90%+ of the javascript in our app is used to normalize device-specific I/O quirks. The rest is to do things like disable form elements when the form is submitted.
I'm sure the people who complain aren't the ones with the smallest smartphones or the ones with ultrawide monitors with a maximised window.
Just as an example - Look at Google Drive in a regular laptop / desktop browser. All the relevant and frequently used actions are behind menus and icons.
The entire point is you don't have to design one UX for both kinds of devices. The screen resolution is an OK proxy but there's buttons in every mobile browser for requesting the desktop site so obviously there's more reliable ways to tell the webserver which kind of device is requesting the site.
And this site quite fittingly has one narrow and centered column with huge left and right gaps.
Otherwise I think the majority of windows laptops now have touch screens, so while they still have a pointer based input most of the time, touch friendly design is an advantage for the majority of the users.
It would be nice to have specific dedicated designs for all cases, but I am sympathetic with how much of a challenge that is.
Not trying to detract from your point, and maybe I’m “out of touch” but I don’t see hardly anyone but a rare few folks actually using touch screen laptops.
I see many people with laptops, but other than one person I know who exclusively buys Microsoft Surface laptops, the average laptop user I know is just typing and clicking away like normal.
How many folks actively go looking for touch in their laptop? I keep hearing about it on YouTube reviews, but even in families with kids, the kids don’t even use the touch features even if the laptop supposedly has it.
I’m just amazed how much “touch on laptop” comes up and I quite literally never see it in reality.
Well.. I've been using touch on my laptops since the start. My current laptop is a mini asus "tablet pc" with detachable keyboard. When I'm just web browsing I detach the keyboard and use touch. But even on normal laptops I got from work I'd prefer touch for many things like scrolling over the built in touchpad.
Especially when I'm using the laptop as a portable device on my lap, in a plane or on a bus.
I have to admit I don't use touchscreens that much when I can put a laptop on top of a desk. But when I'm sitting at a desk I much prefer a desktop pc.
It doesn't need to be the best though, just needs to be good enough for specific use cases. Same way pen support on the iPad is great, though not everyone will use it extensively nor have it as their best way to do anything.
I have actively gone looking for a way to disable the touchscreen on my laptop, because I explicitly never intend to use it - who wants to look at smudgy fingerprints? It only gets activated by accident and I'd rather not have it at all.
I know some disable the touchpad to not have to bother with palm rejection and accidental touches at all. Same for shitting off mouse input when the touchpad is used. And so many other combinations.
Started uni recently. My friends have those. They don’t have or use a mouse. All they use is touchpad and the touchscreen. Well, to be honest, a lot of them don’t have a touchscreen yet still don’t use a mouse.
I saw it a bunch with family members. They're not using touch as a primary interface, but more as an alternative to click a button in the middle of the screen or select stuff on the laptop screen wen their mouse is on their external display. I'd suspect there's many "occasional touch" users, in particular on laptops where the trackpad is not great.
But yes, people going full hog on touch usually have Surface pro or Yoga like devices in the first place and won't be an average user. And people used to point fingers at their screens tend to hate it now that it actually reacts.
Most Windows laptops definitely do not have touch screens, and most(?) users also tend to use a desktop monitor most of the time (the only ergonomic choice).
The opposite to your 4K screen situation is also true - many modern sites have so much whitespace that I have to zoom out to 80% to use them comfortably on my old laptop with 1366x768px display.
> The problem starts when designers ignore these facts, and instead pop giant buttons, zero navbars, hamburger menus, and thin columns with low information density into the Webbrowser running on my PC with a 4k screen and a 120$ laser mouse.
And using phones as a 2FA device. A giant, relatively immobile device is a much better 2FA device than something that is easily stolen.
Another problem is designers working only on 4K/5K screens and not taking into account how little of their design fits on a FHD screen that a major part of the desktop population still uses.
Yep, I see this in both directions. People are still of the mindset that "desktop" means a single resolution and aspect ratio that everyone uses. That wasn't really the case in the past, but it's really not the case today.
- On Linux, the assumption is that everyone has a 1920x1080 monitor, so if you get a high resolution 13-inch device like a Surface suddenly half of the apps are unusable because everything is scaled so tiny, and the apps literally just do not know how to handle the aspect ratio.
- On Web and in popular design studios, the assumption is that everyone has a full 4K mac and so everything becomes larger and spread apart; you load them up on a normal monitor and everything becomes cluttered and the interface of the app starts taking up more room than the content you're looking at.
Test your apps on multiple resolutions y'all, and for the love of everything that is holy if you're designing a desktop app, please add button density and font size controls to your settings. Some weirdos like me even use multiple monitors of different resolutions and pixel densities hooked up to the same computer at the same time, so being able to adjust on the fly or handle fractional scaling is kind of a big deal for apps that I use. Standard resolutions are a myth.
Caring so much about screen resolution has always seemed strange to me when not everyone maximizes their browser window, anyway. My browser windows are generally close to square.
I think that differing device resolutions and aspect ratios in some ways forced designers to think about things that were always worth thinking about but were easier to ignore. I use a tiled window manager, I care about whether your desktop site is responsive even at minimal widths because I tile windows. I also have a touchscreen monitor hooked up to my desktop and I like to be able to use it. And sometimes I also full-screen windows on a 32-inch screen and use a mouse-and-keyboard. If a desktop site accommodates me in all of those scenarios, it'll probably be fine on a phone as well.
But it was so easy in the past to just ignore that and treat PCs like they were uniform devices used in a uniform way, and phones meant that you suddenly had to care about what a website looked like in a single-column view, you couldn't just tell your users to maximize the browser window. Unfortunately, rather than taking away the lesson that design should adjust to nonstandard situations, layouts, and input-modes that can not be fully predicted or tested for in advance -- instead developers took away the lesson "okay, now there are two standard devices we have to support: mobile and desktop."
The distinction isn't real, there is no hard line between a desktop and a mobile site. There are mobile tablets that are big enough that they should be served a desktop layout, there are desktops with touchscreen displays, there are monitors that are 3/4 ratios. And there never was a standard and computers were always like that, but it's an understated truth that every developer and every designer would secretly love to develop exclusively for consoles with integrated screens and one input method, and developers often kind of behind-the-scenes somewhat resent the fact that general computing is an open ecosystem with diverse devices. So designers often just treat computers like they have two completely discrete interfaces, or at worst decide that because they're not targeting one of them that they now have permission to target exactly one resolution and size again.
Sometimes that takes the form of designing "mobile only" like the top-level comment talks about and calling desktops a dead platform. Sometimes it means designing desktop only and getting mad that somebody flipped their monitor vertically instead of horizontally and now wants the ability to move a side-drawer to the bottom of the screen.
Actually, I think what happens is that the team adopts a "mobile-first" policy, which is reasonable, since most visitors wil be mobile. But they don't follow through with the "desktop-after" corollary, and they don't engage with the "progressive enhancement" philosophy, because that gets even more costly than simply having two websites.
I find phones impossible to use as web browsers. My eyesight is too poor, and my thumbs are too fat. I use phones for making phone-calls and for trading SMS messages; if I need a website, I use my laptop. But that's just me.
I think the real problem is that mobile phones make awful platforms for browsing websites. Native checkboxes and native select-boxes are often unusable, so developers use "frameworks" <spit> that replace them with Javascript monstrosities. Because that all depends on plugins and code, each website ends up with it's own idiosyncratic UX.
I think the correct solution is for phone makers to deliver platforms that can render HTML so it's useable. Then the only problem for devs is create responsive layouts, which isn't that hard.
Designers usually not the problem here. Most are well aware that rendering should change between different types of devices and displays, they use these website and devices too!
The problem usually is the resources and time available to implement such designs. Most of the time the devs simply don't have the time, desire, or even ability to implement more advanced responsive design, so designers will design what will actually get made.
It takes maybe 2 hours for someone experienced to turn a desktop layout into a mobile responsive layout for all screen sizes using media queries. Longer than that usually means less experience.
Sure for a content-site template, blog, or something else fairly basic. This is not at all the case for things like art-directed super-custom designed sites like magazines, fashion brands, museums, etc, OR highly complex interactive SAAS web apps like the ones I work on. These have lots of unique considerations like complex animations, layered menus and controls, optimizing for change from mouse to touch interactions, handling the higher rate of people who use zoomed text on mobile devices, adapting to device safe areas in portrait and landscape, etc.
I am a designer and HTML/CSS coder so I am aware of the challenges from both directions.
Your use case sounds very much like an edge-case in websites. Of course highly customized animations and weird out-of-the-ordinary UI elements are going to be an extra pain in the ass. I have no doubt there are customer requests that simply can't be fulfilled with HTML and have to be done in WebGL. The fact is, most sites are "fairly basic" and only really need HTML, CSS, and a little javascript to accommodate the vast majority of use cases. I'm glad you're doing complicated things, but that doesn't change the reality of most web developers.
It isn't an edge case in the SAAS world, it's just that the majority of SAAS tools either don't implement mobile, or don't do it well. Every single SAAS company I have worked for in the last decade has had complex web apps that required very involved HTML and CSS work (and a dash of JS) to get them to work well on mobile. Additionally very few of the front-end or full-stack devs on those teams actually knew HTML/CSS well, they were all React/JS-first.
Sure the majority of websites on the web aren't SAAS tools, but the nuances of mobile vs desktop layout described in this article don't apply so much to such simple content pages.
Most SAAS tools aren't really used on mobile devices. Laptop or desktop is the expected use case. You're still dealing with an edge case if you need to have a "complex" SAAS tool that is mobile friendly.
About 6 years ago, the company [0] that owns most of the local newspapers in my state did a "mobile first" redesign of their website ... which actually was a "mobile ONLY" redesign.
It was so, so bad it was almost totally unusable on anything larger than a tablet. It made it virtually impossible to read articles on a desktop because everything was so spread out, the font sizes were all messed up, navigation was hidden in a tiny little hamburger at the far upper right of the screen, and a bunch of other problems. But what was wild was how easy it was to fix them. I ended up writing a small (maybe 100 line) CSS user style that fixed almost all of the problems.
They did eventually "fix" the site so that it wasn't as bad on desktop.
100% this. The amount of times I get given a mobile wireframe then subsequently brushed aside when I enquire about desktop is unreal.
Our work flow often ends up: get design > ask for desktop > told to ‘use best judgement’ > uses best judgement > get a load of amends as best judgement wasn’t what the client has in mind > repeat.
Don’t even get me started on the mythical black hole that is the tablet screen. It’s like designers have forgotten that they exist and people use them at times.
These days we're actually lucky to get any desktop experience at all. Look at e.g. Instagram Threads. The response to "desktop is hard" and "most users use mobile" is often now "only weirdos use desktop, don't even bother".
I start with desktop layouts, create that, then make it responsive for mobile devices of all sizes. I'm often only given a desktop design for a page, and I'm fine with that.
"Mobile first" is not the right way to approach the problem. I dislike desktop layouts that were obviously "mobile first" and only look like a wider version of a mobile layout. It's just the wrong way to do things.
It's very easy to use media queries to make all the content of a desktop design fit into a mobile layout. I really don't understand the disconnect about this. I manage to get full functionality in both desktop and mobile devices of all sizes, but others cry "mobile first!" like if you don't do it that way, then you're doing it wrong? It's nonsense. "Mobile first" almost always leads to sub-par desktop experiences, and that's a shame.
My favorite challenge is a design meant to be printed on a single page. The page also has to load on desktop and mobile browsers. With the printed page, the content absolutely cannot overflow even though it's dynamic content and could have text of any length, or list items of any length (scaling is used to a point, but often some items must be omitted from the layout). So in this case, it's absolutely "print first", not "mobile first". And yet I manage to make a perfectly good mobile responsive layout and a desktop layout out of a "print first" page.
The reasoning behind mobile-first was exactly what you say is "easy" and I disagree - it is not always "easy" to shrink contents of complex desktop layouts into a mobile one. Mobile first helps figure out the simplest possible version of a design. And whether building mobile first or desktop first isn't really a design choice, that's a development choice, and either way of building a site (as long IMO as you don't mix/match) is equally valid) and the same goal can be accomplished from a technical perspective.
I agree though, that doesn't mean we need dumbed down desktop layouts or scaled up mobile versions, it just means we need to consider both and design accordingly. Mobile first is fine as the starting point, there are a lot of valid points to that design paradigm. But that is just the "first" part, then there are the rest of the parts to account for all viewport sizes.
I get why they are used on mobile. If you only have room for content, it makes sense to tuck actions away into a hamburger menu except for a small number that you assign to tiny little hieroglyphs. Fine. However, if you have space, this is a terrible way to use it. At best it adds steps, at worst it invites experimentation and disaster to figure out what the heiroglyphs do (which wouldn't be so bad if undo worked but we've apparently decided undo is fine to break too). Like the Apple HIGs used to say, on Desktop you should want to get the most common actions out of menus and onto labeled buttons so that users can answer "what can I do?" without playing hide and seek. Undo should be baked in from the very start (it's hard to retrofit) to reduce the consequences of experimentation.
Unfortunately mobile design has taken over so completely that even on apps which will be used almost entirely on desktop, even on apps with an internal advocate for Desktop design, UI designers go for the hamburgers and heiroglyphs and broken undo because it's standard these days. Sigh.
Oh, and modals are back with a vengeance, but I need to stop here or my blood pressure is going to get unhealthy.
I don't think there's any excuse for hieroglyphs. Even a low-end 5 year old phone like the moto e4 has a 1280x720 display; there's plenty of pixels available to label the icons. Hieroglyphs are a "we hate our users and want them to know it" first design.
Hamburger menus could also frequently be done away with when you look at how many options they have. Like Gmail's app has them when it could fit the icons across the screen as a bar. And it's hard to argue that real estate was important since they put in a bottom bar for chat, video, and spaces whatever that is.
I deal with some legacy web apps and ticketing system at work. They could use a hamburger menu or two. 10 buttons, 15 tabs, and a million inputs most people don’t use.
> Hamburger menus could also frequently be done away with when you look at how many options they have. Like Gmail's app has them when it could fit the icons across the screen as a bar.
Just cracked open Gmail to check this. In the hamburger side menu, there's 18 items not even counting labels. No shot you fit this across the screen as a bar.
I was specifically looking at when an email is open. There's 9 menu options. Move To and Change Labels do the same thing, and it has a UI element on screen already. There's also Mark Important which is apparently different from star. Consolidate Move To/Change Labels and move help to the bottom, and everything should fit on top.
Then there's another menu below that with 8 items, 4 of which also already have UI elements. Give the other 4 icons. There's plenty of space on the show pictures line.
You need a menu for label filtering since the user can create many, but let's look at settings. There's a mostly blank screen with a ... menu with 2 options (why is it sometimes hamburger and sometimes ...?): manage accounts and help. Just put them on the screen. Now look at general settings. Enough stuff that I have to scroll, but for some reason 4 of them are in a ... menu. Two are the same as the last screen, with clear search and clear picture approvals added. Now go back to settings. Suddenly settings has all 4 options in the ... menu! The hidden options on the same screen are different depending on where you were before, when they could all just fit on the screen.
In general, scrolling is much faster than clicking on an icon. Lots of web UIs (e.g. navigation menus) could benefit from just putting the links at the bottom.
Pixel density isn't the problem, physical size is. Phone screens are small and many people have poor vision. Some even scale up the contents of their browser 25% or 50% or even 100%.
The more text you have, the more difficult it is to ensure a usable UI on small screens, let alone a good one. Don't be upset about the use of symbols instead of text, but about the use of bad symbols. Nobody needs the "play" button on a video widget to say "play" - they know what the right-facing triangle means. (Ironic because I don't know if it makes geometric sense to even say the triangle has a facing, but as a symbol it's well understood.)
An unlabeled bespoke icon is useless for everyone though, which is strictly worse than text being unhelpfully small for people with uncorrectably poor eyesight.
Put the text below the icon in whatever size you can. It's a strict improvement in usability.
I like having greater content area by default, and the text next to an icon in the Gmail Android app is nice too. (The spam button, with its explanation mark, could easily be mistaken for an important button otherwise.)
It's one of the reasons I prefer how Vim and VS Code look over Intellij and Visual Studio standard. Let me better see what I'm focusing on without distractions (the content) instead of shoving a gazillion buttons on your UI in the default view.
Edit: I was too harsh about Intellij I think. The old UI I was thinking of doesn't look bad in my opinion, but I still think I would have enjoyed my experience with Visual Studio more if it had a stronger focus on content (the code) visually.
I agree hieroglyphs make discovery difficult. But I believe designers like them because they allow for consistent design across different languages. E.g. accommodating for German localisation can be difficult.
Yep. Real localisation is too expensive, English-labelled buttons will get you shouted at for being noninclusive (even though, speaking as an immigrant, a labelled button that I can translate with a browser plugin is much nicer than an inscrutable icon), so everyone is in this pit of awfulness.
I built the nav bar at the top of my website[0] to be scrollable if the content doesn’t fit horizontally. I’m slightly concerned about users not realizing there are more options to scroll over, but I prefer it to a hamburger menu that has to open and cover the content since you can see every option and read the corresponding word. No need for any of that when visiting on a desktop however.
Yeah I only run into the issue when using an iPhone mini with an increased font size. But it’s ready to go if I add more routes. If the list grew to be too large, I would switch to a two-column layout on my homepage for the primary points of interest.
I’m a big fan of collapsible table of contents. That design paradigm allows for the higher level to use a word to indicate what it contains and then can open up to a list. But it does really depend on the type of information conveyed. I can currently get away with always avoiding hamburger menus but that might be tougher for something like a banking app to avoid.
I think the biggest opponent to what you're advocating are new users, they are so easily intimidated by too many things on the screen. These are the people that dominate focus groups and so designers seem to have wrapped themselves around the axle over this one (terrible) rule.
Hieroglyphs sums it up so nicely. Lol. I'll also add hidden, context sensitive options to that list. I like having options that are disabled (aka greyed out) if they're unusable because at least I can see there's a possibility to do something if I get conditions right. Instead, modern designs will hide those options and, if you don't know the magic conditions needed to expose them, you'll never see them.
An example of this is Ubiquiti with their Unifi stuff. If you go to manage switch ports, the page they give for that doesn't have an option to "Select All" ports. You need to select at least one port first, and then the "Select All" option magically appears. So not only is it hidden, it gets the context wrong. Think of having it as a disabled checkbox. Everyone would immediately realize the context is wrong because having the "Select All" checkbox disabled when no ports are selected would be obviously dumb.
I've been seeing this more in content, and also apps that are "browsers" really - some view control that have a mobile & PC/MacOS equivalent - like they are intentionally formatting everything for portrait type display on mobile
My devices are a literal ton of iOS ones, and then 4k and a 2560 × 1440 display which I use most frequently lately.
Tons of whitespace, oversized text everywhere and incorrect use of Z-index are some of the hallmarks of this mobile-first design.
What you really want is two apps, completely different UX's and its not worth the effort more times than not. No one is going to Herman Miller's website for example and not buying a chair because they don't like the desktop web app experience.
They might pass though if they can't get the site to work well on their phone.
Don't forget contact too. It was difficult to find contact information on some sites. I remember 10 years ago contact information are usually at the bottom of the main page or in the nav menu. Now, it took some soul searching to find it where they buried it in the submenu. Sometime I usually use Google Maps to get the address or phone number since some site don't make it easier to find it
The trend that I have found to be truly aggravating is restaurants recognizing that sometimes I just want to look at the menu. I don't want to place an order. Don't make me tell you when I want to pick up my order or where I want it delivered. I just want to browse and make a decision later.
> I refuse to go to restaurants that have QR-code menus that download a PDF with unusably small entries.
I either go on the restaurant's website directly to find the menu or ask for a physical menu. I've never been tripped up by that. I understand I'm still rewarding the owner for their bad choice, but I'm not going to force my friends and family to get up and leave a restaurant we all wanted to try out because of it.
> I refuse to go to restaurants that have QR-code menus that download a PDF with unusably small entries.
It gets worse. I've been to a restaurant in Silicon Valley where not only were the menus reached through a QR code, the linked page was not the menu. It was the onboarding funnel to get customers to sign up for a food-delivery service. You had to sign up to get menu access. Then you could order online. Dine-in was just ordering food delivered with a really short delivery trip.
That's awfully amazing in a very Silicon Valley way.
Here in Seattle we have a few restaurants that use a similar model, you scan a QR code and order food online, only it's "delivered" to your table. But they don't need any account information from you, so it's pretty convenient.
It's a small Asian restaurant in a strip mall. They'd signed up with some Restaurant As A Service provider which handled the ordering, both remote and local. This put them in the position of an Uber driver - they were just gig workers for the app.
> restaurants that have QR-code menus that download a PDF
Oh yes, about half of the time when a restaurant requires me to scan their QR Code to read their online menu, it's a 20 MB PDF - not a responsive web page. And the PDF usually has multiple columns of text, which means I need to zoom and horizontally scroll (generally a big no-no in web design). I'm a technologist at heart and I find this implementation so needlessly bad, and an extremely poor use of technology. I would prefer a no-bullshit paper menu instead.
You and I live in completely different worlds. I will absolutely not complete a purchase if your website is unusable.
In fact, this happened last week--I was trying to purchase a plane ticket and the animations were so excessive and poorly done that it obscurbed a form field that made it impossible to book the ticket. I bounced and booked a ticket from a competing airline.
The prissy prima donna web developers in this thread would have you believe that all users are just like them and obviously bounce from any site that isn't perfect (as defined by them of course). In reality most sites are shit and people just suffer through them anyway because something they want is on the other end.
Yeah, as someone who can't use touch screens, this is a serious pain point in a lot of my web browsing. Mobile first design is an accessibility problem.
Dark mode requires visual content rich sites to have two sets of assets. Example would be a marketing chart with a white background needs to have a corresponding asset with a black background with different color text and bars.
The visual design problem mirrors a problem with the organization producing the website. Before mobile, a website was the entire online presence of a company; every subdivision within the company had a presence above the fold. The culture and conceptual structure of web development developed around this concept. As mobile mandates pushed things below the fold or off the site entirely, web teams found themselves unprepared and have adapted awkwardly, as this article shows. Mobile app teams never had this cultural baggage, which is one of the many reasons native apps are perceived as superior.
The irritating thing is that it is neither mobile first nor desktop first. Most websites I come across are designed and built for desktop but using a mobile aesthetic.
The problem sadly isn't even mobile-first vs. desktop, but rather designers who still haven't figured out that the web is dynamic content that should be allowed to flow according to the user's display device size and shape. It's not and never has been a static medium like paper. It's not limited to a specific size and shape like paper, and should not be treated as if it were. Web "designers" should not be trying to force the content into any specific size or pixel resolution, as there's just too many different resolutions of screens and width vs. height layouts of those screens to ever be able to cover them all appropriately without adapting to the idea that the content must be able to flow accordingly. It also severely harms accessibility for folks with vision issues who might scale up their fonts to compensate if doing so causes the content to break in horrible ways that make it unreadable.
The designers probably know that, but it costs money to design for 2 platforms. So they pick the 2 biggest platforms for non-hackers... Android and iOS...
You're not designing for two (or more) platforms at all. You're designing for one platform. The Web. It's built on some pretty well defined standards that a ton of folks seem hellbent on breaking to force the web into a shape that it simply isn't.
They didn't mean platform in this way. But in the sense that small touchscreens are fundamentally different than big monitors + mouse & keyboard. That's why anything that is not the simplest website should use two different interfaces. (Also, apps don't belong in browsers.)
Some designers can use Figma's equivalent of grid and flexbox and some can't. What's hard is implementing all the shades of gray between two pixel-perfect designs because the designer didn't do this basic work.
Yeah, it's not really "easy to say stuff like this" because everyone who thinks they know better than actual real honest-to-goodness web designers will instantly want to argue with you to the bitter end why their fantasy web design has to be 100% "pixel perfect" layout exactly as they envision it on every single device or browser ever invented. It's a huge part of why I'm no longer a web designer. More of my time was wasted fixing literal one pixel differences in layout between browsers (and browser versions) than almost any other part of the process.
I haven't encountered a "pixel perfect" designer for at least 15 years now, if not more. Virtually every single UX designer I've worked with provides flexible designs that scale with screen size.
In my side of the agency world there are a lot of designers who design UX that aren't UX designers. A lot of them want started in print and expect pixel perfect designs/don't understand the need for breakpoints. We had a client who got on our case about a design being a half a pixel off. That sounds like a joke but it genuinely happened.
I have worked with one of those freaks last year. She argued that every block had to be exactly like it was on Figma, and she once sent me a screenshot with a little ruler drawn on it, to show me a 3px gap. It was such a waste of time and energy...
They said the people who claim to know more than actual designers will want it pixel perfect. So i.e. The designer knows pixel perfect is a fallacy, the client doesn't care and wants a pixel perfect match of their figma document on their personal laptop screen.
Solution: make that only for that specific viewport, ignore it for the rest. Hard unreasonable clients are not so common as people depict them to be, at least in my experience. I do have a spidey sense after years of client work in sorting them out right away, maybe, but even stupid clients are reasonable if you’re able to make business points about their requests
There is pixel-perfection and 'pixel-perfection'. One is a pointless fight against the nature of the medium while the other is love for the craft, sophistication, and actually giving a fuck that something isn't needlessly 2 pixels off of where it should have been. A certain attitude that will show its mark throughout the UI.
I'm not UX person and I don't know whether "pixel perfect" and absolute positioning requirement come from clients or designers on average. I'd guess it varies by organization, industry and whatever.
But it's worth being clear that mixing such thing with flowing text and graphic is where things get hard. Html 1 had flowing text in the 90s and you can still do that.
Moreover, all this is related to overall user hostile designs. Organizations broadly don't want their pages to be neutral streams of information but want to control a user experience that nudges people this way and that and fixed are important to that.
But ... we did, and do. It's called HTML. It allows you to send back structured data in a client-agnostic way. It's just that it got bastardized to the point that people will send the data in a way that only certain clients can intelligibly render it, and then, only in a way usable to people without certain disabilities.
It's not just a technical problem, but the social problem of how you get people to keep using that API, and not extending it, and not breaking it in favor of some different purpose (like ads)
Whatever API for web data you propose, I can tell you exactly what will happen to it:
1) Initial clients are geek-designed and geek-friendly, and render the data intelligently.
2) This API gets popular for not having all the cruft.
3) Some genius discovers they could add some cutesy visuals and effects if only the standard were extended, and targets the clients that handle these extensions.
4) Eventually, only those clients are cared about, and you can only make sense of the data with those clients and if you don't have disabilities.
If you want to make progress, figure out how to eliminate that dynamic.
"It needs to look exactly like this PSD file I made!"
You get the same with some native UI designers. They kick and scream until you've got some custom widget that precisely apes the Photoshop layer effects. Then kick and scream again when they make changes that take non-zero time to rebuild with that custom widget.
Honestly, this is not a technical issue but rather a communication and “positive non-narcissistic persuasion” one. I think I’m a meh to ok designer and an ok frontend webdev, but my strongest selling point is communication, with clients praising that aspect of my work more often than I would have ever expected. Designers might care about pixel perfection, but their bosses rarely do. If you have engaging, respectful, data-driven, and business-oriented points to make and you communicate them clearly and effectively, you’ll be surprised how many times you can change someone’s mind. Even designers’ minds, because they don’t live in a vacuum and they know that shipping is relevant to their own interests.
Tl;dr invest in effective communication skills as much as you would invest in more technical knowledge.
It's literally 120 characters to make a website that flows on any (reasonable) screensize and adapts perfectly.
Modern webdev is just throwing frameworks at self-caused problems.
(I'm exagerrating of course. But most websites are just about showing text, maybe with some images every now and then (news sites, reddit, hackernews, google, come to mind). For those websites this is certainly true).
> flows on any (reasonable) screensize and adapts perfectly.
No it doesn't. It's this pointlessly narrow column in the middle of my screen surrounded by arces of whitespace. If I wanted narrow text I'd make my browser narrow. Looks like the result of some designer fucking around.
But that is the job. The job of developing on the web is developing for a platform where you do not know the size or format of the display or what the inputs are in advance.
The job of a UX designer on the web is to consider this kind of stuff and to build a design that's very reactive to evolving displays within the demographics and market segments that the client wants to support. If that's not happening, if the CSS people are just getting handed static designs and being told to figure it out -- the problem is not CSS or the developers, it's that the designers building those designs are not good at their jobs. And there are ways to make this easier: notably UX designers involving the CSS department in the design phase, and/or making a point to always lay out the contents of the page without styling in a hierarchical way before making decisions about how to present that content.
But a lot of programming is hard. It's hard for me to write maintainable Javascript that doesn't fall apart if a project goes over 100,000 lines of code. It's hard to document methods. It's hard for me to write code that does complicated things that can work on low-end machines. These are skills that programmers get better at over time with practice. Responsive design is the same; it's just another skill to learn.
Imagine trying to shoot a movie and having the cinematographer tell you that it's hard to frame everyone in the shot since they don't know exactly where the viewer will be looking, or the sound mixer telling you it's hard to balance dialog and sound effects so everyone is audible without it being noticeable that they're muting background audio. Or a recorder telling you that it's hard to master a pop song given that everyone has different speakers and sound profiles on their headphones. Imagine you're building a car and the designer tells you that it's hard to make sure the controls can be reached by people who are different heights and weights.
On one hand, yes it is; all of that stuff is very hard. On the other hand, yes, that is also the reason web UX designers and developers get paid money; because the job is hard and requires training and expertise, and designing a website interface requires more thought and intentionality and planning than is required to make a PDF.
>It's not and never has been a static medium like paper. It's not limited to a specific size and shape like paper, and should not be treated as if it were.
I often get "print first" page layouts, created from dynamic data that can have varying amounts of content. These pages also have to work in mobile and desktop browsers and look good on all of them. I don't find it to be that difficult. Sure it takes a little longer, but it's what the job requires. Media queries make it all possible, as well as a little bit of javascript.
Designing good UI for such a varied platform as "the web frontend" is incredibly challenging. They might be at 300px wide, they might be at 1920px wide, they might have a mouse, or they might be using all touch. Or both. Or neither.
I work with agencies coming from print and oh boy, don’t get me started.
At the same time it’s a freaking mess even for someone who’s been doing this for a long time.
My go to strategy is now to address concerns as much as possible by being involved in the design phase, as I have a design background, then implement and ship and then always have a “tell me everything that’s broken in obscure viewports only 1% of people use” and fix those live with CSS patches and viewport specific media queries during review phase or even live.
Vanguard has been guilty of this as well. Its recent site redesign has been all over the place, and sometimes leaning heavily toward folks using its phone app (not that its phone app is very user friendly either; for example, checking what orders one has placed by account is impossible). It used to be that the website has a table view that shows almost everything I need to know about my holdings. Now, it takes a few clicks to find that info and even then, the layout is so sparse (mobile optimized) and hard to read.
Maybe I'm getting really old and just like to complain about this because I'm not very much used to this phone-oriented UIs.
I think they also eliminated some of the color hierarchy in favor of just making everything big black text swimming in a sea of white. So it's a little harder to see which pieces of text belong together.
Vanguard's website has always been a mess, to be honest. It's really hard to figure out how to do some basic stuff like transfer money.
I figure their website is so bare bones because it reflects their low cost ETFs. They'd rather have a crappy website and cheap ETF's than a fancy website with slightly higher cost ETFs.
I’m less concerned with brochure and ecommerce sites. But mobile first design for productivity sites and tool interfaces drive me crazy. Who normally accesses these tools from their phones?
I recently had the misfortune of having to use a background check app that was mobile only!
It was a real pain to enter past employer and residence names and addresses on a mobile keyboard, but even worse when it came to dates, because the date picker would only scroll a month at a time, starting from the current month and year. To enter my birthdate, I had to tap ~550 times.
(I was kinda tempted to file an EEOC claim, since the broken date entry has a disproportionate impact on older workers, a protected class. But that's not a great way to introduce yourself to a new employer's HR department.)
Rightfully so, what’s in it for them to spend more resources on such a niche group?
Desktops/Laptops are for gamers, workers, and programmers. This isn't 2006, people don't read articles on their desktops in leisure. If they are it's because they were also doing one of the three use cases I mentioned.
> Desktops/Laptops are for gamers, workers, and programmers
Nah. Like, I'm all of those; but I very rarely play games these days, and I've retired from programming. But I strongly prefer to use a laptop to browse; I never use a mobile browser. My eyesight is too poor, and my fingers are too fat.
Think a lot of the issue is the difficulty grasping what size the actual screen is. I get webpages on my 1080p monitor where everything is just far too big but I guess as far as the code is concerned it has limited knowledge of whether the physical size of the screen is 24" or 5"
Shit like this makes me want to learn more about using accessibility features of my browsers. I'm far from going blind, but I don't want to scroll through the angry fruit salad of alegria art, huge stock images that take a huge amount of screen real estate and the important bits being tucked away probably somewhere in the bottom.
"Minimalist design" and it still takes multiple megabytes of bandwidth to show a pretty nothing.
I'm using Reader Mode or an equivalent whenever I can. If a site cannot be dealt with using RM, I mostly go elsewhere.
503 comments
[ 2.7 ms ] story [ 313 ms ] threadWhat's worse, formerly normal websites start degrading. Typically, when a new manager is hired and decides to "reimagine" the product with the "mobile-first" vision. The recent Patreon is a good example.
And of course, in some cases normal websites go away entirely, and are replaced with crapps: Venmo, Amazon Alexa, Chamberlain, etc.
It has finally been told! I was crying and talking about making the return of information rich websites, but people were just following trends blindly :(
It's like: our visitor can't just see our half page table with tech spec to know everything, he should go trough 20 images on 2 long pages and during that we will show him all our 'important' messages that he won't be interested otherwise.
opposite way in: 2013 article about high density on the japanese web being (in part) a legacy of their pre smartphone era
I even had juniors maximizing terminals.
"We suffered for years waiting to get true multitasking and this newb doesn't even use it!" ;-)
The design developed at Xerox Parc.
Guess I must be a junior then.
Stop judging other people's personal preferences. It's their computer and whatever works for them is a good solution.
For me it is much better than multiple terminal windows...
Some websites are better maximized too, like maps for example.
I switched to a 52" TV ~2 years ago. It's the first time I found I didn't like maximized windows.
Personally, I find the way windows overlap distracting. It's labor to organize windows.
E.g.:
https://www.nytimes.com/
The browser should be the User's Agent, not the Web Developer's Agent. If I want to do something with my browser layout that a designer finds appalling, that should not be his concern.
If the web developer and designer really think that text should appear in tiny 5" columns no matter how wide my browser is, fine, then flow your design to display multiple side-by-side columns like a newspaper. Don't just fill my screen with whitespace.
I don’t really want text to reflow to be, like 23, inches wide or whatever. Books with 23 inch wide pages are quite rare, because, I think, that is too much horizontal space, scanning that far with you eyes can become a drag. Of course, if a page just uses the whole width uninterrupted for text I can just give it half the screen, so that is fine. But I’m curious, do you actually like the look of a page like that? Or is this just on principle—respect user choice and all that (if so, good principle!)
In general web devs seem to think way too much about the layout of pages, if they would just do the simple thing users could resize the window to their liking.
HN's handling of different browser widths is... pretty weird, at least on my Desktop Safari browser. Looks like from browser widths of 1920px and greater, HN maintains fixed size whitespace borders and scales the content width. Nice. When you shrink the window past 1600px, it holds the content size fixed and shrinks the borders. I guess the intent is to smoothly transition into a mobile design without the borders. Past 1516px, it removes the borders altogether, and seems to transition into this "mobile" design. Between there and around 610px, it seems to shrink the content width by discrete fixed amounts every 200px or so, to "keep up" with the browser width. Finally, below 610px or so, the site goes back to the non-mobile design, laying out as if the browser was 1600px wide (and actually truncating the right hand side of the text)--totally broken.
All that complexity--for a text only site! When they could just make the text 100% of the browser width and let me as the user decide what is comfortable to view. It's still much, much better than sites that just limit the content width to 600 pixels and fill everything else with whitespace!
It's fixable, of course, by "just" re-flowing the text to match the viewport size. On a desktop, pages of multi-column text at a readable font size are nice. On a phone, multi-column text would be annoying, but a smaller font size can be used because phones are typically held closer to the face than computer monitors. Getting the layout to work correctly like this isn't something I can actually remember ever seeing, but it'd provide a "best of both worlds" way of reading.
Continuing with scrolling as default instead of pagination after the switch to high-res wide screen monitors was a mistake by browser makers. The future of the web - I think - will be with browsers that are real user agents and open every web page in reader mode, with multi-media presented exactly as the user wants. No more letting web-sites control CSS.
As for web-apps, they are not the web, they are programs and should live as PWAs in the OS instead of as bookmarks in the browser.
Like you wrote, there is little reason for column view on phones. Their width is one column and no more. I agree with you that it's strange that we never see this, especially on blogs or newspaper websites, where column view should be used.
[0] https://futurepress.github.io/epubjs-reader/
You say the browser “should” be your agent - but it is. You can use ‘reader’ mode or any number of browser extensions to tailor things for your own tastes, or even copy and paste the article text somewhere else to read it however you want. What you cannot reasonably expect is for every site to be ideal for your personal tastes out of the box.
Web sites are fast, flexible, responsive, readable, scrollable, accessible, and respectful of user preferences... by default, from the moment you add text between <body> tags. Then web developers add code and CSS to make them worse. Sometimes they make it better, but very often it's worse.
I've seen this argument come up before multiple times on HN, and it's wild to me. Having sensible CSS defaults is not a designer dictating that you are only able to see content one way. You might prefer to read text in a giant line spread across a giant monitor, and that's fine, but it's not a freedom thing. It's not denying your browser's role as a user agent that sites have CSS files.
Every single website (HN included) makes CSS decisions for the user. What colors should be used, what is the default contrast. Every single line of CSS on a website is a designer decision by a designer 2000 miles away from you about how they think that content should be presented. And if you don't like that, turn off CSS in your web browser. Assuming you're using Firefox (which you should be using), it's trivial to do.
Of course, browsers should allow overriding CSS, and (imo) they should make it easier to do so and more accessible to non-technical users. And yes, part of making a website that respects the browser as a user agent is shipping HTML that can be viewed unstyled and that is easy to override styles for. Ironically, HN does a horrible job of this -- the HTML is not semantic, the use of tables is so egregious that even stripping the CSS out doesn't really remove all of the styling. The site is really messy if you want to override anything. So that HN uses a design that happens to more closely align with what you want does not make the site more respectful of your browser as a user agent. It just means that you and the designer(s) happen to like the same design.
And in comparison, putting `max-width: 45em` on a text column is not even remotely user hostile, it is a very simple CSS property to override -- especially for designs that use single columns because you can change that CSS property without even worrying about reflow. `max-width` is a default that statistically works better for the majority of users even on large monitors (I use a 32 inch 4K monitor and max-widths make text on that monitor easier to read). But of course, some people are different, and that's fine. Go yell at the browser makers to allow easier CSS overrides, or turn off CSS entirely, or install an extension that lets you add CSS to given pages or spend a weekend building an extension that strips max-width out of stylesheets for every website you visit, or customize Firefox's userContent.css file. There are options here. And if you had made an argument about those options, I'd be 100% on board. CSS for websites should be treated as a default setting instead of as a requirement and browsers should support CSS overrides more easily out-of-the-box.
But the idea that designers are denying user agency by not making a proactive design decision to present by default the specific format you want to read -- it's just ludicrous. You're not asking for user freedom, you're asking for designers to target your preferences instead of other people's. Those two things are not the same.
Browsers allow you to disable styles altogether, but as you note, most sites are horribly broken in that mode. Even Google's home page, which should be dead simple, is horribly broken with CSS disabled. I think if browsers had spines and enabled users to be more opinionated about styles, web developers would respond by ensuring their sites worked better without them.
I'm still honestly a firm believer in the design technique of designing the HTML of a website before I start working on the CSS, and I know that a lot of people call that naive or say that it doesn't work... but I'm not saying that you can't revise the HTML later to fit a design, just that first I want to know what the content is and I want to treat the HTML as a primary rendering target, not an authoring language. I think there are a lot of benefits to that (one being that in addition to being more user-controllable and flexible, it also makes it much easier to do responsive design if you approach web design through that lens because page layouts become views of a unified block of content rather than completely separate isolated designs).
But I don't think including the CSS is where that process falls apart or that it's disrespecting the user or denying agency. It's like how if someone hands me a image of a block of text, my problem is not that the contrast in the image is too light or that it's the wrong color; my problem is that they handed me an image of a text document. If someone hands me a website that is so intrinsically tied to CSS that it's impossible for me to easily adjust column widths, that coupling is the problem more than the column widths.
Firefox does have some some great options around CSS control for partial or small adjustments but in typical Firefox fashion its best features are all hidden like Mozilla is embarrassed of them. I didn't bring up userContent.css to be dismissive; genuinely you should take a look at it if you've never used it before. I make heavy use of it for websites, everything from building grayscale modes when I want a website to be less distracting, to swapping layouts around. But it's a valid criticism that it's not user-facing and you need to go into advanced settings to even enable it. Browsers could do more.
That is completely subjective though, and the user has the option to not use a full screen browser to view the comments. I personally prefer it.
See: https://github.com/plibither8/refined-hacker-news
Edit: You can use the F12 debugging pane to adjust the width of a single tab without resizing the window. It's kind-of a hack, though.
Just push F12 and drag.
Then again, I rarely read HN on mobile. It's just not the kind of stuff I enjoy looking at when I'm "on the go." Perhaps that's why they never tweaked the layout for mobile?
> ...leading to overly wide text in comments if using a full screen browser.
IMO, that's a bug, both with HN, and with the "default" styling in a browser.
The problem is "mobile only" design.
PCs and Laptops exist. They have wide, high resolution screens and precision pointing devices. All relevant technologies support changing the rendering based on the display available to the browser. It's not that hard.
The problem starts when designers ignore these facts, and instead pop giant buttons, zero navbars, hamburger menus, and thin columns with low information density into the Webbrowser running on my PC with a 4k screen and a 120$ laser mouse.
https://idlewords.com/talks/website_obesity.htm#sprawl
1: https://www.youtube.com/watch?v=LXzJR7K0wK0
It actually is very hard to design a responsive UX that can handle anything from the smallest smartphone up to ultrawide monitors.
Only when folks try to get fancy. K.I.S.S(illy).
Yes, on a large screen you might have to increase the size. But a mediocre design you can recover from is better then being stuck with some meth addled designer’s unusable one.
l
i
k
e
t
h
i
s
The links are too close together on a small phone screen and I cannot tap them accurately half the time. This might mean the difference between upvoting/downvoting something, or flagging something instead of clicking on the context option, when I don't mean to.
HN is pretty great when it comes to desktop, though - simple design, no dark patterns, except for maybe the comments with lower score becoming unreadable, which is bad from an accessibility point of view and an odd design choice otherwise.
> old Reddit
Again - by far the best site when compared with the new version, which has bad performance on both desktop Firefox and mobile Firefox; in addition to lots of dark patterns, sometimes refusing you the ability to view a page if you don't sign in, in addition to nagging you to download their app.
It's still bad, though - too zoomed out, can't read anything without zooming in a lot with a phone and when you do, you need to scroll horizontally, which makes reading paragraphs of text a pain. Curiously, they do/did have a version that actually looked okay on phones (i.reddit.com, or something like that), but it doesn't seem to open anymore and redirects to the main site instead.
I think that once you go below ~400px of screen width, designing a decent UI becomes difficult regardless of what you do. It's so much easier to mess around with the meta viewport tag and offer a slightly zoomed out version, but even then you still have the challenge of making something usable across multiple platforms, input methods and so on.
On HN, yes, the arrows are small. And you can trivially zoom in whenever you need them to be bigger and more easily select one over the others. This is worlds ahead of mobile-first designs that lock you into one specific view that you can't modify.
As I said in the other comment: "mediocre design you can recover from" is much more pleasant than meth-addled design you're stuck with -- which about sums up HN/old reddit vs typical mobile first.
>It's still bad, though - too zoomed out, can't read anything without zooming in a lot with a phone and when you do,
Huh? New reddit doesn't do that any better, which can fit only a tiny amount of readable text on the screen as well.
https://service-manual.nhs.uk/design-system
https://designsystem.digital.gov
A smartphone, iPad, and ultrawide monitor demand fundamentally different UX considerations. Generalizing across all of them, and in one codebase, demands a certain expertise or else everyone would be doing it.
I don't think it's a question of expertise; it's a question of effort (and cost). So it's a management issue; are we going to put the effort in to support desktops, or are we going to settle for a crap website? Because a website that doesn't support desktop is a crap website.
Instead, my advice is to create individual designs for each, share when it makes sense, but actively diverge when it’s good for your customers. There doesn’t need to be a single version of a page.
Your mileage may vary.
Maintaining N versions of your application has costs that aren't necessarily great for your customers either. In my experience it usually cashes out into one version (either mobile or desktop) getting all the support and features while they slowly drip down into the other versions. Meanwhile a responsive design can have the upside of forcing support and feature rollout for all devices simultaneously.
None of this is easy.
In practice, working in small and medium organizations, I have met very few UX designers. Instead I have met plenty of graphical designers that know almost nothing about UX design. I've been at places where I - as a backend developer - know more about practical UX design than anyone on the design team.
I think the reason why we have "bad mobile first design with awful desktop UX" is because very few of the people designing these experiences are UX designers.
I was surprised the article didn't highlight the horror show that is Vector22 at Wikipedia, a design so colossally bad that after three years of suck costs the only path to saving face was to make it the default theme for all users: "Mission Accomplished!"
https://en.wikipedia.org/wiki/Wikipedia:Vector_2022
I also checked if I had created some rules for that site in Stylus and uBlock Origin, nothing. For once I'm lucky that a change didn't destroy one of my workflows. One could say that if I didn't notice the transition they could have spared themselves all the work, or one could argue that they performed a perfect job.
Anyway, I get directly to the page I need from Google. I found several threads on Reddit complaining about the change and this one https://www.reddit.com/r/wikipedia/comments/10g2cir/im_prett... I see a different usage pattern "all I had to do was open the site and use the search bar. And then from there it was easy to get to the main page, current events, etc." The home page, current events? I'm sure I never heard about current events before now and about the home page, I know that there is one but the search bar of my browser is closer to Wikipedia's internal pages.
Unfortunately some of the designers I've worked with more recently were primarily graphic designers without a UX background, and actually became an impediment to good design because they were given authority over it despite not really know what they were doing.
I think it's probably an unfortunate consequence of there being more demand for UX designers then there are good UX designers, and simultaneously being a lack of jobs available for graphic designers. And a lot of hiring companies not really understanding what makes a good UX designer.
The issue at hand is that overly long lines reduce reading speed and comprehension of the content[1]. The optimum length for a digital line of text is somewhere between 66 characters per line and 100 characters per line. I personally use the 100cpl rule. For reference, this HN page has ~185 characters per line on my 1920x1080 display at default scaling.
I do actually remember un-minimizing my browser in order to improve the rate at which I could read the text of ur-Wiki pages.
And then they provided an escape for old men shaking their fists at the sky. Given a choice, I would, without hesitation, choose the new design.
[1] https://en.wikipedia.org/wiki/Line_length#:~:text=characters...
You get a sort of garbage-in-garbage-out effect if you apply science to a field like design, where it only serves to amplify your own convictions, as what is being fed into the scientific process as unquestioned assumptions inevitably fall out of it as conclusions.
At best you get KPI driven design, which is a vehicle for enshittification, not for building great design.
I don't disagree with this, but it's none the less an assumption that went into the study, and likewise a conclusion that fell out of it.
I strongly disagree.
Design without considering all of the HCI research that has been done is what you call "garbage-in-garbage-out." We already know how humans perceive information, what makes things salient or invisible, and so on, yet the current design trends completely disregard that with flat UIs and trendy designs that have poor usability.
> At best you get KPI driven design, which is a vehicle for enshittification, not for building great design.
No, you just get trendy design, not usable design.
I took the poster as meaning UX that considers the results of, and perhaps even performs, actual user testing & observation, to decide what works and what doesn't. Like operating system vendors used to. I'll grant that "scientific" UX that's just incompetent (99% of the time) application of "telemetry" and A/B testing is awful. But that—and the other bad kind that's just trend-following, personal preference, and whatever will get the best reaction in a design presentation meeting full of non-experts—aren't what I understood as being advocated.
The good kind performs & pays attention to science.
Any opinions you get out of the scientific method were put in there by the person designing the experiment.
yep. i guess that reddit hired one of those.
old.reddit.com is awesome and stood the test of time, the new reddit is awful and slow (and i hate it).
One, not all Reddit users prefer old.reddit (I do).
Two, Reddit aren't designing for users, they're designing for advertiser's to push adverts at users.
Wrt the second point, this means designers aren't designing to the brief you would give them. Like when engineers design obsolescence into a product (it's purposefully inferior for the end user).
Any idiot can see it's bad user experience to keep forcing a user to a design they don't like, but it's not for UX reasons that they do it. The trick is keeping UX good enough.
To extend that: note that the very companies that spend most money on UI, that hire the experts and pay them well, that set the trends for entire field of UX - are all companies whose primary business is user abuse - advertising, high engagement, etc. That's what they pay the UI/UX experts to optimize for, and that's what ends up leaking into the wider field - leading astray people who are trying to build things beneficial to their users/customers.
It's really an issue that many UX designers don't know how browser rendering works, so they design static pages as if they were printing in a magazine.
Pixel perfect mocks are terrible for designing responsive UIs. Trying to build pixel perfect pages in a browser is impossible. Somehow these designers get through school with zero understanding that designing for web is different from designing for print.
The reality is just that designers gonna design - and designing is often an unscientific craft, pursuing aesthetic values before practical considerations. Google and Apple designers are well-paid and experienced web-heads, and still they led us into a land of well-padded desperation.
At the end of the day its all an ROI problem (as are most things)
Guess based on user agent (or other fingerprinting metric of choice), redirect to guessed site, provide user the option to override when the page appears, remember the choice in cookie (or local storage).
Though personally I think you can do a lot with responsive CSS if you try hard enough - that is my preferred option.
I always wondered about that. What's the point of redirecting instead of serving a different template on the same URL?
I think that websites should assume that devices are being truthful. I should be able to request the desktop view on my phone or request the mobile view on my computer. The former I can do sometimes, the latter I can only do with developer tools (and usually doesn't work because the website detects that I'm on desktop!). Browsers could add a header to switch to the mode in which the website dynamically readjusts based on actual device parameters like window size, but by default I need the view to be what I requested regardless of my window size and device type.
You know how Wikipedia has no table of contents on mobile? I made my browser request the desktop site by default so that I could see the table of contents and don't have to tap to open the article sections. (Unfortunately, Wikipedia changed its desktop view UI by moving the table of contents into a hamburger button. On mobile the desktop view forces me to tap the hamburger button to view a blocking popout of the table of contents, while on desktop the contents are automatically opened in a sidebar.) If Wikipedia had forced a dynamic design on me to restrict me to the mobile view on mobile, then I would've wasted time opening article sections to decide whether I wanted to open them in the first place.
And if you keep the URL the same but serve different output depending on the browser, then you get inconsistent behaviour between two different devices.
Nailing the UX for mobile and desktop is actually pretty damn hard.
I can connect my Librem 5 phone to a screen/keyboard and I get a full desktop.
I agree with comment above that it is very hard to make one website responsive to multiple screen sizes.
I also think one of the things good designers do is to take this into account, and make pages that are built up of components that work at various sizes, not just scaled up from mobile. In addition, a good designer will setup the page design such that it can scale up and down nicely from one viewport size to another.
So, while I don't 100% agree that you need "individual" designs for each, I do think you need a designer that takes the different viewport sizes into account and provides the appropriate adjustments for each. And developers that are skilled at then building those pages.
But I think a lot of the challenge is using pixel perfect static mockups drawn in some design tool.
It would be faster to have a napkin sketch and work with UI dev and figure out the cascading and wrapping at design time.
I'm a CSS person who works in Figma every day and Figma absolutely sucks for responsive design and handoff to devs.
I wish I could just design in Framer or Webflow but those tools while being Figma-like are entirely catered to content websites and not to product design.
Design tools should render with HTML and CSS, not make the mistake Figma made in creating their own rendering engine they have to painstakingly recreate CSS from scratch with.
A motherfucking website made with plain html, no css and no javascript is responsive and works everywhere. Any problems found when you go beyond this are entirely self-inflicted.
Now try to do the same thing with a complex app like your bank’s website, which needs to handle every type of account including credit cards, checking accounts, and investment accounts, rewards, and a travel/shopping portal.
Which is pretty much what 99% of websites need to be able to display. That includes many sub-sections of web applications.
> Now try to do the same thing with a complex app like your bank’s website
Fun story, my bank has a website that works great on both my phone and my PC. On the one I can navigate it fully with one thumb, on the other it is information-dense and respects that I have a high precision pointing device available. They also offer different Apps for Phone and Desktop.
Sounds like you’re the right person to convince everyone to buy cars with manual transmissions and crank windows. After all, they are more reliable and simple, and everyone is wrong for not buying them anymore.
I’d also like to know how you expect all of our serious business productivity apps to work as text-only or server-side rendered plain HTML web pages without being seriously compromised. Google Docs/Sheets/Slides? Jira? Google Meet? draw.io? Tableau? PowerBI? Gong? Notion? Slack? AWS Console? I honestly don’t even know how I would avoid getting fired if I only used text-only websites.
No. I'm saying that there are only few websites that "primarily deal in video and multimedia". They may take 9 spots in a top 20 list, but that 9 is like half of all such websites. The rest deal primarily with text (which includes formatted, rich text).
My business checking account has started offering partner promotions from the transfer screen and I’m tempted to switch to another bank because of it. Their developers and designers were tasked with delivering that component. At the same time they took away their mobile app and mobile check deposit because it was not secured properly.
Most bank websites and apps are examples of teams and organizations focusing on the wrong thing in my opinion.
These days it's even easier with MUI and similar UI libs that have responsive components built-in. Tailwind also makes it very easy to build your own.
We’ll be able to design components to scale to their parent instead of screen size, making them much more generic.
But... I'd add that doing that well isn't easy. I frequently find cases where the mobile version simply removes features the desktop version has. And tablet version are very very rare. They tend to be either just the desktop or mobile version. Rarely is someone designing for tablet.
And that makes sense. Designing 3 different sites to all be the same feature-wise isn't trivial. Then you throw mobile apps on top of it, and suddenly it becomes much harder.
Can it be done? Sure. But I wouldn't say it's trivial to do it well.
Sure I'll agree it's hard, but don't web designers do their work on desktop machines? It seems like even if they are primarily targeting mobile, they must see the results on desktop right? There have to be some known strategies for dealing with it, and they must be aware of the problems. Right?
Maybe the real solution is to treat a wide monitor as multiple mobile screens side-by-side. That is you give your user N-views into your app with no other coupling between them, almost like browser tabs. It sounds silly but I could think of worse solutions. Note: N would be equal to floor(laptop-width/mobile-width).
It's strange that I have to scroll horizontally to view source code and at the same time 2/3 of my screen is empty.
Could be purely CSS, could be JS or SSR
A lot of bad UX decisions come from bad management, not necessarily bad designers.
We don't have to touch every class of device with our B2B product, but we do have to support desktop/tablet/etc. We decided to make a tradeoff in terms of aesthetics and keep the overall design as simple as possible. When you don't plan to test the dimensions between iPhone and iPad or concern yourself with foldable/esoteric devices, you should probably not get too elaborate with your design language.
Our app has 1 simple breakpoint @ 960px. Below this, we assume we are on smartphone and run with one column layouts. Above, we display the full width view. We combine the media query with CSS grid layouts to swap between modes. The specific number was chosen to allow full-size presentation in side-by-side window arrangement on a 1080p desktop (our most typical power user scenario).
Again, we are B2B and only have to tolerate US audiences. So, we have the ability to get away with far more than developers who have to polish B2C experiences with international audiences.
If I had to do B2C web properties and ideally support as many devices as possible, I would be more amenable to that adjective. Otherwise, I would say it is a normal amount of "hard".
Not to mention the market for this target is shrinking so much compared to mobile it's easy to understand how the choice is made.
Just as an example - Look at Google Drive in a regular laptop / desktop browser. All the relevant and frequently used actions are behind menus and icons.
And this site quite fittingly has one narrow and centered column with huge left and right gaps.
Otherwise I think the majority of windows laptops now have touch screens, so while they still have a pointer based input most of the time, touch friendly design is an advantage for the majority of the users.
It would be nice to have specific dedicated designs for all cases, but I am sympathetic with how much of a challenge that is.
I see many people with laptops, but other than one person I know who exclusively buys Microsoft Surface laptops, the average laptop user I know is just typing and clicking away like normal.
How many folks actively go looking for touch in their laptop? I keep hearing about it on YouTube reviews, but even in families with kids, the kids don’t even use the touch features even if the laptop supposedly has it.
I’m just amazed how much “touch on laptop” comes up and I quite literally never see it in reality.
Especially when I'm using the laptop as a portable device on my lap, in a plane or on a bus.
I have to admit I don't use touchscreens that much when I can put a laptop on top of a desk. But when I'm sitting at a desk I much prefer a desktop pc.
I noticed that as soon as I pair the iPad with a Bluetooth keyboard, and an external display, I’ll also use my mouse to navigate.
So, even for a touch first device like an iPad, when using a keyboard, touch is not the best way to navigate.
I know some disable the touchpad to not have to bother with palm rejection and accidental touches at all. Same for shitting off mouse input when the touchpad is used. And so many other combinations.
But yes, people going full hog on touch usually have Surface pro or Yoga like devices in the first place and won't be an average user. And people used to point fingers at their screens tend to hate it now that it actually reacts.
a) I would be really interested in the reasoning behind that opinion
b) Even if a laptops screen is touch-capable, it still has a precision pointing device
c) PCs exist, and so do docking stations.
And using phones as a 2FA device. A giant, relatively immobile device is a much better 2FA device than something that is easily stolen.
Another problem is designers working only on 4K/5K screens and not taking into account how little of their design fits on a FHD screen that a major part of the desktop population still uses.
- On Linux, the assumption is that everyone has a 1920x1080 monitor, so if you get a high resolution 13-inch device like a Surface suddenly half of the apps are unusable because everything is scaled so tiny, and the apps literally just do not know how to handle the aspect ratio.
- On Web and in popular design studios, the assumption is that everyone has a full 4K mac and so everything becomes larger and spread apart; you load them up on a normal monitor and everything becomes cluttered and the interface of the app starts taking up more room than the content you're looking at.
Test your apps on multiple resolutions y'all, and for the love of everything that is holy if you're designing a desktop app, please add button density and font size controls to your settings. Some weirdos like me even use multiple monitors of different resolutions and pixel densities hooked up to the same computer at the same time, so being able to adjust on the fly or handle fractional scaling is kind of a big deal for apps that I use. Standard resolutions are a myth.
But it was so easy in the past to just ignore that and treat PCs like they were uniform devices used in a uniform way, and phones meant that you suddenly had to care about what a website looked like in a single-column view, you couldn't just tell your users to maximize the browser window. Unfortunately, rather than taking away the lesson that design should adjust to nonstandard situations, layouts, and input-modes that can not be fully predicted or tested for in advance -- instead developers took away the lesson "okay, now there are two standard devices we have to support: mobile and desktop."
The distinction isn't real, there is no hard line between a desktop and a mobile site. There are mobile tablets that are big enough that they should be served a desktop layout, there are desktops with touchscreen displays, there are monitors that are 3/4 ratios. And there never was a standard and computers were always like that, but it's an understated truth that every developer and every designer would secretly love to develop exclusively for consoles with integrated screens and one input method, and developers often kind of behind-the-scenes somewhat resent the fact that general computing is an open ecosystem with diverse devices. So designers often just treat computers like they have two completely discrete interfaces, or at worst decide that because they're not targeting one of them that they now have permission to target exactly one resolution and size again.
Sometimes that takes the form of designing "mobile only" like the top-level comment talks about and calling desktops a dead platform. Sometimes it means designing desktop only and getting mad that somebody flipped their monitor vertically instead of horizontally and now wants the ability to move a side-drawer to the bottom of the screen.
Agree.
Actually, I think what happens is that the team adopts a "mobile-first" policy, which is reasonable, since most visitors wil be mobile. But they don't follow through with the "desktop-after" corollary, and they don't engage with the "progressive enhancement" philosophy, because that gets even more costly than simply having two websites.
I find phones impossible to use as web browsers. My eyesight is too poor, and my thumbs are too fat. I use phones for making phone-calls and for trading SMS messages; if I need a website, I use my laptop. But that's just me.
I think the real problem is that mobile phones make awful platforms for browsing websites. Native checkboxes and native select-boxes are often unusable, so developers use "frameworks" <spit> that replace them with Javascript monstrosities. Because that all depends on plugins and code, each website ends up with it's own idiosyncratic UX.
I think the correct solution is for phone makers to deliver platforms that can render HTML so it's useable. Then the only problem for devs is create responsive layouts, which isn't that hard.
The problem usually is the resources and time available to implement such designs. Most of the time the devs simply don't have the time, desire, or even ability to implement more advanced responsive design, so designers will design what will actually get made.
I am a designer and HTML/CSS coder so I am aware of the challenges from both directions.
Sure the majority of websites on the web aren't SAAS tools, but the nuances of mobile vs desktop layout described in this article don't apply so much to such simple content pages.
It was so, so bad it was almost totally unusable on anything larger than a tablet. It made it virtually impossible to read articles on a desktop because everything was so spread out, the font sizes were all messed up, navigation was hidden in a tiny little hamburger at the far upper right of the screen, and a bunch of other problems. But what was wild was how easy it was to fix them. I ended up writing a small (maybe 100 line) CSS user style that fixed almost all of the problems.
They did eventually "fix" the site so that it wasn't as bad on desktop.
[0] https://www.al.com/
In a nutshell everything Instagram does!
Our work flow often ends up: get design > ask for desktop > told to ‘use best judgement’ > uses best judgement > get a load of amends as best judgement wasn’t what the client has in mind > repeat.
Don’t even get me started on the mythical black hole that is the tablet screen. It’s like designers have forgotten that they exist and people use them at times.
But it's a slowly dying market segment. We might be at a point where it's more likely a household as a Chromebook than a PC.
"Mobile first" is not the right way to approach the problem. I dislike desktop layouts that were obviously "mobile first" and only look like a wider version of a mobile layout. It's just the wrong way to do things.
It's very easy to use media queries to make all the content of a desktop design fit into a mobile layout. I really don't understand the disconnect about this. I manage to get full functionality in both desktop and mobile devices of all sizes, but others cry "mobile first!" like if you don't do it that way, then you're doing it wrong? It's nonsense. "Mobile first" almost always leads to sub-par desktop experiences, and that's a shame.
My favorite challenge is a design meant to be printed on a single page. The page also has to load on desktop and mobile browsers. With the printed page, the content absolutely cannot overflow even though it's dynamic content and could have text of any length, or list items of any length (scaling is used to a point, but often some items must be omitted from the layout). So in this case, it's absolutely "print first", not "mobile first". And yet I manage to make a perfectly good mobile responsive layout and a desktop layout out of a "print first" page.
I agree though, that doesn't mean we need dumbed down desktop layouts or scaled up mobile versions, it just means we need to consider both and design accordingly. Mobile first is fine as the starting point, there are a lot of valid points to that design paradigm. But that is just the "first" part, then there are the rest of the parts to account for all viewport sizes.
Mobile is king, second to 13-15 inch laptops.
I get why they are used on mobile. If you only have room for content, it makes sense to tuck actions away into a hamburger menu except for a small number that you assign to tiny little hieroglyphs. Fine. However, if you have space, this is a terrible way to use it. At best it adds steps, at worst it invites experimentation and disaster to figure out what the heiroglyphs do (which wouldn't be so bad if undo worked but we've apparently decided undo is fine to break too). Like the Apple HIGs used to say, on Desktop you should want to get the most common actions out of menus and onto labeled buttons so that users can answer "what can I do?" without playing hide and seek. Undo should be baked in from the very start (it's hard to retrofit) to reduce the consequences of experimentation.
Unfortunately mobile design has taken over so completely that even on apps which will be used almost entirely on desktop, even on apps with an internal advocate for Desktop design, UI designers go for the hamburgers and heiroglyphs and broken undo because it's standard these days. Sigh.
Oh, and modals are back with a vengeance, but I need to stop here or my blood pressure is going to get unhealthy.
Hamburger menus could also frequently be done away with when you look at how many options they have. Like Gmail's app has them when it could fit the icons across the screen as a bar. And it's hard to argue that real estate was important since they put in a bottom bar for chat, video, and spaces whatever that is.
Just cracked open Gmail to check this. In the hamburger side menu, there's 18 items not even counting labels. No shot you fit this across the screen as a bar.
Then there's another menu below that with 8 items, 4 of which also already have UI elements. Give the other 4 icons. There's plenty of space on the show pictures line.
You need a menu for label filtering since the user can create many, but let's look at settings. There's a mostly blank screen with a ... menu with 2 options (why is it sometimes hamburger and sometimes ...?): manage accounts and help. Just put them on the screen. Now look at general settings. Enough stuff that I have to scroll, but for some reason 4 of them are in a ... menu. Two are the same as the last screen, with clear search and clear picture approvals added. Now go back to settings. Suddenly settings has all 4 options in the ... menu! The hidden options on the same screen are different depending on where you were before, when they could all just fit on the screen.
In general, scrolling is much faster than clicking on an icon. Lots of web UIs (e.g. navigation menus) could benefit from just putting the links at the bottom.
screen resolution vs browser resolution
the most common mobile browser resolution is 800x360
also, 5 years is not that old
Really? You're saying most people are using their mobile phone in landscape mode?
your highlighting of the confusion only adds to the confusion
congrats
The more text you have, the more difficult it is to ensure a usable UI on small screens, let alone a good one. Don't be upset about the use of symbols instead of text, but about the use of bad symbols. Nobody needs the "play" button on a video widget to say "play" - they know what the right-facing triangle means. (Ironic because I don't know if it makes geometric sense to even say the triangle has a facing, but as a symbol it's well understood.)
Put the text below the icon in whatever size you can. It's a strict improvement in usability.
It's one of the reasons I prefer how Vim and VS Code look over Intellij and Visual Studio standard. Let me better see what I'm focusing on without distractions (the content) instead of shoving a gazillion buttons on your UI in the default view.
Edit: I was too harsh about Intellij I think. The old UI I was thinking of doesn't look bad in my opinion, but I still think I would have enjoyed my experience with Visual Studio more if it had a stronger focus on content (the code) visually.
[0] https://www.winstoncooke.com/
On the other hand, hamburger menus typically have a lot more entries than this, enough that a horizontal menu wouldn't look good even on desktop.
I’m a big fan of collapsible table of contents. That design paradigm allows for the higher level to use a word to indicate what it contains and then can open up to a list. But it does really depend on the type of information conveyed. I can currently get away with always avoiding hamburger menus but that might be tougher for something like a banking app to avoid.
Hieroglyphs sums it up so nicely. Lol. I'll also add hidden, context sensitive options to that list. I like having options that are disabled (aka greyed out) if they're unusable because at least I can see there's a possibility to do something if I get conditions right. Instead, modern designs will hide those options and, if you don't know the magic conditions needed to expose them, you'll never see them.
An example of this is Ubiquiti with their Unifi stuff. If you go to manage switch ports, the page they give for that doesn't have an option to "Select All" ports. You need to select at least one port first, and then the "Select All" option magically appears. So not only is it hidden, it gets the context wrong. Think of having it as a disabled checkbox. Everyone would immediately realize the context is wrong because having the "Select All" checkbox disabled when no ports are selected would be obviously dumb.
My devices are a literal ton of iOS ones, and then 4k and a 2560 × 1440 display which I use most frequently lately.
Tons of whitespace, oversized text everywhere and incorrect use of Z-index are some of the hallmarks of this mobile-first design.
Then I have to scroll down on my 27" monitor to be able to actually read anything on that site. That is stupid - at least in my opinion.
They might pass though if they can't get the site to work well on their phone.
I refuse to go to restaurants that have QR-code menus that download a PDF with unusably small entries.
Unless you HAVE to use something, you can still vote with your wallet. Herman Miller is not the only furniture company in existence.
I either go on the restaurant's website directly to find the menu or ask for a physical menu. I've never been tripped up by that. I understand I'm still rewarding the owner for their bad choice, but I'm not going to force my friends and family to get up and leave a restaurant we all wanted to try out because of it.
It gets worse. I've been to a restaurant in Silicon Valley where not only were the menus reached through a QR code, the linked page was not the menu. It was the onboarding funnel to get customers to sign up for a food-delivery service. You had to sign up to get menu access. Then you could order online. Dine-in was just ordering food delivered with a really short delivery trip.
Here in Seattle we have a few restaurants that use a similar model, you scan a QR code and order food online, only it's "delivered" to your table. But they don't need any account information from you, so it's pretty convenient.
Oh yes, about half of the time when a restaurant requires me to scan their QR Code to read their online menu, it's a 20 MB PDF - not a responsive web page. And the PDF usually has multiple columns of text, which means I need to zoom and horizontally scroll (generally a big no-no in web design). I'm a technologist at heart and I find this implementation so needlessly bad, and an extremely poor use of technology. I would prefer a no-bullshit paper menu instead.
In fact, this happened last week--I was trying to purchase a plane ticket and the animations were so excessive and poorly done that it obscurbed a form field that made it impossible to book the ticket. I bounced and booked a ticket from a competing airline.
I can't imagine you are talking about the same thing here. (Or if you are, then you are making OP's point.)
Zoom in on the [Touché!] button and there are artifacts between the rows that make up the corners.
But it's worth being clear that mixing such thing with flowing text and graphic is where things get hard. Html 1 had flowing text in the 90s and you can still do that.
Moreover, all this is related to overall user hostile designs. Organizations broadly don't want their pages to be neutral streams of information but want to control a user experience that nudges people this way and that and fixed are important to that.
It's not just a technical problem, but the social problem of how you get people to keep using that API, and not extending it, and not breaking it in favor of some different purpose (like ads)
Whatever API for web data you propose, I can tell you exactly what will happen to it:
1) Initial clients are geek-designed and geek-friendly, and render the data intelligently.
2) This API gets popular for not having all the cruft.
3) Some genius discovers they could add some cutesy visuals and effects if only the standard were extended, and targets the clients that handle these extensions.
4) Eventually, only those clients are cared about, and you can only make sense of the data with those clients and if you don't have disabilities.
If you want to make progress, figure out how to eliminate that dynamic.
Earlier threads on this point:
https://news.ycombinator.com/item?id=30727026
https://news.ycombinator.com/item?id=20224961
You get the same with some native UI designers. They kick and scream until you've got some custom widget that precisely apes the Photoshop layer effects. Then kick and scream again when they make changes that take non-zero time to rebuild with that custom widget.
Here you go:
main { display: flex; flex-direction: row; flex-wrap: wrap; }
..and set reasonable width/margin constraints on your primary content blocks.
Linear, scrollable flow on small/vertical displays, and a denser "grid" on large/horizontal displays.
It's literally 120 characters to make a website that flows on any (reasonable) screensize and adapts perfectly.
Modern webdev is just throwing frameworks at self-caused problems.
(I'm exagerrating of course. But most websites are just about showing text, maybe with some images every now and then (news sites, reddit, hackernews, google, come to mind). For those websites this is certainly true).
No it doesn't. It's this pointlessly narrow column in the middle of my screen surrounded by arces of whitespace. If I wanted narrow text I'd make my browser narrow. Looks like the result of some designer fucking around.
The job of a UX designer on the web is to consider this kind of stuff and to build a design that's very reactive to evolving displays within the demographics and market segments that the client wants to support. If that's not happening, if the CSS people are just getting handed static designs and being told to figure it out -- the problem is not CSS or the developers, it's that the designers building those designs are not good at their jobs. And there are ways to make this easier: notably UX designers involving the CSS department in the design phase, and/or making a point to always lay out the contents of the page without styling in a hierarchical way before making decisions about how to present that content.
But a lot of programming is hard. It's hard for me to write maintainable Javascript that doesn't fall apart if a project goes over 100,000 lines of code. It's hard to document methods. It's hard for me to write code that does complicated things that can work on low-end machines. These are skills that programmers get better at over time with practice. Responsive design is the same; it's just another skill to learn.
Imagine trying to shoot a movie and having the cinematographer tell you that it's hard to frame everyone in the shot since they don't know exactly where the viewer will be looking, or the sound mixer telling you it's hard to balance dialog and sound effects so everyone is audible without it being noticeable that they're muting background audio. Or a recorder telling you that it's hard to master a pop song given that everyone has different speakers and sound profiles on their headphones. Imagine you're building a car and the designer tells you that it's hard to make sure the controls can be reached by people who are different heights and weights.
On one hand, yes it is; all of that stuff is very hard. On the other hand, yes, that is also the reason web UX designers and developers get paid money; because the job is hard and requires training and expertise, and designing a website interface requires more thought and intentionality and planning than is required to make a PDF.
I often get "print first" page layouts, created from dynamic data that can have varying amounts of content. These pages also have to work in mobile and desktop browsers and look good on all of them. I don't find it to be that difficult. Sure it takes a little longer, but it's what the job requires. Media queries make it all possible, as well as a little bit of javascript.
Maybe I'm getting really old and just like to complain about this because I'm not very much used to this phone-oriented UIs.
I hate it lol
I figure their website is so bare bones because it reflects their low cost ETFs. They'd rather have a crappy website and cheap ETF's than a fancy website with slightly higher cost ETFs.
It was a real pain to enter past employer and residence names and addresses on a mobile keyboard, but even worse when it came to dates, because the date picker would only scroll a month at a time, starting from the current month and year. To enter my birthdate, I had to tap ~550 times.
(I was kinda tempted to file an EEOC claim, since the broken date entry has a disproportionate impact on older workers, a protected class. But that's not a great way to introduce yourself to a new employer's HR department.)
Desktops/Laptops are for gamers, workers, and programmers. This isn't 2006, people don't read articles on their desktops in leisure. If they are it's because they were also doing one of the three use cases I mentioned.
Nah. Like, I'm all of those; but I very rarely play games these days, and I've retired from programming. But I strongly prefer to use a laptop to browse; I never use a mobile browser. My eyesight is too poor, and my fingers are too fat.
What about tablets?
"Minimalist design" and it still takes multiple megabytes of bandwidth to show a pretty nothing.
I'm using Reader Mode or an equivalent whenever I can. If a site cannot be dealt with using RM, I mostly go elsewhere.
Now get off my lawn, kids.