Policy Backfires

Ever wonder how a well-intentioned policy turns into a horrible nightmare for the very people it was designed to serve? I found the perfect example at Apple’s WWDC where going to the restroom isn’t permitted for adults.

Ever wonder how a well-intentioned policy turns into a horrible nightmare for the very people it was designed to serve? I found the perfect example.

Let’s take the case of Apple’s technical WWDC ’09 conference in San Francisco. Brilliant talks. Amazing speakers. Fantastic audio and video. It’s good stuff.

Now Apple is a company that is on the forefront of user experience, they pioneer usability and design, and their big presentation this year is on efficient resource and queue management. You’d think this innovative thinking would hold over into how they actual manage crowd control, but you’d be wrong. Apple has totally missed the mark. I know, it seems impossible.

There’s an absolutely stupid policy that’s being enforced, and while the best of intentions are there, the policy isn’t helping anyone. It actually makes things worse. Follow this.

You’ve figured out your course tracks for the day, bunkered down to do some work on your laptop, and are watching a series of presentations being held in that room with your development buddy. It finishes, and so you tell him “Can you watch my stuff, I’m going to hit the restroom before the next presentation.” He says ‘sure’ and you leave. After all, being a convention center, the restrooms leave little to be desired in terms of personal space.

On the way out, you’d tell the Apple guy at the door “be right back” and empty handed you walk across the hall to the restroom, return in minute, and reclaim your equipment-occupied seat. At least that was how it was at the start of the conference. All was fine. Things ran like clockwork.

Mid-conference someone revised the policy. Instead, if you leave, you now have to go wait in line to return.

Why did Apple do this? I asked. Two reasons.

First, by only letting people out and not back in, this is supposed to make things easier for the presenters to set up.

Second, it’s supposed to establish an order of fairness for those people coming into line.

On the surface it appears to make sense, but what this policy really does is prevent grown adults from being able to go to the restroom. Instead, you’re standing there with a full bladder and Apple’s staff is literally telling you that you’ve got three options:
a) Hold it until the session starts.
b) Abandon your equipment (as you might not have a buddy to watch it), and then wait in line to see if it’s there when you get back.
c) Go get your equipment and hold it while you do your business, and potentially miss the session (although you already had a seat).

Let’s examine this.

1) Does the policy improve seating fairness?
No. There’s equipment, and most likely a person, reserving the seat until you return. No one standing in line is going to benefit whether you reclaim it now or later. And, realistically, every talk that has been “filled to capacity and people were turned away” had plenty of chairs mid-row, plus people are willing to stand.

2) Does this improve the line?
No. It actually makes them longer, meaning Apple has more to manage. And, as the lines wrap all over the halls, it makes them more cramped, confusing, and uncomfortable.

3) Does it make conference attendees happier?
No. It’s annoying, bordering on rude, telling someone they have to return to their seat and wait for the presentation to start in order to relieve themselves. It’s a frequent conversation topic to overhear, Apple is putting a lot of people off.

4) Does it make Apple look corporately smart?
No. In fact, even its own employees are mocking the policy behind Apple’s back, all the while blindly enforcing it (most of the time), at the door. Even their own realize how ludicrous it is. This makes Apple look bad in a very self-aware Dilbert way. Of course there’s an insulting double set of standards, as the guy managing the gate preventing people from using the restroom calls on his buddy to take his place while he goes to take a piss.

5) Does it make the presentations go smoother for the presenters?
No. In fact, worse. Now one has to wait for the presentation to start, interrupting the speaker, and by going in and out letting more light in the room. It causes distractions. Plus I’ve seen one attendee fall over a chair during a presentation, and two people trip during a presentation, all trying to temporarily exit.

6) Does it make viewing the presentation go smoother for the attendees?
No. Being seated in the middle, one now has to navigate over other people who are trying to watch the presentation. I’ve had my equipment kicked as well as my foot stepped on by someone telling me “whew, now I can go.”

7) Is it safer?
No. There is now less room to get out, where before the row was empty. Plus, there are power cords, laptops, cases, drinks and other obstacles to navigate, crush, and trip on.

8) Does it provide accurate metrics for seating?
No. In re-entering you get counted a second time. This messes up Apple’s counts and artificially makes room seem more full, turning away people who could be viewing.

9) Does it make it easier for the presenters to set up?
No. The presenters are up on stage, a good distance from the audience. No one is trying to interact with the presenters before the talk.

Got more reasons it’s a bad idea? Let’s hear them.

So, what starts as a “good idea” ends up impacting far more people than it should. Compare this to a simple first-come first-serve policy, which would allow everyone to get settled before a talk begins. If seats are full, stand; if you don’t want to stand, sit; if you don’t want to sit, find another session; if you don’t want that to happen, get there on time or before, just like everyone else does. It’s acceptable to leave a session during Q&A in order to find a good seat at the next session.

Unfortunately, as with most failed policies, the solution usually is to add more policies (rather than correcting the root problem). Kudos to Apple for not going this extra step. The slippery slope would be to kick everyone out in order to have them stand in line again; that however would be truly idiotic, especially given the equipment people carry and set up to attend these things.

MacHeist 3: A Look At Group Purchasing Behavior

Have MacHeist sales stagnated? He’s my take on why, and what can be done to fix it, and how it has to play out… for the better!

As a glossed over quick introduction, MacHeist is a short-run sale of software packages for the Mac that has a twist. You pay $39 for a bundle of software, and some of that software is “locked.” A portion of your purchase price goes to charity, and the more money raised for charity, the more items in the bundle that get “unlocked.” Thus the more people buy, the more you continue to get. It’s a great scheme, only it isn’t working.

MacHeist 3MacHeist, at the time of this writing, is conducting their third “heist” and after some amazing fluster of activity, new sales appear to have stagnated at an alarming rate.

Alarming to bundle purchasers, because if not enough sales happen, bundle purchasers won’t get all the amazing high-cost software at the extreme end of the bundle. What’s important about that statement is that it’s never happened before, and the problem isn’t the recession.

In informal polling, there appear to be two kinds of purchasers: early adopters and frugal purchasers.

The early adopter purchases the bundle early, knowing a good value when they see it, spurred on by the fact that there are additional incentives for doing so.

The frugal purchasers have their eye on either the final packages in the bundle, or are looking at the bundle as a whole. They don’t want to purchase the bundle until they know everything in it is unlocked.

And that’s the interesting part. If no one buys it, nothing gets unlocked. If everyone takes a risk, everyone gets handsomely rewarded, guaranteed. Thus each potential purchaser is waiting on the action of everyone else — it’s crowd mentality, only the driven behavior is idleness.

The secret ingredient is momentum. By carefully crafting a set of software incentives, under ideal circumstances the early adopter crowd overlaps with the late takers. This manifests itself as a steady stream of purchases.

It might be argued that The Directorate which runs MacHeist became victims of their own success and actually caused the problem by marketing the sale too well. Based on all the pre-sale puzzles, rumors, and incentives, there was a flurry of purchases in the early hours of the sale and projections seemed rather high.

However, one of the primary packages in the bundle required what looked like a high goal to unlock, the perception was that momentum was slowing. And perception drove reality. “Hmm, that doesn’t look like it’ll get unlocked, I think I’ll wait to see if it does before I buy,” is all it took to slow the influx of unlocking purchasers.

This was ill-timed, as it also happened to coincide with the reward for the first 25,000 buyers being removed from the table as the 25,000th bundle was sold. Days later, a only mere 5,000 more have sold and questions are being raised if the final packages will be unlocked.

The up-front fast burn created enough of a gap that people who were on the fence at different points became more segregated than usual. This didn’t happen in the last two sales.

So here’s my prediction: they have to fix this. Meaning, new incentives will re-emerge, the goals will have to be re-addressed, and it’s in the best interest of MacHeist to unlock the bundles anyhow at the end of it.

Turns out before I could finish this post, a new bonus was added, and that did stir a little traffic. But the real objective here is to convey there’s movement, specifically enough that the goal could be reached. That will inspire sales again, and in turn actually unlock the software. By re-calibrating the goal levels, this would solve the problem. In fact, the easy solution is to put all the last packages into one final, achievable goal.

The truth of the matter, however, is whatever happens will be remembered, if not chronicled in Wikipedia forever. If MacHeist goes down in flames for not unlocking all it’s bundled packages, people will be ever the more skeptical, and that means early adopters turning into late purchasers. That only exacerbates the problem, killing future sales opportunities.

By contrast, if the packages do get unlocked, whether by purchasers or by The Directorate making its own donation from the profits it receives, then MacHeist will be seen as more of a sure thing in the future, sliding more of the late comers and risk adverse customers into the early adopter side. This would actually increase future sales, because more gets unlocked sooner, enticing the skeptical buyers.

As such, “betting” on MacHeist with a purchase at this point still seems like a safe move. And, even if none of my predictions happen to come true, enough is unlocked already that the $39 price tag is still an awesome buy for the collection of software provided.

Safari 4 Beta – OS X Users: Wait

Installing the new Safari 4 Beta gave a great browser experience, but it stopped OS X’s Mail from working. Uninstalling it restored normality. Anyone else getting this?

Yesterday I downloaded a copy of Safari 4 Beta for Windows, and I have to say that the speed increase was obvious. Just a little playing around with the browser [especially in developer mode] tells me that Apple has something good. Real good.

However, my experience when installing the Safari4.0BetaLeo.dmg version on OS X wasn’t as hot. Well it was, but the collateral damage was unexpected.

In short, the browser worked great, just like on Windows. The speed up was there, but certainly not as dramatic as when you’ve got Internet Explorer to compare it to.

Safari 4 Beta Kills MailMy problem, however, was that when I went to open up OS X’s Mail, the Mail program crashed. Hard.

Repeated attempts did the same thing. Open Mail, it shows the cached list of old messages, it attempts to download from the IMAP servers, and clicking anywhere causes the Mail application to implode.

It was certainly repeatable.

Two things about the crash impressed me, though.

Number one, Mail was blaming it on a Growl extension. That’s nice to know that an application can tell where it’s detecting a fault.

Number two, after a few repeated failures, it was just like Apple to automatically sense my frustration and have mail automatically ask me if I’d like to reset my preferences and try launching again.

I did. And, it didn’t work.

So, after logging a few problem reports, I decided to uninstall Safari using the Safari4.0BetaUninstall.pkg.

No surprise, Mail returned to normal, and my Growl extensions were functioning just fine.

This raises the question about what the new Safari is doing that affect Mail to begin with.

But the real point here is that this software really seems to be beta. Good beta. But still beta. If OS X Mail stops working and you don’t know why, revert to your original Safari install. I bet it’ll help.

Can any other OS X users confirm or deny this is happening to them?

CONFIRMED WITH SOLUTION: Thanks to reader comments and feedback, it’s clear the problem is with current Growl extensions not being compatible; simply remove them (see comments on how) and wait for Growl to come out with an update.

Found: The Best iPhone Development Book So Far

Want to write your own iPhone applications but Objective-C, XCode, Interface Builder, and the steep learning curve of Cocoa getting in the way? Have I found the book for you.

Warning: long and geeky post follows — iPhone wanna-be developers, read on!

Beginning iPhone Development - Exploring the iPhone SDKI’ve found it, finally, the best iPhone development book so far! Read on to see why.

Fairly recently, I decided to turn my attention to native iPhone application development, but I found the arena a little sparse when it comes to what I’d call good documentation.

For some perspective, I’m a software developer of 20+ years with background in Unix and Windows; I’m very well versed in C, C++, C#, and Java, among a good number of other higher-level languages, having produced a number of enterprise applications.

You’d think that picking up Objective-C and the Cocoa Touch frameworks would be a fairly simple task. However, the moment you step foot into the pool, you’re get a cold shock at how much you don’t know and it can feel daunting enough to want to retract back to familiar territory.

Don’t give up. It is easy.

Looking forward into the unknown presents a much more gloomy impression than when you’ve taken a few steps and looked back to see just how far you’ve come and in such a short period of time.

Here’s what’s happening: The Apple Frameworks represent a large and mature collection of some impressive code. The closest experience I’ve felt to it, and this is admittedly a horrible analogy, is Ruby on Rails.

With Rails, there’s so much going on by convention that you have to sling very little code to get impressive things to happen. This makes it hard to understand: there is no code to trace.

Same way with the Apple Foundation classes that are based on NeXTSTEP — a lot is handled for you, and often in new ways you might not have thought about because of limitations of other platforms, so that very little code is required to do something quite impressive. The problem is figuring out what that code is you’re supposed to write, and more importantly how’d you know to go about doing that in the first place. Hint: knowing the Foundation Framework is important to understanding the Cocoa Touch Framework.

This leaves one in the lurch that the sample code appears rather sparse, and the framework documentation overwhelming, with little guidance on how all the pieces fit together into a simple, cohesive whole. The problem is all too common.

My biggest gripe with many frameworks, especially Java and it’s auto-generated documentation, is that all you’re really presented with is a list of method signatures with very little discussion about what they do, purpose and limits to the input values, discussions of side effects, the importance of call order, and so forth. With other languages, you’re lucky if you can find the header file to include or the library file to link against. It’s all just expected that you somehow know this, and that doesn’t work when you’re learning a framework, though it’s fine if you just need a reference.

Apple’s online documentation is certainly comprehensive, but the reality is you’re going to be watching videos and reading tons of documentation, picking up crumbs of useful bits as you go. The cohesive moment of comprehension will come, but it will be a long and slow ride. You want something faster.

If you’re learning Objective-C at the same time, the ride is extra bumpy, because not only are there just a few language extensions sitting on top of C, but the ObjC library is actually doing some clever work that you want to know about, and this has additional implications because there’s a lot of convention going on as well. Further obscuring things is the fact that, due to historical reasons, the terminology you are most likely already familiar with doesn’t map nicely. A nice look under the hood solves this. Objective-C isn’t just some new keywords, it’s new application behavior.

What’s Wrong With Other iPhone Books At The Moment
As of early 2009, you’re going to find few iPhone books out there. Most of what exists is for the hacked version of the iPhone, and while that may even sound useful, the tearing apart of the SDK is rough and incomplete, not to mention the implementation to call is painful. This just isn’t applicable to the real world constraints of native mode development.

Think you can get by with a slightly out of date copy of a Cocoa book? Think again. The UIKit framework is just different enough that your approach needs to be slightly different. Tight, efficient, resource management becomes very important.

Also, unless you already know and understand Interface Builder, it can be a hard time following along when your book doesn’t match your software version. Apple keeps modifying Interface Builder, making it better, but the changes can come across as so dramatic, interface-wise, that to the new comer it looks like a totally different application each revision. Once you “get it” the sweeping changes are cognitively transparent. The iPhone SDK includes, you guessed it, a new XCode and Interface Builder.

What few modern iPhone books there are out there jump straight into a technical feast of SDK details, leaving the reader with a learning curve that’s as vertical as a brick wall.

What’s needed is a book that introduces only what you need to know, when you need to know it, explaining tips and tricks along the way, delving into the philosophies of why things are the way they are, what the developers were thinking, how the frameworks are structured, what the conventions are, and when those conventions aren’t followed. And, instead of showing you the end solution all refactored into a neat package, take the long way, when needed, to introduce you to what’s going on and then evolve into the optimal solution.

I’ve Found Such A Book!
The book, by Apress, is called Beginning iPhone Development – Exploring the iPhone SDK by Dave Mark and Jeff LaMarche. This book is about the fundamental concepts you need to understand in order to make the frameworks do their magic.

Its tutorials are very well constructed, easy to follow, and are specifically designed to teach the framework in such a way as you understand what’s going on and learn to fish for yourself.

This is in stark contrast to substandard books that merely cover a framework’s capabilities with cut’n’paste examples that have little bearing to real applications. This alone gives is five out of five stars by my standards.

My only complaint is a minor nit that there are a small handful of typos, and unfortunately, they happen in the code examples. However, they’re glaring, and you won’t get tripped up by them. (For example, on page 85, the tutorial is about UIImage. And, UIImage appears four times in a six line sample. The first one, however, says “jmUIImage” and the indentation is off. It looks like a macro expansion, a note, or the mangled initials of one of the authors. The code won’t compile with it, and it’s obvious from context what it should be.) To me, this is forgivable. Especially since it’s rare.

Tagging 1430216263I want to show you something.

I have a habit of tagging my books when I find an exceptional piece of information that I haven’t found elsewhere. I give a book high marks if it earns somewhere between three to seven tags, as the majority of my collection never gets any tags. Tagging, for me, is not note taking — it’s rare event.

I think the picture speaks for itself.

For Example…
So, at this point, I present for my own edification and future reference, some of that tagged content. Who knows, maybe something you see here might just get you traction on the learning curve.

– In Objective-C, colons are a legal character of the method identifier, they are not syntactic sugar.
– Even though a number of macros translate to nothing, void, zero, or null under the hood, their presence provides important hinting for data types and method calls.
– The NIB’s File’s Owner is a place holder for the class that loaded the NIB file.
– The NIB’s First Responder is the object the user is currently interacting with.
– The application icon is a 57×57 .png file, see Info.plist’s Icon File.
– The iPhone specially optimizes .png files so this is the best format.
– Reset the iPhone Simulator by deleting its directory from ~/Library/Application Support
– You want to use @property (retain, nonatomic) as often as possible.
– Interface Builder uses your defined accessors to properties, which use retain; that means you do need to deallocate Interface Builder objects, even if you didn’t instantiate them.
– There are four control states on a control, often you want UIControlStateNormal.
– Learn to use retain/release, there is no garbage collecting on the iPhone.
– It’s better to init/release than using factory methods; factories use autorelease pools, and while this will work, it often keeps resources around longer than you intend — avoid autorelease pools.
– Hog too many resources, whether CPU or memory, and the phone will reboot.
– Everything from UIApplication on down will fire messages to Delegate objects at certain well-defined times, you need to learn what these times are and what messages are sent; it’s not just subclass avoidance.
– You can Option-Click on a class or interface name in XCode and go right to the documentation.
– You can press ESC to cause auto complete to happen immediately.
– Command-equal_sign will size a control to fit.
– When you’ve got a lot of control hierarchies going on, use the View Mode button to see them as a list.
– Scaling an image takes computational overhead, avoid if you can.
– Set the Alpha slider to 1.0 in order to optimize the drawing sequence, it skips looking at the underlying background and factoring it in — it applies to the image drawn.
– Also set the Opaque checkbox in order to optimize the drawing sequence, it skips drawing the underlying background for the parts where the image is transparent.
– The Tag control allows you to assign a numerical identifier to controls to locate them later.
– You need to handle the Did End on Exit event in order to make the keyboard go away.
– You may also need a huge, invisible, custom button as well to make the keyboard go away.
– In XCode, use Option-Command-up_arrow to toggle between a header and its source file.
– In the Interface Builder, move the cursor over a view and hold down Option to see how many pixels there are between the item and its superview.
– Option-dragging a control in Interface Builder makes a copy.
– Nifty buttons are actually stretchable images, and Apple has buried a ton of them free for your use in the UICatalog sample code on their site.
– There are three different ways to handle layouts when rotation happens: autosize, reposition, and view swapping.
– The rotation callback passes you the orientation the phone came from, you need to use other means to get the current orientation.
– If you want to use Core Graphics, for things like view transitions, you need to link the framework into your application.
– Some frameworks, like Core Graphics, have one version for the iPhone hardware and one version for the iPhone Simulator.
– If you use the correct parameters, XCode’s build process can play games with the path and always target the right framework (use Relative to Current SDK, and do not select Copy items).
– Right-click the Resources folder and use Add / Existing Frameworks… to do this process in a safe way.
– If a view isn’t shown, it’s superview is nil.

…there’s plenty more, but you get the idea. The book is jammed with all kinds of useful things to someone who is new to iPhone development. This presentation of material makes the learning curve very approachable.

And, once over that hurdle, all those other books that I said were problematic suddenly make a whole lot of sense.

This book is the best first step I’ve seen in the journey to writing iPhone applications. Period.

Walt gives “Beginning iPhone Development” two thumbs up, five stars our of five starts, and a head nod of appreciation to the authors. Well done, guys. Well done.

Changes at the Apple Store – For the Better!

Apple has changed the Genius Bar policies and procedures. INCREDIBLE IMPROVEMENTS!

Anyone who’s been to an Apple Store, especially the one in Tysons Corner, VA, knows that Apple is experiencing some serious growth pains. Yes, as predicted, more and more people are starting to adopt Apple hardware and software and the cost/benefit factor becomes more apparent. The hardware is not that much more expensive, and if you take in to account all the stuff you get and all the stuff you don’t need to buy, it’s actually a pretty sweet deal for the total cost of ownership. Vista didn’t win any favors, Windows 7 is invoking similar fear, and Apple’s forth coming Snow Leopard looks like it’s going to be dealing a death blow. Meanwhile the number of ways to run Windows applications on a Mac, even the graphically intensive ones, are climbing — that a Mac won’t run Windows software is just not true.

Where Apple dropped the ball was the in-store support. If you walked into the store, all appointments were filled. Even if you registered in advance, you couldn’t be seen before hand. And turns were taken in the ordered registered — which meant if you had the identical problem as the person at the counter, and someone required 45 minutes of training in front of you, you had to wait. In short, it was awful and you had resort to gaming the system to get seen when scheduled.

As it turned out, my iPhone started wonking out on me when it came to WiFi. My connections would drop, and with the last firmware update, my WiFi connection would drop seconds after being established. Manually cycling WiFi, power cycling, rebooting, and even firmware reloading did not solve the problem. All I could use was Edge, even when someone next to me could see the network access point at full strength on their iPhone.

I loathed the idea of going in to the Apple Store with a real hardware problem, which would require seeing a Genius, especially a shopping day or so before Christmas Eve.

Unbeknownst to me, Apple had made substantial improvements in customer service, the likes of which exceeded all my hopes and expectations. Check this out!

The moment I crossed the store threshold, I was greeted with “Welcome to the Apple Store, is there anything I can help you with?”

“Uh, no, I’m here for a Genius Bar appointment, and I’m an hour ahead of schedule.”

“No problem sir, I’ll register you’re in-store, so head on over to the bar now, and we’ll see if they can take you early.”

Huh? Normally the Genius Bar has a crowd around it with very frustrated people, and four to six gurus working madly. However, as I looked over there were only two, and tons of empty stools, and zero crowd waiting. Meanwhile, the store looked busier than I have ever seen it.

I go over and take a seat. Again, I’m greeted, they ask my name, and they say they see me as appointment number 9. Usually that means that I can expect an hour and a half wait.

However, I’m watching as the two people there are taking cases, and the moment they require some hardware restore or check, they start the automated job and immediately start taking the next person. They’re working concurrently, and they are cranking through the list.

Less than five minutes later, it’s my turn.

“What seems to be the problem?”

As I’m describing it, I notice he’s typing. So I pause and ask what he’s doing.

He tells me, “I’m setting up an order in the computer to replace your phone with a new one. I’m going to flash the firmware, and if that solves it, I’ll press cancel and give you your phone back. If it doesn’t, I’ll hit submit. Either way, you’ll have a working phone in five minutes or less.”

My mouth drops.

“While I do this, do you mind if I take another customer?”

“Uh, no, of course not.” And he calls the next person in line. I’m shocked. I’m impressed. I’m please. And everyone at the Genius Bar starts socializing with one another. It’s turning into a little party.

As he’s talking to the other customer, he’s pulled out a box, moved the SIM card from my phone into the new one, and pushes the new phone and the paper work my direction. I sign it, and he says to me, “You’re all set. And 15 minutes before your appointment was supposed to start.”

That couldn’t be right, I was there an hour early. Looks like they bumped me up in line a few times when “Last call for Mr. Noshow” was hollered out.

I did get to talk with the Genius, and he stated that Apple now allowed them to take people early, as well as work concurrently, and group similar cases together. It was clear that this removed all congestion and put them ahead of the game.

For as I was talking with him, a floor person came over and said “I have a woman on hold, she was wondering if you could do a walk-in.” The Genius spread his arms and said, “absolutely, I have nothing but real-estate” and gestured at the empty bar.

The service was friendly, prompt, and I’d give it six stars on a five star scale.

Walt gives the new Apple policies and procedures at the Genius Bar two thumbs up!

Aurora Feint: Recovered

For some unexplained reason, Aurora Feint would no longer start on my iPhone. Starting the game exited back to the main menu. Here’s how I restored the game and recovered my previous game play.

Aurora Feint won’t start.

I’ve been playing Aurora Feint on the iPhone, and all of the sudden, it quit working. The game, not the phone. I’d go to start it, and then get returned to the main menu. Seems other people were having a similar problem. Some were lucky to get the game working again, others lost data.

Here’s how I recovered mine, preserving game play. Your mileage may vary.

0. Back up your iPhones by syncing it with iTunes.
1. Hold down the Aurora Feint button until the icons jiggle.
2. Press the (X) delete button over the Aurora Feint icon.
3. Acknowledge that you’re deleting the game and that all game files may be lost.
4. Hold down the power button on the phone, slide to Power Off.
5. Power phone back on.
6. Immediately go into App Store, select Search, enter Aurora Feint, and Install.
7. Acknowledge dialog that you already purchased this item and want to install again.
8. Let the game download and install.
9. Again, hold down the power button on the phone, slide to Power Off.
10. Power phone back on. For me the phone went through a very long boot cycle with the Apple logo.
11. Press the Aurora Feint icon to start the game.
12. For me, the screen went blank and stayed there — tap the center of the screen, movie controls appeared.
13. Unpause movie intro and let play to completion.
14. After a moment, I was returned to the map.

I’ve found that I always have the best of luck restoring the game when I’m at the map. Exiting while at the character page or in the middle of a mining activity does work, but not always; this causes the game to be fussy and exit prematurely to the main screen after start (unless you can intercept with a tap in the upper right corner).

Good luck.

Macbook Pro Screen Goes Dark on Wakeup

My MacBook Pro should have woken up when I lifted the lid, but all was dark. However, while checking the battery level, I noticed it had woken up. The problem was the backlight wasn’t coming on. Here’s the solution. It isn’t the brightness button either.

Today I learned that there’s a nifty little utility called Maintenance 3.8 out on Apple’s site. You can find it by going to Apple / Mac OS X Software…, and when the web page pops up, type Maintenance in the search box.

It’s an automator script to repair permissions, verify preferences, updating prebindings, do cleanup, update databased, rebuild indexes, empty Trash, and so forth. My guess is it’s much like Onyx.

Deciding to give it a try, I downloaded it, opened the .DMG file, and double clicked the automator icon, selecting Restart when done. And while I got a very little in the confirmation department that things were working, I saw a lot of CPU activity running utilities I was familiar with.

So, with the laptop plugged in, I left to to chug away. I heard the restart sound several minutes later. And, I ignored it.

Later, I picked up my laptop and went to login.

Nothing.

The “breathing LED” on the front was off, and nothing was responding keyboard or mouse wise. The screen was black.

So, I decided to check the battery. Full power.

But then I noticed something. At the steep angle, in the near pitch black of my LCD screen, I saw the login window. What was happening: the backlight wasn’t coming on. Fiddling with the brightness control didn’t help either.

Sure enough, I could make out the cursor once I located where it was.

I tried opening and closing the lid. Nope. Backlight still off.

So, I restarted (as I mentioned, it was operational, I could barely make out the GUI).

The machine sprang to life, showed me the blue background, and right before it went to the login screen, the backlight cut out again, leaving me in pitch black.

Titling the screen back again (with the keyboard sticking up in the air and the screen flat on the table), again I could make out the login box and mouse. I did a restart again.

This time I held down Command-V as it booted. And I watched as it came up, lots of normal diagnostic messages, and then the blue background, and right as the login screen appeared, back to pitch black.

Annoying. But now I’m wondering if all the times I’ve ever woken my laptop after a case where the lid didn’t quite clasp perfectly, was this what was happening — could the machine be up, but the backlight off?

So, one last time, I restarted. Only I held down Command-Option-P-R (four fingers) to reset the power management settings. Several chimes later, I let go, and the machine booted perfectly, and the login box appeared, backlight and all.

I’m hoping that my experience may lead to an additional piece of the puzzle about the Mac waking up funny. I would have never have noticed anything on the screen if I looked at it dead on, as I always do.

It’s fairly well known that if you close the Mac’s lid, but down engage it fully, the lid will pop back up, but not after putting the machine to sleep. At that point, it becomes a little dance with the lid, trying to get the lid back down, so that the machine can see it re-open, and that usually wakes it. But sometimes the screen is still dark, and you have to play with the power button (and if frustrated, hold it down to restart).

Sometimes this same problem manifests when you wake the machine, enter your password, and suddenly everything goes dark. You wiggle the cursor and hit the keys and nothing happens. Caps Lock toggles, but it feels like it’s gone back to sleep.

Well no more. From now on, I’m going to tilt my screen back and see if I’m operational. That way I won’t lose data from an unnecessary restart.

New iPhones? Speculation at the Apple Store.

At the Apple store, I was given an interesting tidbit about an “event” that happened, and passed by rather silently.

Total speculation follows.

This weekend, I was at the Apple Store, and managed to get into a rather in depth conversation with someone, who, well, really knew their stuff. More so than other store employees I’ve chatted with, and some of them were pretty good.

I was passed the observation that an interesting “event” had occurred rather silently.

They ran out of iPhones.

This person explained to me that Apple does a really good job of keeping them stocked, since they were a major supplier for the area. However, they were clean out.

The only times that ever happened, was when Apple was about to change inventory on them. Killing the 4GB model was one. Going to the 16GB was the other.

A 32GB or 64GB iPhone seems likely, as iPhone customers want as much memory as an iTouch allows.

This would be a good time to add additional gestures, which, incidentally would help out with the lack of cut’n’paste.

But the real feature I’m looking for? The ability to push my contacts to other people with an iPhone. We’ve got the same device, the same applications, the same data, and bluetooth, there’s no technical reason I can’t give someone my ‘electronic business card’.

iPhone Registration Problem

Here’s a nifty little screen shot of an Apple web site error that provides a little insight into what’s happening back on the server.

Last year when I bought my iPhone, I tried registering it at the store with an Apple Genius at my side.

This popped up. Amusing as it was, I took a snap shot of it and had been meaning to share it for a while now.

iPhone Registration Problems

Perhaps it was a time when Apple’s servers were being over whelmed. Nonetheless, it might provide some insight as to what they’re doing.

NOTE: I tried later that evening and it worked fine; my iPhone has been operating just fine.

iChat Problems: Fixed

Got Leopard? Find that iChat isn’t working? Do you run Parallels? Guess what, that may be it. What? You’re not running Parallels at the same time you iChat? Not relevant, Parallels has network services active even if the client isn’t. Here’s the workaround to get you chatting…

iChat and Parallels
While trying to iChat using Leopard to a system running Tiger, I ran into a problems that I never had using OS X 10.4 before: bad video quality to downright refusing to connect.

With a little research, I ran across this article and that was enough to resolve the problem.

Here’s how to get iChat working on OS X 10.5
…if you’re running Parallels.

See, turns out that Parallels, I’m using 3.0 Build 5582 (Dec 5, 2007), appears to be running some services, even when the virtual machine is active, that gets in the way of iChat.

Get out of iChat.

Go to Apple / System Preferences…, select Network, and click on Parallels NAT and change the Configure drop down to Off; then go to Parallels Host-Guest an change the Configure drop down to Off. Press Apply.

Get back into iChat and try again. For me, it instantly fixed the problem.