Benjamin J Gilbert

My iPhone is a computer. And it’s almost powerful enough to be my only computer. But when I’m at my desk, I want the rich interface, multi-window interaction, and file system of Mac OS X. Mac OS X could, in the near future, run on my iPhone. Imagine this:

I’m using my iPhone as usual. It has an iOS interface with sandboxed apps, and is beautifully optimized for the screen and interaction model of the device. But then, I get close to a monitor, mouse, and keyboard. For simplicity’s sake, let’s say that I have to plug my lightning adapter into some hub that connects to these peripherals.

My iPhone detects the desktop setup, and switches over to a Mac OS X interface. It’s as if I’m running off of a Mac Mini, but all of the processing is happening on my iPhone. And if we’re really moving in the direction that Apple (and everyone else) is betting on, most of my file storage is in the cloud anyways.

App developers will ship apps that have three interfaces: iPhone, iPad, and Mac. These new forms of “Universal Binaries” will be the new standard. All of the apps will live in special folders that are entirely sandboxed, and run as-is on iOS. Any app that doesn’t follow these sandboxing rules, and doesn’t have iOS interfaces will live in the traditional /Applications folder, and won’t be distributed by Apple in the App Store.

One computing device with multiple interfaces depending on what I’ve got available at the given time for an interface.

I’m sure there’s a team in Cupertino working on getting OS X to run on ARM, and then we’ll hear an announcement similar to the Steve Jobs’ Intel announcement:

Now, I have something to tell you today. Mac OS X has been leading a secret double life for the past five years. There have been rumors to this effect, but this is Apple’s campus in Cupertino. Let’s zoom in on it and that building right there. We’ve had teams doing the just-in-case scenario. And our rules have been that our designs for OS X must be processor-independent and that every project must be built for both the PowerPC and Intel processors. And so today for the first time, I can confirm the rumors that every release of Mac OS X has been compiled for both PowerPC and Intel. This has been going on for the last five years. Just in case. So Mac OS X is cross-platform by design, right from the very beginning. So Mac OS X is singing on Intel processors and I’d just like to show you right now. As a matter of fact? As a mater of fact this system I’ve been using right here…Let’s go have a look.

Perhaps in the near future, we’ll hear:

Now, I have something to tell you today. Mac OS X has been leading a secret double life for the past few years. And so today for the first time, I can confirm the rumors that Mac OS X has been able to run on iOS devices to power Mac OS X apps from your pocket. Just in case. So Mac OS X is cross-platform by design, right from the very beginning. So Mac OS X is singing on ARM processors on iOS devices, and I’d just like to show you right now. As a matter of fact? As a mater of fact this system I’ve been using right here…Let’s go have a look.

Traditional SMS is a peer-to-peer system across multiple networks. Apple’s iMessage is a centralized system with a single network. This gives Apple the opportunity to do some interesting things, such as deliver read receipts, show typing status, and send high quality images over “text” messages. But it shouldn’t stop there.

Apple has the opportunity to build one of the greatest things about email into iMessage: auto-responders. Specifically, dead battery auto-responders. I’m thinking that it could work something like this:

1. User opts into a service that allows their iPhone to transmit a quick signal upon a dying battery to Apple’s iCloud servers if network is available. This signal flips a bit in iCloud saying, “this device’s battery is dead.”
2. User can set a message that gets blasted out to anyone who iMessages that account notifying the sender, “Hi, I’d like to respond, but unfortunately, the battery on my iPhone has died.”
3. When the iPhone gets charged again, it sends a signal back to iCloud that flips the bit back, and the auto-responder becomes disabled.

One potential reason that Apple wouldn’t implement this feature is that it increases user awareness of dead iPhone batteries, but it’s certainly a great way to mitigate that helpless feeling of, “if only I could tell this person that I wasn’t receiving their messages!”

There’s also the fact that, yes, I could access my iMessages from other devices, but better safe than sorry.

It seems a little silly, but I was on the bus last week on the way to meet a friend who was visiting town, and I sure felt like a jerk knowing he had an unanswered message to me: “Are you on your way? Am I at the right place?”

I’ve filed a Radar feature request with Apple, and you can view it on Open Radar here. If you’re an Apple developer and you agree, feel free to dupe!

I’m upset about the name, “iPad”. I’ve got a lot of other thoughts regarding the product, but this is what particularly gets me right now.

Sure, there are all the jokes out there, but that’s not what really bothers me. I think it has a terrible ring to it.

1. I’m not a huge fan of the “i” prefix. It’s not really necessary anymore, and simply “Slate”, “Tablet”, “Canvas”, or even “Pad” would have sounded more pure. The “i” sounds cheesy these days. “The Apple Canvas”. Now that’s a name with some prestige.

2. Say “iPad” out loud a few times. It feels wrong after saying “iPod” all these years. It feels like I’m patronizing someone from the South side of Boston trying to pronounce a renowned Apple product. Or even how a “stupid American” would pronounce a beautiful foreign word with a shortened and cropped vowel sound. There’s something inherently ugly about the “short-vowel-a” sound in this particular product name. The pronunciation of the “o” in “iPod” felt a little pretentious. It gave the product a little boost in subconscious value. “iPad” sounds cheap and insincere.

Don’t get me wrong. I love Chrome for Mac. The simplicity, the screen real estate, the speed – it is my current browser of choice. Throughout the development of this site, I preferred to evaluate it aesthetically through the frameless monocle of Chrome.

But something doesn’t feel right. Google missed something.

It’s not just that the software isn’t perfect. Nothing ever is (and it’s still beta software).

I’ve been using Chrome for about a week now, and the little things that bother me are starting to add up. I’m not just talking about lack of in-browser support for PDFs, choppy rendering of heavy sites while altering the window size, or easy indicators of a site’s RSS feed. I know these features will come in time.

I’m extremely sensitive to design inconsistencies. Apple’s done a pretty phenomenal job ensuring that software that’s written their way is consistent in UI and behavior. It’s almost relaxing to use software developed to the Human Interface Guidelines specifications. Every single behavior and placement is expected. Apple cares about every pixel, and the behavior of every single keystroke and mouse click.

This is where Chrome falls short. The tiny nuances that are generated deep in the software stack matter. They matter a lot. I don’t know all the details of Chrome’s implementation, but I know it doesn’t quite feel like a native Cocoa app.

I’m upset that in Google’s genius (I really mean it) decision to place the tabs above the Omni Bar, they screwed up the title bar buttons. In their rewrite of the standard title-bar, they somehow lowered the close, minimize, and zoom buttons by two pixels. This just seems careless.

The implementation of the red “circle x” image that appears when a user hovers over the matte “x” to close a tab is horrendous. There is no other attempt at a 3D graphic anywhere else in the entire application. Nor is there any global light source to justify the half-hearted attempt at a shine on the top. In fact, when viewed against the standard shine on the bar button items, it looks especially tacky. I have another issue with the hover graphic. As it tries to match the same “x” size as its tasteful counterpart, the matte “x”, the circle must take up a larger area. When the title of the page just barely fits in the tab (as seen in the graphic below), the red “circle x” spills into the empty space intentionally left to be aesthetically pleasing, and awkwardly juts up against the text.

The position of the “x” has been widely debated by others, and I buy into Google’s strategy here.

There is one more example that really screams at me. In all standard Mac OS X applications, a user can select text, and then drag the text to any appropriate location. The interface for this is snappy and intuitive. A lighter version of the highlighted text moves with the cursor.

Google has decided to use some type of proxy for this. This is disappointing. Their choice doesn’t even really make sense. There is a small image of a globe. This is for text, images, and anything else draggable. Perhaps it is a “global proxy” for anything you drag? I have no idea, but it’s annoying.

I’d liken it to earlier versions of Mac OS using a proxy outline of a window when dragging instead of moving a the whole window. The upgrade was just flat out refreshing.

I hope someone from the Chrome team is aware of these issues, and cares as much as I do. I can’t wait to see what fixes and features are added with future releases. It’s a beautiful browser, but it needs some serious work on OS integration. Mac OS X users expect a certain quality of native applications. Where would we be if we didn’t deliver that quality?

You just can’t skimp on the little details.

Maier nails it:

Good user experience isn’t something that can’t be “bolted on” after a website or application has been built. It needs to live within the application’s development process, and breathe in every interaction a user has thereafter.

He makes some great points about considering the user experience at initial exposure, continued use, and predicting how your community will evolve and use your service. Also, I love the graphic showing the evolution of the facebook.com profile page. Seems like nostalgic images of the old page rarely show up anymore.

Everyone’s looking for a good metric on defining the breadth of your influence on Twitter. Sure, you could just look at the number of retweets or favorites, or you could look at MG Siegler’s “Golden Ratio” discussed a few months back, but what if you really want to know where you stand on the pulse of the planet?

The slow rollout of Twitter’s new feature, Lists, has been speculated to shed some more light on the situation. Mark Drapeau raises an interesting point. In fact, he even (satirically) goes as far as to say “I always knew I was awesome, but now I can prove it.”

This got me thinking about the manor in which Twitter Lists will be used, and if they actually will provide a good metric on one’s influence. Lists can be public or private. These are used for the intentional purpose of packaging up people for other to follow, and creating personal convenience, respectively.

Think about it. If you are going to make a list of “people who I want to read all of their tweets” or “these are my close friends,” these will most likely be private lists. If you’re creating “My recommendations for who to follow in the tech industry,” that’s going to be a public list.

The interesting part is, being added to someone’s private list does not increase the “Listed” count of a user at all.

So, what does it mean to have a high “Listed” count? Lots of people have decided that other people should follow you as well. What doesn’t it mean? That lots of individuals have promoted you to some type of elevated status among their personal streams.

A product is designed with the customer in mind. From the user interface to customer support, the user’s interests are paramount.

The user’s experience with a product is a life cycle. It begins with their initial exposure to the product that they do not yet own. It continues through their purchase, ownership, discussion with others, and eventually their need for support. Whether their support needs are due to their elevation to power user status, or their difficulties adopting the conventions of the product, customer support is part of the customer’s experience with the product.

They don’t think of support any differently than they think of product design.

And neither should you.

Corporate structure should reflect the mindset of the customer. It’s great that the UI team is collaborating with the implementation team under the umbrella of user experience. But it’s not enough. When a customer needs additional resources outside the scope of the users manual, or the intuitive design of the product, they shouldn’t have to change their perspective to interface with the company that produced the product.

There absolutely cannot be a disconnect between the support team and the product design team. It is all part of the user experience, and the user must never feel any more alienated by the support system than they do with the product itself.

Let’s look at Apple. They’ve nailed it. People keep calling the Apple Stores retail. But it’s far more than that. It’s an extension of Cupertino into the customer’s back yard. The Geniuses at the Genius Bar work mere inches away from the product. They stare at the user interface all day. In fact, the whole Apple Store feels like an Apple product. Even the packaging is part of the experience. Apple has created an environment around their products where merely unboxing products is exciting. That’s the kind of customer experience I’m talking about. Seamless integration between the user’s experience with their product, and their experience with the support staff. In the user’s mind, Apple is Apple. They buy an Apple product, it feels like an Apple product during use, and when they are getting support, it’s just another Apple product.

It’s just that simple. Manage your service experience like you manage your product experience. It’s all the same thing to the user.

Don’t just build insanely great products. Build insanely great customer experiences.