App Streaming
We’ve talked a lot here at AVC over the years about the difference between web and mobile and the pain points around mobile web and getting users to download your native app and the challenges of dealing with all of this stuff. Deep linking and app constellations are part of the solution but the mobile environment remains a far cry from the web where you could follow links all day long and never need to download anything.
Google, which has a strategic interest in making mobile more like the web, is working on something called App Streaming which allows a user to get the benefit of a native app experience without having to download the app. Here’s a blog post that talks about how all of this works.
This is still pretty experimental but I think its an important tool for companies who are struggling to grow users/usage on mobile.
I started writing about deep linking in mobile apps in mid 2012 and it took many companies, including Apple and Google, two to three years to implement deep linking in a way that makes it truly ubiquitous to users.
I hope it won’t take as long for app streaming to come to market and get adopted by the mobile operating systems and app developers. The more we can do to make the mobile experience web-like the better in my view.
Comments (Archived):
In other words: FirefoxOS was/is right.
They may not have succeeded, but that doesn’t mean they didn’t have a point. Personally I think they we’re right at the conceptual level, but at an operational level of being the one’s to make it a reality they were doomed to failure.WebOS on the other hand had a real shot of creating a dual native and web based interface, had they not blown it IMO.
Gotta feel awe for a company so powerful it can usher in a completely new global mobile ecosystem just because it suits its business model.
Exactly
But this is good for users too. How is this selfishly good for Google and not for users?
Didn’t say it wasn’t good for users. It may be. But that’s a byproduct. What’s interesting to me is google can control the whole game.
yup. it’s Apple that’s on the defensive with this…potentially. And Amazon to some extent because they have their own version of app searching.
Apple and Google are each tackling this their own way. On iOS a search uncovers content in an app and clicking the link opens the app. On Google searching opens a link that streams the app.For us little guys it is a constant game of adjustments.
An example of creating a standard after considering the opinions of practically no other stakeholders.
well….we vote (indirectly) with our clicks and usage. Google listens to this, and they decide.
Sure and if you show a person with an eating disorder and/or no self control food (or alcohol) they will vote as well. [1] But that doesn’t mean it’s good. (As you can see I am all in knots over this subject. I will admit that..)[1] I was in a bakery a few weeks ago. They always have cake samples and sometimes I sometimes take a piece. This time I took some creamy buttered something or other (aka ‘to die for’) and offered said delights to the two ladies that work at the office next door (who take in packages for me). Now of course they are both quite heavy (one really heavy) and they lit up immediately and said “sure” and thanked me like I had just delivered heroin to them. I figured one “hit” was ok. And they wonder why they are heavy (yeah I know some people have medical problems and all of that..)
Agree w/that, but worth noting it does assume that they will make ethical choices in medium and long term (acknowledging currently there is a financial and business model culture at Google that fosters this). Was a bit less reassured when they went from “don’t be evil” to “do the right thing.”
It’s an automatic extension of their core – it just makes sense it would come out of them – it’s the inherent nature of velocity. It is pretty neat that it fits snuggly into their existing business though.
Fear not awe. Another example of large incumbent companies creating a barrier to a small company going on the web by creating something that will require startup type capital (aka opm) or larger corporate resources to take advantage of and play. [1][1] Ditto for the things like google deciding when we should all not be using sha-1 anymore https://konklone.com/post/w… and also deciding what IP’s are allowed to send email and not be consider spam hosts.
How is this different than it is today? All of us little guys are already mice running around the legs of elephants trying not to get stepped on while the elephants stampede.
Hence saying “another example of”. Sure life isn’t fair but doesn’t mean you have to lie down and just keep quiet.
I hear you but I have a business to run and family to feed. iOS developers have been complaining for 8 years about the lack of trials and upgrades. It has done them no good. I can’t wait for the world to change. I need to work within the one that exists.
Agree and onee of my points constantly which is “working within the world that exists” by adapting. I have always done that. Work harder stop whining. But thanks for pointing out that what I said might be considered something that I didn’t mean to convey.
Ah, thanks for clarifying. I did read in meaning you didn’t mean.
Remember that by definition “awe” already contains an element of fear, in addition to reverence. This one does command both.
Agree with that Mario. However I will point out that a typical straight man will have awe for a naked beautiful thin woman, but it’s his wife who would have fear of the same.
Ha ha ha!I agree that there is room within the definition, and that’s the beauty of the English language.For a semantic discrepancy such as this one, I personally find it useful to refer to Noah Webster’s first dictionary, dating back to 1824, as a way to see how the various meanings of a word have progressed over time, as compared to the purer meaning that is closer to the word’s origin.
fear
If this is successful, just a matter of time before google stops streaming the app and will make the content of the app a card in google now. Just like they are doing with the rest if the web now.
This is brilliant from Google, because its slaps iOS apps in the face. How can Apple react to this?
Glad to take the opposite side of this bet William.Nobody is getting slapped cause today ap streaming doesn’t exist.I hope it does and the quicker the better. I’ve been a believer in Apple since day 1.Have no reason to believe that they will not only adapt to but lead the market moving forward.
But Google controls search, no?Of course Apple can allow iOS app streaming in search results, but they would be laggards and subservient to Google’s requirements. How else could they make it available to the wide market?
DunnoBut if you look at the world through that lens you are only seeing the future as Google imagines it.If Facebook restricted in its drive towards world domination by Google in anyway at all?Just saying its never exactly as those in control see it.
Facebook isn’t going to be restricted by google but they will be potentially be restricted by Zuck now being a family man (taking 2 months paternity leave). Remember when Gates got married (Jan 1 1994) and that is right before they kind of missed out in a big way on the Internet. Not saying they didn’t do fine but they didn’t do as fine as they would if Gates kept his eye on the ball. (Note the same didn’t happen to Jobs when he got married because of his personality and who he was married to (not his mother in other words).
Well I would argue that if Apple controls the smartphone market then in theory they have the last mile with the customer and could potentially upend google in search (or a significant enough portion of what people would search on their iphones with).Search is a total long tail but the majority of things people are searching for don’t require the huge lead that google has (my guess). At least searching for from their phone. All pretty predictable (local info, bar bet info [1], (see below) hotels, travel etc. By majority I mean enough things that apple could be the first stop and apple can handoff to google if they don’t have the answer at hand. Similar to the way that Amazon is the first stop when I want to buy something (instead of the actual company that might sell it themselves off their website.) Or netflix is the first stop for movies for me.[1] A few days ago I thought “how tall is Shakira” and bingo google had that (5’2). So does duckduckgo.com just checked. So it would be easy for Apple to show me the answer to that question from my iphone w/o relying on google at all. Possible if you have billions in the bank. Right now spotlight sorta does this but it just gives you a “search the web for ‘how tall is shakira'” when it could easily just pop up the answer…
Well, Google sets the standard for search, and it’s very difficult to implement search as well as Google. Look at search on Facebook, Twitter and iTunes for that matter. It’s dismal.
Take a look at the “standard for search” screen grab below. (Couldn’t resist this after just seeing it)….
But it’s pretty good overall.
Oh I agree it’s great and it continues to amaze me every day. It’s a real crutch actually. And dangerous in the sense that things you would normally in the past have asked a human for the answer to you now can ask google.
See problems with paid apps? Copyright? In app advertising ?
Rev share?
Take Twitter .. Seems like API requests would still be a problem? Will google host a copy of the app on its own servers ?
Not sure about that.
They are just following their mission to ” to organize the world’s information and make it universally accessible and useful.”It should serve as a wakeup call to any company whose primary value is information…. because they are really just ‘leasing’ it from Google at this point and who knows when that lease could expire.
That’s a great analogy Jess!
hm, does organizing the information means you own it tho?
They want it to.
They don’t own or originate it, but they serve it to the user. I’m sure they see little distinction.
By that logic then, they are not following their mission.
I’m pretty sure the real mission is completing the circle.
No you didn’t finish the sentence:To organize the world’s information and make it universally accessible and useful AND then charge the piss out of companies that value consumers looking at that information.Tongue in cheek a bit.
Someone at Google should lift that sentence and make it the company’s stated mission on Google’s homepage next April Fool.
Also drop anything when contribution to bottom line is nominal and/or when the next shiny ball comes along. Reason being is that nobody wants to work at google unless they are working on moonshot projects. [1] And if you only hire the best and brightest there is no room for coorky and the little bus that brings him to work. [2][1] There is no William Morris mailroom at google apparently.https://en.wikipedia.org/wi…[2] That one is for https://twitter.com/donnawhite
what sentence? I was asking a question, not sure what you mean.
Their mission sentence. “To organize the world’s information and make it universally accessible and useful”Many times companies don’t finish sentences like that.
Mmmmm….1- the streaming is opt-in2- who would NOT want a demo of their app streamed to potential users to make them discover it ?
1. If streaming becomes the dominate way in which apps are found, is it really opt in at that point?2. Those apps in which 90% of their value can be derived from the stream alone. In those cases, they have not captured the user, google has.
If app streaming becomes as ubiquitous as Google’s web search, it’ll be as opt-in as Google’s web index: totally opt-in in theory, but such a useful traffic driver that everyone does opt-in. I don’t see how that’s bad ? Do apps not want to be discovered just like web sites ?AFAIK, a streamed app still behaves like the full too, with ads, tracking… Google is not hijacking streamed apps’ revenue.Plus apps only stream over wifi, and are, obviously, not available off-line nor over 3/4G, so there’s still a strong case for installing an app discovered via Google search.I’m not understanding the negativity. It’s one extra way to discover apps, that reaches users who don’t trawl for apps in the PlayStore, with significant constraints/drawbacks compared to the real app ie strong reasons to graduate to installing the app… and it’s opt-in.As a user, I’m loving the extra lead-in to useful apps. I’d like it to go one step closer to how browsing the Web works: allow me to bookmark apps, and to Favorite (= install) some. Add the possibility to pin (= force/ask the OS to not swap out of RAM) a handful of key apps, and I’ll be even happier.
Also, if you’re afraid Streaming will hurt your installs, you could have a streamable light/trial version and try to get users to install for the full features. Like the free trial / full paid app dichotomy in the PlayStore.Really not understanding the bit… moaning.
They are going to OWN the control layers for transportation networks. They are focused with moving the packets around efficiently. Whereas the transport segments still think in analog terms (ie how we connect to our car). They are going from controlling information flows to controlling the way people move.
here is a demo link for some streamed appshttp://my1.runthatapp.com/a…
This is something we already do @APPCityLife, for both iOS and Android. We see it as a must for cities to offer many services and open data via apps to citizens with one footprint, while providing a native experience. It’s a manageable way a city scales it’s many services to mobile, as the average user keeps a little over 40 apps on their smartphone, and so they can discover any city app and stream any other city app within it.
My take from a couple years back. I see apps as BBSs in the ’80s – ’90s: locked islands. Now bridges are finally being built http://m.huffpost.com/us/en…
Do the islands want a bridge to them though?
They have to because of demand. That’s the problem with the current model. Demand is ever-changing and growing at a rapid pace. Everyone is on their own unique demand curve. Something the big data guys and their average, incomplete results don’t want you to know about.Silos don’t scale and their ecosystems are not sustainable. We’re falling farther and farther behind what is technologically feasible today (4K VoD, 2-way HD collaboration, mobile first, and IoT), let alone what technology will bring us in 5 and 10 years. IP (settlement free peering) will be looking at as the “middle-ages” of mankind’s progression to the modern digital information networks begun ~32 years ago.
Complete silos scale, just not with the viral impact of being connected – at least to a degree. I agree it’s the middle-ages with putting technological innovation into practice, I do wonder what other terrible scenarios may unfold though.
There is complete and then there is complete. The core silos are limited by the edge access silo’s high pricing and limited high-capacity access. So there is no north-south clearing in the IP stack. As well the 3-4 biggest silos control 80% of the revenue, force all users into a nearly “average” consumption model with a lot of redundancy and waste (ie cost for both supply and demand), and are doing so mostly through invading our privacy.Show me a world where a sensor (an edge endpoint) isn’t just installed and used by one app and it’s user base (hundreds/thousands), but by multiple apps and tens/hundreds of thousands of users. How is that done today? It’s not. There is no east-west settlement exchange. Then show me a world where one or two or a few of those apps want that sensor to be upgraded for some new performance feature (let’s say from IPv4 to IPv6 or a new protocol, or power backup, or security code, etc…). Can’t be done. There are no price signals and incentives in the IP stack.Today’s siloed model is ultimately limiting even for the “complete” silos. Think AT&T by the 1950s when it became apparent that others (from the edge) could establish a better world. Change in my model happens both at the edge and core; organically and constantly unlike today’s ossified world. I say that based on knowing what technology is actually capable of today and what markets are not delivering.
perhaps raises the question of whether apps can “block” exposure
“Nofollow”
Seamless integration, hard to argue w/ the benefits there. Testing solely via Android 5 or 6. Would be very un-Google like (and quite doubtful) any roll out would be exclusive to their devices. A great feature and easily emulatable. Consumer and Google both win here.
Hard to argue with getting a big inheritance and not having to work. Other than the fact that maybe you might lose meaning in life and consequently spend it in a lazy fashion that leads ironically to unhappiness. My point being there is for sure a downside and impact to google doing things like this.
I am concerned at the speed at which app streaming would likely vary compared to it being locally hosted. If someone has a bad user experience because of it going through an app, I’d be pretty upset that was a user’s first encounter with my business. That “G” icon as well hurts the user interface/user experience.The value to Google of knowing every interaction is extreme – and I’m really not sure who will benefit the most. If used as part of discovery, how can Google be able to determine quality of a content or value of an application? Percentage of time a person uses an app, sure, maybe – but if there is a tie-in say with email as part of that value? They just can’t get a big enough picture to really calculate it. However, it certainly will give them valuable data to compare with the whole ecosystem – at which point Google will use that information to create their own internal apps that compete with the other top apps.This is what will happen at an increasingly accelerated rate, with a most recent example being what Facebook is doing with their on-site crowdfunding service – wait until someone else proves the model and the best UI to use, and then copy it. Google will have a copy of the data and user behaviour for all of this.Google would have an unprecedented look at every detail as to why any type of app is most successful – and that should scare everyone who has or is trying to build a business; the larger your business is, the more immediate your concern should be.And they certainly won’t be paying you for this data — they will however try to make it one of the main channels for discovery, so if you don’t give yourself to this channel and a competitor does, then they can make your business suffer in the immediate short-term.I wonder if legislation is possible to prevent this kind of power being given to these companies who want to provide this infrastructure – allowing for the value and benefit to the end consumer, without a business giving power to one of these beasts.The other interesting tie-in is that you’d ultimately be using your Google user credentials to login to these apps.I imagine Facebook will copy Google shortly with this as well – if they don’t already have it in the pipeline.
My first thought was “neat!” And my second thought was, “uh oh.”
As in 1996-98 the source of monopoly lies elsewhere. MSFT dominated the edge and the government was looking for ways to reduce that near monopoly. But broadband (Web 2.0; 2000-2007) really picked up the pace at which processing collapsed back to the core. Web 3.0 (2007-present ) was a step ahead in terms of 7×24 real-time connectivity, but it was a step sideways in terms of bandwidth and processing (back out to the edge) and hence the ascendance of the app. However this time monopoly is not driven by where processing is, but rather by where the monetization of information flows occurs. In this case it is Google’s view into our habits and preferences, which you clearly point out, looks like it can only improve with this approach.This issue goes away with a different settlement model; just as the MSFT issue went away with changes in access speed. Time to rethink bill and keep and settlement-free peering which, perversely, supports monopoly and stasis and reduces the ability for new entrants to gain a foothold. It’s also non-generative and deters investment. At the same time, we can’t lose sight of where the processing is and we need mandated interconnection all the way to the edge (wifi just isn’t gonna do it even if it gave Steve Jobs a way to resurrect equal access).
This is somewhat opposed to your other post saying make sure things work offline : http://avc.com/2015/11/goin…
I think they complement each other. If I want offline I’m probably downloading the app. If I don’t know what app, I’m probably searching on Google. But now Google’s search results have more context than before as data from within the apps appear on their searches.
In theory you could have offline caching capabilities in the browser like Google does with many of their apps in Chrome desktop. Ofcourse this would necessitate that the mobile browser be upgraded to the equivalence of it’s desktop peer’s capabilities.
Good point. It feels like, to me, people will eventually only install apps that need to work for them even offline. Everything else, just like now, will be ok to only work when connected.Also, local caching.
I think most of these apps basically require a connection to work anyway, at least the ones in Google’s initial partner list. I don’t know if that’s a bad thing. Or maybe that’s what you are saying?
Exactly. It’s not a bad thing. It just is what it is. We’ll be installing apps that we need/want to work offline for a long time.
A very big reason users (and hence developers) prefer apps over browser is the unreliability (not just connection, but speed and latency, etc…) of network access. This includes not just 4G networks but increasingly congested wifi APs. Apps can include a lot of information on the device that improve performance (screen rendering, cached data, etc…) which cannot be supported by or translated well to the browser experience.
I am in the process (tail end) of converting our primary product to a web app with mobile apps to support it. It’s been pretty clear for a few years now that a url was way too critical to our success and that being hemmed in by Google’s and Apple’s app stores was limiting my business potential. The app had formerly been a mobile-only app.In early customer discussions it is pretty clear that that url is going to open up some new use cases for us, those that allow teams to work together, where before that wasn’t really easy.In my mind Google is doing what I’m doing, although they care more about discovery then usage I think. Anything they can do to help me with discovery works for me.
A shame OnLive shuttered this year. It was an early and ambitious attempt to tackle the challenge with perhaps the most difficult application set (realtime games).
It surprises me that interfaces do not distinguish egRecover (information I believe I may have in my phone browsing history contacts etc) vsSearch (look for content associated with this key words that will be new to me)For many normal use cases this is a generally early and decisive branch point of expectations
Wasn’t the first facebook mobile app HTML in disguise? I think as soon as the experience is “snappy” enough, mobile apps might fall back to “full screen” mobile web pages.Coining: “MAAAS” Mobile App As A Service
Don t think this will be a game changer. It may work for “catalog apps” like ecommerce at best. But the experience is far from fluid and definitely broken for sophisticated apps like apps or education or even streaming. My best guess is that once html5 becomes truly performant but most of all once the browser will have access to all the OS and hardware capacities of the device, then, and only then, the advantage of building of native apps vs web apps will just fade away
Agreed. This is logical and good enough for showcasing content centric apps. I’d put this more in the bucket of “app-lifying” content than actually streaming of apps themselves.Then again, content centric apps more naturally lend themselves to being indexed which is google’s primary goal.As to the magical day when HTML5 usurps native, wouldn’t surprise me if it’s still “just around the corner” five years from now.
Well said! This is great for the catalog app, and addresses the install requirement, albeit with the degraded function similar to Windows Remote Desktop. However this doesn’t address the fact that for most situations an app is the wrong way to go in the first place and is just an unnecessary artificial burden imposed by the OS’s owners.
Thanks for the note. When you say unnecessary, artificial burden, for who? Presumably, developers do what they see as in their best interest, and Apple especially provides a great Mobile Web environment.If you are arguing that Consumers are being artificially forced to download apps, that’s another argument, but one I’d question since download is a tax on engagement. Hence, if the consumer truly has a choice between two equal services, and one is click and view web and the other requires a download, presumably the consumer would choose path of least resistance, right?
I don’t think there is one-size-fits-all solution for any mobile strategy. It really depends on the audience and product. There will always be advantages for native, web, watch, etc. It will come down to choosing the right technology for the service, which will include all the above for most companies, if they want to the best experience for their users.
So Google is going to simulate apps for us in the browser. Neat. I wonder how much of the phone’s native functions will be available .It’s good that Google wants to make more apps reachable by everyone. But I wouldn’t want that to be the only way people could use my app (God knows it’s already the only way they’ll find it).Rather than rely on this layer in between, ideally we’ll figure out how to develop web-based mobile apps that don’t need a gatekeeper to work. HTML5 platforms like Ionic feel like the interim step between old skool native apps and the way we’ll actually eventually all use mobile. I dream of a future where the line between the web and apps is practically nonexistent 🙂
Nicely said. I sort of cracked up thinking about saying to person at coffee shop next to me “oh, I’m sorry, I can’t interact with you because I’m an app and you’re a web page. Let me know when we have the same OS.”
Great imagery 🙂 Very much captures the current app development experience!
How about the line between mobile (wireless) and fixed is nonexistent as well. It would be great if we had a world where sessions could traverse physical network borders seamlessly; aka mobile first, not mobile only. And I’m not talking about wifi which, while great, has really been a poor man’s substitute to the real thing only because most everyone still thinks in silos and vertical integration models.
Yes, anything that clunky feels like it hasn’t reached its ultimate expression yet.
You make a good point regarding native functionality. If they extend native functionalities to the browser because of this, it could be a real win for the HTML column in the native vs. web calculus.
It’s one of those things that just feels like it should already work this way, so I can’t help but believe it’s a matter of the technology catching up. The current situation feels ‘primitive’ (for lack of a better word).
The technology is there and has been documented. The reason the mobile browsers pared down capabilities is the wish to protect and push the app stores which promotes OS lock-in. That said: Fingers crossed!
The more we can do to make the mobile experience web-like the better in my view.A better way to do this would simply be standards that allow this to be handled by the browser. Same way that HTML5 allows for playing of videos for example.Why? That way anyone and their uncle in a garage can play as opposed to people who are able to write apps. By this I mean the “hello world” is possible and the ability to write a simple web page (and cgis) at the start without some big CMS or IDE was what allowed the web to get to where it is now. (Similar to the example in the post that you linked to). That is what the danger with this is.
Culture consists of layers (and politics, economy, and tech follow culture). Apps as self-contained technologies in a walled garden fail that test, but they’ve already had an effect on the open web.Ultimately the value will always realign back to a) the problem solved and b) the ecosystem around that specific problem, the hows and whys of its’ existence. IMHO apps as they are currently do a nearly non-existent job of that second part, but they do a great job of the first and will probably be integrated into HTML5 or some other similar standard that’s more open / flexible.
Looking at the comments, I’m really not getting the backlash vs something that’s an opt-in tool to help with app discovery.People are saying “we don’t want our app in search results !” Well, don’t put it there, and… think hard about it ?
Was this a message to Google, or do you not typically email them directly? He he he.Kidding aside, it does indeed seem at the present like the next logical evolutionary step for mobile.Hope this public plea impinges on those poised to more quickly implement the changes.I wonder, though, how fast or how slowly will this feature move to the iPhone following Android; or will it somehow be concurrent? Can anyone predict / explain it?
We’ve had deep linking in Bandapps for a couple of years, works really well for us as all Bandapps link together as one. Works well in music
> The more we can do to make the mobile experience web-like the better in my view.Good. And to do that, have mobile devices just run a Web browser that uses HTTP and HTML, CSS, JavaScript, etc. to display Web pages.Then, sure, a Web browser for a mobile device would want to upload an image, say, from the mobile camera, the user’s GPS coordinates from the mobile device’s GPS chip, etc. Okay.Might want some new ‘elements’ in HTML. Okay.The beauty of HTTP and HTML, etc. is that it is a universal user interface, that is, analogous with an old ‘dumb terminal’ that could connect with any server over an async modem on the dial-up voice network. That is, the ‘dumb terminal’ specification was a ‘standard’ with an enormous ‘network effect’: Nearly all the servers supported it because nearly all the terminals did; nearly all the terminals supported it because nearly all the servers did. There were different approaches, e.g., from IBM, but they were a total pain since they blocked what was available in both servers and terminals in the ‘dumb world’.Then the Internet with HTTP/HTML caused Internet users just to give up on all such non-standard mud wrestling right away, join the standard, and go forward. Terrific.Sure, HTTP/HTML does not have everything, and something non-standard can in some ways offer more. But the general lesson from the history of standards and network effects indicates that being non-standard is going to be a struggle.And for something non-standard, that is, not the same as the current standards for HTTP, HTML, CSS, JavaScript, etc., the more promising solution is just to tweak the current standards, e.g.. as in scalable vector graphics (SVG), HTML5, HTTPS, etc.Here Fred’s post just further convinces me that for my startup, where my servers assume that the users have a Web browser, say, up to date as of five years ago, I should just f’get about having an ‘app’. My ‘mobile strategy’ is just to have Web pages that also look good on mobile devices.I’m not excited by the future of mobile and guess that for maybe 10 years mobile devices will remain basically as they are now. To be clear, I believe that the mobile devices will remain essentially the same; the number, variety, content, and popularity of the Web sites they connect with can continue to grow.Maybe some of Wall Street agrees with me: IIRC, if take Apple’s cash off their balance sheet and reduce the stockholders’ equity and stock price correspondingly, then what is left is a company with a comparatively low price to earnings ratio. That is, Wall Street doesn’t see big gains for Apple in the foreseeable future. Neither do I.In particular, the effort described in Fred’s link to MarketingLand strikes me as promising a ‘user experience’ well described by a unanesthetized root canal procedure. E.g., so far for Web sites, getting good exploitation of JavaScript is proving to be a severe challenge — a lot of Web pages just do not work, e.g., pop-up for no good reason, overwrite the main content, require a big effort to find some tiny ‘X’ to close an overlay image, change the meaning of various standard keystrokes and mouse clicks, go to full screen for an ad for no good reason, lose screen focus for keyboard input, follow the mouse cursor and do just infuriating ‘pop-ups’ when the cursor is being used just to scroll the screen, make the page unusable due to lack of scroll bars, have single lines of text with way too many characters to be read, say well over 100 instead of, say, 40-60, grow the virtual memory size to outrageous levels, and go into literally infinite loops that peg CPU busy at 100% and block nearly all other software from running on the computer. That is, some of the recent extensions of a traditional Web browser have permitted so much freedom that way too many Web page designers have created unique messes that only they on their combination of computer, screen, Web browser, etc. could like if then. It’s a non-standard mess.The streaming of mobile apps as described in MarketingLand promises for a long time to be an even worse mess.The MarketingLand discussion did make clear that in the ‘streaming’ efforts, Google, etc., are interested mostly in the situation in India and China with, apparently, much more ‘eyeball time’ for apps than Web sites. For that reason, the ‘streaming’ efforts might be an important business issue for Google, etc. but of little concern for everyone else.The clear solution for everyone: Return to a relatively simple, universal, standard user display device, ‘client’ device, almost certainly current HTTP, HTML, etc. with, maybe, occasional extensions of the standards.E.g., for my startup, to heck with apps.
Apps already run HTTP. They are “web clients” that aren’t browsers.
Sure. I can believe that. IIRC, HTTP is a little like e-mail, that is, SMTP: So at the beginning are some header lines. These end with the first blank line. After that is the ‘body’ with some data. As I started on the Internet, I wrote my own e-mail client using just TCP/IP — of course, just old Telnet is also sufficient. With SMTP and POP3 e-mail, I still keep the header lines!For a Web page, HTTP is similar: The data is just HTML elements and text. But with HTTP, right, the data might be just XML. IIRC SOAP is a special case. So is REST. Likely so is Microsoft’s new, do everything, API infrastructure Graph.Way back there I wrote some TCP/IP code to grab Web pages, and there my code cuts out the header lines — to be sure, I’d have to glance at my old code, but it’s too late at night to do that now! I used that code for a long time, but, really, the standard utility CURL, which does handle HTTPS, is better and what I’m using now (sometimes to get initial data for my startup).For the server to server communications inside my server farm, I’m not using HTTP and, instead, using something simpler and faster: I just take an instance of a serializable class, serialize that instance to a byte array, send the byte array over just a simple, old TCP/IP socket connection, and at the receiving end just deserialize back to an instance of the class. Works great, e.g., also for my Web site session state server (my DIY instead of Redis).So, any program can use HTTP to communicate with a Web service. IIRC, on Windows, can still use Microsoft’s internet information server (IIS) to bring up the server side of a Web service. Okay. If my starup needs that, then I will do it. And, sure, there is likely a connection with Web sockets.That apps use HTTP, and maybe also HTTPS, is interesting, but my main point was that the world needs to, and likely will, standardize on the protocol stack of HTTP(S), HTML, CSS, JavaScript, HTML5, SVG, AJAX, etc. as a user, client, interface instead of something unique to an app or the app infrastructure. In that case, streaming apps would be less important. And, as I tried to explain, my guess is that streaming apps will not be very important for very long.Then, even on a mobile device that can run apps, mostly the user interface will be from a Web browser, not an app. That is, a good Web browser as a uniform, universal user interface, supported by the biggest network effect since the solar system, is just too big to fight!Sure Apple, Android, etc. all want something proprietary that they can control and milk, and they might be successful in some cases, but, IMHO, for the user interface, fighting the Web browsers is hopeless.
Sometimes tech companies (big and small) try to make tech A work like tech B when tech B already exists.
as my beautiful wifeBringuth multiple pictures so we can all decide the validity of your claim to a beauty! (Matt’s wife is a 10 to me).*and* fear when starring a little too strongly at the younger, beautiful, thin woman’s unclothed body.Part of the fun is the fear I think that’s a male builtin.
I’m afraid you’ll have to take my claim at face value unless you can manage to find your way to my Facebook photo albums, and that might not be worth your bother.
this discussion makes me a little less likely to buy a Nexus 5X. i think i might give Cyanogen or Oxygen a go.
I am confused by your last line. “The more we can do to make the mobile experience web-like the better in my view.” Why? Aside from the screen size, native apps are so much better. While I do like the concept of App Streaming as a way to minimize the load of finding and downloading an app, you can argue if you go from one streamed app to another often enough, might as well download the original.
One can not see the benefits of on-demand application streaming if the implementation presented is not designed to be so.Thus approach it as the core concept in it’s best case rather than looking at the inherently flawed approach being presented. For example the best case in relation to installing is an application that is simultaneously installing itself as it is being interacted with. As the portions being streamed are also the portions being installed. They are one in the same in best case app streaming. Thus there is no reason to “download the original” because what is being streamed as it’s being utilized is the original. Meaning ultimately as you utilize the app you are constructing the, as you put it, “original”. This alternative approach involves a different methodology entirely. I’ll avoid promotion of any kind but it is utterly feasible to google me and find my related github for more details. There is a correct implementation out there this is just far from it. The presented implementation, I hate to say it, is a charlatan of true application streaming.
A company called http://www.Runthatapp.com is doing app streaming and you can see a some example apps for both iOS and Android on their website.
The truth is this technology is old and it’s implementation is terrible inefficient. There are far better ways to construct applications that are inherently on-demand self-building. None the less people will flock to HOT words with knowing very little of what is actually going on.I have authored many on-demand self-constructing web (some hybrid with Node) based applications for the past 6 years. The recent version of my authored platform is far more efficient than traditional installs, does not require virtual machines/specific server configuration and saves processing time/bandwidth. The older implementation has been in production for years now. However the back-end is proprietary and will not be open-sourced anytime soon. None the less there is a front-end library that can provide the basic model for app streaming (it’s on github free for anyone to use).In the context of the web and native their methodology and many other implementations are entirely missing the point. It’s sad to see such a fantastic company miss the ball on this one.
https://youtu.be/Ch3-bUWy4Tg
I’ve been involved with Amazon AppStream around its launch – it’s a similar concept, although it focuses on graphics-demanding apps. I don’t think this model is going to work anytime soon. The closest thing to a “streaming app” is simply a properly designed web page, optimized for mobile. Nothing beats that at the moment, and whatever will, it will be far in the future, IMHO.