I’ve spent the last two weeks wandering around London, Paris, and Istanbul (not Constantinople.) As an experiment, I left my trusty MacBook Pro behind and brought only the $199 Chromebook on which I type this. And to my considerable surprise it has served admirably. So admirably, in fact, that I believe ChromeOS is only one or two iterations away from being the right choice for many-if not most–homes.

I was skeptical to begin with: after all, I thought, Chrome is acceptable when you’re online, but I’ll be spending much of my travel time offline, which probably makes it a non-starter, right? — So I devoted most of my Chromebook’s (bizarrely spacious) 320GB hard drive to an install of Ubuntu. Which I then never used even once.

I suppose I would have if some kind of critical work emergency had come up: after all, I’m (mostly) a software developer by trade, and ChromeOS isn’t much of a developer platform. But that didn’t happen. Good thing, too, because Linux-on-the-desktop seems as ugly and frustrating as ever for someone, even a deeply techie someone, who just wants to get things done.

ChromeOS, though, is both very pretty and almost painless. Its biggest problem is that out of the box it naively insists that you’ll be online all the time–even though it can be perfectly serviceable while disconnected. You may not have known that nowadays both GMail and (most) Google Docs can work just fine offlne.

And if you didn’t, well, Google sure isn’t about to proactively tell you. You actually have to make a point of seeking out, installing, and then activating Offline Gmail and Offline Google Docs from the Chrome Web Store. Why ChromeOS doesn’t prompt you with this option as part of the onboarding process is truly beyond me. Similarly, why on Earth are “Gmail’ and “Offline Gmail” two separate apps? Google may be full of incredibly smart people, but they can also be insanely myopic when it comes to end users.

Once those were up and running, though, my Chromebook was a charm to use under almost all circumstances. Offline, I could write documents, check old email, and even play a few free games from the Chrome Web Store, although most Chrome games still seem to require an initial server connection to start up. And online, of course, the world was my oyster.

Did I have access to all the features of, say, Word or Excel? Hell, no. (You still can’t create a Google Docs spreadsheet when offline, either.) Was it an all-guns-blazing gaming experience? Again, no, although Chrome’s rapidly evolving Native Client ought to keep matters improving here. What I could do, though, was email, play a few games, surf the Net, communicate (via GChat or Google Hangouts, which worked excellently), and write documents — which unless I’m much mistaken is pretty much everything that most people use their computers for at home.

ChromeOS still needs better, and simpler, offline support; and I’d like to see more diversity of available hardware; but once those two things are addressed, which shouldn’t take long, I would happily recommend a Chromebook to my parents the next time they upgrade. In fact I’d happily recommend one to anyone who wants a small second laptop for travel, or who doesn’t need to do serious work on their home computer.

Long ago Neal Stephenson, when comparing operating systems to vehicles, described MacOS as a hermetically sealed day-glo VW Beetle; MS Windows as a clunky two-tone station wagon; and Linux as the product of a horde of dreadlocked hippies who spent their time building M1 battle tanks and giving them away for free. Which sounds great at first, but who actually wants to drive a tank?

Well, if I may extend that a little, ChromeOS is like a sleek, shiny Airstream trailer built around that same M1 engine. There are many things it can’t do, and a bunch more at which it’s very clumsy, but within its bailiwick, casual exploring, it’s both very attractive and awfully comfortable.

I don’t think Stephenson’s original analogies quite hold any more, though. Nowadays OS X is more like a Porsche…and Windows is a gas-guzzling pickup truck, or a cube van that makes disturbing noises whenever it corners. Still suitable for work, but not particularly great for either road trips or sub/urban living — and nowadays looking nervously over its metaphorical shoulder at the flotilla of drones and self-driving cars on the horizon.

Image credit: Dan McCullough, Flickr.

Article courtesy of TechCrunch

About a month and a half ago, Google switched to its own WebP image format in its Google+ Android app, the company revealed at its I/O developer conference in San Francisco today. This, Stephen Konig, a Google product manager who focuses on WebP and Chrome Remote desktop, and Make the Web Fast team member and Chrome developer advocate Ilya Grigorik said in today’s presentation, is saving Google – and its users – about 50% in bandwidth.

Google+ App For Android Quietly Switched To WebP Image Format A Month And A Half Ago, Saves 50% Bandwidth

Google+ is obviously a very image-heavy service and given that Android can display WebP natively since the introduction of version 4.0, this was a pretty logical move for the team. The team, however, also said that the plan is to introduce WebP to virtually every other Google product, too – and possibly within the next year. The slide the team showed during the session including the logos of YouTube, Google Image Search and virtually every other Google product (and sadly I didn’t catch it in time).

The company made this switch very quietly, just like it did with the Chrome Web Store earlier this year. In the Store, the team reiterated today, using WebP resulted in image sizes that were about 30% smaller than using PNGs.

The current problem for WebP – which can save developers a good amount of bandwidth thanks to its improved compression ratio – is that it’s only natively supported in Android, Chrome and Opera. For other platforms, developers still have to service traditional JPEG or PNG images or use other tricks to display WebP. The WebP team, however, also said that it believes Firefox will support it within the next year, too, and seems pretty optimistic about the format’s future (but then, of course, they would say that…).

Article courtesy of TechCrunch

One of the most interesting product demos on display at Google I/O this year was a virtual sky diving simulation build using eight separate computers running Chrome, along with a Kinect-like motion sensor made by ASUS called the Xtion Pro. The Maps Dive experiment was created by Portland-based independent digital agency Instrument.

Developer Ben Purdy explained that they built the impressive tech demo to show what’s now possible with Chrome and how it can be used to create amazingly rendered multi-display experience that looks like you’d expect it to be powered by current-gen gaming hardware instead of just a loose assortment of lightweight Linux-based computers running essentially the kind of code that web developers are already comfortable and familiar with.

Map dive provided an experience that seemed as least as accurate and sensitive as your typical Kinect game, and Purdy said that really it’s a just an early example of things that could be built with the computers we already have, and the mobile devices as well. Considering how far Chrome already reaches, imagining this type of experience running on even low-cost Chromebooks and Android tablets does open up a lot of possibilities.

Article courtesy of TechCrunch

Google’s decision to fork WebKit and launch its own Blink rendering engine came as a surprise when the company made the announcement just over a month ago. Yesterday at the Google I/O developer conference, the Blink team provided an update about the state of the engine. As Alex Komoroske, a product manager on Chrome’s Open Web Platform told the audience, the team has already removed 8.8 million lines of code from the original WebKit repository.

When Google first announced this move, the company argued that it was doing so because WebKit had become somewhat unwieldy to maintain because of the wide range of platforms it needs to support. In the process, WebKit development slowed down for all of the partners involved. The fork, the Blink team told me at the time, would allow them to “remove 7 build systems and delete more than 7,000 files—comprising more than 4.5 million lines—right off the bat.” Clearly, Google has been moving quickly to identify even more code in the WebKit source.

This not just about removing the crud from WebKit for the sake of it, however. The team argues that just over the last month, this move to Blink has already made all of the developers who are working on Blink far more productive than ever. Indeed, they argued that they don’t really need to hire more people now that they are going it alone because the individual developers are so much more productive.

The Blink team is already doing more than just removing code, too. Google also talked about a number of Blink experiments it is working on, including Oilpan, which tests putting DOM nodes in a garbage-collected heap, and Lazy Block Layout, which examines how the engine can speed up the rendering process for large web applications by just focusing on the parts of a site that are actually currently on the screen. In one demo, this system helped the team to bring down the rendering time of a very large page from 4 seconds to 32ms.

The team also noted that it’s already getting support from other companies that want to contribute, including Adobe, Intel and Microsoft, which just yesterday submitted a formal Intent to Implement to the Blink team to bring its Pointer Events API for interoperable mouse, touch, and pen interactions in the browser.

Article courtesy of TechCrunch

Flying under the radar amid a flurry of announcements from today’s Google I/O developer conference is the bigger news of how Google is stepping up its efforts to compete with online payment giants with a revamped checkout process for the web, mobile web, within mobile applications running on Android, and more.

It’s a proposed death to PayPal by a thousand cuts, leveraging everything from Chrome to Android and even Gmail. What Google hasn’t quite worked out yet is how all this will tie together in the long run, but you can see the plan beginning to form.

#1: Google Wallet On The Web: Storing Payment Credentials In Chrome

Let’s start with the browser, the de facto home for online shopping.

It’s not news that the checkout experience is broken. Shopping cart abandonment is one of the biggest pain points for today’s merchants, mainly because their websites have traditionally offered only cumbersome and tedious forms for shoppers to fill out in order to make a purchase.

As noted during today’s keynote, one of the hardest things you can do on the web is try to buy something. The process takes around 21 steps, the company explained. Of course, Google is exaggerating here a bit – billing and shipping details are usually the same, but Google counted each field (street, zip, etc.) twice.

That being said, things are even worse on mobile. Google notes that shopping cart abandonment on mobile devices is now an outrageous 97 percent. Again, that seems high (here’s the source for that figure), but the trend Google is illustrating with these slightly puffed up figures is not.

For comparison’s sake, Monetate’s data put global cart abandonment at around 82 percent as of Q4 2012. The company has been seeing increases in cart abandonment – which had been around 60 percent over the past several years – due to an increased number of shoppers doing research on mobile phones and other devices. As they reach the point of checking out on mobile, they’re now more likely to give up and move on because of the increased difficulty of the experience on mobile’s small screen, combined with retailers’ failure to roll out mobile-optimized experiences even as percentages of mobile shoppers continue to grow at record rates.

A number of startups have been attacking this challenge in various forms – mobile apps featuring universal carts, native m-commerce storefronts, mobile optimized payment flows, one-click mobile payments, in-stream payments, and more.

Google’s plan?

Leverage Chrome.

Chrome is already the world’s most popular browser, with more than 750 million monthly active users today, up from 450 million just a year ago. Now it will begin baking in a speedier checkout experience into its browser by syncing your billing information and other details within Chrome.

What that means is that, in the future, when you visit a website using the Chrome browser, including the Chrome mobile browser, you’ll automatically be offered up a prompt with your billing profiles. Chrome can then use autocomplete functionality to fill in information for you like your address, zip code, credit card info and more.

This functionality is being introduced via a new requestAutocomplete API, which Google describes here as “an aspiring web standard that will allow users to bypass pages of form fields with an imperative API for requesting details the browser knows.”

Says Google, this drops the checkout process from 21 steps to just 3.

Overall, it’s a worthy attempt at solving the problem with online checkout, but it still suffers from some potential obstacles to broader adoption: website owners will have to implement the functionality (the API) on their end, and unless this “aspiring” web standard becomes an “actual” web standard supported by all browsers, its impact would be limited.

This feature is still in its early days, but it’s designed to be open. Presumably, the company would still want to at least offer support for payment information retrieved from users’ Google Wallet accounts, if not actually require it. (Theoretically, payment info could just be saved directly in Chrome or any other browser without the need for a Wallet account.)

#2 Google Wallet On The Web (Um, Again): Google Wallet API

While the above describes what will first be a Chrome-only feature to start, Google Wallet has already found a way to support the web and mobile web through more traditional means.

In addition to supporting online checkout through Wallet, last fall, the company launched a Google Wallet API which allows e-commerce website owners to support checkout via Google Wallet on mobile devices. This is independent of the browser or mobile operating system however, making it more like an alternative to the PayPal button.

It’s a bit confusing because with the new Chrome autocomplete functionality, it seems there will be some overlap between the two. Site owners would end up implementing two APIs to be fully supportive of Google users: one to speed up checkout through automated form filling in Chrome (likely pulling payment credentials from a user’s Google Wallet), and another if they wanted a Google Wallet button on their site which users could click to instead be walked through the Google Wallet checkout flow.

Which is better? How will these two tie together? For now, Google can’t say, only noting that it’s still the “early days” for the Chrome autocomplete API and it’s probable that Google Wallet will be supported in some way.

But nothing is definite yet.

It’s a perfect example indicative of how Google needs to bring its separate teams together in order to tell a more cohesive story about payments. Rumor has it, the Wallet team has been too “siloed,” which has caused some issues. (See part #5 below, for example).

#3 Going Wallet On Android: Paid Apps, In-App Purchases & Now, the Google Wallet Instant Buy Android API

Android is the world’s most popular mobile operating system, so it only makes sense for Google to take advantage of that fact to pull in more users’ payment information. After all, today’s users are already using Google Wallet to purchase paid applications for Android devices as well as in-app purchases, so why not extend Wallet to support purchases of physical goods, too?

That’s just what Google did.

With today’s new Google Wallet Instant Buy Android API, merchants and developers selling physical goods and services (as opposed to virtual goods, like those sold in mobile games), can now offer 2-click checkout to their customers.

At launch, the company has signed on a number of new partners, including Airbnb, Booking.com, Expedia, Fancy, GoPago live POS, NFC Task Launcher, Priceline,
Rue La La, Tabbedout, Uber, and Wrapp.

The service ties in also with Google+, allowing users to register and sign in to the apps, similar to Facebook Connect, and then tap to checkout without the need to enter in billing or shipping information.

#4: Google Wallet in Gmail: “Attach” Money

Another vector in the fight to topple PayPal is person-to-person payments – like paying the babysitter, or paying your dad the money you borrowed, for example. Digitally savvy folks today still largely turn to PayPal to make this happen.

Google’s plan here?

Leverage Gmail.

It’s simple and ingenious really. The familiar email “attachment” icon has just become another onboarding experience for Google Wallet. With the Gmail update, the service’s 425 million+ users can hover over the attachment paperclip icon, then click the $ icon in order to “attach money” to their message.

Of course, you’ll need a Google Wallet account first.

For now, the feature is only available in the desktop version of Gmail, but it will certainly come to mobile in time.

#5 Google Wallet In Real World? (What’s Plan B If NFC Never Wins?)

The only area where Google is lacking a solid strategy is in real world payments – an area where competitor PayPal has been ramping up quickly in recent months. PayPal has been working with nearly two-dozen nationwide retail chains, including Home Depot, Jamba Juice and more, to be integrated into their point-of-sale systems. It has separately announced integrations with point-of-sale and hardware makers like NCR, gas station and convenience store-focused Gilbarco Veeder-Root’s point-of-sale system, coin-counting kiosk maker Coinstar, and more.

Google has been trudging along with its NFC-based Google Wallet app – an app using technology whose broader adoption has been slow to pick up here in the U.S., in part due to a lack of support from Apple, as well as swirling questions as to how much of an improvement tapping your phone at point-of-sale really has over a card swipe in the long run.

Google had plans to launch a plastic “universal” credit card which would allow users to switch between their preferred payment methods on the fly while still using a physical card at point-of-sale. For whatever reason, the company scrapped those plans just ahead of Google I/O.

Combined, all of the above areas on their own can’t be considered a PayPal killer by any means. But as they become more tightly integrated over time (assuming Google can get its teams together to focus on the bigger picture beyond their own product’s development and focus on the global stage), you can see a viable threat to PayPal starting to shape up.

Article courtesy of TechCrunch

Today, Google announced that its conversational search that is available for its Android and iOS apps would be coming to the desktop within the Chrome browser. Until now, you could search for things using your voice…but you couldn’t ask questions.

Now, you’ll be able to keep your mic open without clicking a button, by waking Google up with the prompt “OK Google.” This is similar to the prompt that wakes up Google Glass.

You can say things like “Show me things to do in Santa Cruz” and get results quickly, and with the context that you need to take an action. It’s very similar what you can do with Google Now right now. The familiar voice will respond to you, answering your question. That’s what Google Search is all about now, asking questions.

Without having to worry about “how” to search for something and asking a simple question, you can get more done, faster. That’s Google’s goal. You’re not going to get answers to all of your questions, but the company does collect information about those failed searches. It gets smarter, like all of their products.

Will you sit and speak to your computer? Asking it questions? It sounds odd, but no more odd than talking to a microphone on a pair of lensless glasses.

Article courtesy of TechCrunch

Sundar Pichai, Google’s senior vice president for Chrome and Android today announced that the company’s Chrome browser now has more than 750 million monthly active users. That’s up from 450 million users Google announced at last year’s I/O. This number, as far as we can see, includes both desktop and mobile users.

Google launched Chrome in 2008 and since then, as Google proudly noted in today’s keynote, it has become the most popular browser in the world. It is also now, as Pichai noted early on in the keynote, a very important platform for Google that stands side-by-side with Android.

Just recently, Google also decided to take more of the development process of Chrome in its own hands when it dropped WebKit and decided to start developing its own Blink rendering engine based on WebKit.

Updating…

Article courtesy of TechCrunch

Google’s Sundar Pichai spoke to Wired in an interview published today ahead of Google I/O this week, describing what it’s like to be taking the helm of both Android and Chrome going into the annual conference. Pichai took over for Andy Rubin, who stepped out of his role heading up Android back in March.

These days, he says not much has changed around his thinking about Chrome and Android, but he did have some statements about the open nature of Android that rang more sincere than most statements from Google execs on that aspect of the business, which is usually referred to as an impossibly good thing.

Open Is Great, But…

Pichai reiterated the company’s general love for the “open” nature of Android, but he also brought up the very real ways in which it limits Google’s ability to provide a consistent and recognizable experience to all users of its mobile OS.

“Here’s the challenge: without changing the open nature of Android, how do we help improve the whole world’s end-user experience?” Pichai told Wired when asked about the biggest challenge facing Android. “For all your users, no matter where they are, or what phone or tablet they are buying or what tablet they are buying.”

It was a theme that Pichai came back to again and again, when discussing how Facebook Home has changed the OS experience at a basic level and what Google felt about that. He said that Facebook Home is “exciting,” while disagreeing diplomatically with it from a central philosophical standpoint, explaining that he believes people aren’t at the center of the experience in his mind. Once again in relation to Facebook Home, Pichai talked about the challenges of providing a universal experience to users.

“We want to be a very, very open platform, but we want a way by which end users are getting a good experience overall,” he said in the interview. “We have to figure out a way to rationalize things, and do it so that it makes sense for users and developers. There’s always a balance there.”

Finally, Pichai talked about the different issue of forking Android entirely, and discussed how Google feels about that.

“In general, we at Google would love everyone to work on one version of Android, because I think it benefits everyone better,” he told Wired. “But this is not the kind of stuff we’re trying to prevent.”

This is possibly the most frank anyone at Google has been about how the company views these tangential efforts. Google accepts them, because that’s the nature of the open approach it took when it started out with Android, an approach that helped it win over carriers and OEMs looking to do more than just provide an interchangeable vehicle for another company’s software and services. But Google is also frustrated by them, in that they splinter its efforts, ultimately resulting in Android fragmentation.

Google And Samsung = Microsoft And Intel

On the subject of the supposed Samsung/Google rift that many in the media suspect may be developing, Pichai echoed the company line and said that Google isn’t concerned about Samsung’s prominence in the overall Android ecosystem. He basically said that Samsung has been instrumental in helping push the technology forward for both companies.

Samsung’s relationship with Google is like that of other “long stable structures” found throughout the industry, Pichai said, pointing specifically to the relationship between Intel and Microsoft. Microsoft and HP would be another key example of a long-prosperous combination that never destabilized because of one party craving too much influence over the other. One could argue that the Android ecosystem is a different beat, with Samsung having much more power than any one partner that Microsoft ever had, but that’s hard to quantify.

Google I/O May Be Light On New Stuff

Pichai also seemed keen to take the wind out of people’s sails regarding what’s coming up at Google I/O, which takes place this week Tuesday through Friday in San Francisco. He said that the event will be very much developer focused, especially since it’s not timed around any major product announcements.

“It’s not a time when we have much in the way of launches of new products or a new operating system,” he said to Wired. “Both on Android and Chrome, we’re going to focus this I/O on all of the kinds of things we’re doing for developers, so that they can write better things. We will show how Google services are doing amazing things on top of these two platforms.”

Rumors suggest we might see an updated Nexus 7 and possibly a Nexus 4 with new features like LTE connectivity, but those could be considered minor enough.

Chrome And Android

The biggest takeaway from Pichai’s talk with Wired was that he clearly loves both of his children equally. He resisted multiple attempts by Levy to pit the two against one another, and to point one as unnecessary in the face of the other. Pichai didn’t seem like a man running two horses with the intent of picking the winning one late in the game; Chrome and Android both came off as equally worthy pursuits that Google intends to continue for different but equally valid purposes. That could be why we’re hearing that Android-powered notebooks are on the way, as well as Chrome-powered tablets.

It’ll be interesting to see if Pichai gives both equal billing at the Google I/O keynote, too, which takes place at 9 AM PT on Tuesday morning. We’ll be there covering the action, so tune in to see how it shakes out.

Article courtesy of TechCrunch

At last year’s I/O, Google launched its Cloud Messaging push notification service for Android. This week, it extended this service to Chrome and Chrome OS, which, Google says, allows Chrome apps and extension developers to wake up their apps remotely and/or send alerts to users.

While mobile app developers have long been familiar with the concept of push notifications, this is a pretty novel service for web developers. Unless a Chrome app or extension is running in the background and pulling down information from the service, after all, users can’t usually receive alerts like news updates or stock ticker notifications from the developers’ servers.

Google product manager Mark Scott writes in his announcement that ”event pages keep apps and extensions efficient by allowing them to respond to a variety of events, such as timers or navigation to a particular site, without having to remain running persistently.” This works, but it does consume bandwidth and reduce battery life if you are on a laptop or Chromebook.

Cloud Messaging for Chrome, on the other hand, allows developers to push messages directly to signed-in users. As long as the user is signed in and on a machine where the app or extension is installed, the alerts should automatically start appearing.

To get developers started with this service, the Chrome team has published a couple of sample apps, as well as a pretty in-depth tutorial.

Article courtesy of TechCrunch

Google just reminded developers that they can use Chrome as the default browser for their apps and easily switch back and forth between app and browser. With x-callback, Google says, developers can open links in Chrome and once the page has loaded, Chrome will show a link back to the original app in the top left corner of the screen. This should make it much easier for developers to allow users to support Chrome in their apps.

Currently, Google says, developers have two options when they want to access web content from their apps: they can create their own in-app web browser frame – using Apple’s own WebKit browser, of course – or by sending users away from their apps to a browser.

Once users are in the browser, though, chances are, they won’t come back, so Google’s scheme will surely help to ensure that users remember what app they were coming from in the first place.

To get started, developers have to download the OpenInChromeControllerClass and add it to their projects. The class will check if Chrome is installed and, if that’s the case, you can start sending links to Chrome with x-callback enabled.

Given that Chrome is essentially just an app on iOS, it can’t be set as the default on Apple’s operating system. That’s obviously a problem for Google, because apps will always open links in Safari by default. Because of this, users have little incentive to switch to Chrome because they’ll always be forced back into Safari anyway.

Article courtesy of TechCrunch