Do you remember what mobile phones were like before Apple's iconic iPhone burst onto the scene? Some had advanced features like touch-screens, some had highly functional software apps for playing media, and some even had reasonably functional Web browsers. But overall a mobile phone was not what most people would consider particularly sensuous or stylish, except perhaps for a handful of die-hard tech fans willing to overlook major design shortcomings.
Then came the iPhone. It felt real, real good in your hand, it had a touchscreen which at the time was amazingly good, and you could get both very well-designed mobile apps and a highly functional Web browser. In other words, the iPhone sold the idea to everyday status-mindful people that Web-connected mobile phones were worth investing in to make a fashion statement that offered a high level of polish in their technology. Not all of the apps available at first lived up to that image, but the design of the iPhone and its software encouraged both high function and good looks.
In the meantime, the Web based on desktop and laptop PCs was progressing rapidly also thanks to technologies like HTML 5 and CSS 3, but not necessarily getting the attention that it deserved from developers. Many would pan Google's Chrome Web Store catalog of highly functional Web apps as "just a set of bookmarks to Web pages" instead of providing people access to "real" apps. Google's Chromebook laptops running the nothing-cut-Web Chrome OS operating system have carved out a strong niche for inexpensive laptops accessing Web apps, but because they're based on good but unflashy hardware they haven't been strong drivers for accelerating in-browser Web apps for lots of developers so far.
The Chromebook Pixel hopes to change that. As the only giveaway hardware at the recent Google I/O 13 developers' conference, it emphasizes Google's prioritization of Web apps as where they want to point the flow of functionality that supports their signal-gathering capabilities. Chromebooks were giveaways at previous I/O conferences, but they were low-cost units which were functional, but not necessarily the type of hardware that would appeal most to software developers wanting the best technology for applications. The Pixel changes all that. It has plenty of power and memory, a touch-screen display that has both resolution and color clarity that beats any Apple device - and leaves other Chromebooks gasping for breath across the board, except in battery life - which is going to change for all mobile units soon anyway.
Beyond raw performance, though, the Pixel is a sensuous machine very much in the image of Apple's best mobile hardware. The case is all-metal with rounded edges and has a remarkably smooth, silky gunmetal finish that makes it a pleasure just to have it in your hands. The touchpad display is a well-machined piece of glass that feels like it's an extension of the silky metal that surrounds it. The LED light bar on the lid glows blue whilst the Pixel is alive and then flashes the rainbow colors of the Google logo as it puts itself into a slumber. The screen has phenomenal color depth and clarity, making Web content as attractive as anything found on the best tablets today. The touchscreen responds precisely and is actually quite useful once you accept that you can get good touch responses from Web apps - aided by Google's own updated coterie of services such as the updated +Google+ , Google Play Music and Google Play Books apps. Especially with the +Google Play apps, it's apparent that their touchable design on the Pixel is on a par with their refreshed Android versions, which didn't even require a downloaded update - in other words, the Android apps are basically a lightly wrapped version of the HTML 5 apps being seen now on the Pixel and other compatible PC browsers.
So the Pixel as hardware and on-screen experience with the right Web apps is all-in for transforming our sense of what the Web can be on a full-screen browser in very much the same way that the iPhone transformed our sense of what the mobile phone Web experience can be. The high-end appeal of the Pixel helps to drive this point home much like the premium iPhone helped drive home to consumers the idea that the mobile Web was fashionable, fun, well-designed and easy to use - not just something for technophiles. Google's also taking this approach with its new Google Glass headwear for mobile Web viewing, pushing it into the hands of fashion designers and other prominent trend-setters years before the public will get general access to the product. It appears that you have to feel trendy and fashionable to be willing to adopt cutting-edge technology and to attract developers who want access to the affluent and influential consumers who think that way.
All of this would be a partially good strategy if Google were delivering things via its Chrome browser for Web content only in the familiar bar-plus-tabs configuration that we're used to seeing. But key announcements at Google I/O underscored that increasingly its Chrome browser and its Chrome OS PC-less laptops are in fact launching devices for full-screen, sensor-enabled experiences on a par with installed software on PCs, smart phones, tablets and TV game consoles. The new Packaged Apps program for +Google Chrome enables full-screen capabilities for Web apps via a set of APIs which exclude the browser bar as targets and which add the ability to address hardware beyond the browser not yet addressed by HTML 5 standards. This enables experiences such as a skydiving game demoed at the I/O conference, which featured a 3-D gamespace through which you "fell" based on your interaction with an +ASUS
motion-sensing device akin to Microsoft's Kinect motion sensor appliance for Xbox 360 - except that the whole experience was working in a Chrome Browser.
Packaged Apps install using the same files and methods as Google Chrome Extensions do today. That seems like an innocent statement at first blush, but it's another way of saying that Google Chrome has become in essence with own operating system environment for Web apps, regardless of what computer-level OS might be in use. From that perspective, Chrome OS's ultralight underpinnings compared to traditional PCs may give it a performance advantage at times for Web apps. It also means that increasingly Chrome is going to be delivering rich content and experiences via Android devices essentially akin to anything that can be delivered via a native Android app. As mobile phone makers and mobile phone network carriers try to create their own unique features for their devices using Android, Chrome for Android and for other mobile devices is becoming well positioned to provide developers a cross-platform development environment that will bring the principles of easy development and interoperability back to the mobile Web. At the same time Chromebook Pixel makes it possible to have those same experiences on touch-screen desktop and laptop devices that also help us a lot with our productivity - all of which will be delivering Google more signals from which to power its own applications for The Second Web, of course.
So just as the iPhone lured developers into Apple's proprietary apps development platform, Google is trying to lure them back to the Web via the Chromebook Pixel to develop secure, high-performance, sensor-aware software, based largely on Web-standard development tools that can help their apps to work anywhere in the world on any device. The Pixel's hardware is powerful enough to make that possible in the hands of any software developer, and will serve as an attractive calling card in the hands of the thousands of trend-setting people who attended the Google I/O conference this year. "What's that you got there?" might be a common question in the months ahead when someone sees a Chromebook Pixel for the first time. Increasingly the answer might become, "Well, it's The Second Web, of course."
And of course they'd be right.
Monday, May 20, 2013
The iPhoning of The Second Web: The Sensuous Chromebook Pixel Sells Sophisticated Cloud Apps
Labels:
apple,
applications,
apps,
asus,
chrome,
chromebook,
development,
display,
google,
iphone,
laptop,
open source,
packaged apps,
pixel,
retina,
sensors,
software,
strategy,
touch screen,
web store
Thursday, May 16, 2013
Larry Page Pushes the World Towards The Second Web at Google I/O 2013
To the more than 6,000 attendees at this year's Google I/O developer's conference, there was perhaps an understandable letdown from last year's edition. Last year, there were skydives, tablets, phones, Google Glass and all sorts of other device mojo in play. People got lots of toys, to say the least. This year, attendees got one really nifty toy, at least nifty if you happen to love the Web - a Chromebook Pixel. But that was it for freebies.
Think that there is a message here?
If you weren't sure about what the message was, then you haven't been paying attention to what +Larry Page, +Sergey Brin and +Eric Schmidt have been saying and writing as of late. The message is simple: we're building The Second Web, and we want you to join us.
It's a message that some people don't seem to be getting clearly, and that lack of understanding is perhaps frustrating at times for Google's senior management. It showed clearly in a surprise appearance by Google CEO Larry Page at the end of the opening day keynote presentations at I/O, in which he spoke without a teleprompter. Page expressed his concern about the stagnation of so many companies that are using the Web for communications and services to try to create one "walled garden" or another, and encouraged I/O attendees to think big about the Web and its future.
To that end, making the sole giveaway at I/O a Chromebook Pixel running the nothing-but-Web Chrome OS operating system was telling developers in effect to focus on the Web as much as possible, because the rest is just hardware and noise. Instead of a new Nexus phone or tablet, there was the announcement that Nexus-style software would be available on top-end Samsung phones as an option, instead of a Google-branded phone. Instead of a new Google TV, there was a quiet acknowledgement that apps from that platform would be supported in upcoming Android releases in general. Instead of a new tablet, there was the emphasis that the Google Chrome browser was capable of supporting rich functionality on all kinds of mobile devices, largely supplanting the need for platform-specific apps.
In other words, except where a piece of hardware can advance a new form of Web services and signal-gathering radically, such as with the anticipated Google Glass product, Google is stepping away from the highly parochial battles of hardware vendors and telecommunications carriers as much as possible. So, for example, why give attendees yet another mobile phone from yet another slow-moving U.S. telecommunications carrier when they can focus people on apps and services that ultimately bypass these slow-moving incumbent interests? Why settle for a canceled introduction of a physical credit card for +Google Wallet when you can focus on styles of payments that are more in tune with the future of financial transactions and not the past? Why highlight appliance makers trying to integrate their home devices like washing machines to the Web when most of them seem to want to corral their customers into a world in which only machines from their own factories exist?
Instead, Google I/O highlighted mostly an array of powerful Web-driven services and apps, fueled by Google's growing array of cloud computing resources that interpret the semantic meaning of images - even using that meaning to correct the look of those images automatically - as well as voice, text and human gestures gathered from mobile appliances and inexpensive Web-connected sensors being propagated throughout the world. In the hands of Google developers and developers using Google development tools for Web apps, the Web can be filled with apps as beautiful, fun and compelling as any installed software program and more powerful through their ability to take advantage of the semantic interpretation of data collected from those apps.
Games development with Google tools also emphasized the capabilities of a Web that is aware of touch, gestures and spatial relationships. Two key examples: a simple screen-based race car game that could lay out a "track" for the cars to follow that ran across the screens of multiple nearby devices. Each person's screen becomes in effect a filter for a Web-aware experience that can be handed off to another person's Web-aware appliance. In other words, we've established that mobile devices can communicate with the Web; now how intelligently can they be coordinated to do powerful things together?
Another interesting game demo was an all-Web skydiving experience, developed for Google's Chrome browser, that was equipped with a motion sensor similar to that used by Microsoft's Kinect game console controller. Computer games have long been targeted at specialized hardware equipped with proprietary software. Now, the Web is catching up to the point where both single-player and massively multiplayer game experiences can work in the same programming languages that support other native Web functions. So while games targeted at Android platforms will continue to gain attention and popularity, on the horizon is a new era of online games taking advantage of powerful Web apps that both sense our motions and that can be integrated with social networks smoothly.
All of this creates a sea of data about us and about our world, which is the real focus of Google services. Demos of search features coming to Google's search engines demonstrated how one query such as "where is the roller coaster in my town" followed by another query "how far is it to the restaurant" can understand both other information not in those queries - such as a pending dinner reservation - and the relationship between them that is implied but not specifically mentioned in these two sentences. This is what you might call "conversational search" - asking the Web about the world as if it were directly aware of the world as we understood it in the moment.
All of this and more may have been hard for some people to absorb, especially those who had come just hoping for the next hot mobile gizmo. But the big picture is that Google is doing all it can to push the most innovative thinkers in software and services design to embrace programming for a Web that works like the world - a Web that is both aware of itself and aware of everything that surrounds it, making collaboration on understanding the world as a data-aware place essential. Others will follow Google's lead in this direction, but already Larry Page is impatient for the world as a whole to catch on to The Second Web.
Think that there is a message here?
If you weren't sure about what the message was, then you haven't been paying attention to what +Larry Page, +Sergey Brin and +Eric Schmidt have been saying and writing as of late. The message is simple: we're building The Second Web, and we want you to join us.
It's a message that some people don't seem to be getting clearly, and that lack of understanding is perhaps frustrating at times for Google's senior management. It showed clearly in a surprise appearance by Google CEO Larry Page at the end of the opening day keynote presentations at I/O, in which he spoke without a teleprompter. Page expressed his concern about the stagnation of so many companies that are using the Web for communications and services to try to create one "walled garden" or another, and encouraged I/O attendees to think big about the Web and its future.
To that end, making the sole giveaway at I/O a Chromebook Pixel running the nothing-but-Web Chrome OS operating system was telling developers in effect to focus on the Web as much as possible, because the rest is just hardware and noise. Instead of a new Nexus phone or tablet, there was the announcement that Nexus-style software would be available on top-end Samsung phones as an option, instead of a Google-branded phone. Instead of a new Google TV, there was a quiet acknowledgement that apps from that platform would be supported in upcoming Android releases in general. Instead of a new tablet, there was the emphasis that the Google Chrome browser was capable of supporting rich functionality on all kinds of mobile devices, largely supplanting the need for platform-specific apps.
In other words, except where a piece of hardware can advance a new form of Web services and signal-gathering radically, such as with the anticipated Google Glass product, Google is stepping away from the highly parochial battles of hardware vendors and telecommunications carriers as much as possible. So, for example, why give attendees yet another mobile phone from yet another slow-moving U.S. telecommunications carrier when they can focus people on apps and services that ultimately bypass these slow-moving incumbent interests? Why settle for a canceled introduction of a physical credit card for +Google Wallet when you can focus on styles of payments that are more in tune with the future of financial transactions and not the past? Why highlight appliance makers trying to integrate their home devices like washing machines to the Web when most of them seem to want to corral their customers into a world in which only machines from their own factories exist?
Instead, Google I/O highlighted mostly an array of powerful Web-driven services and apps, fueled by Google's growing array of cloud computing resources that interpret the semantic meaning of images - even using that meaning to correct the look of those images automatically - as well as voice, text and human gestures gathered from mobile appliances and inexpensive Web-connected sensors being propagated throughout the world. In the hands of Google developers and developers using Google development tools for Web apps, the Web can be filled with apps as beautiful, fun and compelling as any installed software program and more powerful through their ability to take advantage of the semantic interpretation of data collected from those apps.
Games development with Google tools also emphasized the capabilities of a Web that is aware of touch, gestures and spatial relationships. Two key examples: a simple screen-based race car game that could lay out a "track" for the cars to follow that ran across the screens of multiple nearby devices. Each person's screen becomes in effect a filter for a Web-aware experience that can be handed off to another person's Web-aware appliance. In other words, we've established that mobile devices can communicate with the Web; now how intelligently can they be coordinated to do powerful things together?
Another interesting game demo was an all-Web skydiving experience, developed for Google's Chrome browser, that was equipped with a motion sensor similar to that used by Microsoft's Kinect game console controller. Computer games have long been targeted at specialized hardware equipped with proprietary software. Now, the Web is catching up to the point where both single-player and massively multiplayer game experiences can work in the same programming languages that support other native Web functions. So while games targeted at Android platforms will continue to gain attention and popularity, on the horizon is a new era of online games taking advantage of powerful Web apps that both sense our motions and that can be integrated with social networks smoothly.
All of this creates a sea of data about us and about our world, which is the real focus of Google services. Demos of search features coming to Google's search engines demonstrated how one query such as "where is the roller coaster in my town" followed by another query "how far is it to the restaurant" can understand both other information not in those queries - such as a pending dinner reservation - and the relationship between them that is implied but not specifically mentioned in these two sentences. This is what you might call "conversational search" - asking the Web about the world as if it were directly aware of the world as we understood it in the moment.
All of this and more may have been hard for some people to absorb, especially those who had come just hoping for the next hot mobile gizmo. But the big picture is that Google is doing all it can to push the most innovative thinkers in software and services design to embrace programming for a Web that works like the world - a Web that is both aware of itself and aware of everything that surrounds it, making collaboration on understanding the world as a data-aware place essential. Others will follow Google's lead in this direction, but already Larry Page is impatient for the world as a whole to catch on to The Second Web.
Labels:
appliances,
chrome,
chromebook,
conference,
development,
games,
google,
html 5,
I/O,
internet,
larry page,
OS,
search,
semantic,
sensors,
social media,
technology,
video,
web
Friday, May 3, 2013
"Seeing" in the Second Web - What Happens When Our Sensors See Better Than Us
Google's efforts at developing self-driving vehicles continue to progress, and are creating an excellent example of how sensors and semantics are combining to create new and powerful services in The Second Web. Bill Gross, Founder and CEO of IdeaLab, noted in a blog post on LinkedIn recently that apparently Google's autonomous cars collect about 750 mebabytes of data a second when determining what to do next. The data comes from sensors, and from the semantic signification of the data from those sensors.
A simple example: if a self-driving Google car sees a cigarette butt near a parked car, that's a potential signal that a person smoking cigarettes may be near that vehicle. A ball near a car could mean a child is nearby ready to run to pick it up. And so on. These are visual cues that people are trained to learn about as they gain driving skills, but the machine-driven mind of a Google-equipped vehicle is always thinking about these possibilities every moment - and nothing else. There's not really such a thing as a distracted driver when a self-driving vehicle is on the road.
But think about the semantic layers of interpretation that go along with the visual cues in these scenarios. First, the self-driving car's "brains" get visual input, usually from several directions at once - something that a human simply can't do. Then it has to figure out what are recognizable objects in those images - if you've ever used a camera app like Google Goggles on your smart phone to get information on a nearby landmark simply by taking a photo of it, then you're using image recognition technology similar to what the self-driving car is using. Google Googles and apps that are similar to it match the contours of objects in your photo to a database of other photos that have been tagged as relating to specific well-known artifacts like famous buildings or landmarks.
Once the self-driving car recognizes an object in an image, or a sound from microphones outside the vehicle, then it has to relate it to the significance of that input. What does a ball on a street mean to safe driving? Answering that kind of question requires the software in the self-driving car to have an understanding of the semantics of objects similar to what the human mind has, but in a very tuned way. If you've used Google's Knowledge Graph information in their search results, then you have a general idea of how a "web of things" can use semantic relationships between objects to make us smarter - it teaches us that Leonardo DaVinci is related to paining, to inventions, and so on. So, too, does a self-driving car "know" about the broader significance of simple objects in relationship to complex problems.
More to the point, any individual car's sensors are feeding into a database of experiences from other self-driving cars - the systems can actually become smarter than any one driver, because each moment of self-driving can accumulate correlations between semantically identified images and what happens in regards to safe driving. Perhaps in some specific neighborhood specific types of objects that the car encounters - like specific type of street vendor's cart or a new kind of toy - begin to "surprise" a self-driving car. The semantic significance of these novel experiences can be fed into the "brains" of other self-driving cars to help them in those specific circumstances - and to recognize when they're becoming a prevalent safety threat. Like bees learning about new flowers and communicating their type and whereabouts to other bees back at the hive through "dances," the "hive mind" of self-driving autos makes any individual car as smart as all of the self-driving cars combined.
Of course humans are not bees, but we do benefit from learning from one another, and of course we learn about the world in far more complex ways than a self-driving car. The car can "learn" that there's a Ferrari ahead of us, and it may know that it's a sports car, but it will not care particularly that it's a beautiful car. Yet, as people who are coming to rely on the bee-like minds of appliances like self-driving cars enabled by sensors, senses and the cloud computing capabilities of The Second Web, we are becoming reliant on these bee-like appliances in much the same ways that farmers rely on real-world bees to pollinate their crops and trees. They are becoming a part of the ecology of human life as surely as the millions or organisms that fly, crawl and swim throughout the earth. So the next time you happen to see a self-driving car rolling by, you're not looking at just a machine - you're looking at an extension of our human mind that now uses a bee-like intelligence to survive and to thrive. In The Second Web, we "see" life better - and that is a good thing.
A simple example: if a self-driving Google car sees a cigarette butt near a parked car, that's a potential signal that a person smoking cigarettes may be near that vehicle. A ball near a car could mean a child is nearby ready to run to pick it up. And so on. These are visual cues that people are trained to learn about as they gain driving skills, but the machine-driven mind of a Google-equipped vehicle is always thinking about these possibilities every moment - and nothing else. There's not really such a thing as a distracted driver when a self-driving vehicle is on the road.But think about the semantic layers of interpretation that go along with the visual cues in these scenarios. First, the self-driving car's "brains" get visual input, usually from several directions at once - something that a human simply can't do. Then it has to figure out what are recognizable objects in those images - if you've ever used a camera app like Google Goggles on your smart phone to get information on a nearby landmark simply by taking a photo of it, then you're using image recognition technology similar to what the self-driving car is using. Google Googles and apps that are similar to it match the contours of objects in your photo to a database of other photos that have been tagged as relating to specific well-known artifacts like famous buildings or landmarks.
Once the self-driving car recognizes an object in an image, or a sound from microphones outside the vehicle, then it has to relate it to the significance of that input. What does a ball on a street mean to safe driving? Answering that kind of question requires the software in the self-driving car to have an understanding of the semantics of objects similar to what the human mind has, but in a very tuned way. If you've used Google's Knowledge Graph information in their search results, then you have a general idea of how a "web of things" can use semantic relationships between objects to make us smarter - it teaches us that Leonardo DaVinci is related to paining, to inventions, and so on. So, too, does a self-driving car "know" about the broader significance of simple objects in relationship to complex problems.
More to the point, any individual car's sensors are feeding into a database of experiences from other self-driving cars - the systems can actually become smarter than any one driver, because each moment of self-driving can accumulate correlations between semantically identified images and what happens in regards to safe driving. Perhaps in some specific neighborhood specific types of objects that the car encounters - like specific type of street vendor's cart or a new kind of toy - begin to "surprise" a self-driving car. The semantic significance of these novel experiences can be fed into the "brains" of other self-driving cars to help them in those specific circumstances - and to recognize when they're becoming a prevalent safety threat. Like bees learning about new flowers and communicating their type and whereabouts to other bees back at the hive through "dances," the "hive mind" of self-driving autos makes any individual car as smart as all of the self-driving cars combined.
Of course humans are not bees, but we do benefit from learning from one another, and of course we learn about the world in far more complex ways than a self-driving car. The car can "learn" that there's a Ferrari ahead of us, and it may know that it's a sports car, but it will not care particularly that it's a beautiful car. Yet, as people who are coming to rely on the bee-like minds of appliances like self-driving cars enabled by sensors, senses and the cloud computing capabilities of The Second Web, we are becoming reliant on these bee-like appliances in much the same ways that farmers rely on real-world bees to pollinate their crops and trees. They are becoming a part of the ecology of human life as surely as the millions or organisms that fly, crawl and swim throughout the earth. So the next time you happen to see a self-driving car rolling by, you're not looking at just a machine - you're looking at an extension of our human mind that now uses a bee-like intelligence to survive and to thrive. In The Second Web, we "see" life better - and that is a good thing.
Labels:
analyst,
camera,
cars,
ethics,
futuristic,
goggles,
google,
image,
knowledge graph,
safety,
self-driving,
semantics,
sensors,
transprtation,
vehicles,
web
Tuesday, March 12, 2013
We, Robots: RoboEarth Designs a Cloud-Based Brain for The Second Web
It's obvious that robots are going to be a key part of humanity's future. It's not just a matter of an aging population that will need inexpensive and reliable aides, or the need for more productivity for manufacturing and services; there's just a lot more information to act on than there are people able to act on it. That's one of the net effects of The Second Web: We have more Web-aware sensors able to collect and transmit data than ever before, trillions of them all told. Who's going to digest that information and make sense of it in time to take useful action? That's the real place for robots in a world in which everything is connected to everyone.
For robots to take full advantage of their potential in The Second Web, though, they need not just reasoning but the ability to make sense of everything that's happening in the world around them. This is where RoboEarth comes in to provide the architecture for how this would be done. RoboEarth is an initiative founded by research scientists at the +ETH Zürich university to establish open-source computer programming methods that can create information resources and program logic for robots connected to the Internet. RoboEarth makes it possible not only for robots to store information on the Web from their sensors about what's happening around them, but also to share that information with other robots, as well as data from other sources and libraries of programmed actions that a robot can take based on all of that data.
In other words, the Web can be the robot's chief source of intelligence and inferred actions, while the robot itself can be designed mostly to collect information about the world around it and to be a machine that acts on information as good as possible. So, instead of the model of thinking that a robot has to have a "brain" exactly analagous to the human brain - a huge store of knowledge and logic and sensor processing - the robot can remain relatively dumb, as long as it can be connected to the smarts of the Web, and act both individually and collectively based on the data gathered by other robots.
In fact, this concept is already taking form today in more simple ways in products that many people use all the time. When we use a smart phone, for example, its sensors are picking up up data and often sharing it with a service provider like Google or Apple. These service providers in turn are learning how to find correlations in that data with personal interests and actions that the person are likely to take when certain data patterns emerge.
The Google Now service found today on many smart phones and tablets is a simple and potent example of this type of low-key cloud robotics in action. As you search for things via Google's search engine, answer your email or just move around or take photos, Google Now learns about your patterns and sends information automatically to your mobile device that it thinks might be of interest to you. Right now, it's just information provided to your device, but it's a relatively short leap from delivering those kinds of cloud-based inferred actions to more active control of sensors via the Web. If a service like Google Now saw that traffic was slowing your return from work, perhaps it would "talk" to your Web-aware oven at home and put dinner down to a simmer automatically.
Those types of interactions are on the near-term horizon for Web services, a good thing in its own way but also an example of the challenges that RoboEarth might face. There's lots of money to be made in owning both the data that robots collect as well as delivering the services that they can perform via Web-based "brains" controlling their actions. However, there is a lot more to robots than what we can have on our smart phones or personal appliances. There is a wealth of data out in the world from agriculture, weather monitoring, scientific experiments and a host of other sensors that may involve robots collecting and acting on data. So while RoboEarth may not necessarily become the Google of robotics, it may very well become the Wikipedia of robotics - a universal framework for Web-aware robotics that can accelerate both world knowledge and fundamental productivity in places where consumer services aren't the most useful framework for robots. In turn, inevitably even consumer services will be likely clients of data and logic served up by a service like RoboEarth.
In my book +Content Nation I envisioned a time when the world would have vast underground caverns filled with organically-based computer storage and logic providing a worldwide infrastructure for collective gathering and sharing of sensors and other sources of content. In a sense RoboEarth is the framework that could result in a publicly managed infrastructure for such global robotics and knowledge-sharing. The flip side of this potential, of course, would be a system like SkyNet, the global weapons control system in the famous Terminator movies that is taken over by a computer virus that turns the system into a weapon for robots determined to take over the earth. We're always afraid of robots on some level, it seems, and perhaps not without some reason.
But looking at how other open source computer projects have helped to minimize the risk of viruses overtaking sophisticated computing systems, it's worth noting that when everyone has an investment in such a service succeeding, it tends to stay on the side of good things, not evil things. The truth seems to be that human life has become so complex that we need a smarter planet to help both us and the planet itself to survive. Commercial services can take us down the path of collaborative robot intelligence only so far. At some point we need to own that path, otherwise we wind up turning over the very logic of human survival to a small group of people who may or may not have the world's best interests in mind. So from this perspective I think that RoboEarth is a daring, forward-thinking and necessary initiative to ensure that the combined intelligence of people and machines can remain a resource available to everyone. Here's hoping.
For robots to take full advantage of their potential in The Second Web, though, they need not just reasoning but the ability to make sense of everything that's happening in the world around them. This is where RoboEarth comes in to provide the architecture for how this would be done. RoboEarth is an initiative founded by research scientists at the +ETH Zürich university to establish open-source computer programming methods that can create information resources and program logic for robots connected to the Internet. RoboEarth makes it possible not only for robots to store information on the Web from their sensors about what's happening around them, but also to share that information with other robots, as well as data from other sources and libraries of programmed actions that a robot can take based on all of that data.
In other words, the Web can be the robot's chief source of intelligence and inferred actions, while the robot itself can be designed mostly to collect information about the world around it and to be a machine that acts on information as good as possible. So, instead of the model of thinking that a robot has to have a "brain" exactly analagous to the human brain - a huge store of knowledge and logic and sensor processing - the robot can remain relatively dumb, as long as it can be connected to the smarts of the Web, and act both individually and collectively based on the data gathered by other robots.
In fact, this concept is already taking form today in more simple ways in products that many people use all the time. When we use a smart phone, for example, its sensors are picking up up data and often sharing it with a service provider like Google or Apple. These service providers in turn are learning how to find correlations in that data with personal interests and actions that the person are likely to take when certain data patterns emerge.
The Google Now service found today on many smart phones and tablets is a simple and potent example of this type of low-key cloud robotics in action. As you search for things via Google's search engine, answer your email or just move around or take photos, Google Now learns about your patterns and sends information automatically to your mobile device that it thinks might be of interest to you. Right now, it's just information provided to your device, but it's a relatively short leap from delivering those kinds of cloud-based inferred actions to more active control of sensors via the Web. If a service like Google Now saw that traffic was slowing your return from work, perhaps it would "talk" to your Web-aware oven at home and put dinner down to a simmer automatically.
Those types of interactions are on the near-term horizon for Web services, a good thing in its own way but also an example of the challenges that RoboEarth might face. There's lots of money to be made in owning both the data that robots collect as well as delivering the services that they can perform via Web-based "brains" controlling their actions. However, there is a lot more to robots than what we can have on our smart phones or personal appliances. There is a wealth of data out in the world from agriculture, weather monitoring, scientific experiments and a host of other sensors that may involve robots collecting and acting on data. So while RoboEarth may not necessarily become the Google of robotics, it may very well become the Wikipedia of robotics - a universal framework for Web-aware robotics that can accelerate both world knowledge and fundamental productivity in places where consumer services aren't the most useful framework for robots. In turn, inevitably even consumer services will be likely clients of data and logic served up by a service like RoboEarth.
In my book +Content Nation I envisioned a time when the world would have vast underground caverns filled with organically-based computer storage and logic providing a worldwide infrastructure for collective gathering and sharing of sensors and other sources of content. In a sense RoboEarth is the framework that could result in a publicly managed infrastructure for such global robotics and knowledge-sharing. The flip side of this potential, of course, would be a system like SkyNet, the global weapons control system in the famous Terminator movies that is taken over by a computer virus that turns the system into a weapon for robots determined to take over the earth. We're always afraid of robots on some level, it seems, and perhaps not without some reason.
But looking at how other open source computer projects have helped to minimize the risk of viruses overtaking sophisticated computing systems, it's worth noting that when everyone has an investment in such a service succeeding, it tends to stay on the side of good things, not evil things. The truth seems to be that human life has become so complex that we need a smarter planet to help both us and the planet itself to survive. Commercial services can take us down the path of collaborative robot intelligence only so far. At some point we need to own that path, otherwise we wind up turning over the very logic of human survival to a small group of people who may or may not have the world's best interests in mind. So from this perspective I think that RoboEarth is a daring, forward-thinking and necessary initiative to ensure that the combined intelligence of people and machines can remain a resource available to everyone. Here's hoping.
Labels:
AI,
appliances,
artifical intelligence,
cloud computing,
computer science,
computers,
ETH Zurich,
internet,
mobile,
network,
open source,
phone,
programming,
research,
robotics,
sensor,
software,
tablet,
web
Wednesday, January 23, 2013
DIALing for Apps: The New TV Surfing Comes to The Second Web
Your average TV viewer under a certain age is pretty much used to the idea that mobile phones and tablets go together with their televisions like toast and jam. Services like Apple's AirPlay and +Google TV have enabled video and other content available on mobile devices to be displayed on TVs easily. However, screen sharing or "flinging" of content has been limited for the most part to very generic video streaming (TV as a dumb receiver of an image) or limited to specific services and technologies. That's not the type of openness that's likely to feed a world of technologies waiting to transform the "boob tube" into a new form of interactive entertainment.
In other words, the idea of app-to-app communication is experienced by most people as more of a techie thing than a media thing. There's channel surfing and then there's those apps that somehow you manage to navigate through to get things up on the big screen - or back to your mobile device. OK, but not great. DIAL intends to change all that by making it a "it just works" experience to get a mobile app to communicate with its counterpart on whatever smart device is attached to your TV. So if you want +Netflix on your TV, for example, you can queue up what you want on your tablet, tap once, and launch the video via the Netflix app on your TV. This eliminates the need for your mobile device to be streaming video to your TV and enables features specific to the on-screen TV experience that remote streaming could not provide.
Enter DIAL, a standard for multi-screen sharing that focuses on device-to-device apps communications. In its basic form, DIAL changes the whole sense of what it means to have a "smart TV." Today's smart TVs you have some sort of computer-gizmo that communicates with a remote to flip between applications (in the instance of Google TV, you can flip over to live TV also from within the gizmo). Some of those apps might support their counterparts on mobile devices, but there are often pairing codes and such to get the mobile app to communicate with the TV's version of the app.
But DIAL is more than just making app-to-app communications simple. As DIAL-enabled apps become more prevalent, it will change the way in which we consume our content. We'll be more apt to surf apps on our handheld mobile devices for content than we will a cable or satellite TV guide - something that "cord cutters" do already, but generally within a very small universe of apps that come on their TV-connected smart devices. With DIAL, the norm will become app surfing, with each app becoming potentially an entertainment experience in and of itself.
In the short run this will mean that games, video, music and social media will be far easier to consume and share on a TV screen, making the mobile device the center of both content discovery and control rather than bulky, weird and redundant remotes. That can create very interesting opportunities for search-oriented Google, which already has used its PrimeTime app on Google TV to combine searching of online video rental sources with local video collections. Why search just the Web when you can search content available through DIAL-compliant apps? You can see why Google has partnered with Netflix and Samsing, Sony and Hulu early on in DIAL's development.
In the long run, tough, DIAL may change the very nature of how entertainment and services are packaged for people. Old-school is selling tickets to the film, video, the "collector's edition" video with outtakes and games, and so on. Nu-skool is more likely to be to sell people the app via a YouTube or +Flixster trailer, from which they can gain entrance into a movie showing that's charged to their account, with in-app premium options that can be managed on a universal or per-screen basis. Social media-embedded widgets can provide ways for people to share app/media experiences easily and to enable people to launch into them on whatever screen or device they'd care to. While the emphasis on this is mostly on video so far, you can see where games music and appliance controls will benefit from DIAL universal apps communications also.
What will help to accelerate the acceptance of DIAL is an emerging generation of tiny, high-power computers not much larger than a typical USB "thumb drive" or Roku stick. On the road and want to catch up with your favorite entertainment on a hotel TV screen? just plug in your "thumb computer" into your room's TV monitor and have a go. Going to a friend's house to play some games? bring your thumb drive if your friend doesn't have one already.
DIAL promises to streamline the management of intellectual property rights also, enabling revenue-sensitive media companies to keep their payment plans within the walls of their own apps. Hopefully this would make it far easier for device makers to simply crank up a new gizmo on a commonly deployed platform like Android and be done with it. It's even possible that Google TV as we know it might become an app within such an environment, enabling cross-source, cross-app search and content selection where media providers felt that they could benefit from it.
All of this points to a far more robust environment for selecting and using Web-aware services on our TVs and other in-home appliances, making smart services the norm rather than the exception. With in-room and mobile sensors such as Microsoft's Kinect becoming more pervasive in the next couple of years the ways in which these apps will respond to our humanness will also be accelerated, further feeding the multi-screen value chain that DIAL supports.
And then there's the Web itself, of course, which so far remains outside of DIAL's functionality. This is where high-function Web browsing via smart TV devices will continue to be important - and where the longer-term battles are continuing to emerge. As the Web itself becomes smarter, the merging of DIAL and Web standards is probably inevitable, but not necessary for starters. So long, channel surging - hello, app surfing. Yet again something new to explain to my wife, but thank goodness it will be easier for her to use.
Subscribe to:
Posts (Atom)














