Well, Apple apologizes

Funny, if Apple really cared about customer experience as they claim, I guess Mr. Cook should have gone a little bit further, I mean it's not only the Maps experience, you've got a premium product that scratches so easy, that many new iPhones come with scratches (It's a feature, we love our customers so, that we try to prescratch each and every iPhone for them, to save them the bother), the we've got the Lightning cables that jam, at the same time they do include an authentication chop to protect Apple's revenue stream, ...

If you summarize all these problems, if Mr. Cook really wanted to improve the user experience, he should have recommended that users interested in a new phone buy it directly from the competition.

Why is the outcry about Apple Maps not bigger?

Apple maps data is far from perfect in the US, and it gets worse out the US (as in data that is obviously over a decade old, misplacing complete towns, and stuff like that).

Worse, it seems that not only the data is bad, the processes to create and manage the data are broken, e.g. it seems to simply match words in the name to define the type of an object. The issue here is not that it turns train stations into parks or invents airfields where there are none, the issue is that these errors are to common and to systematic, which suggests that the data is being generated by a dumb computer.

Additionally, it seems the Maps app does have problem with navigation as in the blue line not managing to connect the green and red pins. Not good.

Now some suggest this is an overreaction as it happened to Antennagate and other Apple problems in the past. They also suggest that if this goes away in 6 months, nobody will much care.

The author compares the wrong "Applegate" with the past, IMHO, the already scratched new iPhones plus the fact that iPhones, at least the black ones, scratch easier than cheap trac phones, and Apple comments only that this is as it should be. This is something that is comparable to Antennagate.

I also strongly believe that Apple Maps will get better, but many issues will be with us when iOS7 is released, and not fixed in six months:

• The navigation algorithm problem, that problem will probably fixed in short term. It's basically debugging a bug, which as such is hard plan, but it's a thing that you can scale by adding developers to the bug hunt. So expect that one to be fixed with the next minor update.
• The bad data issue is a bigger problem. As Geodata experts have pointed out, merging geo data from different sources via automatic algorithms does not work. (Basically addresses are not standardized, have fun matching these automatically, my experience in a related field that involved matching products by description suggest that some of these decisions are hard for human experts, so how should a computer manage it?)
  As people have pointed out, a big part of Apple Maps have been human-reviewed first by Apple customers, which is a big red flag for problems, all places need to be reviewed first by humans, ideally humans that happen to have local area knowledge.
  So how big is the issue? Well, Apple has a workforce globally of roughly 20K employees. Google Maps alone has roughly 7K employees over the globe that review and fix data. Building up that kind of workforce is doable, and Apple has the money to do so. But it won't happen in 6 months. Apple's need for review and data is even slightly bigger, as they need to handle search issues too, while for Google this is a core competency. 

So considering, that realistically speaking this will not be fixed short term, the outcry about the downgrading the user experience (because the nicest features are irrelevant in the mapping field, if applied to garbage, and users cannot trust the data) is way to small. I don't see Apple offering any compensation for downgrading a vital functionality of 100+ millions of iDevices.

Fast wireless charging on the cheap

As it has been already pointed out, wireless charging has a number of drawbacks, e.g. it's a misnomer, not being wireless at all, as it still needs a wire from the wall wart.

But what most people concentrated on the iPhone lost, is that "instant wireless" charging is already a reality.

It's simple as having a second charged battery, and even better it's mobile, you can take it with you.
The only things you need are:

• a phone with user changeable battery.
• a second battery.
• an external charger for the battery.

The battery and charger will set you back roughly $50, so it's cheap. It's not so elegant as a wireless charger, but it does not waste electricity and it's instant charging.

 

Why Android fragmentation does not really matter

So what is fragmentation. In the context of mobile phones (or computers and similar devices), it means basically diversity, in hardware and software.

It's usually argued that it's a bad thing, or a very bad thing, and it's usually associated with Android mobiles. The other players in the smart phone market seek to eliminate it, e.g. there are basically 3 iPhone and 2 kinds of iPads on sale, and that's it. In practice, that means that an app developer needs only to handle 4 different resolutions (1024x768, 2048x1536, 960x640 and 1136x640) while an Android developer needs to handle resolutions from 320x240 to 1920x1200. The difference in real estate is not that much bigger than in the Apple world, but Apple, with offering basically 6 devices (iPhone 4/4S/5, iPad 2/iPad 3, iPod Touch), allows for more fine tuning and more exhaustive testing.

Microsoft btw went in some ways even further, for Window Phone 7 they specified such a stringent hardware design, that the phones basically came out with hardware one year or so old, WP7 phones basically did not even cause a yawn in the market, as top of the line WP7 handsets had hardware specs similar to midrange Android handsets at the time of their launch.

So yes, from the perspective of the developer, Android fragmentation is a PITA, it makes designing harder, because you need to handle way more different devices, and it makes exhaustive testing an impossibility with over 100 different handsets on the market.

But from the perspective of the user, it's a huge benefit. You've got small hands, go with a small device that feels comfortable in your hands. You've got clumsy hands, and need big on screen keyboards, well, 5"+ phablets to the rescue.
You need a phone that can keep up with your job as a builder or hardcore skiing, no problem. So while the iPhone is and for a long time probably will be the most sold mobile, the iOS ecosystem is starting to become dwarfed by the Android ecosystem, because Android manufacturers while not tailoring an individual handset for your needs, come way nearer to this.

So what about the poor poor developers. Well, they are still in a better situation than in the PC market, where every body can throw together a mix of hardware, slap some OS onto it, and wonder why this does not work as well as a box build monolithically. Android handsets provide certain services, a certain basic level works everywhere, you can query what else is provided by the phone, and so on.

So what about exhaustive testing?

1. exhaustive testing as such is not really feasible. (Every chip designer will tell you that, even a simple boolean function in hardware quickly goes beyond being completely testable.)
2. Well, yes, you have put more work into testing. More leg work, but also more brain work to design the testing that it captures a maximum coverage.

So no, Android fragmentation is not a really big issue (because even the worst differences in the Android space are dwarfed by that Windows XP box from a decade ago versus a Windows 8 touch screen laptop), and it offers huge benefits to the customers. (So even if it would be a big issue, it would be still a question pain for a small set of people versus benefits for a huge set of people.)

Apple loves you, but it loves your money more

So the new Apple Lighting cable introduced with the iPhone 5 has an authentication chip embedded. Guess Apple wants you only to use their reasonably priced cables, naturally just to make sure that you experience  true quality, and certainly not to milk your wallets.

As a tip for frustrated Apple users, try a 3rd-party cable, oops, right that's not okay, that would eat into Apple's revenue.

Funny

This is not a block hole, I mean guys, who has ever seen a black hole with corners?

Apple Maps is not about the availability of a Google Maps app for iOS

As others have already pointed out, it's not about funny displays.

It's about faulty, incomplete data. Old data, examples e.g. from Germany suggest that the data is 5-10 years old, e.g. by land marks not being renamed correctly. In the UK it shows stations that have been closed down in the 1990s.

So the current repair plan for the Apple Maps disaster seems to be:

1. maps.google.com
2. Google Maps app to be provide by Google, unclear when this will happen.
3. Apple Maps will get better over time, the more you use it, the better it will be.

Some observations:

• Usage of 1 and 2 will lower the usage of Apple Maps, hence slow the repair of Apple's data.
• maps.google.com is being sold as a temporary solution. Well, it's not much of a solution, providing even worse an experience than the old Google Maps app, which might have been better than Apple Maps, but far behind the experience on Android.
• But almost everyone seems to assume that the Google Maps app will fix the problem.
• This is not so, as Localisation services are nowadays part of mobile operating systems. Hence all other apps will continue to operate with faulty/incomplete data, with potentially no feedback channel back to Apple to ask for fixes.

As a simple analogy, consider the clock inside your phone would sometimes (say in 1% of cases, really seldom) show the wrong time. Guess installing the "Swiss Quality Timing Service Clock" app would only solve the issue partially, as the phone would still sometime have a faulty idea of the time, hence alarms would sound wrongly (to early, to late, never), your GPS tracker app that records your jogging tracks would show crazy speed jumps, and so on.

Worse in the Apple Maps case, there seems to clear split up, US users seem to have the best data, European seems to be 2nd class users, and the rest of the world, well, guess for these Apple thinks it's enough to be nice enough to allow them to buy the cool iPhone, ...

Naturally, Apple did have a number of hard decisions to take:

• Cooperation is not really high on Apple's priority list. Steve Jobs decreed the thermonuclear war, and Apple has turned a cold (patent) war into a hot one. Outcome despite the jury verdict in Samsung vs. Apple is completely open (if you wonder, groklaw.net does not often predict outcomes, but if PJ does, she is usually right).
• Keeping Google without motivating Google to upgrade the experience was not an option either, I mean Apple Maps mostly adds features which Android users have been using for a long time. (Not that it matters that much, if you cannot rely on data).

On the other hand, for a company with such a big war chest, for a project that been running for years (numbers that have been mentioned range from 2 to 5 years), I'd expect Apple cars driving around the globe, photographing, recording location data, so that the data can be cleaned up. Guess it's not really about the user experience. 

Seems like Apple was caught with their hands in the cookie jar.

The company that claims that everyone copies their design seems to have copied 1:1 the Swiss railways  clock design which has been protected as a design patent for decades.

Why data caps are a bad (or at least dishonest) way to pay for the Internet.

The Internet is based on the TCP/IP (v4 for the moment, v6 is currently "just starting" as it has been for a number of years), is based on splitting data up in packets and sending these independently to the target. The important part is, that IP is by design assumed to be non-perfect, e.g. an overloaded router is supposed to drop packets, and this is the correct behaviour, higher layers rely on this to handle the situation in a sensible way. E.g. TCP does have builtin rules how long to wait for acknowledgement, before starting to resent data, and so on.

Btw, this applies in truth to all ISPs, not just mobiles.

So back to our (simplified) story how a webpage is fetched to your mobile. First the mobile sends a packet to the server to request the page. The request travels over the air to a base station of your network, travels over the internal network and at some point passes over to the public internet, and arrives at the server. The data back from the server travels more or less the same path back.

So where is the problem with this?

Data packets can be dropped at any stage, and especially the last stage over the radio waves is prone, because of overload and/or bad coverage. Now your phone does not get a packet of the response data, hence does not acknowledge hence the server starts to retransmit the response. Depending on your luck, your mobile gets this and acknowledges it, or not, which starts another retransmit.

Okay, that's fine, that's how the Internet is supposed to work.

Well, the Internet yes, but the Internet has been designed without the idea of toll booth, hence it's very hard to count data usage correctly. Most networks count probably at the border to the radio waves, which admittingly is probably the customer-friendliest way to count, but it still does not take into account if the packet is really received by the customer. Basically metered voice calls/texts have the property that usage is clearly observable by the user. Data usage OTOH, cannot even be correctly observed by the device. If your device cannot record correctly the usage, how are you supposed to notice it?

Depending how on local network conditions (coverage, load) about 5-10% difference between what your mobile tells you that you used and what your network charges you can be explained this way.

But there are further issues. Many networks provide only "private" IP addresses. If so, you have basically a "PBX-style" setup, were you can communicate outside, but your extension is not direct dial-able. Which can give you some issues with P2P communications, e.g. for multiplayer games. The most important from our point of view is that without your device initiating traffic, nobody can directly send data to your device. (That's why most PUSH systems in the mobile space are in truth more like connect-and-wait-till-something-interesting-like-email-happens.)

If on the other hand you've got a public IP address, basically anyone can send you garbage, and the usage data counter won't be able to tell these packets from stuff you wanted, not only will your connectivity start to crawl like a snail, your data cap will be used up pretty fast, ...

If you wonder how to tell which way your provider handles this, you can install something like IP Widget to see what address your device has been assigned. If it starts with 10, 172.16-31, or 192.168 you've got a private address that is being translated by the provider when you access the Internet. If not, you've got a public address that can be used to access your phone from the outside.

And there is just a third way that might use up your data cap pretty quickly.
Most providers use billing increments and bill at least one billing increment every time you connect to the network. If the increment is 32KB, that's ugly but somehow tolerable. But an increment of say 1MB can add up quickly, especially if connect it with bad coverage which increases the probability that your phone with kill the non-working (from the point of the TCP/IP networking software in your phone) connection and reconnect from scratch, oops, here your billing increment goes. E.g. everytime I walk the dog, I pass through the elevator that has no coverage, and the travel time is long enough that the mobile notices the coverage problem, so that implies on my contract, that implies 3.8MB data usage (in the worst case, the average will probably be 1.9MB) by rounding. (2 times daily times 2 in/out times 30 days a month * 32KB increment).

So to summarize, paying by data used, always includes some inaccuracy, and worse, in some cases can you expose to data usage that was not caused by you, as the data traffic counter never can know if the packets are garbage, or just the newest cool app that transmits only encrypted data.

Wow, it´s getting hard to avoid the i + animal (sheep, lemming, ...) words

How do you label people that require step-by-step directions how to open a website? (maps.google.com)

OTOH, no practical tips like wait with upgrades and buying the iPhone 5 till you know how Apple will handle this interesting and funny development.

Furthermore, maps.google.com or even a new Google Maps app will not really solve the issue:

E.g. currently I use an app that sends my location to somebody via email/sms. As long the OS relies on faulty data (you mean as whole towns not existing or being entered at completely wrong places), the message can be quiet misleading, the app that´s really cool when driving to let someone know how long it will take me is (potentially,  depending upon local data quality) useless, without even one line of code changes.

Basically all apps that have location awareness can misbehave at any time, till the data in Apple Maps gets fixed. No addon app/web app will fix that, and I´d even guess that even on jailbroken devices it won´t be easy to fix. (Well one can always hope that dropping in some parts from iOS5 would fix it, but such ugly fixes tend to be partially broken at best.)

The influence of payment options

Over the years, Internet access has been billed in a number of ways, which does influence user behaviour more than perhaps one realizes.

1) by time unit: Nervous high speed clicking.

2) by data transferred (no MB included, high price per MB): Minimalistic usage, this btw what the mobile industry has been selling for years, and somehow they wondered that nobody bought their cool 10 bucks a MB GPRS service. Quelle surprise.

3) by data transfered (no MB included, resonable price per MB/GB): Usage, but one tries to figure how much it will cost you, e.g. one avoids youtube, video downloads.

4) by flatfee (by time unit day, week or month): you basically don´t need to figure out what will it cost me.

5) by flatfee with data limits, this can be combined with reaonable or unreasonable overage fees, or non-monetary punishment e.g. limit the download speed to a crawl, so that you will hate yourself.

Sadly, why 4 is the desireable (from the customer PoV), the reality is that in practice some form of flatfee with some punishment is what one gets currently.

A Google Maps app for iOS will not solve the issue

Mapgate or Mapplegate won't be solved by a native iOS Google Maps app, it will be at best hidden, as modern mobile OSes provide the geodata to apps.

Hence a Google Maps app might change the initial user experience, but the wrong Apple Maps data will be still there, used by all other apps. Not a good situation.

The amazing cloud map

Fascinating. Guess strategic business decisions are way more important than customer satisfaction.

And before you dream of an Google Maps app for iOS, well even if it arrives, all Localisation-aware apps will continue to access Apple Maps data.

iPhone 5 gets 2 million preorders

Well, isn't that a crazy number. That's about 3-4 days of Android activations, I mean, that's a crazy number, right?

If you compare the phone by phone numbers, yes, all Android handsets are less popular than the iPhone (whatever iteration). If you compare platform to platform, Apple is the clear underdog, that did not provide anything overly exciting, even the 4S was a bigger jump.

Let's recapitulate:

1. The CPU is fast. Nice, but for 99% of the users, all phones over $300 have CPUs that are fast enough. Smartphones reached that level way faster than PCs, where for the common stuff more or less every PC has the power to handle it. Smartphones are more or less that just now. Another hint, the two currently relevant platforms do use techniques that do not squeeze out the last bit of CPU power, iOS relies on Objective-C, which if I remember right resolves method calls at runtime (basically when calling a piece of code, it does not dial it on speed dial, it calls directory assistance to figure out what to do now), and Android interprets the apps in virtual machine (although the VM is optimized more than standard Java VMs for the mobile space, it's still a VM).
2. It's thin. But there are a number of phones that are thinner, and let's be truthful, for most people, when they get a $600 gadget into their hands, the first thing they'll get is a cover, which makes discussions about how thin and how fine the finish is somewhat moot.
3. The "most advanced mobile OS", if you believe the Apple CEO, still does not provide services that Android 1.0 provided in 2008, like Intents.
   (Basically, that means that an app can package up an item, e.g. a photo to be shared, and hand it over to the OS so the user chooses the sharing app. iOS 6 still makes the app do the sharing all by itself, hence you get a random collection of sharing opportunities depending on the app, while Android users are used to install a sharing tool app and have it available for every use case.)
4. The size is slightly bigger. Big deal, the only inch size in the range between 2" and 7" that you probably cannot get a device for is 6". The resolution is nice but nothing to write home about.
5. The connectivity now includes LTE. Cool, but again, in truth it's irrelevant for the average user. As long you've got some usage cap, LTE is relevant for some niche users, where the speed is relevant, but not for the average user. Just to get a feeling, LTE at 100mbit/s can pull about 30GB per hour. On most plans, you'll be either paying painful overage or slowed down to a crawl in minutes not hours, if you use it. And if you have to use it like UMTS, why not just use UMTS? (Plus it's no great news either, LTE handsets have been available for some time now)

So no, for users in the know has many deficits before one might want to consider spending one's money for a $600 phone.