Convopage
See the entire conversation
So the way I see it, there are three aspects to this problem.
1) Investment
2) Technology
3) Culture
Gonna need more than 280 characters for this one…
A thread:
Switched from the Facebook app to the website. The web animations are disappointing. The app has pleasing, smooth animations; the website lacks some animations altogether, and in other places they're jittery. Are web animations a lot harder, or is it a matter of investment?
213 replies and sub-replies as of Dec 13 2018
1). Investment:
Companies are pushing everyone towards their native apps. The web is littered with “open this in my app” banners that destroy whatever semblance of a good experience could have been on the web site anyway, making the average mobile-web experience *terrible*.
It’s an implied statement of “we don’t believe the web is good enough for mobile, so we don’t even try”. This behavior perpetuates the culture and is a self-fulfilling prophecy: If we put banner ads to leave the web all over, then it *is* worse than a native mobile experience.
It’s not just app install ads though. Most web sites have way more annoying ads than their native app equivalents. Why?!
And because everyone is stuck on the “responsive design” train, we just “squish” all those ads down into the small viewport of a mobile device so that the mobile web experience is *even worse* than the desktop web experience.
There’s some nuance around how we got into this state… there’s real business advantages to having someone installing an app (semi-permeant) rather than browsing a web site (ephemeral).
But now the expectations of the web are so poor that if someone really tries to invest in a Good Mobile Web App, they will be let down because users aren’t giving them a chance anymore. They want a native app, and the numbers are showing it.
2). Technology:
It’s amazing that anyone really builds anything at all on top of DOM / JS. It wasn’t built for applications, but that’s really what people are wanting to build these days.
You can say (and many do) “but this web site should just be a document. It doesn’t need so much JS!”. I’m sorry but so can most native mobile apps. But that doesn’t stop people from making them feel 10x better than their web equivalents by making them more then Just A Document.
Service worker and related standards make some real progress here, but it’s not enough, and companies don’t seem to be investing in it.
I wish more focus from a web standards perspective was spent thinking about how to turn it into a *good* app platform instead of letting it continue to accidentally be a crappy one.
Where are our virtualized list views built into the platform? Where are our robust stack-based animation-based navigation APIs? Where are decent gesture-handling APIs?
Finally, the fact that the web has to download, parse, execute the code for an entire app on every page reload is a huge limiting factor. We haven’t really done much to mitigate this.
I still think we should have signed JS script tags and content-addressable modules in such a way that browsers aggressively cache the generated byte code from scripts in such a way that it would actually make sense for large apps to not bundle their whole app into a single file.
This is a hard problem, but I’m not aware of much being done to fight this limitation on the web at all. Hopefully WASM won’t make the same mistakes.
3). Culture:
This is the biggest one IMO. Real talk time. There is a significant culture difference between web developers and native mobile app developers. Put plainly, the minimum “bar” for UX is much, much higher for native apps.
Most “beautiful” web sites have some UX problems on mobile (ones we have the tech to fix) that simply wouldn’t fly for a middle-of-the-road native app. The expectations are set differently. This is a systemic issue and I’m not trying to point any fingers. It’s just different.
It almost feels to me like a type of Stockholm syndrome. We seem to not realize just how much worse the mobile web experience is than the current status quo on Native.
I’m not sure what the fix here is, but having a few notable exceptions in the wild, especially from some vocal engineers that talk about the importance of it would be a great start.
And that concludes my rant. I hope it didn't sound overly negative. I deeply care about the web platform, and consider myself a web developer at my core. I love the community and hope (and believe) some of these things can be turned around.
Should be interesting to see what happens to fb www and mobile when the new server renderer ships
fb's tried multiple times, with the best engineers, to get good ux out of mobile web. the new renderer will make it faster, but inherent problems with the model stay. touch is the big problem.
has horror stories of trying to build a simple photo gallery.
Yeah, I guess this goes to the Technology bucket. Gestures are huge and the web doesn't have any support for them really.
we can have conspiracy theories about whether or not the mobile browser makers want these or not, but part of the problem is no one is really asking for them AFAICT. Are there examples of w3c proposals for solid gesture support (or other things from the list above?)
I honestly don't know, haven't heard much. I'll dig in some more after my pto. maybe they should just copy react native's responder system ha
I actually tried to hack together a clone of UIKit's gesture system at one point (didn't get very far, but started thinking more about the problem):
lelandrichardson/gestio
Declarative DOM-Based Gesture Responder System. Contribute to lelandrichardson/gestio development by creating an account on GitHub.
github.com
This looks helpful but still nowhere near what is needed to compete: Gestures inherently conflict with a bunch of other gestures, and any gesture system needs an API for you to declare relationships between them to determine which one "wins" in which contexts.
Events end up being only a small part of it. Thanks for looking! I wonder if there are others.
Also missing from a lot of these proposals: A way to tell the browser that some of the built in gestures (like swipe to go back) need to be disabled, or else there's no point in any of this :/
As a web developer for many years I feel more and more the urge to move to mobile dev. The Web feels like a great mess - browser vendors trying to agree on stuff, and some of them breaking some(hello chrome) and what we have today is a grand hack on top of a simple document model
To accentuate your point about constraints, "cutting edge" on the web could either be the height of an immersive/interactive experience, or something that loads instantly and has jump-cut transitions for everything. Our ideals are at competing ends of the continuum.
What bundle size would developers be willing to pay for top-of-the-line gestural interactions? If I gave you a 100K library to enable native-quality interactions on the web, would you include it? 50K? 30K?
Gestures are my expertise, but I still wonder if there's a sustainable balance between an implementation that's easy enough for the average web developer to use, but small enough in your bundle that you don't mind including it.
I think 'bytes' are the wrong way to look at anything web now. Instead think "time to glass", "time to interaction", delayed components etc. With CDNs like @Cloudflare & lazy-loaded bundles make 100k a non-issue, esp if it is loaded & ran in the background after initial load.
I think you should build it and find out. If it's compelling enough, maybe it can be proposed as a standard and eventually turn into a polyfill instead (unlikely if it's possible to build it in user-land though).
For an app where gestures were the core, 100k might make sense out of the box. For other apps, it might not. Also, if gestures were only needed for page transitions or something else, this might be a reasonable thing to defer loading of.
Many of gesture's use cases will not need to block the path to first paint
Funny you should say that, because I should be putting together a Codepen sample of Material Motion in the next couple weeks, although it still needs a lot of documentation.
Interesting point about deferring load. In my demos, Motion usually owns the styles for elements that change during a gesture. I'll have to think about what alternatives that allow lazy loading look like.
Other reason would be getting more people to use the native app.
Totally agree. These days when I start a new project I take the mobile first approach. It really helps me because I don't have to shoehorn a wide layout into a smaller one whereas the reverse is much easier. But yeah many developers won't have the liberty of working on greenfield
Also the reason (apart from, of course, the usual inevitable gatekeeping) why everyone and especially native devs across all platforms complain so much about Electron/Cordova/Ionic web-apps "turned native". They're often not actually native but still have the lesser web UX.
Turbolinks fixes that...wish more people took it seriously.
Yeah, I've never really given turbolinks much thought but the approach does seem like it would solve a lot of issues if your app is architected for it. are there any popular websites that use this approach at scale?
Github, Basecamp, Shopify, SitePoint, Untappd, Cookpad. Biggest (and really only) problem I’ve encountered are things I have no control over (Like Drift integration)
This can be solved at some level with code splitting and caching vendor files via service workers.
I’ve built stack navigation but the mobile browser gets in the way so you can’t actually do it!
right! We need a spec/standard so that the browsers (mobile included) will turn off their handling appropriately. This is my point - the web as an app platform being as good as it is is mostly an accident. The primitives to build truly nice experiences aren't there yet
And often the Thought Leaders are pushing towards less JS and reverting back to document based model. IMO that's just giving up on the web as an app platform, and I think that's a bit of a bummer.
Don't get me wrong, we shouldn't be putting humongous bundles on a page for no reason, and making the experience (mobile especially) even worse. But we should be figuring out how to build sophisticated apps on top of the web.
Those jokers sell ads. They have no clue what you’re even talking about.
Put differently, the Gmail iOS app is now over 150mb...and yet DevRels are out here fat shaming webapps for shipping 300kb 🤷🏻♂️
yes. exactly! We need to rethink how to ship JS to web sites. the download/parse/execute entire minified app bundles model does not scale and I believe there are other approaches we can try
... hi I might have a technique or two to suggest to solve this.
Yeah, code splitting. He’s thinking bigger than that.
cc: @stubbornella
Possible to start a conversation here about what's missing and how to resolve?
I’d love to chat about that more. We’re working on layered APIs right now in particular virtual scroller/list. imo HTML needs an update for 2019: mobile, assistive, etc.
Would love to hear your thoughts, Sean
This technology already exists for 80% of the apps that are symptomed with large bundled.
It was invented by GWT, adopted in webpack in 2012 called code-splitting. It is synonymous to lazy loading binaries in android but doing it statically so deps are optimized.
But as long as JavaScript is the most expensive asset to parse, it is the only way to reduce the load time for pages up front. This is not impossible and has gotten easier to do via tooling, but it requires respect and attention from time to time and not when it just snowballs.
This is how we have to keep size and bundles under control.
Companies choose apps as a business decision because they are advertised about the incredulous amount of private data they can get constantly from users. This can't happen in Web Apps as easily. See Facebook ironically
yes, I am quite familiar with code splitting. I think we could do a lot of things that would make code splitting more effective, and I think many could code split that aren't right now, but I do *not* think this is enough.
If it's not *the problem* apps wouldn't be shipping. 70-90% of their code unused up front. On initial downloads.
*the problem*, i guess, is that we have such a low ceiling to begin with. and that a big chunk of those bundles is due to Other Things. Telling people they need to keep their "bundle size under control" is like telling someone with a flu to keep their temperature under control
I'm not saying that people shouldn't care. Right now initial page load times can dramatically affect user experience, and my whole point is that we need to improve user experience. But it's a ceiling. I think bundle splitting (practically applied) doesn't raise it enough
Sure. I'm only mentioning this in the original context: parse, eval costs.
Is there a whole set of users experience bars to raise yeah. How fast your apps load though, is based on this one.
yes, but there are other ways we could reduce parse times and download times: bytecode caching and module signing/caching
Now, I have to admit I'm not well versed on the challenges here. But this would have a much greater impact if the JS we parsed wasn't bundled but instead was individually signed and cached at the module level
Also, related but different: There are a lot of things contributing to bundle weight that I feel like aren't talked about enough
For example: babel lowerings for classes and other constructs that a high percentage of browsers don't need. How about a better way of delivering JS to a browser based on the abilities that it has?
isn't this just polyfill.io? I feel like a lot of people seem to have forgotten about it with the rise in popularity of babel and no popular app scaffolds using it
I know that there is concern about the quality of the polyfills they ship but surely that can be fixed?
No, this is a bit different. I'm not talking about polyfills. Classes, for example, are natively supported in most browsers, but many people will still transpile them because the tooling makes it easiest to target the "lowest common denominator"
The transpiled classes take up *significantly* more space, and don't minify well, so it becomes significant when people are using classes for a big chunk of their code base
There are a lot of things, but the former is BY FAR the biggest low hanging fruit. For sure.
Biggest low hanging fruit and has the highest impact****
sorry, which thing are you referring to as "the former"?
Code splitting. Reducing initial download cost, deferring actually needed code until runtime.
Listen, i'm all for doing both. The problem right now is that the culture (of which webpack is a part of) is heavily geared towards commonJS + bundling. If you turn code splitting on, it helps a little bit but not enough. Getting code splitting to work well is difficult
Fixing the babel issues that I talked about could be fixed at a more cross-cutting level that wouldn't require significant time investment from the user
In other words, solutions that don't require telling all developers to Eat Their Vitamins are infinitely more useful than ones that do
This is possible by making separate builds for modern/legacy browsers and using <script type=“module”> and <script nomodule> to target them. Will be default behavior in Parcel 2, and I hope other tools adopt this by default too.
That's good to know! I didn't know about this but that seems like a promising first step.
Caching doesn't work for high-velocity teams everyone's pushing for. Not much good from caching if your CI deploys multiple versions per day, unless you split the code ridiculously, and even then
Also you compare mobile and web and notice that mobile is permanent, while web is fleeting. There is a reason for that: it's either magical ~zero cost web onboarding and documents first, or 100mb+ platform-specific download with long release cycle and nice animations
I agree that that is more or less the current state of the world, but the difference is I don't think that is how it *has* to be, I just think that's how it is currently.
It *has* to be so because we do operate under objective constraints, it's not enough to "think differently" and make believe. Look at the mobile apps and ask yourself why exactly do they have WAY longer release cycles; why do they operate with a WAY less generic tendering
Sorry, of course it's "rendering".
You can't just take the amazingly complex (compared to native) web layouting model for granted, it has real costs which don't translate to mobile, and that has A LOT to do with its speed. Like, try to render markdown on mobile.
Yeah, rendering is another dimension of this whole story. I hadn't really broached this area but I have some thoughts there as well. I don't think the differences here are as drastic though
I don't believe the reason for app-store release cycles is that apps are released as binaries. I don't see how that follows
Not true. Caching doesn't work for *bundles* with high velocity teams. If we cached and signed at the module level, caching would be *way* more effective. The bulk of your bundles remains unchanged even on high-velocity teams
Technically caching does work for bundles but yes if you remove determinism it can work.
Firstly, that's not true because people work on different modules on the same time. Secondly, that's a Bad Idea, because it throws whole-program optimizations (including proper DCE) out of the window. Thirdly, it's just way more _stuff_ to download, even with http2 and all that
It does make whole-program optimizations harder, you're right. There are tradeoffs here. Keep in mind a huge portion of your bundle (of which I'm proposing these changes also affect) would be 3rd party modules
Also, I propose module boundaries as a simplification. Package-level (groups of modules/files) could easily become the boundaries as well, where the order of magnitude is well within the realm of http2
And also, bytecode caching is the thing I really want to get to here. If we can save the time over the wire *and* the time of the parser, the savings compound
Http2 doesn't make roundtrips free, you know. And shoving stuff onto the client with push is kinda problematic and extremely complex to do right even with cache digests and stuff (think about polyfills).
I think we may be talking past each other a little bit. I am not claiming http2 makes all problems go away. There is more that is needed to really make this work
But that's pretty hollow, isn't it? An average webapp contains literally tens of thousands of modules. It's only bearable because it's all loaded at once and sometimes there are no modules at all (see nolanlawson.com/2016/08/15/the… for *just* the modules overhead with no network at all)
The cost of small modules
Update (30 Oct 2016): since I wrote this post, a bug was found in the benchmark which caused Rollup to appear slightly better than it would otherwise. However, the overall results are not substanti…
nolanlawson.com
I don't think "more work to be done" is an argument for the idea that loading multiple thousands of modules separately over a flaky network can be done reasonably close in speed and complexity to loading just one big batch of code.
Moreover, mobile is literally one big parcel.
People download mobile apps because they buy into their usefulness. If they still didn't, they use web because they expect it to be instant, ~zero cost, and flitting. That's the tradeoff we should acknowledge. Instead, we take fast web from people, replacing it with half-native.
Now this is a point I really do agree with. There's a meaningful difference in intent once someone has past the filter of "i'm willing to download your app". No disagreement there.
Yep, that's why I strongly believe that the defining features of the web are its speed and zero buy-in. Remember the push notification fiasco? That was an attempt to directly translate native features to the web. People hated it.
Performance and impermanence should go first imo.
(sorry, I'll have to disengage for a while, it's pretty late here across the pond. Thanks for arguing in good faith, it's very refreshing to have a honest argument! I may reply tomorrow if I'll think I have something to add to the discussion)
no worries. Likewise!
Native mobile is *not* one big parcel in terms of code execution (sure the app is downloaded as one usually). mobile has the advantage that it can load code on the fly off the file system and that's what they do
It is from the network perspective. What do you do if one of the modules/packages/whatever didn't load? What are the failure modes? What is the chance of failure? On a bad network it's WAY more probable you'll finish one big download successfully than a few hundred separate ones
Yeah, I agree this is a problem with the strategy overall. I don't know how much of a problem it is or isn't, but I believe that there's a real difference. It sounds like a problem for browsers to optimize though.
So 1. as I mentioned in a previous tweet, packages are just as likely candidates for this boundary, an the number of them there is much lower.
2. Bytecode caching is the real win here. Especially when you're talking about inter-page navigation on the same site
Code splitting only takes you so far. I have an app that has gone from 380kB to 140kB, but every single kB after 150 have been a lot of work. Eventually you end up with libraries you can not split and do need at the initial render. For me those are React, Apollo and Material-UI.
Hmmmmmmmmmmmmm
Parse/eval costs should likely be mitigated by transmitting a compiled to JS VM or WASM intermediate binary representation and heap snapshots, not just by splitting out some parts of the textual source code to still be parsed/evald later in the UX.
Sounds pretty heavy! Good thing is you can and should code split your wasm too!
Yes, I didn't discard code splitting. Btw have you got any insights what's heavier to transmit and harder to parse/eval: gzipped JS source, WASM binary, or theoretical JS VM IR + heap?
hard to compare wasm because they aren't equivalent, but in general i think wasm should be more compact and def. quicker to parse (since those don't really apply)
the theoretical js vm IR vs normal JS is harder to know. the point of it would be to be quicker to parse, but the weight would depend on the format. These things would probably always be cached locally though (since it would be browser dependent) so not sure it's the right metric
If we're talking initial load, they aren't cached unless it's a returning visitor, so we should consider these two cases separately.
agreed. I guess I was thinking that a IR + heap snapshot would never be sent over the wire, only cached locally. I think you'd have compatibility nightmares otherwise unless i'm missing something
Only if this IR was standardized like WASM... 😇 dreams dreams. Anyway, I believe there's much more unsolved UX problems than squeezing last tenths of a percent of initial loading time.
Not a fan of another Parse goal but if it solves something we'll be able to concat scope hoisting etc even these formats. They will still contain obnoxious levels of wasted code. This is my problem. We just don't need to ship a bunch of wasted code. Tools should get better but
It requires some stricter patterns and devs willing to make a few tradeoffs and respect the process.
Hey, I always wanted how come you webpack guys are so oblivious to the absolute hell lazy loading opens for the developers. The hell has a name: Distributed State. Before lazy loading the app/page is either loaded or not; after that good luck if you net is flaky ¯\_(ツ)_/¯
It’s why I like native dev. Thicc bundles. No worries.
300k compressed ;)
Is this professional fat shaming?
sorry, but thats bullshit. there is nothing good that gmail is 150mb. there is no a chance that it is "needed". I am not saying that we should be squeezing everything in less size, but this as an argument is a bullshit, justification of incompetence.
have you ever looked at the code of lets say google ads? I've educated it a bit (obfuscated one obviously, not sources). it's fucking huge, it contains a lot of stuff like features hidden behind the flags and a lot of experimentation and it looks like it's never getting cleaned.
and it is EMBEDDABLE code! code that thousands of websites loads, to show fucking text ad! it loads LOTS of js files, each of them hundreds of kilobytes of javascript. And this is with EVERY google project. And thanks god web is not native, otherwise we would have 150mb on pages
event.preventDefault() could fix most of my complaints 😂
What about history.preventDefault() and many other preventDefaults 😉 The closest to the former has luckily appeared recently: history.scrollRestoration = 'manual'; but if the browser URL bar & history are parts of the app UI, the app needs more control over it: getState, render.
I think that’s what I meant? If I could preventDefault a pan handler I could create stack nav in the browser
Taking all platforms into account, including desktop, I guess pan handler is not enough. Consider async cancelable navigation for instance: chicken-egg problem because URL bar state and UI are lumped together im the browser, and the state is private, only partially observable.
Chicken-egg I mean the order of state changes is different depending on the use case: user clicks Back, nav state URL changes, app nav starts, app nav ends, URL bar UI changes; or user enters new URL, URL bar UI changes, app nav starts, app nav ends, nav state URL changes, etc.
(hard to fit several sequence diagrams into a textual tweet)
Also between any of the above events there may be interruption of the flow with some other event such as Stop button, Forward button, etc. Browser doesn't tell the app about that.
Where can I read more about what you mean by stack navigation?
Many ios/android-based navigational models work with nested stacks, so you can "pop", which is equivalent to the browser's "back", or "dismiss", which essentially goes back one level in the tree of stacks, dismissing an entire flow
The web's history APIs make it hard to emulate this behavior. Ryan has a lot more knowledge in this area than me.
But beyond just the stack-based model, having APIs to seamlessly transition between pages on the same domain with animations, shared elements, shared state, etc. are all things that are close to impossible right now on the web
And those limitations make it necessary to make a tradeoff between "SPA" and "multi-page app", where if you choose the latter it is hard to create a seamless experience, and the former it is hard to have a reasonable bundle size, so they are at odds
also to be clear, @ryanflorence is way more knowledgable in this area than I, so I'll let hm give his own answer as well
I'm working with @ElliottZ at Airbnb on a project that will be thinking very hard about this problem. If you're putting a plan in place for this, I am sure we would be open to working together!
That would be amazing. It’s much easier to prioritize work with a clear partner/customer.
Leland has my email. Let's bounce some ideas around!
This is always what gets me. Sometimes it feels like "I just want fancy animations between states or 'pages'" but it's REALLY "I want to be able to do it without feeling like I'm sending a huge unnecessary payload of JS", which you'd want either way.
It’s funny timing because just this week I proposed a KR for 2019 to explore building supoort for transitions into the browser. (Still very hand wavy, but hoping to convince @jaffathecake to help with it)
I think a lot of folks would like to put the "should it feel like an app or a website?" debate to rest and that would help.
I think the answer is whichever works best for the user, and that's probably on a per-feature basis.
I'm still pretty convinced we need some kind of navigation event (like in github.com/jakearchibald/…). Portals alone don't cover the back button case.
jakearchibald/navigation-transitions
Contribute to jakearchibald/navigation-transitions development by creating an account on GitHub.
github.com
The native experience is still the hardest thing to achieve parity with on the web for me as well, although with some of the work being done in the vue and react communities it seems to be slowly getting better...would def appreciate some standards in this regard tho, for sure.
I think about your proposal a lot, and I think you’re absolutely right—it would remove 90% of the justifications for a Single Page App architecture at a stroke.
This is the first I'm seeing this proposal, but I like it. I think this would solve a reasonable chunk of the use cases. Without really trying to build on top of it, my first thought is that being able to declare your JS process as "stay alive" would be useful
One of the things that will make the web feel less app-like immediately is the fact that going to a new screen and then coming back, I expect the state of the initial screen to be completely unchanged.
On native platforms, this ends up being the case by default because they've never been unloaded to begin with. And even in low-memory situations, android will provide lifecycles to correctly save that state
Most browsers (except Chrome) already do that. It's called the bfcache
I see. Interesting. I actually thought it was the opposite (that chrome did something like it, but others didn't?). Are there any events for you to capture the lifecycle of these interactions at all?
Very interesting. It would be very interesting to build a lightweight multi-page-app navigator on top of your proposal with this then! Especially with shared element transitions etc.
That’s what I’m proposing we do in 2019. To make it super easy for devs to get his right w out heaps of additional js. Single origin first so we don’t have to wait for portals.
I'd also be curious to help with this.
We're aiming to implement bfcache support for Chrome in 2019. Avoiding having to reconstruct DOM, execute script and redo layout should have a visible impact to UX during navigation.
See this thread, starting with @jlongster's first tweet:
I remember now how I did it.
- I kept the last URL as persistent state in each Tab
- At the route, check the state and redirect to the last location if there was one
- The nested routes inside passed the parent url to the child so it could
- Link to it in the UI back btn
Yep I've seen this one before. Very excited about it!
We’re looking at all three as potential Layered APIS.
The developers at Google are working on a virtualized list web component. Would be awesome to have all that you mentioned too.
one more thing there, app stores are more fair than search engines sometimes eg. Google has penalized competitors like Yelp, TripAdvisor many times in the past because they needed to push their own thing. The business rationale is I cannot depend on X to get returning users
Complete freedom when shipping websites as opposed to mobile, where there's usually an authority reviewing your UX and the way you utilise ads?
You may be right, but is that all it is? It feels like for some reason people still don't *think* to put ads in their apps in the semantically equivalent location where they're putting ads on the web. I'm not sure why.
And does Google/Apply actually regulate ad placement in apps? I wasn't aware of that if they do, but could definitely be wrong about that.
Maybe it also has something to do with the historical focus on making mobile experience as good as possible to meet user expectations - not that web users don't have same expectations but that's where the bias comes from.
Yeah. That's the conclusion I've come to. It's an interesting state we're in...
The acceptance of poor ad-injected experiences on the web that are not tolerated by native apps has strong parallels with the web's acceptance of poor performance (cc @jaffathecake)
It's not a technology problem. Both are fixable. Both need the project sponsors to demand better.
I'd be willing to bet it's because it's a lot easier to entice people into mobile purchases this way. With a native app users don't have to fill out their details because they're already logged into playstore. not the case in the browser
I dunno. I've had to manually put in my credit card into plenty of native apps. I think many companies avoid the play-store/app-store payments because then they have to rev share.
There's definitely that.
On the note of entering card details: I never have to enter my card details on my phone, just need to enter a password/use biometrics to make a purchase. I'd imagine a lot of people are the same
hmm. Maybe i'm doing something wrong. I feel like i have to do this with most apps when i freshly install them. Though I think maybe I did this less when I had an iPhone (am I using android wrong? lol)
That said, mobile browsers like Chrome autofill CC fields for me when it comes to a web page that has those details, so there's some friction removed there too (though in general I think autofill on all three platforms is terribly broken, so don't get me started...)
I think in general the line of thinking is that mobile apps have a more holistic experience since users likely have connected social media accounts, the app store makes purchasing easy, push notifications, that sort of thing.
these things are hard*er* with chrome
many web API standards lag behind mobile APIs. also a portion of users I would wager will probably not use Chrome or a web browser nearly ever on their phone and will use the playstore (probably less tech savvy users, source: my ass)
most of this stuff isn't unique to mobile but just feels like a smoother user experience, I guess.
idk, i'm a lowly associate engineer not in marketing, UX or mobile :P
yep. this is one of the points I was trying to make. I think a lot of the battle has already been lost. Users are voting with their feet, so to speak. I think part of that was caused by the experiences being so bad to begin with, that now the expectation is baked in
i remember an article a few years ago that showed the % of people visiting a site on a phone vs a mobile. mostly tech workers will use the web and a pc but a lot of less tech savvy users probably don't even own a pc/laptop anymore
/shrug.
Although for a lot of places it doesn't make a difference. No need to enter cc or use biometrics for Amazon since they store your details on their own servers. But I've not had to do it for mobile games for example (the microtransaction abuse is rife in that market..)
Yeah, I think maybe since I don't play very many mobile games I don't see this as much. Most places where my CC is stored, it travels with me across web into native land and back through logins
i'm similar. but the sample size in this conversation is two tech savvy engineer types. most of the world aren't in that circle and many of them probably don't even own a PC and only interact with the internets through apps
very true
I would argue that there's a large missing piece to your list, Motives:)
Facebook messenger does NOT work at all in mobile browsers. They force you to install their app. Might that be so that they get more access to your PII? They are after all, a surveillance company at core.
Yeah. I agree. I tried to encapsulate this in "Investment" or what could be renamed to "Motives for Investment". There is great value in the permenance of an app install.
What’s your opinion on cross platform building (like with React Primitives) in this regard? Can write once, use anywhere help in this regard?
Maybe a little bit, yeah. When I was working on Primitives and related work, I found that it was producing better mobile experiences (sans bundle weight) by the mindset just being different. The biggest difference was psychological, I think.
By being able to build on top of a huge RN code base that had been built with only mobile in mind, it was surprisingly easy to make all of that work in a browser and have the browser look and feel like a native app
To the point where it made me question why we didn't see that type of thing more in the wild
But I think all of the limitations I mentioned in that tweet are still there. And building an app to production-level quality will cause you to run into that ceiling rather quickly. And the issues with bundle size even quicker.
Brilliant. I think one important aspect of this is also the huge privilege an executible gets over a webapp. Geolocation, storage, peripherals, microphone, camera, vol btns, contacts, sms. I mean ad targetting means for the owner, not a better UX for the user.
Yeah. I agree. I tried to encapsulate this in "Investment" or what could be renamed to "Motives for Investment"
One really large reason is because of web ad blockers. Can’t block ads on the native app.
Agree. Yet for some reason, there are FAR less ads in native apps than on web sites.
I wonder if it’s because the ad purchasers can know that the ad will be seen, so they can charge a higher rate for it.
Holy crap I never thought about that. That might be exactly why so many sites try to push users to apps.
Have any companies discussed that openly?
They are also less intrusive on mobile, which could be thanks to Apple having some sort of policy as far as designing ads within the app (not sure if that's the case)
I am surprised I am even saying that but - I do enjoy ads inside Instagram app. They are really well implemented in between regular elements (e.g. every once in a while, a "story" is an "ad").
I've learned about many interesting products since then 😅
I don’t mind ads. I use an ad blocker on web but turn it off on most websites as long as they behave. Those devs have to pay bills too.
Yeah, that's also my approach. Aside from that, I've been also educating my friends (including developers) that look for serial keys or cracks that it has the opposite effect long-term.
I am really happy that some newspaper magazines provide a paid subscription to enjoy their content as that's where I am regularly experiencing most annoying ads.
I avoid ad blockers. It just feels like stealing to me. If a site is too annoying I will vote with my feet, and hopefully enough will that it causes a behavior change.
I understand this approach and am torn between wanting to control my online experience and ... well, your take.
But most people have no problem blocking all ads aggressively. We’ve lost this battle.
I have absolutely no problem with ads done well. And I get frustrated with people who categorically hate ads, yet enjoy all of the free stuff that is paid for by ads.
You can if you use a DNS level blocker, works pretty well on Android.