I was going to say that they didn't buy that part of Motorola, but it turns out that they moved the set-top box (and cable modem) division into Motorola Mobility before Google bought them.

That seems weird to me.

I think Google's Nexus phone/tablet approach of partnering with manufacturers, co-branding the devices, but ultimately having it sold as a Google product first and foremost is a great idea, and is in keeping with Google's A/B testing philosophy. You try one manufacturer, then the next one, etc. and see what works. The manufacturers are forced to compete for your business, which leads to better products. I've read that Apple does this on some level with some of their suppliers -- though Foxconn has pretty much become the go-to facility, many other suppliers and manufacturers have worked to gain Apple's business in Shenzhen. Obviously the end result is an Apple-branded product with no Foxconn logo on it, and, yes, Apple does micromanage the design details more than Google has with the Nexus phones, but ultimately, I think the approaches have more similarities than they do major differences.

Re: the Nexus Q, one interesting point I heard on NPR today that I don't think has gotten a lot of mention is that the device is going to be assembled in the U.S. with U.S. labor, which explains why it's so expensive relative to comparable devices. It's an interesting decision, and should help root out how many people will put their money where their mouth is when it comes to being against cheap foreign labor (my guess is it won't be that many.)

I think people know that Android == Google, and that HTC, Samsung, Motorola, etc. are all just people who make "Android phones" (the recent Moto acquisition notwithstanding -- still not sure exactly how that will play out long-term.) The manufacturers have tried to differentiate with UIs and whatnot, but it's all part of the Google mothership, and I think there's broad recognition of that. Maybe an individual manufacturer won't like that deal, but ultimately I think it works for both parties, and there's nothing really to be gained by Google in scratching off the Asus name, or by Asus in minimizing the Google branding.

I don't really get the Nexus Q either. I guess I see two different things that would be better.

1) Something for $50 or less that does what the Nexus Q does, minus the speaker amp. At that point, you've got a useful toy at an impulse-buy price that you can connect to any TV and get something vaguely useful.

2) The full GoogleTV experience wired into a fancy Japanese home theater receiver. Much as I like my Pioneer Elite SC-25, their attempt at a UI is comical. It's only modestly improved in their newer receivers.

As it is, the Nexus Q slots into the funny space populated by compact audiophile all-in-one products like, say, the Arcam Solo Mini. Assuming that the amp in the Nexus Q is any good, it might even be competitive in this oddball audiophile category.

I haven't read anything to suggest that the Nexus Q approaches audiophile quality in any way. Certainly the fact it has an integrated 25w amp helps push it firmly away from that category.

Like many things Google has tried over the years, it's a solution in search of a problem, and even the designers don't understand what it is - read the interviews. They talk about what it can be, but right now it's a paper weight.

The blowup of the amp stage shows a small TI chip and some capacitors. I can't read the part number but it could be something like this (here's TI's press release from last year).

This certainly isn't sold as an audiophile part, but until the audiophile measurement dudes start beating it up, we won't know for sure. Class D amps are often surprisingly good.

They're big fat inductors (you need these on class D output otherwise you'll be radiating a lot).

I don't get it either; the defence for the price appears to be "we're competing with Sonos", but to be honest just having a 12+12W amp internal does not make you a Sonos competitor. Being able to stream from multiple local and remote sources and have drop-dead simple networking would make you more like Sonos.

The other comparison would be the Rio Receiver

- Linux based (same as Q)
- Made in the americas (ok, Mexico) (kinda same as Q)
- Only streams content (same as Q)
- Great quality audio out (I actually think the Burr-Brown 1716's in the Rio are likely better sounding than the Q, but I can't prove that)
- 10-12W class D speaker amp built in (same as Q)

Of course, the Rio was launched over 10 years ago and only cost $249. You also didn't need a smartphone/tablet to control it, as it had a screen and a remote (and a volume control on the box!)

Hmm.

Sonos is pretty niche, but Google isn't likely to sell even a fraction of the same volume with their Q. Which incidentally is already ripping off the name of Ceton's streaming PVR. Not to mention a new Motorola handset coming out soonish.

In any case, Sonos is a fully baked product with years of development behind it. Google don't have the talent in house to do anything even remotely similar in quality over the course of a few years, let alone a few months. If they were serious about music devices and streaming, they'd just acquire Sonos.

While it's expected that we don't understand Google, what's laughable is that Google doesn't understand Google.

David Pogue on Google Q: Baffling

Apart from its lacking features, which we already knew, the clusterfuck that is their software design is just icing on the cake.

You can rotate the top of the Q's sphere to control the volume. But that is the only physical control it has.

While city dwellers and unlimited data plan people probably don’t care I’m pretty stoked about the offline Google maps.

While NavFree worked OK it has some issues. Like sometimes telling me to perform a U-turn on a highway and then after that do a second U-turn. It’s good I have a little bit of a brain or I’d be stuck doing endless U-turns at the Michigan/Ohio border on I-75. Not the safest, or for that matter even a legal thing to do.

Yeah, that was actually available as a "labs" feature in previous releases of maps, but the UI for it is improved now that it's a proper advertised feature. Good to not be burning up my data connection, GPS, and display all at the same time, which often uses battery faster than it can charge in my car.

While I haven’t tried the new offline maps yet it looks like you can download as much area was you want. The with labs version you could only download 10 square miles (or something very small) at a time. Not so hot for a 500 mile road trip. Or if you get lost.

Is the new offline feature out now? It will let me download an area the size of the metro area here but not 500 miles or anything.

Yeah, it's still limited, just not as limited. I can get the Pittsburgh region, but not as far out as where the in-laws live. You can create multiple offline areas to work around that, but it gets a bit silly if you want to get, say, the whole east coast or whatever (though that might use up quite a bit of storage space.)

The largest area I can cache takes 80MB. I can view the cached area offline but I can't do a lookup in it unless I have a signal.

Really, wow I was hoping for better than that. I know Google Maps has a lot of detail and probably all of that would take a lot of space but it seems like they could allow you to select the level of detail you want to download. Not allowing you to set a course without signal is pretty weak.

Are the maps still tile-based? That's useless for interactive maps, especially for offline use. Are there any vector-based mapping solutions available, like TomTom?

Maps has been vector-based since 2010 or so. 80mb seems reasonable for vector data for a moderately-sized metro area with points of interest, etc.

80mb is good if it will last you for an entire day's driving around. I keep a full NA TomTom install on my iPhone that takes up over 1GB.

While Google has vector data on the back end, the mapping solutions I've seen for iOS using their data had been using graphics tiles which needed to be fetches a few at a time from a live network connection. Yuck.

I'll take well designed, detailed raster based maps any day over poorly designed, sparsely detailed vector maps.

I really like the flexibility of being able to pre-cache areas that I know I'll be in a lot to reduce data use while driving, but I also find myself navigating with the satellite layer enabled from time to time, which does use quite a bit of data, and which you can't really pre-cache since the data volume is quite large (and varies depending on what zoom level you're at.) I think Maps hits the sweet spot here -- if you want more detail, you can get it, but the vector-based road map layer is enough to do just about everything. Wouldn't be bad to add the ability to select cached areas state-by-state or county-by-county instead of just using rectangles, but that's really a minor quibble.

One doesn't have anything to do with the other. This is all about presentation layer and where the data is rasterized. Google's database isn't made up of millions of bitmaps, that's just what's served to the presentation layer so the app/browser doesn't have to perform the rendering.

Just in case: I'm talking about maps and map data used to display the streets and calculate routing, not pretty photographs of trees and buildings, including, but not limited to satellite imagery.

The point I was making is that having the source data on the device and the ability to rasterize within the app gives you the ability to zoom and obtain more detail without hitting the net. A potential sacrifice in CPU/GPU performance for the rendering, but a savings in network access. Should come out ahead since bitmaps take up a lot of bandwidth and the platforms usually have CPU/GPU to spare.

My point in response was just that GMaps has had the best of both worlds for a couple of years now, and now that it can pre-cache the vector maps, it's even more useful.

I understand all that (I actually make mapping sites and apps for a living at the moment).

My point was that given the choice of having a crappy map delivery in vector form, as opposed to a good map in raster, that I would take the raster every time. i.e. that the quality of the map itself is far, far more important to me than how it is delivered.

Got that. I was replying to Andy. The functionality you're describing however is likely specific to the maps app on Android, right?



Understood as well. I was talking about the same back-end data from the same provider expressed in two different ways, not making a distinction between providers with different level of detail/quality.

From a usability perspective, the consumer can only see what's rendered in their app, and having the map data within the app itself when you don't have a network connection, is always going to trump having only some pre-rendered bitmaps.

There are plenty of useless map apps in the App Store using pre-rendered bitmaps. I said map and not nav on purpose, because these guys don't have enough data to provide routing. Which itself is OK as long as that's the kind of app you're looking for, which I was at the time.

For me, I want good street-level detail in a mapping app and a navigating app, with the ability to alter the presented detail level by zooming and/or other preferences. In iOS, the built-in maps app didn't offer that without a data connection - and it was slow, and of course wasn't a turn-by-turn based navigation app at all. And I wasn't able to find that in another non-nav local-based app either. So in the end I use Tom Tom's app for both purposes.

I just might be doing it wrong too but if not yeah it's pretty pointless.

I may be totally wrong, but I'm pretty sure that if you have a data connection when you start your route, your route will be cached on the phone and you won't simply lose it if you go through a dead spot. The problem is that you probably need a data connection if you make a wrong turn and need course correction. But in a case like that, you'd need to cache a good deal of data if you were doing a 500 mile trip and needed all possible detours along the way. Chances are, in those cases, that at some point you'll be able to get signal back somewhere and correct your course anyway.

Frankly I don't find the feature all that useful for that reason. I find it cool, and hope that they'll let you download more info in the future, but until you can I don't see a lot of use for it, which is why I enabled it in labs ages ago but never used it. The way I see it, it's designed to give you cached info of a single place, like a city where you're going to have a data connection all the time anyway. I guess it would be better for things like touring small towns on vacation where they aren't blanketed with a data connection.


I have no idea what the experience is like on iOS, but all I can do is reiterate what Tony said: Google moved to vector mapping in their Maps app on Android (looks like it was around the end of 2010, so not quite two years ago), and I could have sworn that it wasn't long afterwards that the same thing came to the iOS version, but my research seems to tell me that it never did, which is odd. The performance increase when they made the switch was tremendous. The zooming was much more fluid and fast.

Correct, Maps on iOS powered by Google remain bitmap based, and lack turn by turn navigation. At the announcement of these features, Google stated they would be coming to iOS as well. Two major OS revisions later, and it never materialized. I've not found a verifiable reason either, speculation goes both ways. Some say Apple blocked it, while others say Google withheld it when the two sides couldn't agree on some privacy and other data handling issues. Even at the event back in June, Google said their new stuff was headed to iOS at some point.

Doesn't matter now for the built in maps, since iOS 6 will have Apple provided maps from the companies they acquired. Vector based for all iOS 6 devices, and driving directions for people with newer hardware.

Why just newer hardware? Android has had it since 2009. Surely it's not a horsepower issue.

Apple hasn't given a reason that I'm aware of. For those who have older hardware, plenty of other navigation apps will still work.

I wonder why Google just never released a standalone maps program for iOS if they were serious about delivering vector and navigation to the platform. They have plenty of other iOS applications.