But something was brewing at AOL. It had a portfolio of embarrassingly bad products and was admitting that publicly. Tim Armstrong (AOL’s CEO) and Brad Garlinghouse (head of Consumer Applications and famous for his “Peanut Butter Manifesto” criticizing Yahoo’s lack of focus) pulled in Matte Scheinker to fix the problem. Matte — my former manager, ongoing mentor, and one of my absolute favorite people — invited me to help found his new Consumer Experience team. The opportunity was too intriguing to turn down. So I weathered the inevitable, “AOL? Really!?” from friends and family and signed on in May 2010.

Armed with authority over AOL’s product review process, the three of us — Matte, Christian Crumlish, and me — set out to turn terrible experiences into great ones. We consulted, pleaded, designed, brainstormed, fixed typos, debugged code, cleaned trash out of conference rooms. It was exhilarating. The team grew and flourished; by fall 2011 there were seven of us. In the course of it I got to lead the TechCrunch redesign, build an internal social network, and meet and earn the respect of product teams across the company.

But with its acquisition of the Huffington Post, AOL gained new leadership for its core Media business and no longer looked to Consumer Experience for help. It’s no secret I have disagreements with their approach to product development; I can’t say whether they’ll succeed, just that it’s not for me.

Meanwhile, Brad Garlinghouse is leaving AOL. The organization he leaves behind includes incredibly talented people — folks I’ve been privileged to know, work with, and learn from in the past twenty months.  I hope AOL figures out how to retain this top talent in the wake of Brad’s and other high-level departures.

So as of a few weeks ago we decommissioned the Consumer Experience team. I wish Christian, Krista, and Jason (my partner in crime on TechCrunch, various adventures in commerce, and gratuitous pie purchases) luck on the AIM team; I know AIM recognizes the kick-ass talent they’re getting. Same for Gabi and AOL Mail, and for Amy and HuffPost. But I’m leaving. (As is Matte; but he’s still planning his next move.)

I considered staying on in another role. Great people, interesting work, millions of users. A Product role that wouldn’t require a paragraph to explain. And there are people I’m especially sad to leave behind. Yet if anything my time at AOL has increased my desire to go small…really small. The greatest, most rewarding moments in my career have been tight teams of amazing people in a room, building stuff. So I’ve been exploring startup ideas of my own, and talking to existing startups that excite me. Which of those paths is right? Tough call. The former is the Bay Area version of the American Dream but also scary. The latter is safer but lacks the chance to start from zero with my own vision. Neither is a bad choice.

Several years ago I read Gail Sheehy’s Passages. Its central thesis may be obvious today: there’s no such thing as a final adult self. We go through as many changes in our adult lives as we do in childhood, despite society’s expectation that we know who we are by the age of 25. These changes happen via punctuated equilibrium: periods of relative calm followed by times of upheaval. Those who fight the change cripple themselves via a sort of self-induced emotional binding.

I’ve spent the last five years collecting pieces of the next me. At Yahoo! I honed my design skills, led a team, and learned how to navigate organizational politics. At AOL I became a product manager, built leadership skills, expanded my network, grew a thicker skin, and found my ego. (Yes, that’s a good thing. A friend says I’ll succeed because of my humility and she’s probably right — but that’s a counterbalance to ego, not an alternative.)

There are things missing from that list. Sales. Marketing. Business development. Things I can’t anticipate. Things that will blindside me, crush me. I’ll figure them out, or turn to others for help. But I see the rough outline of the next me, and it’s time to make it happen. The best, maybe the only way to do that is to put my money where my mouth is and build something from scratch.

And I’m ready. I’m an interaction designer, a product manager, a visual designer, a front-end developer. I can manage a team, pitch an idea. I have so much more to learn and I’m excited about that too. I don’t want to do it by myself, but I won’t have to: I have talented, passionate, amazing people cheering me on, offering advice and support, and eventually (I hope) joining the effort.

Here I go.

They drove all day. They drove all night. They stopped at a Denny’s in St. Louis. As they dug into their Moons Over My Hammy the Bunny said, “Tomorrow we’ll make for Denver. It’s a flat, boring ride but then we’ll have the plains behind us and see some mountains!”

Just then a long, furry head emerged from the booth behind them. “I couldn’t help overhearing,” said the Ferret. “I’m headed to San Francisco too. May I join you?” The Bunny looked worried but the Frog said, “Sure! I can see from your trucker cap that you’ll add value to our little adventure.”

The Ferret slipped into their booth, grabbing a mouthful of Bunny’s dinner. “All this speculation about routes is silly,” he said. “Look out that window! Hundreds, thousands of cars headed off on their own adventures. Surely our best route will be the one with the most cars. Let’s count how many go each way and follow the biggest crowd.”

“That’s a great idea,” said the Frog. And they headed south.

They drove all day. They drove all night. They stopped at an Applebee’s in San Antonio. As the Ferret shoveled overcooked peas into his mouth the Bunny said, “I don’t understand. We’re following the traffic and I get that. But how do we know we’ll reach San Francisco?”

The Ferret smiled. “It’s not important! What do we gain by setting some arbitrary destination? How do we know we’ll even like San Francisco when we get there? Let’s focus on the here and now, use the information around us to guide our decisions.”

Bunny thought about this. “But if we don’t have any greater destination, what’s to stop us from wander–”

“While we’re at it,” interjected the Ferret, “what are you contributing to this trip? I’m watching the cars, Frog is driving, all you’re doing is looking at the map and suggesting routes that don’t match the traffic.”

The Bunny sat silently, grateful that an angry rabbit is visually indistinguishable from a calm one.

They drove all day. They drove all night. Bunny looked out the window as they passed cities, towns, mountains, strip malls, and deserts. Also more strip malls. They stopped at Burger King in Cheyenne, Cracker Barrel in Nashua, Waffle House in Austin, Chick-fil-a in Atlanta. The Bunny did crosswords.

One morning, as they rocketed east out of Mexico City with the windows down and the Ferret singing along to the radio, the Frog glanced at the back seat and found it empty. “Where’s Bunny?” he asked.

“Gone,” said the Ferret. “Left this morning. He looked angry. Or calm. Said something about San Francisco.”

“What an asshole,” said the Frog.

He did it because he was willing to take big risks on new ideas, and not be satisfied with small innovations fed by market research. He also insisted on high quality and had the guts to leave out features others found essential and to kill technologies, like the floppy drive and the removable battery, he decided were no longer needed.

I’m often hard on Apple. But it’s because I can be: I hold them to a higher standard than their competition because it’s feasible to do so. Steve Jobs seems to have led Apple and often the whole industry through his uncanny gut instinct, willingness to take risks, and unerring attention to detail. We need more of that if we are to continue innovating.

The AOL described to me was in the process of reinventing itself: an aging internet icon that acknowledged the need for fundamental change, that didn’t shy away from the dark corners of its product portfolio. The role was intriguing too. The Consumer Experience mission: to “ensure that AOL only builds and launches the highest-quality products.” The three of us were “ninja janitors,” cleaning up the mess of AOL. We might be accomplished designers and product strategists — but no job was beneath us. The promise: be a part of AOL’s turnaround. Develop standards and practices. Dig in with product teams in need of help and make things happen. Learn from industry veterans. Become better product managers, designers, and most of all businessmen in the process. Learn how to make change happen.

And what a year it’s been. I’ve designed, helped code, and launched AOL’s employee phone book, project database, and social network. I’ve worked with teams across AOL (Mapquest, AIM, AOL Mail, Truveo, AOL Help, and more) to help them refine their experiences — and received tremendous gratitude in the process. I’ve managed agency contracts. I’ve crisscrossed the country on trips to New York and Dulles, VA. I’ve presented to Tim Armstrong, AOL’s CEO. I’ve given a talk on HTML5 and CSS3 to other product managers. Currently I’m coordinating the relaunch of a major media site.

I’ve also found typos and tracked down the right people to fix them. I’ve spent hours graphing the distance from top-of-page to top-of-content on AOL and non-AOL sites. I’ve found tiny problems with rounded corners and helped fix them. I’ve given ad-hoc Photoshop lessons. I’ve cleaned up other people’s trash in conference rooms. I’ve bugged our CIO about problems with our internal systems. I’ve eaten at Chili’s because I couldn’t find my way around suburban Virginia and I was hungry.

All of these things have been satisfying in their own way. Presenting to the CEO is pretty exciting. But finding a typo and knowing how to get it fixed is empowering. And the breadth of tasks — combined with the constantly-shifting landscape at AOL today — means I encounter new challenges, new things to learn, every week.

Of course there are bad days. Really bad days. Days when I’ve been reduced to speechlessness by legacy bureaucracy, technology that was obsolete ten years ago, lack of motivation, organizational whiplash as we acquire new companies, or (perhaps worst of all) good people beaten down by years of corporate stagnation. It is both better and worse because I can’t ignore these things, because I’m here to help fix them.

I don’t hear a lot of “AOL?!? Really?” anymore. Usually it’s more like, “AOL? I think I heard something about them,” or, “AOL? There’s something going on over there, isn’t there?” The tide has turned. We’ve been noticed for our innovative brand and for new products like AOL Phoenix, Moviefone for iPad, PLAY for Android, and the forthcoming Editions for iPad. We’ve made a big bet with Patch, expanding into hundreds of communities. We’ve made some strategic acquisitions, like TechCrunch and Huffington Post on the media side and Thing Labs, Rally Up, and about.me in consumer applications. My bad days have grown fewer, further between, and less bad. We’ve attracted a ton of talent. We’ve renovated our offices. We’ve become the market leader in toilet humor. There’s an energy that just wasn’t there a few months ago.

AOL's new digs in Palo Alto

We're dog friendly

Our kick-ass whiteboard walls

To suggest we’d won would be incredible hubris. We’ve fixed so much, but there’s more to be fixed. Turnarounds are hard, and we’ve got our work cut out for us. Yet the progress we’ve made is exciting, things continue changing for the better, and I’m glad to be here. AOL is an intriguing and unique place to be right now, and the bet I made in joining has certainly paid off.

That change hasn’t affected the core of how a website works. Sure, modules load in asynchronously; some sites use Ajax to load in notifications; and Facebook Like buttons mysteriously appear as you scroll. The typical blog or brochure site is a page-based experience; why overcomplicate things when the Web is, at heart, a page-based medium?

But mobile apps have popularized a new level of page-based interaction. Screens animate smoothly in and out while navigation stays put, not only providing delight but preserving context and reinforcing the user’s position in the information hierarchy. Instead of jarring blankness between screens, users see loading animations.

The No-Refresh Site

Maybe it’s time we embraced this approach for the desktop Web: the no-refresh website. Even with fast load times a full page refresh disrupts context. With Ajax we can leave navigational elements in place while loading in new content. We can bring that content in via animations that reinforce how we’re moving through the information hierarchy of the site. And even with animations, such actions are liable to feel lighter-weight and thus encourage exploration — not least of all because a Back action will be so immediate. 

Granted, such a site is far more code-intensive than its traditional cousin. But a lot of that code has been written: jQTouch and jQuery Mobile already take multiple HTML pages and create an animated, Ajax-based experience — for the most part with no additional JavaScript. They provide a perfect basis for a desktop-friendly framework.

Let’s call it page.js. I took the liberty of reserving pagejs.com and pointing it at a brand new GitHub repository so we can start hacking on it right away. Here’s how it will work:

1. You write your site’s HTML as you would today, adding a little extra info to tag specific page elements. (jQuery Mobile uses HTML5 data attributes, e.g. <div data-role="content"> to define different regions on the page.)
2. When the site first loads, page.js reads and modifies your HTML, wrapping the content area of your page in a movable, scrolling element ready to slide off the screen and adjusting your internal links appropriately. (When performance is critical, this could happen server-side and be cached.)
3. When a visitor clicks an internal link, the new page is loaded via Ajax while a loading animation displays onscreen. The current page slides out of view and the new one slides in. Navigation areas stay put as appropriate.
4. Browser Back/Forward history is preserved using the URL’s hash component (everything after the #). Hitting the Back button slides the previous page back into view. (You can see a very simple example of this on my portfolio using Ben Alman’s hashchange plugin.)

New Possibilities

But that’s just the beginning. A single-page site teems with potential.

As a visitor scrolls your home page, why not load in likely drill-down pages behind the scenes? Tie in your Google Analytics data to identify the most likely destinations after the current page. Break it down by demographic if you want.

Novel navigational paradigms become possible. Previous pages needn’t slide all the way offscreen but could peek out to preserve context, creating a sort of modern breadcrumb:

And, we can use HTML5′s offline capabilities to improve performance on pages that can’t be cached in full: keep navigational and other static elements on the client and use those cached versions to assemble pages on the fly.

Challenges

Right now the barrier is too high for most sites to do this. It requires too much expertise and effort until page.js comes into being. (Anyone?)

Permalinks present a challenge. Ajax-based navigation relies on the hash component of the URL (http://my-site.com/my-page#hash-component). It’s included in a bookmark but isn’t transmitted to the server. So it can be part of a permalink, but (a) requires the cooperation of a JavaScript-enabled client and (b) isn’t indexed by Google and other search engines. Thankfully there’s a solution: Google has created a standard for making Ajax links crawlable that, when used, will keep your no-refresh site searchable. And it gets better: browsers are beginning to implement the HTML5 History API, which is a far more elegant solution to the problem. So you can do it today with a little JavaScript, and tomorrow with a lot less.

These challenges are manageable and can be solved once, at the framework level. So step one is creating page.js and getting it into the hands of site authors. Step three: profit.

Or can you?

I needed a platform for Pints — a mobile app that answers answer the question, “Which beer should I order?” As someone who works in Web technologies on a daily basis I saw HTML5 & friends as an alluring option.

Pints isn’t complicated: a home screen, a few lists screens, a few forms. Its greatest complexity lies at the data level: as an iPhone app destined for San Francisco bars it can’t possibly rely on an Internet connection, so it has to keep a local copy of the beer database and sync it with the server when that’s available. HTML5 has the necessary building blocks in the form of several offline storage options; it’s just a question of writing the synchronization code.

Mobile Web developers have a plethora of frameworks to do the heavy lifting for them: animated transitions, toolbars, buttons, list views, even offline storage. Most of these are new and the landscape is shifting rapidly. I started Pints in jQTouch, then migrated to jQuery Mobile, and finally rewrote the whole app (now in private beta) in Sencha Touch. Along the way I also investigated Appcelerator’s Titanium Mobile. Here’s what I found:

jQTouch

jQTouch is easy to use and relatively well-documented. It’s featured in the excellent Building iPhone Apps with HTML, CSS, and JavaScript. jQTouch takes a progressive-enhancement approach, building an iPhone-like experience on top of your appropriately-constructed HTML. It’s simple, providing a basic set of widgets and animations and just enough programmatic control to permit more dynamic behavior.

But even in my simple test app there were performance issues. Page transitions can be jumpy or missing, and there are periodic delays in responding to tap events. And while the project is technically active, the original author has moved on and development seems to have slowed.

jQTouch is available under the permissive MIT License, one of my favorite open source licenses.

jQuery Mobile

jQuery Mobile is the new kid on the block. Announced in August 2010, it’s quickly progressed to a very functional Alpha 2. It takes a similar – but more standards-compliant – approach to jQTouch and feels very much like that framework’s successor, with a broader array of UI controls and styles.

jQuery Mobile’s performance is variable (though better than that of jQTouch), particularly in responding to tap events rendering animations. It also lacks a small number of key programmatic hooks that would permit easy creation of more dynamic apps. For instance, there’s an event that triggers when a page is about to load (i.e. slide into view) but no way to tell the associated handler code what UI element resulted in the page switch, or to pass additional information to that handler. I was able to create workarounds but hope that future versions will take a cue from jQTouch and build out this functionality a little more.

jQuery Mobile’s documentation is a little scattered but improving; I’m hopeful that it will become as robust as that of the core jQuery library. (Note that jQuery Mobile is really a mobile counterpart for jQuery UI, not for jQuery itself, on which it builds.)

jQuery Mobile is available under either the MIT or the GPL2 license.

Sencha Touch

Sencha Touch is the mobile counterpart to the Ext JS framework. Its approach differs significantly from jQTouch and jQuery Mobile: instead of enhancing preexisting HTML, it generates its own DOM based on objects created in JavaScript. As such, working with Sencha feels a little less “webby” and a little more like building apps in other technologies like Java or Flex. (It’s also a bit more like YUI than like jQuery.) I personally prefer the progressive enhancement approach, but it really is a matter of preference.

Sencha is far more extensive than its competitors, with a vast array of UI components, explicit iPad support, storage and data binding facilities using JSON and HTML5 offline storage, and more. (It’s very cool to manipulate app data in one of Sencha’s data structures and watch the corresponding list update in real time.) It’s also the only Web framework I’ve seen with built-in support for objects that stay put (like a toolbar) while others scroll (like a list).

For all that apparent extra weight, Sencha performed noticeably better and more reliably than either jQTouch or jQuery Mobile in my tests, with the exception of initial load time.

When working with a library or framework, it’s usually counterproductive to “fight the framework” and do things your own way. Given how extensive Sencha Touch is, that means your app will probably end up doing just about everything the Sencha way. I’d originally used WebKit’s built-in SQLite database for offline storage but ultimately eliminated both complexity and bugs by moving that functionality into Sencha’s data stores.

The documentation, while extensive, has odd holes. Between those and the sheer size of the framework, I spent a lot of time fighting bugs that were difficult to trace and to understand. Responses to my questions in the developer forums were more frequent and helpful than with the other frameworks, but still ultimately insufficient. Sencha provides paid support starting at $300/year; I strongly considered purchasing it but oddly, their response to my sales support inquiries was incredibly underwhelming given my interest in sending them money.

Sencha Touch is available under the GPL3; under a somewhat confusing set of exceptions to the GPL that seem similar to the LGPL; or under a free commercial license.

Titanium Mobile

Much like Sencha Touch, Appcelerator’s Titanium Mobile allows you to write apps using a JavaScript API. But unlike Sencha, it compiles most of your code into a native iPhone or Android app. That means it isn’t really a Web framework, but a compatibility layer or compiler. (Note that its cousin Titanium Desktop is Web-based, allowing you to write HTML/JS applications that run inside a native wrapper on the desktop.)

So Titanium allows Web developers to produce high-performance, easily skinnable native apps using JavaScript and a little XML, i.e. without learning Objective-C or Cocoa Touch. My simple test app blew away the true Web frameworks in terms of performance, and wasn’t much harder to put together.

But that advantage is also its greatest disadvantage: you can only target the platforms Titanium supports, and you’re tied to their developer tools. As if to prove this point, my test app quickly got into a state where it wouldn’t launch on the iPhone. Titanium doesn’t include much of a debugger; Titanium projects can’t be run and debugged in XCode; and it ran fine in the simulator, leaving me with no real way to attack the problem.

Analysis

Rebuilding my app on three of these four frameworks was tedious but educational. I like jQTouch but have trouble believing it will evolve much from here. I’m rooting for jQuery Mobile for its simplicity and its very Web-centric approach to development…but it lacks a few key features and doesn’t perform as well as Sencha Touch.

It’s unfair to compare an Alpha 2 product with a 1.0 one, except in one respect: I need something now. Which brings me to Sencha Touch. I was initially impressed with its performance and breadth, but put off by its development style. As I’ve dug in, the holes in its documentation have been frustrating but the breadth has continued to impress me, and I’ve gotten more used to the coding style. The option for paid support is tempting, and I’d probably buy it if they’d answer my emails. But for now, Pints is a Sencha-based app.

Conclusion

I haven’t answered the big question: can a Web-based app really hold its own alongside native apps? And if so, are the challenges of getting it there worth the benefit of a single codebase?

Two weeks ago I was leaning toward no. Pints was in performance and bug hell, hanging for 10-15 seconds at a time; scrolling was choppy; and other animations were inconsistent.

But I’m hopeful again. In my next post I’ll discuss why, what I’ve learned, and my perspective on mobile Web apps today. I’ll also cover PhoneGap and other methods of distributing a Web app in a native wrapper. Stay tuned.

As long-time iPhone owners we’ve done our share of railing against AT&T. Time to put our money where our mouth is. We’ve ordered an iPhone 4 (with AT&T) and a Droid Incredible from Verizon. In 30 days we return one. Two phones enter…

We’ve had the new iPhone for three days now. Since there are plenty of full reviews elsewhere, I’ll restrict myself to a few highlights.

It’s fast. Fast, fast, fast. I cannot overemphasize how important this is. Presumably it’s a combination of the faster processor and the pseudo-multitasking, with an emphasis on the former. (I am upgrading from an iPhone 3G whose iOS4 upgrade slowed it to a crawl.)

The new screen is beautiful. It’s evolutionary, but the type of evolution that feels revolutionary because it makes such a difference. I was doing my Kindle reading on an iPad, but the crispness of text on the iPhone 4 has switched me back to it. In some ways it feels like a different technology.

The hardware is not as dramatically different from previous generations as Apple would have you believe, but nice, compact, clean-looking. It’s a little harder to pick up because of the square edges.

The best news is the signal. Reception is definitely better in San Francisco – and the Mission in particular. It’s possible to make calls in our apartment and to load data on the street, though it’s still spotty. Whether that’s the device or AT&T’s ongoing improvements is unclear: we know they’re adding towers, and our iPhone 2G seems to be doing a bit better as well.

Then there’s the much-discussed antenna issue. It’s real, not simply cosmetic, and confirmed by Consumer Reports. (Mini-rant: the frustrating part is not the hardware problem, but Apple’s all-too-typical response ranging from, “What problem?” to “You’re the problem.” It takes a special brand of arrogance to deny something so easy to reproduce.)

Otherwise…well, it’s an iPhone. Overall a delight to use, irritatingly locked down at times, occasionally annoying. The Droid should be arriving soon…

These trade-offs are unavoidable. If you don’t make them explicitly, you make them implicitly. Can’t decide which feature get a big button? You can create ten buttons but you’re making another trade-off: each will be a little less prominent, and your product’s simplicity and elegance will suffer.

Trade-offs are necessary at every stage of the product lifecycle:

• Apple is often praised for simplicity. Less is more: remove all the physical buttons and do the rest in software. But that’s not the whole truth. The iPhone has two volume buttons, a power button, a Home button, and a ringer switch. Only the power button is necessary. Someone made a trade-off, sacrificing a certain degree of simplicity for the convenience of four more buttons. The result may, in fact, feel simpler: without taking the phone out of my pocket I can adjust the volume or set it to vibrate. What we call simplicity is, in fact, a successful trade-off.

• Facebook has repeatedly favored speed over caution, angering users by releasing features and design changes (e.g. the newsfeed) without vetting them thoroughly. Many look to the resulting uproar as a cautionary tale, but I believe this is the wrong lesson. At worst, Facebook’s tremendous growth has proceeded in spite of these choices. But I suspect Facebook has succeeded because of them: by trading speed for pre-release research and by making sure they can correct course quickly, Facebook has innovated, stayed ahead of the competition, and gotten free user research in the bargain.

Make no mistake: trade-offs are hard. They require sacrifice. They require risk. But then, it should come as no surprise that these qualities are needed for great product design as well.