I think the tweet in the opening screenshot is simply wrong. I would argue that you almost always want paste to preserve the pasteboard formatting. Most copy/paste is within the same document, where you obviously want the odd bolded or italicized word to retain its formatting. But you don't notice those cases, because everything is working as expected. What you notice is that when you paste from an external source, the formatting is completely wrong.
I know that this is tangential to the point of the article, but it highlights an important point: you can't always trust what users say they want. You need to listen to them, because their frustrations point to real problems, but finding out what the actual solution is involves more work than just taking the user's suggestions at face value.
I almost never want paste to preserve any formatting, because I've almost never seen it work perfectly. If I need to reformat it anyway, I'd rather not have to clean up its messes first.
BTW in most programs that handle rich text, SHIFT-CTRL-V does a plain-text paste without the source formatting.
this. the sheer volume of times i have to paste text into a notepad or a URL bar or just any space that will lose the formatting, just to re-copy/paste it into some (usually MS) product that wants to preserve it is way higher than it should be.
I suspect that a more nuanced approach could suit general users the best. Retain boldness, italics and underlining, change to fit target colour and font.
Boldness, italics and underlining actually denote meaning, whereas font and colour are generally just aesthetic
In real Desktop Publishing software, text (content) and its style (layout) are separate — the text usually comes in from an external source (e.g. a file on an SMB share; a document in a CMS) and can be updated independently of the layout.
The linked text format is usually Rich Text (RTF). This allows a lot of things, but the Desktop Publishing tools only interpret the tags for bold, italics, underline, and a few other things (strikeout, subscript, etc.) All other styling in the linked text, they throw away.
This is precisely because, as you say, those specific styles actually denote meaning. They're something the writer adds. No other styling is used from the linked text, because none of the other styling is the writer's job.
All other styling is instead applied to the block(s) within the layout where the text gets embedded into. It's the layout designer that gets to decide the font, size, spacing, etc. for the text. Those attributes aren't stored with the text; they're stored with the layout.
To me, this makes far more sense as a workflow, even if you're a single author. I constantly wish that "word processors" had restructured and absorbed ideas from Desktop Publishing software when it came about. Instead, we got the garbled hybrid: you can have "document styles" like Title, Heading, Body, List Item, etc.; but they are essentially markup, moving around with the text (rather than there being any concept of an "section of the document" that gets styled, that text can be moved into/out of, and where the styles of that section will apply to the text only while it remains inside that section, such that moving text out of that area doesn't copy the styles of the section, only the styles of the text.)
In my case, I almost always want paste to override most formatting — if I copy something from a website, I want it to match my formatting.
What I'm looking for, though, is particularly for the font itself, the font color and maybe the size to match. If something is bolded, or italicized, that should ideally be retained.
A good configuration could be to ask whether you want the formatting of what you're pasting to match the document, and then ask if they want to set that choice as default.
Not only that, but I think the "average user" probably has lesser taste than the tweeter. They see a blue font on the text they are copying from some random web page, they expect a blue font when they paste it. This would be especially important to the average user if they are copying a lot of text with bullets and headers.
So the tweet may be describing a better practice for many use cases, but it may not be the practice most people want.
So if you make paste match the formatting of the destination not the source, both you and the tweeter are happy. Make a funky shortcut to override this if you want but this should be the default.
* Copying formatting works well and is desired when it is done within an app but it is janky and undesired when the apps are different.
I furiously hates copying/pasting of formatting. After reflecting, the problems all exist when I'm pasting from one app to another.
I just think out of the apps I use, the ones where paste with formatting is the default (eg it's what CMD+V does) are the ones where I'm usually pasting from somewhere else.
Is there an option in Word to change the default paste? I think that's what many of these opinions boil down to, and while I imagine there's hundreds of opinions on even the smallest thing I suspect many of these large pain points could be solved relatively easily if those in charge had a vision like the article is suggesting.
I agree, I often copy and paste to a basic no-formatting text editor and back just to clear formatting, eg before pasting to an email or whatever. I rarely want formatting retained when pasting to/from emails. Same when copying from a website, as someone else here mentioned.
>I would argue that you almost always want paste to preserve the pasteboard formatting.
Perhaps you should consider asking the user what they want by just giving them options. No need to prematurely break your software. (which is what most good software does now.)
I use copy/paste in powerpoint explicitly with the intent to copy over the formatting of the original to the destination deck. Easiest way to add a theme to an existing deck.
I know that this is tangential to the point of the article, but it highlights an important point: you can't always trust what users say they want. You need to listen to them, because their frustrations point to real problems, but finding out what the actual solution is involves more work than just taking the user's suggestions at face value.