Yahoo's great new weather app

Yahoo’s great new weather app

It combines weather data with user-uploaded photos from Flickr. Marissa Meyer gets it.

What’s remarkable about this is that someone in Yahoo had a good idea like this, and they were given the resources to build it and ship it. This sounds simple, not something that should be worthy of note–it should just be the way all companies work–but they don’t. If you’ve ever worked at a company anywhere near the size of Yahoo, then you know about the politics and bureaucracy that come with the experience, and the stifling effect that can have.

Indeed, before Meyer became CEO, when was the last time we saw anything like this out of Yahoo? But since she arrived, we’ve had the great Flickr app update, and now this. My only wish would be: More like this, faster. But I can see why they can’t rush, or the high level of quality that Yahoo is slowly-but-surely building could quickly unravel, from the clamour of too many dissenting voices. I suspect Meyer is keeping the teams small and focused, for good reason.

This sort of thing makes me feel good, not just about Yahoo, but about the software business in general.

Google Maps for iOS is broken in a fairly major way, after a recent update

Google Maps for iOS is broken in a fairly major way, after a recent update

After Apple Maps took me to the wrong place once or twice, I switched to using Google Maps exclusively. But I noticed it’s been behaving very strangely recently, relating to automatic screen dimming. But before I explain the issue, some background is necessary.

All about Auto-Lock

iOS has a feature officially referred to as ‘Auto-Lock’, which really is just a fancy way of saying the screen will turn off automatically after a period of time of not interacting with it. You can configure the amount of time it takes before this happens in Settings > General.

It’s worth noting, for reasons that will become clear, that Auto-Lock behaves differently when the device is connected to power (e.g., my car charger), compared to when it is on battery. On battery, the screen will turn completely off after the Auto-Lock interval has elapsed, and the only way to turn it on again is to push either the home button or the sleep/wake button; but when connected to power, the screen will only turn most of the way off, and can be turned all the way on again simply by touching any part of the screen. Most importantly, in this latter case, touching the screen does not send any touch events to the app which is visible on the screen; you could have put your finger right on top of a button, but the app would not know that you had touched the button while the screen was dimmed. This makes sense, because in the dimmed state, you may not be able to clearly see where the buttons and other controls are placed, so it would otherwise be easy to interact with something unintentionally.

Apps can temporarily override the Auto-Lock setting in order to force the screen to stay on for as long as they want. This is usually accomplished with UIApplication -setIdleTimerDisabled:. Regardless of what an app does with this setting, it the operating system restores it back to the standard behaviour once the user returns to the home screen or switches to another app.

Previously, both Apple Maps and Google Maps would override Auto-Lock while navigation was in progress (by setting the value to YES), but restore it after navigation ends (by setting the value back to its default, NO). In other words, simply having the app open was not enough to keep the screen on; you actually had to be in the middle of receiving directions. This is a sensible trade-off between battery life and providing the user with essential information when necessary.

What Google broke, and how they broke it

As of the most recent Google Maps update, the screen now dims automatically, several seconds after the app has provided a direction, in cases when there are no future directions planned for some amount of time. The difference here compared to what I described above is that instead of using the time interval since the last user interaction, Google Maps uses a combination of the time interval since the last direction and the time interval until the next future direction, to determine when to dim the screen.

This is in fact not iOS’s Auto-Lock feature in action; one reason you can tell is that, contrary to how Auto-Lock works, touching somewhere on the screen while it is dimmed in Google Maps does result in a touch event being sent to and reacted to by the app. One likely result of this is disabling location tracking, which is what happens if you touch anywhere on the map (i.e., most of the screen) while the app is in the middle of giving you directions. This is extremely inconvenient: the map no longer shows your current location, but instead is frozen at the location where you happened to be whenever you last touched it, which is almost certainly not what you wanted when you were in the middle of looking at directions for how to get someplace.

Most likely, Google Maps is using the UIScreen brightness property to force the screen to dim after a time interval of its choosing, rather than allowing iOS to use the system-wide configured Auto-Lock interval. This is probably because of the app’s intention to brighten the screen again in anticipation of the next direction coming up; indeed, the way they apparently implemented it is the only way I can think of that it would even be possible to accomplish this, since there is no API (as far as I’m aware) to allow an app to bring the device out of an Auto-Locked state. Moreover, the screen brightness setting, being an entirely different mechanism than Auto-Lock, does nothing to prevent user interaction with UI controls.

In short, Google Maps prevents the device from going into Auto-Lock, but then implements its own feature which is similar in some ways to Auto-Lock, but not the same.

It gets worse. Most of the time, touching the screen after Google Maps dims it, in addition to cancelling location tracking and making you curse in frustration, restores the screen brightness to its original level. But sometimes, it doesn’t. Again, because the operating system’s own Auto-Lock feature is not being used here, it is up to Google Maps to set the UIScreen brightness back up to the level that it was previously at before it was dimmed. But it sometimes fails to do that, in which case you can tap the screen all you want, but it will never go back to being visible. In fact, since UIScreen brightness makes the change system-wide (the same as if the user had changed it in Settings), even pressing the home button to return to the home screen, or switching to a different app, will not fix the screen brightness! The contents of the screen will remain nearly invisible until you press the sleep/wake button to turn the screen completely off, and then press sleep/wake or home to turn it on again, which for some reason sets the device back to a reasonable brightness level (perhaps in some way related to the Automatic Brightness setting Edit: Explained here).

Need I explain that when you are in the midst of trying to drive a car, this is not really a good thing to have to be fiddling with?

Thinking about how I would implement this as a programmer: Before dimming the screen, I would copy the value of UIScreen brightness into a temporary variable, and then when it was time to brighten the screen again, I would copy that temporary variable back into UIScreen brightness. Fairly simple. But it’s easy (for most programmers) to see how this approach could go wrong: If I somehow accidentally copy the value of UIScreen brightness into the temporary variable when the screen was already dimmed, then the original brightness value would be lost; and every time the user or the app tried to restore the screen to its original brightness value, it would just be set to the dimmed value instead, every time, indefinitely. This could happen in the event of a race condition, possibly resulting from an event firing more times than expected in quick succession, or through unsafe use of multithreading. Although this is only my speculation, I have seen similar bugs enough times that this would be one of the first things I would look for if I were trying to debug it.

Sweet road to somewhere else

So, what can we learn from this? Typically, it is a really bad idea to try to re-implement operating system functionality from scratch at the application level, unless you have a really, really good reason. The reason is that your implementation is likely to miss subtleties that users depend on, and introduce bugs or other discrepancies that are not present in the operating system implementation. In the best case, it ‘feels wrong’ in ways that users notice intuitively but are unable to articulate precisely. In the worst case, it fails spectacularly due to a complex condition which the operating system developers anticipated and you, an app developer with much different sorts of concerns on your mind, did not. Which is exactly what happened here.

Although, it’s not really surprising that this was attempted, considering the app in question. Google Maps uses entirely custom user-interface widgets, too. It’s Not Invented Here from the ground up. This sort of design philosophy has a tendency to pervade throughout. In other words: Google aren’t trying to make a well-behaved iOS app, but instead, an experience unlike anything else on your iPhone. Well… I guess in that respect, they’ve succeeded.

What I can’t figure out is why it was so gosh-darned important to have the screen dim and brighten according to the timing of the directions. Why not just leave the screen on all the time while directions are up, like the previous version did, and like Apple Maps continues to do? I suppose there is an argument to be made about battery life, but even then, the obvious counter would be that this should only be enabled when device is UIDeviceBatteryStateUnplugged.

But even then, I’m not sure the trade-off is worth it. I frequently glance over at the screen while driving in order to see how far it is to the next exit or how long it will be until I arrive. As long as that information is always visible, it’s not substantially different from glancing at the speedometer or gas level from time to time. However, having to tap on the screen every time I want to see the map is an extra unnecessary use of my motor skills, which makes it an unnecessary distraction, and that makes it dangerous. I daresay that, even if I didn’t have a car charger, running down the battery a little bit in exchange for a safer driving experience would be the right choice to make, don’t you think?

The simplest explanation might simply be that they were trying to mimic the behaviour of the Android version of Google Maps, which follows the same dimming and brightening pattern, but which likely has a very different system for handling these sorts of things. I’m really going out on a limb here, but: It’s easy to imagine a non-technical product manager making this decision without understanding its ramifications, and then the developers having to do it because that’s the food chain. Then again, this is Google we’re talking about, so in theory there shouldn’t be any such thing as a ‘non-technical’ person. I wouldn’t know.

Have I reached the party to whom I am speaking?

The linked discussion thread does, remarkably, feature a few responses from a Google employee. The first is your standard impersonal brush-off in the form of your-feedback-is-important-to-us (uh-huh). A more recent response makes an oblique reference to ‘optimizing’, without actually admitting the existence of a problem; but perhaps, this may be taken to indicate that someone somewhere is working on something which might hopefully be relevant to the issue at hand. This kind of exchange is typical of what happens when the people who actually understand what’s going on are not the people who are allowed to talk to you. On the other hand, Google is legendary for their lack of end-user support, so the fact that there is any kind of response at all is, perhaps, a step in the right direction. Still, the fact that the app has remained broken for so long (over a month as of writing) is very frustrating. One would expect better from a smaller company that lives or dies based on the strength of their product, but Google are long since big enough for this sort of thing not to matter terribly much to them.

Meanwhile, I’ve been forced to give Apple Maps another try, seeing as how Google Maps is pretty much unusable for me in this state. So far, the Apple Maps data actually seems not so bad, and of course, the UI has always been much better than Google Maps. So, thanks, Google, for… [puts on sunglasses] showing me the way?

Google is forking WebKit

Google is forking WebKit

I honestly have no idea what Apple was thinking with the WebKit2 multi-process model. When a Chrome tab crashes, it’s isolated to that one tab. When a Safari tab crashes, it takes down all of the other tabs with it. This is better than the WebKit1 behaviour of taking down the entire browser UI, but still… kind of missing the point, isn’t it? What good is the browser UI if none of the tabs are working?

At first, I thought maybe this was just a limitation in the initial version of Safari that shipped right after WebKit2 was released, and that it would quickly improve to be more like Chrome. But no. Nearly three years later, Safari still has the same problem, and I still see it happen several times a week¹.

Not only is this multi-process model worse than what Chrome had already been doing for years, but Apple wasn’t content to keep the code in Safari; they pushed it upstream into WebKit itself. What did they expect Google to do, switch to a worse model in Chrome in order to stay in line with WebKit?

Nah: Apple’s typical relationship to other companies is one of indifference. Most likely, Apple simply didn’t care what would happen as a result of increasing Google’s maintenance burden in this way. Well… this is what happens.

The entire internet is currently arguing over whether this is a good thing or a bad thing. LOL, internet. History will be the judge of that.

---

1. Usually this happens when I try to open an ‘Auto-Click’ bookmark, which I guess is Safari’s name for a tab group - it’s a bookmark folder that, when clicked, opens every bookmark simultaneously in separate tabs. ↩︎

Justin Williams on why iCloud Documents isn't that great either

Justin Williams on why iCloud Documents isn’t that great either

Reminds me of a fun story:

I was helping my sister set up her first iPhone, giving her advice on which things she should try. When we tried to turn on Notes for iCloud in Settings, it refused, with an error message stating that you must activate an iCloud Mail account before you can use Notes with iCloud. (She hadn’t done so because she wanted to keep using Gmail.)

Conclusion: Notes still uses IMAP for ‘iCloud’ syncing. It doesn’t use any of the three iCloud methods (key-value, documents, Core Data) that are available to third-party developers.¹

Justin’s customers probably wonder why he doesn’t just do with his notes app what the official Notes app does.

---

1. What a bizarre error message this must seem to someone not technical enough to guess the reason behind it! I helped her set up an @icloud.com email address that she would never use, and logged into the the iCloud web site (!) on a computer (!!!) so that it would automatically forward to Gmail, just in case someone ever did try to use it to send her email.

Bare Bones Software's Travails with iCloud Sync

Bare Bones Software’s Travails with iCloud Sync

I’ve been reading many complaints about iCloud for some time now, but this tidbit in particular was news to me:

And we find it noteworthy that, to the best of our knowledge, none of Apple’s currently shipping products on Mac OS X use iCloud to sync Core Data.

This is the one sole thing that every developer needs to know about iCloud right now. If only this had been common knowledge from the start. When we can see Apple themselves using it, then maybe it works… but certainly not before.

Apple's own words saying there are no hardware changes in the T-Mobile iPhone 5

Apple’s own words saying there are no hardware changes in the T-Mobile iPhone 5

This is to request a Class II Permissive Change for FCC ID: BCG-E2599A originally granted on 09/12/2012.

The change filed under this application is:

Change #1 – Adding UMTS Band IV (1700 MHz)

The addition of this UMTS band does not require any hardware changes to the approved device. There is no increase in the output power rating on this additional UMTS band and the Equipment Class remains the same. There are no other changes to the device.

Thanks to this poster on HowardForums.

Engadget, yesterday:

Apple affirmed to us that it’s not something that can be enabled via a simple software update for A1428 iPhone units already in circulation.

That’s not a direct quote from Apple, so it’s possible that Engadget misunderstood. However, assuming they didn’t: I wish PR people would learn the difference between ‘can’t’ and ‘won’t’.

More details about the T-Mobile iPhone 5 model

More details about the T-Mobile iPhone 5 model

Exact same hardware, just newer firmware. Even the same FCC ID, which I understand to mean that the FCC approval for the new bands retroactively applies to the original A1428 model. So why can’t I have this new firmware?

Apple Modifying iPhone 5 For T-Mobile Bands, Existing Devices Won't Have AWS Support

Apple Modifying iPhone 5 For T-Mobile Bands, Existing Devices Won’t Have AWS Support

I got my ‘existing device’ 3 months ago for use with T-Mobile. I got screwed.

Edit: I went and talked to the people at the Apple Store, and explained my discontent. They were friendly and helpful and I would recommend that anyone else in my position do the same. I’ll leave it at that.

An imagined interview with Richard Plepler, CEO of HBO

Q: Thanks for sitting down to talk with me today, Richard.

A: No problem.

Q: I mean it. For a–let’s say–relatively unknown blog like mine, with a monthly average of 2.4 readers, getting an exclusive interview with the CEO of a huge media company like HBO is, well… it’s almost as exciting as that time I called out Gruber for making a spelling error.

A: Er… okay.

Q: So let’s get down to it. Game of Thrones. Great show, I’m sure you’ll agree.

A: The viewers certainly think so.

Q: So let me toss this out to you. I’m 27 years old. I’ve never paid for cable TV in my life.

A: I hope you weren’t stealing it. (Laughs)

Q: No, no. My parents paid for it, for a time, when I was a kid. I mean, what am I gonna do, spend my allowance on that? I’d be mowing lawns a long time. But no, my parents subscribed to it for, oh, I don’t know how long, probably since before I was born. I used to curl up on the La-Z-Boy in the basement in my pyjamas and watch Nickelodeon. Good times.

A: It’s a part of our culture.

Q: You could say that. So my parents dropped cable after a while, I don’t know why. Tough economy I guess. But then when I went off to college, we had it for free, in our rooms. I guess technically we were paying for it as part of the cost of board, but we didn’t have a choice, and anyway I’m sure the cable company gave the college a big discount, right?

A: (Laughs) That’s how they get you hooked.

Q: Sure. Sure. I would watch Battlestar Galactica and The Daily Show. Those were the only two shows I watched, but I enjoyed them. Especially Battlestar. Not many shows like that these days.

A: You should see what we’re running lately.

Q: On–

A: On HBO, yeah. (Laughs)

Q: Sure, yeah. So anyway, I graduated, and Battlestar ended. And I bought the DVDs and everything, but–I don’t know–it just never really even occurred to me to subscribe to cable after I left the dorm. I mean, why would I? For two shows, one of which was over?

A: I hear you. We get that. We’re doing the market research. We’re thinking it through.

Q: Sure. So I’ve watched some shows since then. Mainly network television. Castle is bearable sometimes–at least it’s got Nathan Fillion. But there’s Hulu for stuff like that now. Ten dollars a month to watch it on my TV, or less if I don’t mind hacking their stupid leaky paywall.

A: We’re aware of those things. We’re watching those services closely to see what happens.

Q: So here’s the thing. Game of Thrones. Bought the first two seasons on iTunes, liked it a lot. How do I watch season three?

A: Well, I guess you gotta subscribe to HBO! (Laughs)

Q: Right. But the point I’m trying to make here is that, it’s not a question of upselling me on a premium package for my existing cable, because I never had that in the first place. And it’s not a case of you losing a customer that you now have to get back, have to draw back into the fold, because you never had me as a customer. You never had a lot of people my age, as customers. Sure, I watched it when it was free, but that was all. And now, even if it was free, I probably wouldn’t want it. Watching TV on someone else’s schedule is inconvenient. I’m grown up, I’ve got a job… my time is valuable! I want to be able to choose when to start it, and be able to pause it at any time.

A: Well, as you probably know, there’s the HBO Go app for that now. On the iPads. You can even–what’s it called? (Gestures)

PR Aide: AirPlay.

A: You can AirPlay it, onto the TV. From the app.

Q: OK. Fine. But then how do I get HBO Go?

A: Well, if you call your cable company, I’m sure they’ll help you out.

Q: Okay. So they’re going to charge me–what, like a hundred dollars, or more? A month? And send a cable guy out here, to install something? I don’t want the cable guy installing anything. I don’t want some guy plugging some box into my TV that I’ll never turn on.

A: (Laughs)

Q: I’m serious! I literally do not want this service, even if it’s free. I just want that one, that single part of it, that one show, on HBO Go.

A: Well, we’re aware that there’s a demand for it, but see, we have to look at the numbers to make sure it’s going to work out…

Q: Okay. So let’s take that number there, call it a hundred dollars. That gets me–what? Basic cable, plus HBO. And the HBO Go app is ‘free’, on top of that, right? That last part is the only part I want. But I could have that, right now, for a hundred dollars a month, right?

A: Sure.

Q: So… I know you don’t want to ‘unbundle’ stuff. I know that’s against your business model. And I don’t know exactly what your numbers are, because I know that’s all secret and competitive. But let’s assume for the sake of argument that the cost I would pay for HBO, out of that hundred dollars, maybe it’s 30 dollars or so? Let’s assume that that 30 dollars that shows up on my cable bill for HBO, that’s not all that HBO is getting from the cable company in exchange for having me as a subscriber. You’re getting some kind of extra kickback from the cable company, on top of that 30 dollars, that makes it more lucrative. And you’re getting free promotion from them, and other intangibles like that. You don’t have to market your channel at all, because the cable companies do it for you. Is that about right?

A: That’s not far off.

Q: So let’s say I just take that hundred dollars, and I pay it all to you, directly, instead. I don’t want any of that basic cable junk, I don’t want the stupid box, I just want HBO. So can I do that? You wouldn’t possibly be losing out in that scenario, would you?

A: Well, no. But I guess, well, I guess we just don’t think very many people would pay 100 dollars per month for just HBO. (Laughs)

Q: No, I don’t think so either. And in truth, I wouldn’t pay that much. I mean, Game of Thrones is good, but it’s not that good.

A: (Laughs)

Q: But, here’s my next point: There’s some number in between there, more than the 30 dollars you get from me for my HBO subscription now, but less than the 100 dollars total I would have to pay to actually get HBO considering I currently have no cable at all. There’s some number in that range where you’d still be doing okay. Isn’t there?

A: Yeah. But I don’t think you’d like that number either.

Q: Maybe not. But I gotta think–let’s call it 50 dollars. Or 75. I have to think, if you made that available, for 75 dollars, just access to the HBO Go app, nothing else, no requirement for a cable subscription–someone would buy that. Maybe not a lot of people! Maybe not even me. Almost certainly not me. But I bet someone would.

A: You’re probably right.

Q: If for no other reason, than to stick it to the cable company. People hate the cable company.

A: (Laughs)

Q: So why don’t you do that?

A: Well, like I said–we don’t think many people would pay that much for just HBO.

Q: Sure. But you already have HBO Go–you already operate that service. So it wouldn’t cost you anything to develop it or to provide it. That part is already done. It would just be some easy money. Not a lot, but some. So what exactly do you have to lose by offering it? Price it absurdly high if you want. You don’t have to promote it at all–people will find out by word of mouth. See how many sign-ups you get. You might be surprised.

A: Well–you see…

Q: Play around with the price a bit. See how it affects the numbers. You might just find that, at some point, you don’t even need the cable companies any more. Maybe not! Maybe I’m exaggerating. But this seems like there is zero risk here. And, you know, everyone else seems pretty sure that this Internet thing is gonna be the future, real soon now. What exactly is holding you back?

A: (Long pause) You know that HBO is a wholly-owned subsidiary of Time Warner, right?

T-Mobile LTE now live in Las Vegas and Kansas City

T-Mobile LTE now live in Las Vegas and Kansas City

LTE networks have been completed in Las Vegas, NV and Kansas City, MO and are ready for customers as LTE devices launch in 2013.

(via TmoNews)

Also, looks like Boston is finally getting filled out a bit in this unofficial map of iPhone-compatible 3G areas. It’s been mostly stagnant since last year, but more data points have appeared in the past month or so.

I’m still waiting for the network to look good enough to bring over my unlocked iPhone. I have no contract, so I could do so any time, but it’s just not worth degrading my already-mediocre AT&T 3G service. I had hoped T-Mobile would be in better shape by now, but progress has been slow.