I think the disruption will emerge out of new replacement tools, probably emerging from some of the existing systems, though not from the current major players in browser space (Firefox, Gnome, Safari, IE), which I'm increasingly seeing as dead ends. This is reflected both in history and in the present situation.
In the past, revolutions in browser models didn't happen through evolution of existing browsers so much as their wholesale replacement.
The Web itself supplanted a whole set of proprietary document formats, both static and hypertext, of which Tim O'Reilly has written and spoken about this in talking about the origins of O'Reilly & Associates. His Open Sources essay covers this tangentially, though I think there are better examples I'm not finding at present:
http://oreilly.com/catalog/opensources/book/tim.html
In this regard, it's interesting to point out that the software industry's first attempts to improve on the web interface for active content--technologies like browser-side Java applets and Microsoft ActiveX controls--failed because they were aimed at professional programmers and could not easily be copied and implemented by the amateurs who were building the Web. Vendors viewed the Web in software terms, and didn't understand that the Web was changing not only what applications were being built but what tools their builders needed.
The upshot: HTML wasn't pay-to-play, you weren't locked within a proprietary "ecosystem". It also wasn't subject to the format limitations of postscript and PDF. It's even been backwards-bolted onto existing information infrastructures such as manpages and GNU Info documents via tools such as Debian's dwww:
And so proprietary doc formats gave way to HTML. Lynx begat Mosaic, which added graphics, then Netscape, which extended graphics and a number of other capabilities, until it fell over under its own bloated mass of bugs and technical debt and birthed Mozilla.
Tabbed browsing came by way of ... um, whatever it was that graced HN a week or so back, in 1997/98, though didn't reach high visibility until around 2000 by way of Opera, Skipstone, and Galeon, from which it was rapidly adopted by Mozilla, which itself grew emphasizing Xul (remember that) until it collapsed and was replaced by a user's one-off, Firefox. Google got into the game with Chrome which seems headed in the apps engine direction (and from which I suspect it will similarly collapse as a Web browser).
For the lightweight document reading and management interface, I suspect we'll see emergence from some of the existing eBook reader / bibliography / online simplification tools. I suspect that sites will start publishing in a simplified format (ePub, Markdown, LaTeX, DocBook, possibly even strict HTML5), which can be rendered to client preferences and in a device- and format-independent manner. Our problem isn't a want of semantic markups, it's running QC over the ones we've got and ensuring people are using them properly. Absent some sort of publishing authority (think along the lines of Debian's package management system) I don't know how this could be enforced. Perhaps adding smarts at the webserver level: "Hey, that document you just loaded, those tags you use, I do not think they mean what you think they mean." A validation step integrated as part of the publishing process.
Or maybe a nudge from search engines (though Google's own craptacular markup in its G+ pages makes me suspect this is wishful thinking). A well-formed, semantically-correct page gets a higher SERP ranking than one that's a clusterfuck. And hey, the SEOs will love me because this gives them yet another contracting/consulting service opportunity. Sigh.
Candidates to grow into this niche on the client side include Calibre, Zotero, Moon+Reader (and other ePub readers), and perhaps some of the generalized reader tools such as Evince and Okular (the GNOME and KDE readers). I'd like to explore the Internet Archive's BookReader as a _local_ client (it's presently oriented at Web content) -- ironically it's actually got vastly better presentation performance than most local readers I've seen. I expect dedicated PDF readers to go the way of the dodo. Pandoc is another tool to keep you eye on. I've played with that recently, with some script glue, to convert an ePub to LaTeX source and then PDF output (still somewhat preferred for local viewing, ePubs still annoy me on Linux desktop). Nothing makes me happy at present, but I'm seeing some glimmers of light.
The apps platform space: some sort of sandbox in which remote apps can play but only in a limited sense. Effectively creating a mobile device environment within the desktop (on mobile, the apps already have their space). Key elements of this will be standardizing on widget sets, state preservation (apps should be immune to having the rug pulled out from under them), and user-controlled privacy controls (lacking in present app and browser models). A data liberation standard would also be very useful, so long as I'm compiling my ideal wishlist. I've got less experience here than elsewhere, and I'm probably missing a lot.
Seeing apps which are functionally oriented rather than site oriented would be a huge plus. The "download our app" annoyance must die yesterday.
On the commercial space, we're already seeing proprietary dedicated ecommerce platforms -- that's what the mobile shopping apps from Apple (iTunes), Google (Play Store), and Amazon (Amazon Marketplace) are, effectively. Each is, of course, a silo. The next step is going to be for someone to come up with a generalized shopping interface which can access any of the back-ends. Google's doing some interesting work here with its Google Shopping Express, and the really interesting element of this would be, IMO, to integrate a few different areas of shopping:
• Information gathering. Essentially, reviews of both merchants and products. A cross between Yelp, Google Reviews, Wikipedia, and Amazon's reviews.
• Merchant info. Often I simply want to go to a physical location and get standard information (hours, available merchandise, service availability for, say, a barbarshop or restaurant or auto shop).
• Stock info. Is X product in stock? This is actually where I think the most interesting aspects may happen, as it could see a tie-in of merchant systems with the rest of the supply chain. As with what I've discussed recently on disintermediating of search, providing local merchants the access to global supply-chain and inventory management which is presently only available to big box stores could be a huge disruptor. It's not an easy problem to solve, but it could be immensely profitable. There's actually a name for this, "Federated Retail": http://instagov.com/wiki/Federated_retail
• Ordering. Requesting a specific item.
• Payment. Note that ordering and payment are separate. I may well want to order online but pay in person.
• Fulfillment / shipping / delivery / pickup. The act of actually getting the thing you want. Note that while delivery to the home may be convenient, it often isn't, and one really useful function a merchant can provide is for warehousing of orders. I actually do special-order products frequently from local merchants (bookstores, hardware stores, clothing stores), especially where seeing, handling, getting fitted, or browsing products is a significant part of the experience. So long as the pick-up location is convenient to my daily habits, walking a few blocks really isn't a big deal. And it's often far more convenient than arranging to be at home at a specific time. At least until such time as homes and residences are constructed with package delivery as a consideration.
• Authentication if necessary. Note that often this isn't a requirement, and, frankly, authenticated deep behavior tracking is a massive turn-off for me on virtually any online shopping experience, and is among the key reasons I avoid online shopping where possible. I'm one of those reverse show-roomers: I'll often research a product on Amazon, then buy it locally.
One of the things I find most interesting about online shopping isn't its size or growth, but the lack of these. For the past several years, online retail has been underperforming growth estimates: http://redd.it/243in1
In 2010, TechCrunch cited Forrester Research predicting 8% of all retail sales by 2014.
From the US Small Business Administration we have "An Analysis of Internet Sales Taxation and the Small Seller Exemption[5] " giving surprisingly low numbers in November, 2013: "According to the U.S. Census Bureau, online sales accounted for approximately 5.3 percent of total retail sales in the second quarter of 2013. While online sales still represent a small share of total sales, they are expected to grow significantly in the future."
For media, as noted, there are a number of existing tools which provide a superior playback experience to browser-embedded players. My main complaint with, e.g., VLC, is that it's unstable (tends to crash), loses playlists, and if playing, say, YouTube content, seems to establish a link to the present instance of the content URL which changes, so that if you're playing with interruptions, you'll lose the source and have to re-queue the original YouTube link to your playlist, which is a bit of a PITA.
Comments
I think the disruption will emerge out of new replacement tools, probably emerging from some of the existing systems, though not from the current major players in browser space (Firefox, Gnome, Safari, IE), which I'm increasingly seeing as dead ends. This is reflected both in history and in the present situation.
In the past, revolutions in browser models didn't happen through evolution of existing browsers so much as their wholesale replacement.
The Web itself supplanted a whole set of proprietary document formats, both static and hypertext, of which Tim O'Reilly has written and spoken about this in talking about the origins of O'Reilly & Associates. His Open Sources essay covers this tangentially, though I think there are better examples I'm not finding at present: http://oreilly.com/catalog/opensources/book/tim.html
In this regard, it's interesting to point out that the software industry's first attempts to improve on the web interface for active content--technologies like browser-side Java applets and Microsoft ActiveX controls--failed because they were aimed at professional programmers and could not easily be copied and implemented by the amateurs who were building the Web. Vendors viewed the Web in software terms, and didn't understand that the Web was changing not only what applications were being built but what tools their builders needed.
The upshot: HTML wasn't pay-to-play, you weren't locked within a proprietary "ecosystem". It also wasn't subject to the format limitations of postscript and PDF. It's even been backwards-bolted onto existing information infrastructures such as manpages and GNU Info documents via tools such as Debian's dwww:
https://packages.debian.org/wheezy/dwww
And so proprietary doc formats gave way to HTML. Lynx begat Mosaic, which added graphics, then Netscape, which extended graphics and a number of other capabilities, until it fell over under its own bloated mass of bugs and technical debt and birthed Mozilla.
Tabbed browsing came by way of ... um, whatever it was that graced HN a week or so back, in 1997/98, though didn't reach high visibility until around 2000 by way of Opera, Skipstone, and Galeon, from which it was rapidly adopted by Mozilla, which itself grew emphasizing Xul (remember that) until it collapsed and was replaced by a user's one-off, Firefox. Google got into the game with Chrome which seems headed in the apps engine direction (and from which I suspect it will similarly collapse as a Web browser).
For the lightweight document reading and management interface, I suspect we'll see emergence from some of the existing eBook reader / bibliography / online simplification tools. I suspect that sites will start publishing in a simplified format (ePub, Markdown, LaTeX, DocBook, possibly even strict HTML5), which can be rendered to client preferences and in a device- and format-independent manner. Our problem isn't a want of semantic markups, it's running QC over the ones we've got and ensuring people are using them properly. Absent some sort of publishing authority (think along the lines of Debian's package management system) I don't know how this could be enforced. Perhaps adding smarts at the webserver level: "Hey, that document you just loaded, those tags you use, I do not think they mean what you think they mean." A validation step integrated as part of the publishing process.
Or maybe a nudge from search engines (though Google's own craptacular markup in its G+ pages makes me suspect this is wishful thinking). A well-formed, semantically-correct page gets a higher SERP ranking than one that's a clusterfuck. And hey, the SEOs will love me because this gives them yet another contracting/consulting service opportunity. Sigh.
Candidates to grow into this niche on the client side include Calibre, Zotero, Moon+Reader (and other ePub readers), and perhaps some of the generalized reader tools such as Evince and Okular (the GNOME and KDE readers). I'd like to explore the Internet Archive's BookReader as a _local_ client (it's presently oriented at Web content) -- ironically it's actually got vastly better presentation performance than most local readers I've seen. I expect dedicated PDF readers to go the way of the dodo. Pandoc is another tool to keep you eye on. I've played with that recently, with some script glue, to convert an ePub to LaTeX source and then PDF output (still somewhat preferred for local viewing, ePubs still annoy me on Linux desktop). Nothing makes me happy at present, but I'm seeing some glimmers of light.
The apps platform space: some sort of sandbox in which remote apps can play but only in a limited sense. Effectively creating a mobile device environment within the desktop (on mobile, the apps already have their space). Key elements of this will be standardizing on widget sets, state preservation (apps should be immune to having the rug pulled out from under them), and user-controlled privacy controls (lacking in present app and browser models). A data liberation standard would also be very useful, so long as I'm compiling my ideal wishlist. I've got less experience here than elsewhere, and I'm probably missing a lot.
Seeing apps which are functionally oriented rather than site oriented would be a huge plus. The "download our app" annoyance must die yesterday.
On the commercial space, we're already seeing proprietary dedicated ecommerce platforms -- that's what the mobile shopping apps from Apple (iTunes), Google (Play Store), and Amazon (Amazon Marketplace) are, effectively. Each is, of course, a silo. The next step is going to be for someone to come up with a generalized shopping interface which can access any of the back-ends. Google's doing some interesting work here with its Google Shopping Express, and the really interesting element of this would be, IMO, to integrate a few different areas of shopping:
• Information gathering. Essentially, reviews of both merchants and products. A cross between Yelp, Google Reviews, Wikipedia, and Amazon's reviews.
• Merchant info. Often I simply want to go to a physical location and get standard information (hours, available merchandise, service availability for, say, a barbarshop or restaurant or auto shop).
• Stock info. Is X product in stock? This is actually where I think the most interesting aspects may happen, as it could see a tie-in of merchant systems with the rest of the supply chain. As with what I've discussed recently on disintermediating of search, providing local merchants the access to global supply-chain and inventory management which is presently only available to big box stores could be a huge disruptor. It's not an easy problem to solve, but it could be immensely profitable. There's actually a name for this, "Federated Retail": http://instagov.com/wiki/Federated_retail
• Ordering. Requesting a specific item.
• Payment. Note that ordering and payment are separate. I may well want to order online but pay in person.
• Fulfillment / shipping / delivery / pickup. The act of actually getting the thing you want. Note that while delivery to the home may be convenient, it often isn't, and one really useful function a merchant can provide is for warehousing of orders. I actually do special-order products frequently from local merchants (bookstores, hardware stores, clothing stores), especially where seeing, handling, getting fitted, or browsing products is a significant part of the experience. So long as the pick-up location is convenient to my daily habits, walking a few blocks really isn't a big deal. And it's often far more convenient than arranging to be at home at a specific time. At least until such time as homes and residences are constructed with package delivery as a consideration.
• Authentication if necessary. Note that often this isn't a requirement, and, frankly, authenticated deep behavior tracking is a massive turn-off for me on virtually any online shopping experience, and is among the key reasons I avoid online shopping where possible. I'm one of those reverse show-roomers: I'll often research a product on Amazon, then buy it locally.
One of the things I find most interesting about online shopping isn't its size or growth, but the lack of these. For the past several years, online retail has been underperforming growth estimates: http://redd.it/243in1
In 2010, TechCrunch cited Forrester Research predicting 8% of all retail sales by 2014.
From the US Small Business Administration we have "An Analysis of Internet Sales Taxation and the Small Seller Exemption[5] " giving surprisingly low numbers in November, 2013: "According to the U.S. Census Bureau, online sales accounted for approximately 5.3 percent of total retail sales in the second quarter of 2013. While online sales still represent a small share of total sales, they are expected to grow significantly in the future."
http://techcrunch.com/2010/03/08/forrester-forecast-online-r...
http://www.sba.gov/advocacy/7540/758295
For media, as noted, there are a number of existing tools which provide a superior playback experience to browser-embedded players. My main complaint with, e.g., VLC, is that it's unstable (tends to crash), loses playlists, and if playing, say, YouTube content, seems to establish a link to the present instance of the content URL which changes, so that if you're playing with interruptions, you'll lose the source and have to re-queue the original YouTube link to your playlist, which is a bit of a PITA.