Goodbye, Native Apps

The reason that junk like flat design and derivatives like Material Design are awful for usability has nothing to do with being old and everything to do with being unpredictable. Often, a user literally can't tell what parts of an interface are interactive or how they work, because affordances barely exist. It's like the old mystery meat navigation meme for web sites, except they actually did it seriously and thought it was good.

But it still sounds like you're using worthless methodology by focusing only on your one app at a time and ignoring how it fits into its environment and the user's broader workflow. Is that correct, or have you actually quantified the overall productivity loss an app introduces by violating the user's expectations and habits?

Well, firstly, a testing methodology is literally the opposite of worthless if it gives you an objective measure of the increased financial value generated by a change under consideration.

Secondly, you assert without evidence that the kind of change we're talking about does violate the user's expectations and habits, and you further imply that this causes a loss of productivity. As I have argued in earlier comments, the assumption that the user's expectations are governed primarily by their native platform's conventions is not necessarily valid any more, because users spend so much of their time inside a browser using online facilities instead of other native applications.

Moreover, the answer to your other question is yes, we have done many tests over the years that compared options including the native approach on various platforms with some other options we were considering. In the nature of such tests, the outcomes varied. In some cases, we did end up going with presentation similar to the native conventions on one or more platforms; often this coincided with cases where the native conventions across major platforms were similar as well. In other cases, we went with a completely different presentation style, as performance with the native conventions was significantly worse.

The point of all of this is still that ideally you don't want to make UI decisions based on assumptions or dogma if you could try different possibilities with real users and make your decisions based on objective evidence instead.

Hardly any? That's been a minor trend in web sites for a while, but changing scroll behaviour for no good reason is widely regarded as an antipattern by UI professionals. I don't recall ever seeing normal scrolling behaviour subverted in anything I'd call a web application.

or the back button

This is a tricky one from a usability perspective, because some users see URLs as shortcuts to particular parts of a web application and expect the back button to behave accordingly as they navigate information in the app, while others think of the whole application as being a single page and expect the back button to just leave everything. But there is a whole set of browser APIs for managing that behaviour, and it's something a well-designed application will at least present in a consistent and logical way.

or the ability to middle-click on a link and get a new tab

This sounds like you're talking more about web sites than applications again, and again it also sounds like you're talking about bad design that web UI professionals would universally disagree with. It's usually caused by newbies who read some style-over-substance tutorial and decided that making links or buttons with elements other than the designated anchor and button ones that exist for that purpose was a good idea. After the first few glaring usability problems, they'll learn better.

or the ability to highlight text.

I don't really understand this one at all. The only times you wouldn't be able to highlight text in a web application would be if the designers have actively prevented it, for example to prevent selecting UI labels along with the content of a text field. This typically works exactly the same way as any native desktop application.

But in spite of that, nobody ever really expects drag and drop or rich copy and paste or any other data exchange mechanism to work between web apps.

I don't know what you mean here, either. Dragging and dropping text between web applications typically works fine. If by "rich copy and paste" you mean other more complicated data types, what happens is obviously highly context specific, but once again, this is the same story on native desktop applications. It's not as if you can copy a selection of spreadsheet cells and paste them into a drawing package with obvious and meaningful results either.

As a final comment, the examples you're talking about here all seem very "meta". As such, they're not particularly interesting to me, because as a UI developer working on a web app you generally get the expected behaviour by default with these kinds of things. Sure, some people can and do break them. They're just bad UI designers. Some people make native applications with shocking pink skins over the normal window dressing, too, but that doesn't mean all native apps are bad.