The Pixate Project: Bringing CSS to Native Apps

On Friday, we announced that @WalmartLabs sponsored the Pixate project on KickStarter at the $10,000 level. Today I thought it would be fun to spend a few minutes writing about why I’m personally so excited about this project.

What is Pixate?

Disclaimer: I’m not a member of the Pixate team, but I have spoken with them a bit about the project. Take what I say as unofficial but somewhat informed content.

Pixate brings CSS to native apps. What does that mean? Pixate allows for the customizing of attributes of native UI components using a syntax inspired by the web’s CSS standards. It doesn’t aim to apply every CSS attribute in the various CSS specifications to iOS–that wouldn’t make sense. Instead, its goal is to take the “selectors” part of CSS and introduce attributes and values that make sense for styling native components. Where existing DOM-centric attributes make sense in a native context, they’ll be reused, but where new ones are needed, they’ll be christened as necessary.

Doesn’t CSS Suck for Apps?

Many web luminaries have gone on the record for years talking about how bad CSS is as a visual layout tool. I couldn’t agree more. In my personal experience, CSS layout has been remarkably unpleasant. Despite my years of hands-on web development experience, I must constantly refer to documentation, commentaries, debugging tools, and multiple browsers to achieve any sort of complex custom layout–heck, even simple stuff much of the time. I’m not interested in bringing this sort of thing to native, where the tools are generally better.

However, there is tremendous power in this concept of declarative configuration of user interface components. The parts of CSS that have to do with changing element attributes works quite well–and that’s independent of whether or not the particular set of attributes you have to work with are a mess. The selector syntax is easy to learn and extremely powerful. Editing a few lines in a text file can radically change the appearance of multiple interface definitions and can do so in both very general and very precise ways.

Peanut Butter, Meet Jelly

I’ve long had two feet in the desktop/native app and web app worlds. I started my career doing desktop apps, jumped to web when it hit the scene, came back to the desktop with Java Swing and then tried to bring some of that back to the web by founding Ajaxian.com with Dion and evangelizing rich web clients. As part of this cross-pollination, I created a Java Swing framework that worked a bit like Pixate: it loaded in interface definition files created with a UI builder (in my case, the third-party JFormDesigner app) and then applied CSS rules to the components in those definition files. Despite having different properties than DOM elements, it was an easy trick to expose properties of Swing components to CSS.

I returned to this idea a second time when I was in Mozilla Labs working on Thunderhead, an HTML5 Canvas-based UI toolkit experiment: I implemented part of a CSS engine to theme custom canvas-rendered components.

Based on these experiences, I’ve found that the native + CSS approach works really well. After all, it’s really just a fairly simple labor-saving short-cut. Both iOS and Android apps generally store the user interface as declarative metadata that is instantiated into a UI component graph at run-time. Whereas no one I know modifies this metadata manually in the iOS community, editing this metadata by hand is the standard approach for Android developers. CSS gives both sets of developers a tool to centralize the style-based metadata and to bulk apply styling rules across multiple components (and potentially across multiple screens) in one go. That’s a clear win.

Even if the UI is dynamically generated through hand-coding, the CSS approach can still work. It can be applied before the interface is displayed, and again after it is displayed for dynamic effects.

Update: It’s also worth mentioning that both Adobe Flex and the QT project have incorporated CSS-inspired features into their platforms (thanks to the commenters below for pointing this out).

Why It’s Useful

This approach opens up a few interesting use cases:

• Making it easier to customize a single UI for various different contexts; a more flexible form of conventional UI internationalization techniques
• Making it easier for non-developers to customize the design of native screens. The Pixate team has visions of integrating their engine with Photoshop, etc. Hey, if this happens, great. But allow designers to iterate in the CSS file directly is pretty interesting on its own.
• Creating app prototypes
• Dynamically changing user interfaces after app deployment. A huge advantage of the web over native is the ability the change the UI from the server. By serving the Pixate CSS to the app at run-time, the app’s UI can be changed in interesting ways without an app update. Lots of native developers have hand-rolled their own mechanism to do this, but it’s handy to have a general tool like Pixate for the job.

What Pixate Is Not

Pixate is not, and/or in my opinion should not be:

• An attempt at using HTML/CSS to create native user interfaces.
• An attempt to allow you to reuse web-based CSS files for native apps. The set of CSS attributes that a browser supports will be different than the set that Pixate supports. There may be some common attributes, but I don’t anticipate the overlap will be meaningful.
• A way to develop UIs once for both Android and iOS. I don’t want the Pixate team to waste a lot of time figuring out how to map disparate attributes for kinda similar Android/iOS components into the same CSS attributes. Cross-platform leverage is a non-goal. Let the Appcelerator folks figure out how to map Pixate into the same concepts–in fact, it may make sense to have an Appcelerator-specific grammar for Pixate. That would be really cool.
• Some kind of cross-platform development toolkit that blocks developers from developing their native apps the same way they always have. (Sure, developers will have to make some minor accommodations to incorporate Pixate, like including the lib and perhaps occasionally giving UI components a unique identifier.)
• A silver bullet. Sometimes it doesn’t make sense to apply static, declarative CSS to a native UI. That’s okay.

Furthering the State of the Art

I believe that we should support innovative tools creators in our industry. When projects come up that represent interesting attempts to further the state of the art, I try to be one of the first ones in line to buy licenses and support the projects, just like many other folks I know. I’m proud that ‘Labs has been able to sponsor Pixate so generously.

And perhaps it goes without saying, but in case it doesn’t: we’re always looking for great talent and we’re doing some really cool things in on-line and in-store commerce. Drop me a line (beng@walmartlabs…) if you’re interested in joining us.

28 August ’12 Update: Made some minor grammatical corrections and added the Flex / QT mention above.