One caveat: I haven’t written native Android code, so this is based primarily on iPhone development. But I believe much of I have to say here will apply there as well.

Performance

Web technologies simply don’t perform as well as native. Animations stutter. Pages jump or blank out when they reload. And that’s on iPhone, which is the best case. Die-hard web developers will point out that these problems are solvable, and they may be. But solving them requires effort and potentially compromises (e.g., a Load More button instead of a continuously scrolling list). Which would you rather spend your time on: building great functionality or fighting a non-native platform so it feels native?

There’s no question that the speed of mobile browsers will continue to improve, and frameworks will evolve to take better and better advantage of them. At some point performance may cease to be such an issue. I wouldn’t expect that to happen in 2012.

Documentation

Efficient development requires great documentation. Apple’s is comprehensive. Several great books will get you up to speed. (I used iOS Programming: The Big Nerd Ranch Guide.) And Stack Overflow and other community sites have answers to nearly any question.

I can’t say the same for HTML5 frameworks. Sencha Touch has extensive documentation but I encountered holes, areas lacking detail or even high-level explanation. The community was similarly hit or miss. And my attempt to pay for support was, strangely, ignored. This is worse for a large framework like Sencha’s than for something smaller like jQuery Mobile (whose documentation was also underwhelming) because you’re spending less time interacting with the browser and more working with the framework’s own middle layers.

Sencha Touch is open source. Given enough time, I might have solved my problems by digging into the code. But again, the goal in choosing HTML5 is to avoid learning new platforms. If I’m going to accept a learning curve why not learn a well-documented, widely-used platform instead of a specialized middle layer?

Tools

Apple’s Xcode is good. There’s a drag-and-drop tool for assembling user interfaces, a debugger for inspecting and stepping through your code, smart code completion, optimization tools, and integrated documentation. I understand you get similar functionality developing for Android in Eclipse.

There are integrated development environments (IDEs) designed for web developers: Aptana, NetBeans, Coda, and others. In my experience they’re not as polished as Xcode and lack tight integration with frameworks. Debugging in a desktop browser has improved tremendously in recent years but you’re debugging the JavaScript, not the HTML5 framework. Your bugs may trigger errors deep in the framework code, which you then have to decipher.

And web debugging in the iPhone Simulator or on the device itself is another story. You can print messages to the console but you can’t set breakpoints or step through your code. And just because your app works in desktop Safari doesn’t mean it’ll work on device. So there’s a lot of poking around in the dark that simply doesn’t happen with native development.

Conclusion: Yeah, It’s Still Nuanced

I’ve been hard on HTML5 frameworks here. We need them. They’ve taken on the important, challenging task of making it easy for web developers to create interactive mobile experiences. They’re developing for moving targets that differ in their capabilities and limitations. They’re constantly at a disadvantage because there’s an additional layer between them and the OS. The work they’re doing is incredible. As the frameworks mature they’re turning their attention to documentation. In the meantime, Microsoft and Adobe seem to be shifting focus away from their proprietary frameworks onto HTML5, so better developer tools may be around the corner.

If you’re building a mobile web experience, an HTML5 framework may be just the ticket. If you’re building an app whose requirements are modest or it needn’t feel native, ditto. Sencha Touch is heavy but gets the job done. Once jQuery Mobile irons out a few more bugs it’ll probably be my favorite because it’s “webbier” and lighter-weight than Sencha.

But if your goal is to produce a polished, native-feeling app then I recommend going native (or native with embedded HTML content as appropriate). That’s partly the designer’s desire to create something pixel-perfect. But it’s also about efficiency: better to tackle the one-time learning curve than to wage an ongoing battle against limited documentation, performance issues, and underwhelming tools.

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.

It’s the myth of the Average User. At Yahoo! we called them Chief Household Officers (an unfortunate warping of a legitimately identified market segment). Maybe you call them Stay-at-Home Moms or Women 30-45 — somehow they’re always female. They’re a catch-all excuse for dumbing down products. We try to get them in the lab but they end up being smarter and more interesting than we wanted. In fact, we’ve never met an Average User.

Perhaps the stereotype is born of helping friends and family with technology problems; or waiting in line behind someone at the ATM; or watching the antics of a fellow cafe customer with fascinated horror. A lot of people are really bad at basic computer tasks. Many don’t fully understand their filesystems, or the difference between an OS and a Web browser.

But that doesn’t mean they’re dumb, or inept. It means they’ve figured technology out on their own, skipping over many of the underpinnings because they weren’t relevant. They’ve spent hours on Facebook and Google and know their way around, but haven’t had to interact directly with their home directories.

The result is a specific, somewhat predictable set of expectations. Show a user something that acts like Facebook or Google and she’s likely to figure it out. Show her something that looks like Facebook but acts some other way and she’ll struggle. Talk to her about friends or newsfeeds or Googling and she’ll get it. Talk about RAM and browser windows and WebKit and not only won’t she get it, she may not care.

Why bother pointing this out? Because it affects the success of your product. Design for the mythical Average User and you’ll have something that’s neither compelling nor efficient to use. At worst it’ll be insulting. At best it’ll limit your chances of success: not only are you designing for people who don’t exist, you’re also creating an environment where it’s easy to justify uninteresting functionality and bland visual design.

Instead, design for real people. Even if your product is meant for everyone, find a more interesting subset with clearly identified needs. Understand their expectations for how a digital product works and capitalize on them. Keep it focused. And respect your users enough to differentiate between experience and intelligence.

I often use Dropbox as an example here. Everyone I work with uses it (technical and non-technical alike). It’s simple to understand and easy to get started. It just works. It explains itself in layman’s terms, but isn’t insulting. Its feature set is small and focused, but it functions flexibly enough for power users to work around its apparent limitations (e.g. using symlinks to work outside the Dropbox folder). It solves one problem and solves it well.

Remember that novice users, once hooked, become power users and need efficiency. Conversely, novices aren’t necessarily your first customer. If your target user isn’t technologically adventurous, the way to his heart is through those who influence him. For example, Gmail’s global rise was fueled in part by tech geeks who eventually convinced friends and family to switch. Facebook started on college campuses and expanded from there.

The next time an absent relative is invoked to justify a decision, challenge it. Get the relative on the line, find a real person to serve as a replacement, turn to the data…whatever it takes to make sure you’re designing for real people. Because mythical users can only generate mythical revenue.

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.

Let’s get one thing out of the way: creating a great standard experience is a hell of a lot easier than creating a great custom one. Even some of the best custom apps (e.g. Twitter for Mac) fail to handle some key interactions (e.g. distinguishing between an active and an inactive window). Your mockup may look splendid in Photoshop but in sidestepping your platform’s own UI toolkit you’ve assumed the responsibility for all sorts of details (e.g. accessibility). In other words, don’t go down the custom route unless you’re willing to put a lot of effort into making design a differentiator for your product (as Twitter has clearly done).

Anyone who’s worked with me knows I enjoy designing custom controls — widgets tailored to the task at hand. Generally these tasks could be accomplished via some combination of standard UI elements, and the argument against them is often about consistency. In “User Interface Conservatism versus Liberalism,” Adam Engst writes,

…the real problem with UI liberalism is that it reduces the usability of the platform as a whole…The more you use applications in concert—and many of us spend our entire days at our Macs—the more you benefit from the consistent user interfaces designed by UI conservatives. And when applications rely on consistent user interfaces, they become easier to learn as well, which translates directly to the bottom line when we’re talking about productivity applications.

Much of his argument is good. But ultimately I disagree: consistency doesn’t matter. In 2005 Jared Spool wrote, “Consistency in Design is the Wrong Approach“:

The problem with thinking in terms of consistency is that those thoughts focus purely on the design and the user can get lost. “Is what I’m designing consistent with other things we’ve designed (or others have designed)?” is the wrong question to ask.

Instead, the right question is, “Will the user’s current knowledge help them understand how to use what I’m designing?” Current knowledge is the knowledge the user has when they approach the design. It’s the sum of all their previous experiences with relevant products and designs.

As an example, consider Apple scrollbars:

Apple scrollbars on the Mac

iTunes and iPhoto’s custom scrollbars are visually inconsistent with the standard Mac one. Yet I doubt this creates any usability problems because they retain the same layout and a set of core visual cues. They all rely on the same current knowledge.

Easy example, you say: that’s just visual design. What about differing interactions? Encountering a Mac scrollbar for the first time, a Windows user might be confused because the up arrow is at the bottom. Here, the visual design serves as as guide: that up arrow is nearly identical to the one found on Windows. So the user’s current knowledge of Windows allows her to find it after a moment’s hesitation.

But that’s where things get nuanced. That hesitation is fine if she uses a Mac occasionally. But if she’s constantly switching back and forth she’s also repeatedly re-training herself, constantly incurring that cognitive load. And however inconvenient that might be, at least she can recognize two different contexts; it would be far worse for a Windows app to use Mac-like scrollbars. Here, consistent placement matters because it’s how we achieve consistent expectations.

It gets worse: suppose your app uses custom code to generate a snazzy scrollbar. You put both arrows at the end since that’s the Mac standard. That Windows user changes her Mac’s system preference so the scroll arrow is at the top. Every scrollbar except your app’s changes to obey the new setting. Yet another example of why custom UI is difficult.

Today, nearly every mouse has a scroll wheel, and many trackpads support a two-finger scroll gesture. I question whether most people use the scroll arrows at all. Twitter agrees:

Twitter for Mac's scrollbar

So that’s bad, right? Well, not necessarily. If most people don’t use scroll arrows few will miss them (or even notice they’re gone); and given Twitter’s more tech-savvy audience that number is even smaller. For those who do, a complete lack of arrows is probably better than non-standard ones since it’s a clearer difference. The visual design helps too: the scroll thumb retains is distinctive shape to prompt user expectations, but its appearance is notably different from any of Apple’s, providing a cue that this is a different sort of scrollbar as the user switches between apps. The lack of scroll track enhances that further. It’s a risk, but one with justification.

Design is hard. The more of it you take on, the harder it becomes. There’s nothing wrong with custom UI when it’s done well — that is, when you design for current knowledge — but that takes time, effort, and probably testing. Apple, Microsoft, and a number of excellent Web UI frameworks have done that work for us, allowing us to create superb experiences without worrying about the details of how a dropdown works. For many developers that will be good enough; better to focus on solving new problems, perhaps with the occasional custom control when a novel task demands it. If you do create a fully custom UI, go in with your eyes open: get a phenomenal, detail-oriented designer; accept that the UI will require significant effort; and leave time for usability testing. Recognize the trade-off: you’ll get a distinctive brand and carefully-crafted emotional impact, but you’ll invest a lot of resources to get there.

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.

I won’t claim to have used an incredibly rigorous process. As previously mentioned, I chose Sencha Touch as my framework almost exclusively based on its performance. At least on iPhone, I threw out PhoneGap in favor of a lightweight custom Cocoa wrapper. (I’m particularly skeptical about whether that ended up mattering, but it did allow me to create a better experience during app load by waiting until the page finishes loading before fading in the WebKit view.)

Inspired by Thomas Fuchs’ “Making an iPad HTML5 app & making it really fast,” I then did the following:

• Pints was routinely hanging for 10-15 seconds whenever the data stores for its lists got updated. Using the built-in WebKit debugger in desktop Safari (which was hanging for 3-5 seconds) I did a bunch of fairly trial-and-error exploration and finally tracked the problem down. Sencha Touch support grouped lists with an index bar, like the iPhone address book — a great feature which apparently slows to a crawl with larger lists. I reluctantly turned that off, reverting to flat lists and eliminating the problem.
• I gutted both my own CSS and Sencha’s, stripping out all images, CSS3 gradients, text shadow effects, and some of the CSS RGBA alpha transparency. The result kept layout-related rules but was mostly unstyled in all other respects. I also pulled out the CSS3 @font-face call, reverting from Ubuntu Sans to Helvetica. This served as my baseline and was acceptably fast for most page-slide and list-scroll operations.
• I then selectively turned things back on based on their importance to Pints’ look & feel and reasonable hypotheses about their potential performance impact. I assumed my static wood-grain background image would be less problematic than the semi-transparent gradient applied to each list item. I left out the custom font because it wasn’t that important. And so on. Each time I turned on another item I ran the app on the device and evaluated, ultimately arriving at a UI that was close to the original but far faster, and not appreciably slower than the baseline.