3 ms·

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 i

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.

ryandrake 3y ago
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.
- andybak 3y ago
  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.
- michaelmrose 3y ago
  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.

ryandrake 3y ago

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.

andybak 3y ago
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.
michaelmrose 3y ago
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.