i too have this story from the dark ages of computing, when my colleague asked how to make a pdf from an excel file. i told them to choose the menu item "print", then choose the PDF-program as a printer and then click on "print". they walk away immediately, come back, grumble at the computer... i ask what's wrong "nothing, nothing, tell me again: print, PDF-program and then print, correct?", they walk away again and finally come back "i found nothing at the printer, where is my PDF !?"
lol I've had this exact same occur multiple times... basically every time we have staff turnover in our condo office no one knows how to print to pdf... so every year or two I have to show someone how to do it, including up to 2022.
My pet peeve is that even in 2023 I still receive scans of printouts from accountants. They print out their reports to add cover sheets and add pages, and then scan it back in to deliver as a financial statement.
Great example of terrible software UX that we just put up with. I want to save this file onto my filesystem as a PDF file. Why the hell do I need to choose “Print” to do this?? If you are a developer, you might know the reason, but as an end user, this is baffling and totally unexpected. Just put “PDF” as another option in File->Export, where it makes the most sense to an end user.
Or, even better, developers, just use the “Save” function, not “Export”. Why we have to separate “Export” from “Save” is another terrible UX that only makes sense to developers.
If you see something that you believe only makes sense to developers odds are it actually DOES make sense in terms of the underling model that the application is working with. For instance the way save works is that you save your file as foo.txt subsequent saves automatically write further changes to the chosen file in the chosen format. If you "save as" again you change what the active file and format is. So for instance you "save as" foo.docx. Subsequent saves go to foo.docx and foo.txt stays as it is before the "save as" and you could open either one an continue where you left off.
Now take PDF a piece of shit format able to submit remote forms, execute JavaScript, and render and manipulate 3D models. Its a garbage application formation masquerading as a bad document format.
It makes sense to produce a pdf as a snapshot of the document but it makes zero sense to treat it as txt or docx one doesn't simply "save as" pdf and then continue editing in that format. If you use save for this feature how do you express the fact that you don't want to make foo.pdf the new default save target especially if you can't subsequently open it? Do you just silently not do that? This violates good design where observable functionality reflects as much as possible the comprehensible part of the user model you are presenting to the user. Having save as silently work differently when targeting an output only format is a bad solution.
Save vs Export expresses the underlying reality. You see the same conceptual reality where you are creating multimedia and the output format is lossy.
This is part of what I'm complaining about: There often _is_ a technical reason (occasionally even a good technical reason) for why the software is made a certain way, but those reasons are things that should only be relevant to the developer, not to the end user. The end user should not care about the "underlying model" or the "active file format". The software should "just work", and the frontend developer's job is to make the right judgment calls and hide irrelevant underlying nuance and complexity from the user. Great software doesn't "ship the org chart" or "ship the class abstractions".
If there really is an important power user case, provide an Expert Mode for those who care about the underlying model. That way, users who care about the lack of editabilty of PDFs or who actually mentally distinguish between lossless source material and lossy outputs to lose nothing, but other casual users gain a lot when these things are done for them.
Providing export to PDF while allowing save to docx is what allows the user to completely ignore virtually everything about the underlying model at the expense of one additional menu. All the model they need is in knowing how to operate a standard menu.
99.99% of document editor don't open or edit PDFs for a reason and doing otherwise is incredibly impractical.
You are best case asking to literally treble the scope of the app to go from one menu to two and because PDF is a giant piece of shit the result will probably be substantially more buggy.
We either need to seamlessly handle the mismatched formats whilst handling complexity like embedded documents or the users mental model now must encompass what features work in different formats. In all likelihood we end up in the worst of all possible worlds where it's a little bit of both.
Then the experts who actually care about sharing working documents now have the functionality they need hidden in a special mode which by definition few will ever learn about while received wisdom will end up being not using PDF or printing and scanning.
If you special case save as *.PDF to produce a PDF but not change the active save target to avoid lovecraftian horror you avoid most of the above but now save as a feature most people understand works different in your app than everyone else's.
The people who have export menus aren't stupid, you aren't actually smarter than them, you should at least understand why the fence you want to bulldoze exists it exists for good reason.
How about this. Some formats are severely lossy. Users are used to "save" not being lossy. If they misunderstand the capabilities of a format then they can irretrievably lose data.
"Export" is an attempt to make that less likely.
Some misunderstandings are more serious than others.
There were reasons for it even developers didn't understand.
PDF is actually Adobe PDF and you had to use the Adobe PDF Creator to create PDFs. To be able to save to PDF by a 3rd party application would have meant licenses fees to Adobe. So some clever guys came up to "misuse" a printer library for PDF creation...
Today in Libre Office, of course you find a button to _save_ directly to PDF. Not sure about MS Office though.
>Why we have to separate “Export” from “Save” is another terrible UX that only makes sense to developers.
I'm actually torn on this one. I can see where you're coming from, but I can also see value in the conceptual separation between saving a file in a form which can reloaded with full editability, and exporting it in a foreign format which effectively freezes it in its current form. Commingling those two concepts does cause significant confusion in non-technical people.
Having said that, I still swear whenever muscle-memory from 20 years ago tricks me into trying to File->Save a .tif in GIMP, and instead of doing what I want, it lectures me about how I should use File->Export instead, like some bratty kid playing "Simon Says".
mind you, it was 2022