Why Is Printing So Bad?
18Lorxus
17johnswentworth
10TsviBT
10aysja
5Hastings
3Lorxus
4philh
11Dweomite
5johnswentworth
11Dr. Birdbrain
5Dweomite
7leogao
10habryka
6Thane Ruthenis
4Linda Linsefors
4ChristianKl
4Ben
4the gears to ascension
3β-redex
3XelaP
3Gavin Runeblade
3Oleg S.
3Aprillion
3Aprillion
2Johannes C. Mayer
New Comment
Oh! I have thoughts about this one!
On my model, it's a matter of basically anything that turns Bits into Its being kinda cursed, especially if whatever process lacks human actuation or even oversight and isn't done to truly exacting standards. Printing is an example of this; 3D printing and general CNC is another; graphic design (and the depths of what a color is) is a third. I'm thinking of the kind of thing you might find on r/shittyrobots as well; a minimal non-example might be polypeptide/oligonucleotide preparation, though I'm not totally clear on the workflow there or how much human labor is involved.
My gears-level model here is most starkly illustrated by 3d printing - something about the physical object creation might change, or be underspecified, or rely on shoddily-made connectors of some kind, and in any case, the actual machine that does the actuating isn't set up to check for failures during workflow or indeed do much more than the simple actuation and an initial calibration step. On top of that, the thing goes from being data which is everywhere and wherever you want it, to being a specific thing in a specific place; often you don't even get to have the affordance of knowing in advance which place it is. Possibly even the yakshaving you notice is a matter of some kind of associated ugh field.
I definitely agree with everything that turns Bits to Its being kinda cursed. I think the natural phenomenon boundary is more general.
Here are some other examples of things which feel terrible in a qualitatively-similar way to printing:
- Dealing with the Department of Motor Vehicles or similar bureaucracies.
- Working on a mature and messy/poorly designed codebase.
- Making a finicky machine work (regardless of whether any Bits are involved).
One piece of what makes these feel similar is recursion - I go on a subquest to solve one subproblem, and that triggers a subsubquest to solve a subsubproblem, etc. One thing I notice about the examples is that the problems maybe typically have to do with assumptions at interfaces - e.g. the printer being out of paper isn't really about "Bits to Its", it's about a finicky machine having been designed with some assumptions about its working environment and those assumptions not always being satisfied.
Partial themes:
- Anyone who knows enough to even begin to think about doing anything about it, knows enough to not have the problem.
- Making it just work is actually a hard problem. Codebases naturally get messy when big, and are born with ontology skew to the eventual ontology. Machines have to be operated with a conscious touch, and therefore the human has to interface with them.
- Legacy systems, especially multiple. E.g. your poor printer is supposed to interface with a huge range of computing systems / your poor computing system is supposed to interface with a huge range of printers.
- Sure someone could put a ton of effort into making the last mile smoother, but who's incentivized to do that? The printer does the hard part of printing, what more do you want.
1Relatedly, I often feel like I'm interfacing with a process that responded to every edge case with patching. I imagine this is some of what's happening when the poor printer has to interface with a ton of computing systems, and also why bureaucracies like the DMV seem much more convoluted than necessary. Since each time an edge case comes up the easier thing is to add another checkbox/more red tape/etc, and no one is incentivized enough to do the much harder task of refactoring all of that accretion. The legal system has a bunch of this too, indeed I just had to sign legal documents which were full of commitments to abstain from very weird actions (why on Earth would anyone do that?). But then you realize that yes, someone in fact did that exact thing, and now it has to be forever reflected there.
What this sounds like to me is a system, where all of the parts are designed cleverly with the assumption that their costs are going to be amortized, but because the current reality isn’t fitting the original assumptions, you’re hitting cache misses and full cost on every single operation
Hm. So it's some larger problem of which the Curse of It From Bit is a subcluster, then? If I've understood you right, this is also something I've spent time thinking about by way of finding them with my face. Something like... some unfeeling machine/system/structure that fails to live up to its own spec, or which has a bad spec or no spec at all, and which makes that state of affairs your problem, you silly goose who wants to actually do things, you. There's the flavor of that thing from Zen and the Art of Motorcycle Maintenance where there's this tiny trivial-feeling problem that humiliates you with a combination of feeling trivially small while nonetheless demanding close attention and deep understanding by way of being a critical blocker to solving whatever problem, I think? I think that the yakshaving bit is downstream of the spec failure piece - it seems like a common failure mode of degraded systems/designs.
1
1The ways that printing and 3d printing are cursed feel different, to me.
My expectation is that if I manage to give a printer any instructions at all, it usually prints the thing I expect. If not, it's usually because it's out of paper or (more rarely) ink/toner. If it has raw materials and receives instructions, I expect it to print a document that looks substantially like I expect. But "trying to give it any instructions at all" may well be an exercise in frustration.
With my 3d printer, giving it instructions hasn't been the hard part. (It's maybe not quite straightforward. You need a microSD card, formatted correctly, with a .gcode file, and I can see those feeling cursed to someone, but they're the kinds of problems I know how to solve. Then you put the card in the printer and select it using the sufficiently-intuitive interface on the printer.) The hard part is that the instructions I give it don't reliably result in a physical artifact that looks or functions like I intended. Airflow, ambient temperature, properties of my filament, bed adhesion, calibration. There's too much that can vary in the environment, and those differences can mean I need to give my printer slightly different instructions (like different nozzle or bed temperature, more supports, slower speed).
2d printers, in my experience, seem to have solved that kind of problem. Though I imagine professional printers have exciting problems that I don't.
(John's blank page 1 is an admittedly weird case here, but "printing a blank page" is still less surprising than, say, "oops, near the top of the page I printed a black area that was too large, and that caused the paper to skip 3mm up higher than the printer thought it was, to fix that next time I need to make sure the printer slows down in that area, or inject some subtle yellow dots".)
(Maybe part of the difference here is "printing at some point on the paper is independent of printing at some other point"? There might be calibration errors, that mean every point is slightly offset or slightly the wrong color, but because they affect everywhere equally I'm unlikely to notice them. And there might be random errors, where ink is fired slightly too late and a specific red dot is in slightly the wrong place. But I don't expect that red dot to cause the next line to also be in the wrong place. With a 3d printer, a missing or unexpected bit of plastic causes the next bit of plastic to be in an unexpected place too, so the random errors compound, sometimes into a goopy blob. Part of the point of printing a skirt is to avoid this: the perimeter of the first layer is some of the most likely plastic to be not-where-expected, but if it's in a skirt it doesn't get printed on top of so that's okay.)
I have a tentative model for this category of phenomenon that goes something like:
- Reality has a surprising amount of detail. Everyday things that you use all the time and appear simple to you are actually composed of many sub-parts and sub-sub-parts all working together.
- The default state of any sub-sub-part is to not be in alignment with your purpose. There are many more ways for a part to be badly-aligned than for it to be well-aligned, so in order for it to be aligned, there has to be (at some point) some powerful process that selectively makes it be aligned.
- Even if a part was aligned, the general nature of entropy means there are many petty, trivial reasons that it could stop being aligned with little fanfare. (Though the mean-time-to-misalignment can vary dramatically depending on which part we're talking about.)
- So, it shouldn't be surprising when find that a complex system is broken in seven different ways for trivial and banal reasons. That's the default outcome if you just put a system in a box and leave it there for a while.
OK, but if that's the default state, then how do I explain the systems that aren't like that?
- Suppose we have a system that is initially working perfectly until, one day, one tiny thing goes wrong with the system.
- If people use the system frequently and care about the results, then someone will promptly notice that there is one tiny thing wrong.
- If the person who discovers this expects to continue using the system in the future, they have an incentive to fix the problem.
- If there is only one problem, and it is tiny, then the cost to diagnose the fix the problem is probably small.
- So, very often, the person will just go ahead and fix it, immediately and at their own expense, just to make the problem go away.
- No one keeps careful track of this--not even the person performing the fix. So this low-level ongoing maintenance fades into the background and gets forgotten, creating the illusion of a system that just continues working on its own.
- This is especially true for multi-user systems where no individual user does a large percentage of the maintenance
I don't think this invisible-maintenance situation describes the majority of systems, but I think it does describe the majority of user-system interactions, because the systems that get this sort of maintenance tend to be the ones that are heavily used. This creates the illusion that this is normal.
Some of the ways this can fail include:
- Users cannot tell that the system has developed a small problem
- Maybe the system's performance is too inconsistent for a small problem to be apparent
- Maybe the operator is not qualified to judge the quality of the output
- Maybe the system is used so infrequently that there's time for several problems develop between uses
- For an individual user, the cost (to that user) of fixing a problem is higher than the selfish benefits to that particular user of the problem being fixed
- Maybe no single user expects to use the system very many times in the future
- Maybe users lack the expertise or the authority to perform the fix (and there is no standard channel for maintenance requests that is sufficiently cheap and reliable)
- Maybe the system is just inherently expensive to repair or to debug (relative to the value the system provides to a single user)
Hmmm... I like the continuous maintenance model here, but I don't buy it as the main explanation for all the systems which aren't printer-like. As a counterexample: consider a table. Or a chair, or a whiteboard marker or toothbrush (which need to be replaced sometimes but don't have the deep-recursive-problems nature), or the chrome web browser (which works pretty consistently, and when it doesn't work a restart or reinstall basically-always works without any further recursive problem solving, even on my linux box). These don't require much continuous maintenance from the user(s).
It feels like there's something here about simplicity - e.g. tables, chairs, and whiteboard markers may have a surprising amount of detail if you look close, but they're still substantively simple in a way that printers are not. My current best articulation is roughly that printers have a more complex/narrower set of preconditions on their environment in order to work, whereas tables and chairs and the chrome web browser have a much simpler/more robust set of preconditions on their environment. The surprising detail of a table is mostly "internal" in some sense; it's in the design itself, not in the preconditions/assumptions made by the designer.
... but I'm not at all sure that that's the right way to think about it.
I guess it’s about entropy. Some items have more entropy than others. They have more parts and more possible states, and most of those states are misconfigured.
A table or a chair has most of its parts glued together in a fixed, low-entropy position, and has few parts to begin with.
A printer has many parts, both at the hardware and software level, and they can be in many states. It has paper, which can be in a state of having run out or not, and if it has run out, the supply can be almost literally anywhere. It has many intricate mechanical parts which can wear out at different rates, it has an ink cartridge that can dry out even when unused, and many intricate little parts that I don’t even know about.
On top of that, the software also has high complexity. Lots of software components, including the low level stuff that manages the actual printing, whatever needs to connect to the wifi, whatever is needed in case it can print from email, etc. all of these processes can run concurrently, which may introduce race conditions, any of these components may have a bug.
And then there’s the drivers installed on your laptop, which may be out of date, or your laptop’s drivers may be fully up to date but the printer software is out of date and your driver is no longer compatible with it.
Many components, many possible states, high entropy.
EDIT: also, I think a big part of it is that printers aren’t really tested for reliability. I used to work at a car manufacturer. Cars are hybrid software-hardware systems, and both sides of that equation are highly complex. Car engineering is a huge discipline that focuses aggressively on reliability. Even though car makers appear to come out with a new model every year, in reality they only change the cosmetics. The underlying platform usually only changes once every six years, and every version of the platform is aggressively stress tested in every possible way. The company I worked for had a test track in the coldest possible part of Canada, as well as in Death Valley, because reliability testing has to be aggressive and thorough.
Also the software side used special, hardened compilers that only supported a subset of the programming language, and were rarely changed. Getting a contract to supply a car company with a critical tool like a compiler is a hugely profitable multi-year deal, because they are happy to pay for reliability and reluctant to change something that is working well.
I bet nobody really cares about the reliability of printers to the same extent, and they have huh entropy, so they generally suck.
I would agree that, while reality-in-general has a surprising amount of detail, some systems still have substantially more detail than others, and this model applies more strongly to systems with more detail. I think of computer-based systems as being in a relatively-high-detail class.
I also think there are things you can choose to do when building a system to make it more durable, and so another way that systems vary is in how much up-front cost the creator paid to insulate the system against entropy. I think furniture has traditionally fallen into a high-durability category, as an item that consumers expect to be very long-lived...although I think modernity has eroded this tradition somewhat.
idk, i don't print stuff that often, but printing mostly just works for me. it's not always smooth sailing, but it's not any less smooth sailing than anything else i deal with when running ML experiments
I mean, I think running ML experiments is like the other most cursed thing that I feel like I have to interface with on a regular basis.
1I've been recently irritated at something that feels vaguely similar with regards to research loops. Walking through this example...
I note that most of those problems have little to do with the printing technology, and mostly about poor organization around that technology.
Friction sources
- Choosing which printer to use isn't trivial for someone who doesn't already know it.
- Counter-intuitive print dialogue which doesn't make it clear how to locate a specific printer/add a new one to someone who doesn't already know.
- The printer's physical location isn't clear from where you control it.
- The printer is not in the same room as where you control it. This means that if you have to iterate on printing due to (potentially minor) errors, each iteration is unnecessarily extended by having to walk back and forth.
- No fine-grained feedback on what the printer does from where you control it (that it only printed two of your pages and then ran out, that page 1 printed blank).
- Paper is not in the same room as the printer.
- Locations of things aren't trivially clear to someone who doesn't happen to know them.
- The printer's initial location.
- The printer's new location.
- Room 1A1's location.
- The location of the paper for the printer.
- The new location of the paper.
- Poor organization of printer output (that it just dumps everyone's print-outs in the same stack; not sure if that was a problem, but sorting that out can add friction too).
- Different printer behaviors depending on the software you print from, and what page you print, even though all entity types (documents, pages, function mapping from document-pages to physical pages) should be the same.
What common threads can we see?:
- Systems are not optimized to make it easy to interface with by someone who is using them the first time; someone with zero local tacit knowledge.
- Printer/room/paper locations, printer choice, print dialogue.
- Arguably (9) fits too: probably the different behaviors were due to some peculiarity of the printing algorithms in different software that someone very familiar with that software would know about.
- No affordances for easily recovering from common failure modes/errors/hiccups, or even for quickly learning about them.
- Paper in a different room from the printer, printer in a different room from where you control it, no feedback on printer behavior from where you control it.
I see a few directions we can take it.
- Direction #1: No affordances for one-time users.
- People who set up/modify systems are usually people who work with those systems a lot. They have tons of tacit knowledge about where things are, how to use them, how to avoid and recover from failures, etc. Modeling the mental state of someone who doesn't have your tacit knowledge is notoriously hard, and even when it isn't ("a random person wouldn't know where I moved the paper"), there are no established societal norms/organizational standards regarding making things frictionlessly easy for first-time users.
- Even when there are manuals/instructions/etc., they usually assume that you're going to be thoroughly figuring out how to work with that system, as if you aimed to become a frequent user, rather than doing a specific thing once and never interacting with it again.
- The problem is that "a person interacts with a system once and then never again" is a very common occurrence. For some systems (e. g., specific bureaucratic procedures), this is potentially the bulk of user experience; and on the flipside, "interacting with a system for the first time and never again" is a significant fraction of any given person's life experience.
- Direction #2: Systemic accumulation of small friction sources.
- All of those individual sources of friction were annoying, but ultimately not that time-consuming (figuring out things' locations, how to install/locate a printer, replacing paper, re-printing things).
- What made the whole experience miserable is that there were tons of those sources of minor friction which came into effect simultaneously.
- Thus, it's easy to see why the person responsible for creating each bit of friction didn't think of it as a big deal, or why we don't have societal/organizational standards regarding not creating such minor friction. (Consider that making a big deal of complaining about any given bit of friction in isolation would make you look like a loon/a "Karen".)
- But the problem is that tons of systems you interact with end up with these small bits of friction cropping up, so your ability to move forward is constantly mired down by that stuff.
- Direction #3: No affordances for quickly recovering from small failures.
- Some sort of default assumptions that things will go as intended, with no minor errors, hiccups, need to fix problems/iterate, etc.
- And as long as things-going-wrong doesn't create a big incident (e. g., someone dying with that as the clear leading cause), nobody is particularly incentivized to think about that and prevent that.
- So there are no affordances for easily recovering from them.
- But this pattern reoccurs everywhere, so a large fraction of the human experience involves dealing with them.
In what other situations does this show up? An obvious example are various bureaucratic procedures, which require some research to make sense of, and where a small typo/mistake in your documents might lead to having to schedule another appointment next hour/day/month. That is: a procedure you'd plausibly interact with only one/a few times in your life is managed by people who interact with it constantly, and the bits of friction you run into are not obviously catastrophic, so those people are not forced to make things easy for first/imperfect/inexperienced users.
Note that the full thing is not necessarily easy to fix, much like e. g. technical debt isn't[1]. The work to keep systems easy-to-interface-with is, as usual, a battle against entropy. Overall, I feel this problem is just another manifestation of that one.
Things could certainly be made much better, though, by both:
- Establishing high-level organizational standards/policies (e. g., keeping printer paper in the printing room).
- Creating low-level societal norms (if you moved paper somewhere, leave a post-it about that).
- ^
And indeed, technical debt is another instance, where, for programmers maintaining a codebase, it's no-one's first priority to make it easy to understand/modify/interface-with for a one-time user.
Potentially the "inconsistent printer behavior" is downstream of that, by the way. Perhaps there's no obvious correct/convergent way to interact with low-level printer software, so each app's designers had to take their own approach, so there are inconsistent behaviors across apps.
I notice that everything you list has to do with finding things. This matches my expereince. Printing is hell when ever I try to prin somewhere new. And since I print so rearely now days, this is the typical expereince. But I remember a time where I printed more often, then it was molsty just click "print" and it worked.
It seems like printers are built to be set up onece, and then be your forever printer? Which is no longer a good match for how you (and me) use printers.
A key problem is that the responsibility for the problem is separated over multiple different stakeholders that all matter.
- The printer company who's usually in the business models of selling you printer ink.
- The OS that manages the printer
- Software that wants to print
- Network sysadmin (different for each organization that has a printer)
- Facility management responsible for locations of printers / paper availability (different for each organization that has a printer)
In your example, it sounds like the main problem is with the facility management that doesn't seem to consider printers as something that they should organize in a sensible way.
When it comes to printing, many times I want to print, I don't really want to get a piece of paper but want to send a letter. Software like Google Docs could just give me a "send a letter" and "send a fax" button and let me pay for the service.
One aspect of this that i think is potentialy significant is processes which 'stick' in a non-working state.
I have on several occasions gone on the quest to find paper or ink, only for the printer to spit out 100 pages that other people had queued up when that resource was depleted. Those other people all, presumably, knew their document had not printed but decided not to get ink or paper. (Maybe their print wasnt that important to them. Maybe the instruction 'check paper in drawer B2' on an unfamilar machine was intimidating).
As i brought the paper/ink to the printer and reflected on the time it had taken, i consoled myself that it was now fixed, not just for me but for those who followed. I had unstuck the process for everyone. However, the queued up documents of people who had already given up, peehaps days ago, plus my print put us back into low-ink territory.
Compare this to stairs. Imagine i put an annoying to move barrier in front of the stairs somewhere. The first person would arrive, and remove it, and then it would inconvenience zero additional people.
I am not sure if printers jam, break oe run out of ink more often than most machines. I am sure that when they do they stay down longer.
A related contributing factor. Every organisation i have been in discourages printing when it 'isnt nesseaary'. This means that some of the people leaving the printer in the stuck position are doing so because they worry that if they start asking where the ink is kept someone might badger them about whether the print they are doing is nessesary. If people have a low level sense of guilt (perhaps enviromentalism related) when they are dojng somethjng they are less likely to ask for help in ways that draw attention.
some examples of things that may be like this, human generated list, varying confidence and specificity:
- nvidia drivers (reduced in severity now)
- drivers in general?
- interfaces between software in general?
- laws and regulations, sometimes
- social group conformance expectations, sometimes
- biology, especially immunology, especially drug design that has to bypass immune system
- prompt design for ais?
- robotic controller algorithms, especially for walking, especially for all-terrain walking
- robot software drivers (see: drivers)
some things that seem not like this:
- pure math (usually?)
- okay at least definitely not arithmetic
- fundamental physics? I mean there is the whole relativity vs quantum thing and that feels at all related but noncentral
- writing software near the beginning?
- playing most sports, as a human? tenuous
- drawing with a pencil
- using youtube, reddit, possibly any given widely deployed consumer software
the generator that feels live to me here is like, things where entropy* accumulates in interfaces or is generated in interfaces in the system somehow. many of them involve human-generated complexity, but that seems optional; seems like you can get this in pure math between conflicting formal systems, where you need a theorem connecting things even though pre-theoretic intuitively they're "obviously" the same thing (of course that "obvious" is sometimes wrong).
* except maybe not literally entropy, but rather like, boundedly-rational unpredictability. I guess by some definitions that's entropy - the definition would involve microstates not predicted by a macro model, and in this case the macro model would be the simple view of a system.
1pure math
Actually, I have been diving into some specific topics lately, and simultaneously formalizing the theorems in Lean to help with understanding. The amount of omissions and handwaving going on in "proofs" in textbooks is insane. (To the point where I am not smart enough to figure out how to fill in some omissions.)
And I know that textbooks often only present a summary of a proof, and cite a more detailed source. But sometimes there is no citation at all, and even in cases where a citation exists, it might not contain the missing details.
seems like you can get this in pure math between conflicting formal systems
Hm... I don't feel like this is what's happening in most cases I encounter? Once I have a detailed pen-and-paper set-theoretic proof, it's mostly straightforward to translate that to Lean's type theory.
Printing with my printers sucks - but e.g. my university has a nice upload service where you upload documents to a website and scan a card at one of multiple printers and can print; and those have always worked like a charm for me. So why is printing sometimes... easy?
There are many perverse incentives in this field.
Companies lose money on printers so are not incentivised to make them better
Customers don't see printers as a purchased good to be optimized, but rather an annoying cost to be minimized
Both see the technology as old and obsolete and only still being used because of ignorance and cheapskate government agencies and companies who haven't gone digital yet, so there is only downward pressure on quality. No luxury models or frontier of development etc.
I don't know that anyone is actually rewarded for trying to make things better.
Two easily solvable problems here.
No paper
Say, I want some tea. I go to the kettle and see no water there. Okay, I look for the water to discover that water filter pitcher is also empty. I'm looking at the kitchen sink to pour some water into the pitcher, but see that it is overfilled with dirty dishes. I open dishwasher to see the dirty dishes there too.
So you have some resource (filtered water, paper) that could run out when it happens unexpectedly it takes time to refill. However marginal cost is minimal - taking 2 packs of paper vs 1 is trivial compared to looking for where to take the 1st one.
Solution: have a reserve pocket of resources stashed nearby, with clear common knowledge that whoever takes the reserve, must refill it and also refill the main stack. For example, have a pack of paper in clear vicinity of your printer marked as reserve; with clear indication that it is reserved, and you have to refill it. Having a coffee maker that can be used as a source of filtered water. etc.
Don't know where the paper is
See also: what the heck this script does? Or: what is this assembly kit for?
Solution: readme. Put a sticker on the printer saying where the paper is, and also saying to update it if it is not true anymore. Add readme.md to the folder with the script. Put a little note saying what assembly kit is for in the ziploc with the kit. Context dependent helpful notes are very underappreciated.
General observation
- If nobody takes care of things, they tend to break.
- Statistics on when things break is adversary. There is no Pauli exclusion principle that prevents two events from happening simultaneously. If anything, one thing breaking increases the probability of other thing breaking.
My workflow in last 2 jobs, if I already printed something in last 3 months:
- print the document
After a change of laptop / floor / other size instead of the usual A4 / fiddling with booklets / ...:
- go to the printer
- follow instructions on the printer (usually just filling the IP address on a Mac, but I once tried testing a web app I was developing how it prints from virtual Windows when testing.. permissions were fun)
- print it
- realize some Unicode characters in some heading fonts in a PDF from Firefox preview didn't work
(or something) - download the stupid PDF and print it again
- fill the paper from the cabinet next to the printer
- remove chewed-down page, confirm everything is fixed, let the printer finish and re-print whatever is a mess
- or set higher DPI if needed for images and re-print
- or sign the document, scan to email, and shred the paper (because they didn't like my electronic signature and asked me to do it for expense report or something where I have to sign-in anyway)
- (not very often) debug our web app for a couple of days to convert position:absolute gantt chart into actual html table that can be paginated with repeated headers and footers
- and find the least worst CSS for page orientation and margins and default zoom and logo resolutions for most common DPI that looks reasonable in at least some browsers
- figure out which backgrounds make sense to force-preserve (icons) and which to remove by default (whole-page background)
- preserve order of text when printing to PDF and completely remove hidden text so that search still works in various PDF readers (reasonably-ish)
Almost forgot - being in a hurry almost certainly triggers the second path through the workflow.. no idea what's the mechanism for that tho, probably availability bias.
Maybe this works: Buy a printer that is known to work correctly with a driver that is included in the Linux kernel.
My Claude says this:
There is a standard—IPP—and if universally adopted, it would mean plug-and-play printing across all devices and printers without manual driver installation, vendor software, or compatibility headaches.
But printer manufacturers have weak incentives to fully adopt it because proprietary protocols create vendor lock-in and competitive moats.
Standards require either market forces or regulation to overcome individual manufacturer incentives to fragment. IPP is gaining ground—Apple's AirPrint is basically IPP, forcing many manufacturers to support it—but full adoption isn't there yet.
The "why don't we just" question usually has the same answer: because the entities with power to implement the solution benefit from the current fragmentation.
As for the magically moving printers. That is just people being incompetent. If you have a printer you should give it a name according to the room it is in, and your rooms should be labeled sensibly (e.g. have floor number, and cardinal direction based on where the nearest outside wall is facing, etc., in the name.)
Curated and popular this week