Yeah, proponents of cross-platform frameworks love to ignore the second half of "look and feel". It's ridiculous to claim that a web app can behave like a native app when even Qt apps still tend to have obvious tells.
Slick web apps are taking over the software world, whether the likes of Apple want them to or not. Looking like any specific native platform is less important, if it's even relevant at all, in an era when users are working with different web apps each with their own look-and-feel all the time anyway.
Does it matter? Yes, of course. The desire for consistency and usability may not be strong enough to reverse the current trend away from native apps, but that doesn't remove their advantages.
And I find it very telling that even your own comment continues the trend of over-emphasizing look over feel. I'd be happy with apps randomly launching in night mode, if they would just have all the right controls in the right places, and have the performance and memory footprint of native apps.
The problem with that argument is that you're assuming consistency with native platform standards is the dominant consideration. I contend that, today, it often is not. Many users are spending much of their time using web sites and applications rather than native ones; this trend does not appear to be in dispute here. Moreover, the basics of how web sites (and by extension web apps) work have a longer history of established conventions than any of the major native platforms; the likes of Jakob Nielsen were making the case for consistency and following user expectations more than two decades ago, long before the likes of iOS and Android and whatever we're calling Windows' UI today were glints in their respective creators' eyes.
Also, web technologies can perform just fine the vast majority of the time. Modern JS engines have excellent performance, obviously not rivalling expertly coded C and assembly, but certainly comparable to your average native application for most purposes. Modern browsers also have good support for hardware acceleration and can render UIs that respond quickly enough to user interactions that again for most purposes there is no perceptible delay or jank. Today we're looking towards WebAssembly as a vehicle for potentially more efficient languages and runtimes, though clearly that technology is still in its infancy and its future is far from certain. Now, you can undermine all of that potential if you bloat your web site/app with tens of megabytes of junk scripts that are all competing for resources and blocking stuff and phoning home and whatever, but that's not really the fault of the web technologies, it's just bad developers and/or bad managers creating a bad application.
> Moreover, the basics of how web sites (and by extension web apps) work have a longer history of established conventions than any of the major native platforms;
That "and by extension web apps" bit is completely wrong. The long-standing conventions of how web sites work are mostly irrelevant to fancy web apps, and to the extent that they are relevant, web apps break them left and right. Just look at how many web sites/apps hijack or break scrolling or the back button or the ability to middle-click on a link and get a new tab or the ability to highlight text. Web apps are all about breaking the usability standards for web sites and replacing them with a bastardized version of the usability conventions from various native OS toolkits. 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.
Just look at how many web sites/apps hijack or break scrolling
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.
I keep hearing the "web technologies are fine, you're just using them wrong" refrain over and over again, but it's ultimately not very convincing. If it's true, then where are all the good web applications? I've certainly never seen any of them. Can you give an example?
If nobody can get Web technologies to deliver a good experience, then I'm not sure it matters that much whether or not it's possible in theory. Delivering a theoretically great user experience won't get you anywhere unless it also translates to practice.
What do you consider a good application? If you have never seen anything that would qualify on the Web then I have to ask what standards you are seeking and whether any software actually meets them.
At least for the purposes of comparing to web apps, the criteria would be: responsive/low-latency (responds to input quickly), fast (completes tasks quickly), uses resources proportional to the functionality it provides, and doesn't often hang or spend noticeable amounts of time waiting for a network request before responding to an action.
Applications that meet these criteria include: Thunderbird, KiCAD, VLC, Vim, tmux, Blender, evince, Handbrake, and Pidgin.
responsive/low-latency (responds to input quickly), fast (completes tasks quickly), uses resources proportional to the functionality it provides, and doesn't often hang or spend noticeable amounts of time waiting for a network request before responding to an action
That seems like a fairly low bar to clear. Aside from the network request issue, I think every web application I've worked on for a decade or more would tick all of those boxes, from intranet tools to browser-based interfaces embedded in device firmware. I'm sure there are many others in the industry who could say the same. A lot of the things I'm thinking of are for internal use, but in terms of public examples, you can just look at most of the successful big-name business SAAS applications, and they tend to be strong on these requirements as well. Ease of use is a huge selling point for attracting customers, and no-one is winning points by being clunky in their web GUI in 2020.
Network speed and reliability is a different issue, and obviously many web applications are particularly vulnerable to problems there because they have such a strong communication element. But then the same is true of native applications that are for communication or a front-end to a client-server system like a central database.
Applications that meet these criteria include: Thunderbird, KiCAD, VLC, Vim, tmux, Blender, evince, Handbrake, and Pidgin.
That's an interesting set of examples. The other point under discussion was about whether web applications cause usability problems by deviating from native platform UI conventions. I can't help noticing that several of the native applications you mentioned there do exactly that.
For example, Blender's UI was infamous for being so unusual that anyone coming from other 3D modelling software found it hard to use, and for looking and behaving nothing like a conventional native application on a platform like Windows. Eventually, that became so much of a problem that they basically rewrote the whole UI layer to work in more conventional ways.
Handbrake has its good points, but its interface looks like a GUI from the early 2000s where the designer just threw as many different types of control onto a form layout as they could manage.
Thunderbird also has its good points, but its UI is incredibly glitchy in some areas (dragging and dropping comes to mind) and it definitely fails to meet your fast and responsive criteria at times.
I agree with that. I've been struggling with that on a web app I've been working on.
Part of the problem is a new twist on the old problem. I don't have to develop for Mac and Windows and Linux, I have to develop for Desktop PCs, Tablets, and Phones. My options are to create a GUI for each of them or use something like Bootstrap to build one that runs on them all, and that has limits and trade offs, but it's still pretty good.
One of the things I've done with this upgrade is provide a way for the user to store their data in the CouchDB native app running on their desktop PC. It's a "local-first" and "offline-first" web app so once it's installed it doesn't need or use an internet connection and while I have no way of making a comparison it appears to me to run pretty close to native app speeds.
When CouchDB is installed on the user's desktop PC any web app configured to use it can use it. It only requires the user fills out a simple web form to set up a user and database for the app.
Taken together, a modern web browser and CouchDB come pretty close to fully featured client side runtime environment for desktop PC web apps. It wouldn't be too hard to create a web app that looks and feels very much like a native app when running full screen on a Mac and Windows.
A client side runtime for web apps is something I've been thinking we need since I built my first web app and that was before they were even called "web apps". I'm not the guy to make that, but I think we need it. CouchDB and a web browser come pretty close.
I don't disagree, but I think you could say the same about native apps too. For this discussion, I think the most important thing is what good examples of each type can achieve, since presumably those are the ones that most people will choose to use.
>"I don't disagree, but I think you could say the same about native apps too"
Of course I could. I was just countering the original point that sounded that web apps are slick just because they're web apps. Making good GUI is hard (well I'd skip Hello world here).
I was just countering the original point that sounded that web apps are slick just because they're web apps.
Sorry, maybe that was written ambiguously, because that wasn't the intended point at all. The point I was trying to make was that the web applications that are slick are taking over the world. Being polished and easy to use is a big advantage, and IMHO there's been a lot more progress on this front in web development recently than in native applications.
In contrast, the mobile platforms are far too much style-over-substance and have glaring usability problems as a result.
Most desktop applications haven't really changed their basic form for decades, they just show up with flat icons and kindergarten levels of bright colours these days. That does mean here is a level of consistency and familiarity, which is valuable. However, it also means most of them aren't benefitting from decades of further experience and research in UI design and from newer UI patterns coming out of that experience that have proved to be effective in other contexts.
Figma falls into the trap of all other claimed high performing web apps, conflating maintaining a 60fps refresh rate with responsiveness. Try dragging any object around (even simple shapes) and you'll see it trail the mouse cursor in Figma. Does not happen in OmniGraffle. The result is a distinct difference in feel.
Can any person in the planet edit the same document than you in real time, for free, running hardware up to 5 to 10 years old, in < 3 min after receiving a link with Omnigraff ?
Because that is the main feature of figma. Latency of mouse issues is a good trade off from my POV.
I always hear about these theoretical web apps that are just as good, nay, better, than native apps. Where are they?! Certainly no web app I ever used would qualify...
The fact you can just run it without installing anything makes up for a lot of faults (doubly so when the vendor isn't Microsoft but somebody nobody's ever heard of).
On the flip side, most web apps don't offer their full feature set without requiring you to go through a sign-up process that is at least as onerous as downloading and unzipping a Mac app bundle. Even when a web app outsources authentication to something like Facebook, there are still at least as many clicks.
Isn't that curious then, that Apple is forcing some developers to turn to web-based solutions [1,2] instead of encouraging them to actually create native locked in experiences?
Seems to me that there's less of a "apple is purposefully malicious towards PWA because of their master plan for platform lock" and more of a "apple has a very long history with being completely incompetent on the web (see: icloud as a whole, safari now slowing standards adoption, newer web endeavors like the apple music app) which in turn is slowing PWA adoption because they now own one of the most dominant mobile platforms.
> It's totally possible to build a PWA that behaves like a native app but Apple actively tries to destroy them.
Ugh, no. No it's not. At least not yet.
Accessibility features alone are almost always woefully crap in web-apps, compared to what native apps have access to, at least on macOS (and SwiftUI is amazing in how it lowers the barriers in implementing accessibility in your app from the get-go.)
Shit like Electron and PWAs seem to be championed by user-hostile developers that just want things to be easy for themselves, without considering what's best for the users and their hardware resources.
Shit like Electron and PWAs seem to be championed by user-hostile developers that just want things to be easy for themselves, without considering what's best for the users and their hardware resources.
There is a standard counter to that argument at this point. Developers on native platforms might be able to achieve a better experience on that platform than a web app given the same time and resources. However, if the time and resources have to be split N ways to build a native app on each of N platforms, compared to investing everything into polishing a single web application, the outcome might be very different. While each native developer is still worrying about whether they're aligning and labelling a button in the platform-standard way, the web team is already refining their UI using the results of their third round of usability testing and has determined that the button shouldn't have been there in the first place and designed and implemented a more intuitive UI. And since they launched their version 1 two months earlier than any of the native apps did, they even have the extra revenue in the bank to pay for those usability tests, too.
> While each native developer is still worrying about whether they're aligning and labelling a button in the platform-standard way, the web team is already refining their UI using the results of their third round of usability testing and has determined that the button shouldn't have been there in the first place and designed and implemented a more intuitive UI
Your hypothetical scenario seems to be treating the app's UI as if it exists in a vacuum, rather than existing alongside other apps.
If there's a platform-standard UI convention that applies to a button, then UI testing in the context of that platform is probably not going to tell you to remove that button entirely—you shouldn't be surprising users by removing functionality they expect to find present. And if there is a UI convention that tells you how to position that button, you probably shouldn't A/B test the positioning of that button and should focus your usability testing on the UI elements that are not dictated by the platform's standards and conventions.
Your arguments use the word "probably" a lot. As someone who does a lot of UI design professionally, I prefer to rely on the kind of user testing you apparently dismiss, precisely because prior expectations about what works well so often turn out to be inaccurate. Indeed, there have been plenty of native platform standards that have awful usability in recent years, which have rightly been criticised for it by professionals wielding empirical evidence.
> Indeed, there have been plenty of native platform standards that have awful usability in recent years, which have rightly been criticised for it by professionals wielding empirical evidence.
Platform native UI conventions are very often sub-optimal, if only because they're old. But sub-optimal standards are very often preferable to unpredictable, and are definitely preferable to having to juggle multiple conflicting UI conventions at the same time when multitasking. That's why we still have QWERTY, and why all the surviving scrollbars are on the right, and why pie menus never caught on.
You say you test UI designs professionally, and claim the higher ground of having empirical evidence. 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?
Platform native UI conventions are very often sub-optimal, if only because they're old. But sub-optimal standards are very often preferable to unpredictable
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.
> 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.
I'm surprised to see you mentioning the flat design trend as something you consider "old" in any way. I see it as a fad that is past its peak but still far too prevalent to regard as being in the past. And when I was talking about platform native UI conventions, I definitely had older stuff in mind than Windows 8.
> 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.
See, this is the biggest problem here. I'm talking about usability and value to the user. You're talking about optimizing the UI to exploit the users for your maximum profit. Those two motivations are obviously not well-aligned, and if you're on the side of that divide where the ad-tech stuff is, then you're not even trying to have the same conversation I'm having. Your incentives are to maximize the user's engagement with your product, so of course you don't care about how well it fits into their multitasking workflow; you want to monopolize the user's time.
I'm talking about usability and value to the user. You're talking about optimizing the UI to exploit the users for your maximum profit. Those two motivations are obviously not well-aligned
I could not disagree more strongly. I have built a career built, in no small part, on a simple business model of creating software that users like because it's easy and works well, and consequently attracting and retaining happy (and paying) customers. This has absolutely nothing to do with ad-tech, which I generally regard as a toxic business model for exactly the reasons you're arguing.
PWAs are extremely user friendly in one dimension: they frequently take 1-2 orders of magnitude less space. This is very relevant for low end devices, and has been one of their biggest selling pints since inception.
I think so. If we're talking about "out of the box" or what you'd find on average. As an Android dev for a few years now I think we get a lot out of the box and I get that web devs also use libraries or frameworks that have similar benefits. At that point it's comparing framework A's a11y vs framework B's a11y vs Android a11y.
Not an Android fanboy but I'm going to assume that the bigger (widely used/constantly iterating) "platform" (for a lack of a better term) has better a11y. And if there is a web framework that provides this (react?) do the majority of websites use it ? like they do native api's for native apps
(and this isn't even talking about the api's accessible to native vs web app)
Apple is definitely not developing cross platform. Swift the language is cross platform. But the SwiftUI is only "cross platform" within apple's different devices. A true cross platform is when a SwiftUI app would work on Android.
Native OSs can be built to be "cross platform". For example, the OpenGL API. The same API works on different OSs, developers can code against the same API and it works on different OSs. In an ideal world, maybe there could be a standard API for presentation controls, UI drawing, animation, 2D/3D graphics, networking, filesystem access, threading and more. Each OSs would implement the same API and add additional platform specific APIs to differentiate themselves. The key is application developers would have a common core set of APIs and language to implement the 80% business logic and UI logic.
Note, this is essentially what HTML, JS and CSS is doing. But the web platform is creating a runtime that exposes APIs to do a lot of different things. A CSS transform a single API that causes the DOM to animate in specific way. There are thousands of these APIs, and the runtime implements all of them. This is why the web runtime itself heavier and it takes 100mb just to show something simple on web platform.
For flutter, the core engine is just a 2D drawing surface, the APIs it exposes is just drawing shapes. And all of the widget self contains rendering, various settings and the application pulls in the widget used in the app. This makes the runtime smaller. Flutter is more efficient because the abstraction is lower and the core runtime is trying to do less things. On the scale of level of abstraction, flutter is on one end and the web platform is on the other. For our ideal OS platform, we can select the right level of abstraction to balance between performance, standardization, and flexibility.
But in the real world, all of this require collaboration between OS vendors. Apple's business model is try to sell more IPhone, Mac, Apple Watch, IPad. They make the argument that Apple's platform has the best apps that isn't available on Google's or Microsoft's platform. And this actually works. Why is Android tablets not taking off, and IPad Pro is? People buy the IPad Pro for apps like Notability, Photoshop and more. People still buys Windows and not ChromeOS because its got native Photoshop and Matlab. These apps are coded using Apple's or Micosoft's language, frameworks and APIs. And that exactly is what is preventing these apps from appearing on Android and ChromeOS easily and reducing people's need to buy Apple and Microsoft's devices. While these vendors may not say they are actively trying to lock in developers. They definitely don't want the some developers who coded an complex application for their platform to easily move it to another platform. If this transition cost is too low, it doesn't play into their business model. Their business model pushes them to differentiate their platform against others, and as a side effect, it increases the barrier and transition cost.
This is a tug of war between application developers desire to have all platform as similar as possible, and the platform owners desire to differentiate their platform and prevent other platforms obtaining the same capabilities as my platform.
Desktop apps got the permission model all wrong. You run a program and that grants them access to everything.
The web's model is closer to that of mobile apps. It asks for a permission at the time that it's needed. Not all sites get this right, but browsers are starting to crack down on requests the moment you enter a site.
I've heard of Ionic/Cordova which gives JS apps the ability to access native APIs, but haven't used it to see if it's truly capable of all functionality
This is why Apple should be forced to allow multiple web browser rendering engines on iPhone. Cause they're so damn anti-competitive and being forced to develop for Safari makes developing web apps horrible
This is why Apple has been so hostile towards PWAs.
It's totally possible to build a PWA that behaves like a native app but Apple actively tries to destroy them.
There will never be a viable hybrid app platform.