Chameleon for Nimbus

Chameleon brings real-time CSS styling to your iOS applications. Good bye long compile times. Good bye re-installs and good bye re-navigating to the changed view controller. Say hello to seeing your changes reflected in real time.

I’ll let the demo video do the talking.

The Tech

Chameleon was fun to build. In summary: it works by detecting changes to CSS files in your project, notifying the app of the changes, and then sending the changed CSS files for the app to then re-apply to any related user interface components.

Chameleon itself is a node.js server that runs on your machine. The node.js server watches changes on a folder that you specify when you start up the server. For example:

> node chameleon.js --watch ../../../examples/css/CSSDemo/resources/css/

Once Chameleon starts, you make a request to the server’s /watch endpoint. This request will only complete once Chameleon notices a change on the filesystem. An example result might be something like:

root/root.css

It is then the request initiator’s responsibility to request the new files from the server via /root/root.css. This will immediately fetch the most recent CSS file from the ../../../examples/css/CSSDemo/resources/css/ directory. In this case it would download the contents of ../../../examples/css/CSSDemo/resources/css/root/root.css.

How Nimbus uses Chameleon

In the demo app from the video, the watch request is initiated by a class called NIChameleonObserver, part of the new Nimbus CSS feature. In the demo we initialize an observer and then tell it to watch skin changes from the Chameleon server.

_chameleonObserver = [[NIChameleonObserver alloc] initWithRootFolder:@"css"];
[_chameleonObserver watchSkinChanges];

The observer will then post global notifications for specific stylesheets when they change. In the case of the sample app discussed in the video we had a root view controller and a corresponding root stylesheet, so the listener looks like this:

// Fetch the global chameleon observer.
NIChameleonObserver* chameleonObserver =
  [(AppDelegate *)[UIApplication sharedApplication].delegate chameleonObserver];

// Fetch the Nimbus stylesheet object for the given file.
NIStylesheet* stylesheet = [chameleonObserver stylesheetForFilename:@"root/root.css"];

// Start watching changes for the stylesheet.
[[NSNotificationCenter defaultCenter] addObserver:self
                                         selector:@selector(chameleonSkinDidChange)
                                             name:NIChameleonSkinDidChangeNotification
                                           object:stylesheet];

We then simply implement the chameleonSkinDidChange method and respond accordingly.

- (void)chameleonSkinDidChange {
  [_dom refresh];
}

_dom here is also part of the new Nimbus CSS feature. It is the beginning of what will soon be a fully-featured DOM object for applying styles to views and laying out views using the standard box model.

Rationale behind building this feature

I built this to scratch my own itch. From my work at Facebook and now at Google I’ve been finding that a large amount of my time has been wasted waiting for builds to compile, even when I just need to make a change as simple as “make that text blue rather than black”. This frustration is surely echoed by anyone who has had the unfortunate task of doing a clean build of Three20. Thanks to the way the Nimbus framework is set up, anyone can use Chameleon in their own project simply by adding the Nimbus Core and CSS components and nothing else! It really brings home the mantra of “stop compiling, start building”.

The idea was originally tossed out on the Nimbus CSS task thread. I’ll have to message Rog about the fact that I’ve just gone ahead and built this! That’s what I get for waking up early on the weekend and working on this before Canadian turkey day when I should have been running errands.

Supported CSS properties as of Oct 13, 2011

The Nimbus CSS feature only supports a small number of properties so far but this number will only grow with time. For version 1 of the CSS feature (likely going out in Nimbus 0.9) the CSS feature will not support properties such as padding and margins.

UIView {
  border: <dimension> <ignored> <color> {view.layer.borderWidth view.layer.borderColor}
  border-color: <color>       {view.layer.borderColor}
  border-width: <dimension>   {view.layer.borderWidth}
  background-color: <color>   {view.backgroundColor}
  border-radius: <dimension>  {view.layer.cornerRadius}
  opacity: <number>             {view.alpha}
}

UINavigationBar {
  -ios-tint-color: <color>     {navBar.tintColor}
}

UILabel {
  color: <color>                  {label.textColor}

  font: <font-size> <font-name>   {label.font}
  font-size: <font-size>          {label.font}
  font-name: <font-name>          {label.font}

  /**
   * Can't be used in conjunction with font/font-name properties. Use the italic/bold font name
   * instead.
   */
  font-style: [italic|normal]     {label.font}
  font-weight: [bold|normal]      {label.font}

  text-align: [left|right|center] {label.textAlignment}

  text-shadow: <color> <x-offset> <y-offset> {label.shadowColor label.shadowOffset}

  -ios-line-break-mode: [wrap|character-wrap|clip|head-truncate|tail-truncate|middle-truncate] [label.lineBreakMode]
  -ios-number-of-lines: xx             {label.numberOfLines}
  -ios-minimum-font-size: <font-size>  {label.minimumFontSize}
  -ios-adjusts-font-size: [true|false] {label.adjustsFontSizeToFitWidth}
  -ios-baseline-adjustment: [align-baselines|align-centers|none] {label.baselineAdjustment}
}

FAQ

Why not use Interface Builder/why use CSS at all?

First off, not everyone uses Interface Builder. For those who do, there are a lot of similarities between using Chameleon and Interface Builder. Where Chameleon comes out on top, though, is in making it dead easy for anyone with a background in web design to style an iOS application. All it takes is understanding how CSS works and you’re good to go. CSS also comes with the advantage of cascading styles. You can define styles for an entire class of views and therefor reuse the styles throughout your application. Make a single change to a shared css file and suddenly your entire app’s style is updated.

Imagine this. As you are working on the app at your desk, the designer has an iPad propped up next to their laptop on the other end of the office. As you’re making modifications based on the new mocks the designer just sent you, the changes are being reflected in real time on the designer’s iPad. Talk about cool.

When are you releasing this?

Hopefully by the end of this week. I haven’t moved up to the city yet so I’m still relatively devoid of anything to do at night down here in south bay (damn is it boring here) so I predict that I’ll have tomorrow night to focus on documenting and releasing Nimbus 0.9 complete with Chameleon and CSS.

If I don’t get it out tomorrow night though then it might have to wait until next week because I’m planning to go to the Treasure Island music festival this weekend. I haven’t been to live music in way too long.

Either way, look forward to getting your hands on this code shortly! As always it will be Apache 2.0 licensed. If you have any questions about Chameleon or Nimbus or why the hell I’d be in South Bay feel free to shoot me an email or @reply me on twitter: @featherless.

First order of business, I want to make it publicly known that I have taken a job working at Google on their mobile team. I will be doing backend work which will be a refreshing change from the contract iOS development I’ve been doing for the past few years.

This does not mean that I have stopped all iOS development. If you haven’t already seen my Nimbus project then I encourage you to take a glance at it when you have a moment. I am planning to continue work on Nimbus by dedicating a chunk of each morning to it and my various other iOS open source projects.

In other news, I’m excited to announce that Nimbus passed 500 followers over the weekend on Github! I’m really excited about this because this project is still in its infancy.

On Leaving Facebook

I learned a lot during my time at Facebook. Facebook is truly an exciting place to work at and I am sad to have left. I had the great privilege of working closely with some of the best designers in the industry and shadowing David Recordon as we looked into the possibility of me working on their open source team. I spent a significant amount of time thinking about what I wanted to do and decided in the end that I needed to switch things up and step away from Facebook.

I wish them the best of luck going forward. Timeline was an incredible launch and I look forward to following the company’s progress.

If you’re coming here from any of the press earlier today, I want to emphasize that my experience with Facebook over the past few years has been incredible and that I was simply recounting my experiences over the past few months related to my work at Facebook.

Oct 10, 2011 Update

And the iPad app is live! Congratulations to the talented team at Facebook that got this out the door. It’s great to see it in the wild!

Cheers,
- Jeff

Here are some of the arguments posited against Three20 lately and my corresponding rationales behind why the modular design will begin to solve them.

Give me what I need, no more, no less.

Three20 is a massive library. Due to the way it was originally created, many of the components of Three20 have interdependencies that, today, make it impossible to pull out single components and use them in your app. For example, if you want to use a TTPhotoViewController, you currently need to import every single line of Three20 code to do so.

There’s no reason that this should be the case. If I’ve already built an application and all I want to do is add a launcher, there is absolutely no reason why I should have to include the entire Three20 library to do so; I just want to add a Three20Launcher module, that’s it.

Even if I’m starting from scratch, it would be much easier to grasp Three20 if I could start from some basic components and add more modules as I need them, rather than having to wade through the entire library to begin with.

A modular design puts the choice into the developer’s hands about what they want to use in their project.

Three20′s documentation sucks

Pulling apart the library into separate modules is going to make it much easier to document the library. The primary obstacle to documenting Three20 right now is that it’s just so goddamn confusing. If the lines in the sand are drawn more clearly between components, it will be much easier first off to comprehend their usefulness, and second off to convey their usefulness.

Three20′s xx feature is outdated by Apple’s yy library

Another argument posited on Twitter today and in the past is that Three20 is outdated, that many of its components have been deprecated by technologies that Apple has included in newer APIs.

This is true. TTStyle, for example, provides functionality that overlaps with CoreText.

But this just furthers the argument for pulling Three20 apart into separate modules. Why should anyone be forced to use TTStyle if they want to use aspects of Three20 but use CoreText for their text rendering? With the new modular design, you’ll have that choice.

An ecosystem of extensions

My long-term vision of Three20 is to see it become a vibrant ecosystem of extensions provided by the community. The only way this could be possible is if we allow projects to be distinct from one another.

tl;dr Summary

Three20 has its share of issues. But I firmly believe that it’s only advantageous to discuss how broken something is with an equal or greater amount of discussion on how to fix it. Some developers are quick to point out the broken components of Three20, but these components are fixable.

And that’s what I plan to do.

Cheers,
- Jeff

That’s why I’m going to take a bit to go over some of the useful things I’ve been finding lately.

Gmail hotkeys on crack

If you use Gmail labels (and you really should), then you’re going to love Gmail hotkeys. I’m not talking the basic stuff, like ‘c’ to compose a new message, or ‘r’ to reply to one. I’m talking full-blown keyboard control of your inbox.

You can use the ‘J’ and ‘K’ keys to move down and up in the inbox, respectively. This will move that little arrow guy on the left edge of your inbox list. I’m going to call him the ‘caret’.

You can press ‘X’ to select or deselect the caret’s current conversation. Once you’ve selected some conversations, you can press ‘L’ to add a label. Simply type the name of the label you want to add and hit enter, and your selected emails will be updated. Now that you’ve labeled your emails, you can hit the ‘E’ key to archive them.

DTerm – Terminals everywhere

The terminal is one of a hacker’s most important tools. Now you can access it everywhere with DTerm, a nifty little utility that allows you to open a terminal at the current program’s working directory. Don’t miss out on that crucially cool little feature of it; it runs from the working directory.

If you use TextMate, for example, and you have a file open, compressing that file’s directory is as trivial as pressing Command+Shift+Enter and typing your favorite compression incantation. Or maybe you quickly want to check out a man page, hit the global hotkey again and man up.

Highly recommended: Download DTerm for free

Block Selection in TextMate

You might have already known that you can block select text in TextMate by holding the Option key and selecting with your mouse. But this short little video could save you a lot of time in the future.

The YouTubez

It was 30%.

Never in the history of my academic career had I received a midterm mark below 50%, but this 30% wasn’t a shock to me. I had been spending nearly all of my time outside of the classroom working on what would soon be one of my largest projects to date, the Strips platform.

When I saw the failed mark on my midterm I took some time to think, as anyone should do when this sort of thing happens. I came to the conclusion that I had reached a point in my academic career where I strongly believed that I had the chops to build something, and that I needed to do it right then.

So I took the plunge. I dropped three of my four courses and spent the next three months working full time on the Strips platform.

This is its post-mortem, and I hope to leave this as a note to myself and anyone else who has the desire to build something.

The Strips Platform

The basic one-liner for Strips is this: a mobile application that puts syndicated web comic content into the palm of your hand. In more detail, it’s an iPhone app with all the flair of a native Apple app, and all the content of your favorite web comics. It had pinch-to-zoom, double-tap-to-zoom, offline reading, push notifications (for when new strips were available), archive viewing and searching, social network sharing, the ability to email strips to friends, alt-text viewing, and landscape reading modes. You name the feature, Strips probably had it. It even let you shake the phone to pick a random strip.

But that’s just the part the customer saw. In the backend I had built an entire architecture for aggregating content from RSS feeds, pushing the data to an Amazon S3 tier, and even used Google’s App Engine for housing all of the push notification information. This meant that the entire web comic’s content was mirrored on a scalable storage solution (S3), inflicting zero cost to the publisher except the initial cost of archiving (which is equivalent to the cost Google’s spiders incurs). So as far as the web comic artists were concerned, Strips caused zero-impact to their existing infrastructure.

The biggest question about Strips was mostly about how the artists were compensated. Obviously it would be stupid of me to rip these artists’ content out of their ad-driven websites and display it on the mobile device ad-free. For many web comics, the ad revenue is their butter. Merch sales are often the bread, and their readers love buttered toast (who doesn’t?). And for many web comics the analogy is reversed. Regardless of where they make most of their revenue, it was crucial to recognize the fact that ads were part of this ecosystem.

To address this problem, I built ads into Strips that were served on a per-publisher basis. This meant that whenever you were reading strips from Penny Arcade, the revenue from the ads that were displayed would be given on an 80/20 split to Penny Arcade. The 20% cut was calculated to cover my personal costs of bandwidth and servers (and is a damn good deal by most publishing house standards). I also built in detailed analytics so that web comic artists would be completely aware of how many users were viewing their content on Strips, for how long, and even how often their content was shared. This data was all anonymized, of course.

Here’s the basic Strips platform so far.

• An iPhone application, Strips
• Automated S3 data duplication for all of the publisher’s content
• Ad-revenue model for artists
• Analytics for artists
• A push notification service (within minutes of new content being posted, your phone would buzz)

From the beginning of Strips’ development, I knew that this product would only reach its maximum potential with support from the artists themselves. I began a campaign of sending emails to artists that started with a number of the bigger players. I sent a general email with a customized “pitch page” showing their content in the iPhone interface.

Feedback was abysmal. Of the 15 or so comics that I initially emailed, only three responded, two saying they didn’t want to be a part of it. The other was incredibly interested. And so even with the abysmal number of responses, I had my first client.

My excitement started to brew.

By mid-July, I had my first working version of the application ready for beta testing. The initial reviews from users were quite positive. People loved the intuitive interface and the ability to read their comics in a consistent, convenient format. They didn’t have to trough through multiple websites with varying navigation methods just to read their favorite comics anymore.

By this time I had sent out emails to a dozen more web comic artists and still, no word. So I continued to work on the project, hoping that I would soon receive word one way or the other from anyone.

August came and went, and I was on my way to my last co-op term for school. Strips was a completed product and submitted to the App Store for review. The first submission came back rejected, as I expected, and I fixed the minor issues and resubmitted. This process eventually involved four submissions and three rejections, with the final acceptance of my app into the App Store nearly a month and a half later.

All throughout this time I was actively emailing the artists. I sent a second round of emails to the artists who still hadn’t responded to my first round, letting them know about the new analytics system and the ad model. Still no answer.

At this stage I had a fully working platform ready to be launched on the App Store. The entire platform was built and designed to be as low-impact to artists as possible, costing them near-zero in bandwidth, while bringing a whole new set of readers to their content. So I decided that since the entire platform was a win for the artists in every possible way, I launched it. What could possibly upset them, right?

So Strips launched as a paid app at $1.99. It launched as a paid application because my rationale was that it was a reader, just like the Kindle or the Nook is, or any RSS reader for that matter. You pay for the device to read the syndicated content and then you can pay to read specific items available on the device. This seemed sensible to me as I’d put a large amount of effort into the application.

The app was live for a little over a month and a half, and sales were trickling in. By October I had sold about 200 copies of the app at $0.99 and 50 copies at $1.99. The user metrics were what really impressed me, though. From the aggregated analytics, I found that most users were spending on average about 45 minutes to an hour every day using Strips. I was excited to let the web comic artists know about this amazing statistic.

In late October, on the 26th to be precise, Scott Kurtz of PvP finally noticed Strips. Sadly he noticed it in the one light I never imagined it would be seen in: as theft.

That Monday I began the day like I began most days at the time, on my way to work I opened Tweetdeck and checked out all of my twitter filters for any talk about Strips or any related subjects (web comics, webcomics, iphone web comics, etc…). I was receiving dozens of tweets per minute to my @stripsapp account, declaring that I was a thief and should be tossed in jail. Around that same time I received an email from Scott Kurtz himself, demanding that I remove his content from the app immediately, which I did. I then engaged in a draining campaign to contain the fires that were popping up all over twitter and the blogosphere.

I realized quite quickly that the public opinion of my app was lowering, and fast. With the heat of a number of popular web comic artists on my neck, I quickly began pulling the plug on the live apps. I had thankfully designed functionality into the platform from the get-go that let me add and remove comics on the fly, even for existing installations. Once the content from all of the artists had been removed, I removed the Strips app from the App Store and posted an apology to the Strips website. Over the next 24 hours I received countless emails and tweets from prominent web comic artists calling me a thief and a criminal, and some threatening legal action against my part.

I was scared shitless.

To have the entire community that I had spent the five previous months working to help turn on me hit me pretty hard. After the fires had calmed down and I’d stopped receiving hate letters I came to the conclusion of one thing. If you’ve been reading up this point, then you’ll be happy to know that this is the biggest, most important thing that I learned from this, and will never forget.

It’s really fucking hard to run a company as just one person. Don’t let the obviousness of that statement make it seem trivial. Never, ever, underestimate the value of having someone else to double-check your decisions and to challenge your thoughts on a day-to-day basis.

So let’s get into the more structured part of the postmortem, shall we?

What went right

Though Strips ended in a fiery crash-and-burn, the personal experience I gained from this project was unmeasurable. If there is ever a point in my life where I think I will someday look back and say “that, that right there; that’s when I got my shit together”, October 26th 2009 was that day. I needed a solid kick to the head to make me stop thinking that I could one-man-show every project I worked on. I’d become complacent in my passion, and I needed to snap back to attention.

Strips was also a great technical landmark in my personal experience. I proved to myself that I could build a fully-functional platform from the ground up, that I could do it in record time, and that I had somewhat of an idea how to scale it.

The development track of Strips followed the track of most of my software projects: rapid iteration and fast prototyping. I was able to build the first working prototype within the first week of development and by the end of the first month had three web comics supported on the platform. Over the next month I increased that number to 20 and built a full push notification service that operated in near real time (a sneaky way of saying that I just polled the RSS feeds on a regular basis).

I also had a great pool of testers throughout the development of Strips. I set up a Google group and had an active mailing list with which I got a solid amount of feedback.

What went wrong

The single largest mistake I made was to launch too early, before I had received complete consent from all of the artists whose content I supported. The irony here is that as of January 9, 2010, Comic Envi is still available in the App Store as a paid app, and they blatantly pull the web comic’s content into their app with no ads or any mention of support from the original artists.

I also made the mistake of assuming that artists would see the value of Strips the same way I did. I worked hard to convey to the artists every way in which they’d receive revenue and analytics, but at the end of the day their first impression turned out to be far from what I’d imagined. This was largely my fault, and some part sensationalization on twitter. I shouldn’t have used the artists’ logos on the web site as a way to say “hey look, these artists are supported by Strips”. A gradual roll out of Strips with only the supported artists along the way would have kept the project alive and hopefully generated enough momentum over time to convince the larger players that it was a viable platform.

I’ll quickly explain where the hell the name of this blog came from. I took part in a musical titled Leader of the Pack during my 12th year of education. Thanks to Google’s book scraping, I can actually point you to the exact line I elocuted while crossing right, downstage of Jeff. I had one line and I got to wear cool shades. It was good times.

I think I may write my blog posts like my git commits. Mostly atomic, but oftentimes a ménage à trois of sorts. Sometimes I might cherry-pick posts from other blogs of mine, and sometimes I might, gods forbid, rewrite history. I’ll try to keep that last one down to a minimum.