I’ve done blog entries on compaction threads, memory consumption, difficulties in doing upgrades, voice command not working over bluetooth, and 240x240 screens. Now I’m going to do one on why the little “X” button on PocketPCs doesn’t close apps. Am I insane? Do I like having you people kick me around? Well, maybe “yes” on the former, but definitely “no” on the latter. That said, someone needs to explain why we do the things we do, and that someone might as well be me.
So why is it that there’s no easy way to actually close apps on Windows Mobile devices? Sharpen your pitchforks, collect your torches, sit back, and I’ll tell you.
The monster you want is in the castle down the road…This won’t reduce the angry name calling, but I’ll say it anyway. I don’t fully agree with our stance on this. You’ll notice that I’ve written a lot of little ISV apps for Windows Mobile and its predecessors, and every single one of them has had an “exit” option in one of its menus. There was a time when we were so hardcore on this “thou shall not exit” stance that we refused to give our stamp of approval to any ISV app that had an exit option. Even then, I defiantly made my apps close. Fortunately, we’ve backed off on that stance and now allow people to write apps that close, even though we still don’t make our own official apps do it. If you’re writing an ISV app and it makes sense to give users the ability to close it, I’m all for you doing so.
Unfortunately, if this hasn’t convinced you to put your pitchforks away, then I’m toast, because I agree with the rest of our stance on this….
How’d we get here?In the beginning there were Microsoft Handheld PCs and Palm Pilots. The Handheld PC interface looked a lot like the Desktop PC interface. It had a desktop where you could drag around icons. There was a taskbar across the bottom that showed which apps were running. The apps had separate “iconify” and “close” buttons. Etc. On the other hand, the Palm Pilot’s interface wasn’t anything at all like the desktop’s. And Palm kicked the Handheld PC’s tail up and down the court. When you pour blood, sweat, and tears into product but only sell a few thousand units, you have to take a long hard look at your assumptions. The most consistent feedback we heard was that the desktop interface wasn’t appropriate for a small handheld device. So we reconsidered many of the design decisions that drove that desktop-like Handheld PC UI. Maybe people didn’t want a “desktop” on a device they carried around. Maybe a “today” screen that quickly showed what you needed to do that day made more sense. Maybe spending screen real estate on a taskbar didn’t make sense when your screen was a quarter the size of the device you took the idea from. And, maybe, just maybe, having users close apps wasn’t appropriate on an embedded device with a slow processor and even slower memory.
None of the other embedded and mobile devices of the time made you close your apps. Palms didn’t do it, cell phones didn’t do it, VCRs didn’t do it, car navigation systems didn’t do it, and game consoles didn’t do it. There are a couple of good things that you get from doing things this way. For instance, the system feels faster when you don’t close apps because it takes longer to launch an app than it does to bring an already running one to the foreground. But what became our philosophical reason for not closing apps was the belief that users shouldn’t need to manage their memory.
If an app closes in the woods and no one hears it…The base philosophy, that users shouldn’t need to manage their memory, is pretty hard to argue against. Come on, tell me that users should be required to manage their own memory. I dare you. You can tell me that you can do a better job. You can tell me that we don’t do a good enough job. You can tell me that in some cases we do a fine job, but in the cases when we don’t, the world comes to a screeching halt, time goes backwards, and history is rewritten to be somehow more dark and foreboding than it already is. But you can’t tell me that users should be required to manage their own memory. That’s like saying that car owners should be required to change their own oil. I don’t think so.
So, on realizing that users shouldn’t have to manage their memory, we set about doing it for them. We made our shell watch how much memory was being used and close apps when more was needed. We made many of our apps remember their state when they were closed so that they could reload it again when they were opened (so users couldn’t really tell that they had ever been shut down). We taught ISVs how to do the same thing. And we removed the close box from all of our apps.
By 2000 we had iterated on this a few times and released a product (PocketPC 2000) that started winning both reviews and marketshare. But there has been resistance to having us manage the memory since we first removed the close buttons. One of the first ISV apps written was a manager that let users close their apps. And, variations on that theme are still popular today.
X marks the spotOne thing we did has been pretty contentious. Along the way, we got feedback that users didn’t mind letting us manage the memory for them, but they really wanted a way to say, “I’m done with this. Make it go away.” So we put a “go away” button in the upper right corner of PocketPCs. This button just sends the application to the background. It doesn’t close it. If the system needs more memory while the app is in the background, it’ll close the app. But, if the system doesn’t need more memory, the app will stay in RAM and be ready to come back quickly the next time the user needs it.
Now, in a move that some people consider brilliant and others consider unforgivably stupid, we made the “go away” look like an “X”. Brilliant because anyone who has ever used Desktop Windows will know that an “X” button in the upper right corner of the window will make the window go away. Unforgivably stupid because every one of those same people will assume an “X” button in the upper right corner of the window will make the app close. Whether you think the move is brilliant or stupid is pretty heavily tied to how much you believe that users shouldn’t have to manage their own memory.
And now we’re hereSome people say that we don’t do a good enough job managing memory. We must agree to some degree because we’ve adjusted or modified the memory management code on just about every release since we added it. I believe the adjustments have been improvements, and I expect that we’ll keep improving it.
I’ve heard some people say that we’ll never do an acceptable job with our memory management and that we should give up and make the X box close apps. First, I’ll say that doing so would break all the apps that expect the current behavior. But, more importantly, there are literally millions of Windows Mobile users who never close apps manually and successfully get their jobs done. While we’re definitely not doing a perfect job with memory management, we have way too many happy users to claim that our memory management is universally unacceptable.
There’s a reasonably sized (but still tiny minority) group of users who feel that they can do better than the memory manager and want an easier way to take control. Because there are so many apps that let you close things, some of which are very well integrated, I’m reasonably comfortable saying, “Use one of those apps.” I know that someone is going to say, “I paid $500 for this device. I shouldn’t have to pay another $10 just to close my apps,” but we do let you close apps with the Memory control panel. If you think there should be an easier way to do it, all I can do is point you to the “I’m Just a Feature” entry to explain why a minority view feature is less likely to get implemented than one that most users want.
Finally, if you’re about to say, “This third party app uses too many resources and I need to be able to stop it,” my answer will be, “If that app really needs to use those resources, then it should have its own close option.”
Donning hazard suitSo, that’s why the “X” button doesn’t close apps. You can start calling me names now.