> it's for shitty low-end laptops that still to this day have 1366x768 displays.

We had scrollbars on 640x480 both ways and liked it. Even SGIs with 1280x1024 monitors had scrollbars, and it wasn't a burden that some folks today seem to think it was.

The UIs of the OSes designed in the 640x480 era used 8pt system fonts, and were very careful about "spending" vertical space. The UIs of the OSes of today are not optimized for the same scenarios.

Here's what Windows XP (not even really from the 640x480 era!) looks like on a modern display: https://ibb.co/W5mVgHT

You could fit a lot of Windows XP, and XP-era apps, on a 1366x768 display. You can't fit much of a modern OS+apps on one.

(That's honestly for the best; text and icons in modern OSes are both a lot more legible due to the increased fidelity and breathing room they have. But display resolutions have to keep up; and, at least for low-end PCs, they aren't.)

What you're showing here is lack of high DPI scaling and it's a completely different issue irrelevant to the GP's point - it's caused by increased pixel density, not screen space (unless your example comes from some 40" monitor or so). To make an honest comparison you would have to set the output resolution to a lower value.

When done right, increasing screen density doesn't really affect available space, just makes everything sharper (unless you manually reconfigure it to get more space, like I do on my hidpi laptop).

Okay, maybe running XP natively on a 4K display was a bit silly. But here's XP in 1080p: https://ibb.co/BB5rsHg

UI elements are still far smaller than comparable ones in Windows 10 or macOS, when those are running at 1080p unscaled. On XP, IE and Explorer both manage to fit four toolbars (rather, a title bar + three toolbars) in 105px of vertical space. On my own macOS Catalina install, Chrome manages to fit only two toolbars in 86 device-independent pixels of vertical space.

Likewise, just consider the fact that people weren't generally looking at PDFs back in the XP era, but rather plaintext, which—as rendered on this image—was exactly 8px tall. A lot of 8px-tall text fits on a 1080p display, no matter how many toolbars you have; and a lot of 8px-tall text will even fit on a 640x480 display, if you make efficient use of the vertical space. But because PDFs use vector fonts, not bitmap fonts, they will look unreadably muddy if you attempt to scale one down such that the text only uses 8px of vertical height. You need more vertical space to look at PDFs.

So, in combination, when you throw a Windows 10, running Google Chrome, displaying a PDF, on a 768p display, it's just an ugly constrained problem.

As mentioned the dpi reasons you described are somewhat unrelated. But there is one factor, the move from 4:3 to 16:9 ratio monitors, which is less efficient in terms of usable area.

Given that most scrollbars are vertical however, it isn't a big deal. I've gotten more vertical space from putting my taskbar on the left (when 16:9 became ubiquitous) than anything other change.

Any operating system would look like that on such a large resolution.

Speaking of title bars, the trend to move content into the title bar is terrible for usability. There is nowhere left to click to move a window. Not to mention each app choosing a different color/style for this region. Do designers assume everyone runs 1 full screen window at a time?

Yes. Yes they do.

And because their designs make windowed use problematic (both because of the title bar issues, and because space is used poorly in the name of "clean design"), they encourage even full screen use.

Add to that the fact that more than a few applications default to full screen at first run, and ...

This is why we can't have nice things.

Let's talk about the new Slack. The crowded title bar (with the hamburger icon, the search box, and now even the profile icon) means you can only grab it for dragging in two specific zones. Even worse, the window cannot be dragged at all when search is active, as the title bar gets completely overshadowed by the search popup. Absolute trash of an UI.

IntelliJ IDEA also fell victim to this trend of abusing the title bar, but they are be reverting the change and providing a setting after listening to the inevitable criticism: https://youtrack.jetbrains.com/issue/IDEA-219212

I think you're comparing apples and pears when you talk about Maps. There's a clear use case for scrollbars on vertical documents (i.e. most of them), and even when viewing something in an infinite scroll, so you know where you are when scrolling back up. (Although don't get me started on the UX of infinite scrolling!)

Edit: Thinking further about this, the affordance for maps is a change in the cursor to a grabbing hand. You have to learn that, but there's a clear visual difference in the cursor to show that something differnt happens there.

I got bit by infinite scrolling yesterday. I liked an article, clicked in the URL, copied and pasted it into a group chat with my team... and then noticed it was the wrong URL. The fine website had "helpfully" autoscrolled a smidge into the next article, so it updated the URL box to the next article. Lesson learned-- read before pasting...

You might resent the autoscroll on the website, but did you consider that the group chat program also has an infinite scroll, for chat history? Imagine what a hypothetical scrollbar for the group-chat program would look like if it had one, and if that scrollbar actually represented your relative position in a complete timeline going back to when the chat-group was created. :)

Consider that an actual timeline is a better interface for chat history than an infinitely scrolling log.

Genuinely curious: what is the difference? Pagination?

What are some examples of the two approaches?

I have such display. It is quite spacious once you remove all decorations [1], that is no window decorations (xmonad), hide URL bar and browser tabs [2], no page scrollbars [3]. I encourage everyone to try at least browser addons.

[1] http://sergeykish.com/side-by-side-no-decorations.png

[2] https://chrome.google.com/webstore/detail/convert-to-popup/i...

[3] https://github.com/sergeykish/hide-scrollbars # chromium, firefox has another rule:

    html {
      scrollbar-width: none
    }

> shitty low-end laptops that still to this day have 1366x768 displays

So users should purchase new equipment to suit designers? Or maybe - crazy idea, I know - designers should design for the equipment people actually have and not whine or look down their noses because not everyone makes designer salaries.

> purchase new equipment

I'm not talking about shitty old laptops. I'm talking about shitty new laptops. There are laptops you can go into an electronics store and buy right now that have 1366x768 displays. And that's ridiculous.

Yes, these laptops are cheaper. But putting a 1080p panel in these laptops wouldn't be that much more expensive. Maybe an extra $0.50 on BOM, compared to the current design. Or, in fact, it might have exactly the same upstream cost. Why, then, use the shittier panel?

The 1366x768 display is purely there for market segmentation. It's an artificial constraint hardware makers impose on their low-spec devices, in order to make them unattractive to people with higher budgets.

A lot of these low-spec devices would be just fine for the small amounts of work many people have to do on computers, and so these people would buy them if they only needed "a little bit of" computer, even if they could afford something more expensive. (Just like you buy a $50 blender, not a $500 blender, if you're only making piña coladas.)

But the people who would consider these low-spec devices (despite having the budget for higher-spec devices as well), are pushed away from the low end, by these artificially-imposed pain points.

And that means that the people who do only have the budget for a low-spec laptop, are getting an artificially-imposed screwing, getting a shittier laptop than their money would buy them in an efficient market, purely because the supplier went to extra design effort to make their low-end products actively repel middle-end customers.

And taken in that lens, the fact that modern OSes don't work well on 1366x768 displays is actually kind of the point. It's not something the OS manufacturer can fix on their end. Because this would be a vicious cycle: if the OS began to work just fine on a 1366x768 display, then the laptop mfgrs would design their next series of low-end laptops to have even smaller displays, in order to re-introduce the market-segmenting "cramped feeling."

> where the view-controller isn't necessarily aware

That's a really poor excuse. If that "awareness" is missing then the code is structured wrong, probably because somebody cargo-culted a design pattern without ever once thinking of the user.

No? Infinite scroll is usually just a direct translation of SQL cursor semantics into the frontend. And an SQL cursor (or its equivalent for a disstributed store) is an optimal choice for a situation where:

1. there's a potentially-huge result set;

2. almost nobody ever wants to see the whole result set, but rather almost always just wants to see the first N chunks, and then drops off;

3. the results are sourced from a data lake, or from eventually-consistent geographic shards, or any other process where you need to actively gather results together with a map-reduce.

When these three factors apply, it becomes very expensive to know exactly how many results you will have, because that changes your partial streaming map-reduce workload into a complete map-reduce workload, over potentially billions of records, just to validate their inclusion and then count them.

Think "Twitter timeline." If every client displaying a Twitter timeline needed to know in advance how many tweets they could ever see, total, if they "scrolled all the way back" — then Twitter's servers would fall over from the load of calculating that number.

Another example is Google Search, which, while not "infinite scroll" on the client, is still a "map-reduced stream" on the backend. Google has put some extra effort into heuristic scheduling logic for its Search map-reduce: it grabs an initial 20-page-or-so chunk of the stream and caches it on a sticky-session node for you. This means that, if your search-result set is less than 20 pages, you get to know the actual result-set size. If it's more than 20 pages, though, Google Search reverts to exactly the same "you'll only know when you're at the end when you get there" semantics of SQL cursors. You see the first 20 pages, with a "next" arrow to go beyond them; and then it just starts counting up, and up, and up...

That excuse doesn't work at all, and you even provided the counterexample yourself. If you know the data fits on one screen, which you know very quickly, skip the scrollbar. If you don't know, add one. All you need from API is an indication of whether you're already at the end, which you probably already have so you can know whether you can/should call again. You might not know the precise number of results to size the "thumb" on the scrollbar, but that's OK. Just guess and nobody will be bothered too much. But if you don't know whether you have even one more result then your system is broken.

I'm glad I work in infra, not apps. Infra developers certainly make their own share of dumb decisions, but they're not that lazy and sloppy and user-blaming.

I’m not in infra or apps; I’m a database engineer. I write ETL pipelines.

If you know you have one more result, that is necessarily because your data pipeline actually has that result available for it to count; i.e. the result record/tuple has been loaded into the database’s memory, and the database has determined that that record/tuple is valid and fresh. (And at that point, rather than counting, the DB may as well send you that record itself. Just counting it has already required almost all of the same work!)

Remember that MVCC exists. You can’t know how much of something you have as of a given instant without doing version deduplication/application of tombstone records. This is the reason that COUNT() in Postgres takes minutes/hours on large (>1bn records) partitioned tables: you have to actually visit records, to see whether they’re still part of the current MVCC transaction-version, and therefore whether they should be contributors to the current count.

That applies whether or not you’re “counting” or actually streaming results. Given the architecture of both traditional data-warehouses — and of the map-reduce systems like Hadoop that are used to do reporting on data-lake data — you can’t know whether anything that’s in the rest of the data set is going to actually exist when you get to it. Your data warehouse might have a 100GB heap of data in a table, but everything after the first 1GB of it is dead tuples, such that after you’ve streamed the first 1GB of results, the rest of the streaming consists of the data warehouse sitting there silently for a minute or two (as it checks the liveness of those tuples) before saying “okay, nothing more, we’re done.”

And because of this, it’s not about precision. You can’t even guess. You can’t know whether you have one more result, or a billion more. Until you actually check them.

Yes, OLAP systems are different. OLAP systems operate in terms of infrequent batch inserts, giving the system time to build indices, generate counts, etc. in-between, that will all stay valid up until the time of the next batch insert. An index is, in a sense, a pre-baked answer of the “set of live tuple-versions” that a data-warehouse is holding. Count the table? Just return the size of the index. If you’ve only ever built OLAP-oriented systems, maybe it feels like these are the “simple, obvious” solutions to this problem.

But none of the things we’re talking about — global-web search engines, social-network timelines, marketplace listings — are OLAP systems. They’re OLTP. They constantly get new results in, and people expect to be able to see freshly-inserted data in the results as soon as they insert it. Data comes in at too high a rate to generate “dataset snapshots” ala ElasticSearch. The pipeline has to deal with data as it comes, doing as little to it as possible so that it can ingest it all at the ridiculous rates required, by pushing all the work of validating tuple liveness/freshness off to query-time.

And given that, OLAP properties don’t attain in such systems. It’s basically the CAP theorem at work: Consistency (and cross-shard index-building) both require time for the system to investigate itself; and you can’t get Availability (and/or cross-shard freshness) unless you run the system too fast to allow for that time.

> I write ETL pipelines.

"Apps" to folks in storage (like myself), networking, OS, etc.