Instead, I thought I’d update the curious on our future. About the change of plans, I’ll just say that finding and buying a solid house is harder than it looks.

Starting next week, I will be working as Head of Product and Design for Bloomberg.com. I probably can’t say much about it right now, but, to borrow a (trademarked) phrase from some friends down in SoHo, it’s gonna be awesome.

Though my days won’t be spent heads-down in a debugger, I’m excited to spend my free time picking up long-delayed side projects. Expect updates here on both iPhone and web stuff, as well as more of my standard UX, tech, and strategy ranting.

Today is my last day at the most fun, creative, weird, and politically-incorrect digital advertising agency in the world. Everything is mutual, long-planned, and awesome. It’s been hard keeping a secret for the past couple of months, but today is the day!

I’ll write something longer, with details about the future soon! For now, I’m trying to finish up some C++ code!

Check it out: Cartilage.

Add it to your Monk set up with the monk command.

monk add cartilage git://github.com/tobyjoe/cartilage.git

Once it’s added, create a new project with the monk init command.

monk init --skeleton=cartilage myapp

Once that is done, freeze all the dependencies.

dep vendor --all

Easy as pie, right?

Contributions

I want to add optional memcached support to both Cartilage and Lazybones.

If you see anything wonky, fork it and let me know, or just leave a comment or file an issue at the GitHub issue tracker.

Cartilage is based on the original skeleton that ships with Monk, by the way.

You can find the project over at GitHub.

Check it out: Lazybones.

Add it to your Monk set up with the monk command.

monk add lazybones git://github.com/tobyjoe/lazybones.git

Once it’s added, create a new project with the monk init command.

monk init --skeleton=lazybones myapp

Once that is done, freeze all the dependencies.

dep vendor --all

Easy as pie, right?

Contributions

I am working on skeletons for Postgres and MySQL as well, and adding optional memcached support to all of them.

If you see anything wonky, fork it and let me know, or just leave a comment or file an issue at the GitHub issue tracker.

It’s based on the original skeleton that ships with Monk, by the way.

The question is obvious for mobile projects because highly variable environments are par for the course. It matters with all non-stationary touch points, though – from door handles on train cars to Android applications to the work we’ll surely be seeing from the new Schematic Touch group.

Asking the question is easy. Using the response may not be. I see mobile apps all the time that are clearly made for users who are stationary, physically stable, connected to a consistent network, and with both hands free for interaction. High demands, right? They conflict with my more common usage patterns, and those apps rarely get launched.

A great example of a more subtle conflict – and one being addressed without much fanfare by many app developers – is iPhone usage in bed and auto-rotation.

Welcome to My Boudoir

My wife and I are incredibly lame. We tend to lie, side by side, reading news on our iPhones before falling asleep at night.

Apps that auto-rotate when the device orientation changes suck in bed. Or on the couch. Or in a reclining seat in first class. Or in a hammock. You get the point.

The problem is that we all flip-flop all over the place in bed (va-va-va-voom!), changing the point of reference for orientation. What makes a lot of sense when we’re upright is a pain in the ass when we’re horizontal.

A Suggestion

I’d like to encourage developers to carefully consider auto-rotation. A lot of devs are starting to catch on to this one as customers complain or make feature suggestions. I thought I might provide an example illustrating a really easy approach to disabling auto-rotation globally in an app. There are more sophisticated and pattern-y ways for the clever.

Don’t get me wrong – auto-rotation can be a great feature. I am all for it. But I have decided the baseline rule should be: If your views auto-rotate, you should provide a (preferably in-app) preference for disabling the feature.

An Example

So how does a developer do that?

Well, the interface is up to you. Let’s assume you have a project with a button that brings up an in-app settings screen.

If you have a UISwitch in there that represents the global auto-rotation state, just save it to the user defaults when you close the settings.

- (IBAction) dismiss:(id)sender
{
	// Update the defaults.
	NSUserDefaults *defaults = [NSUserDefaults standardUserDefaults];
	BOOL autoRotationEnabled = self.autoRotationSwitch.on;
	[defaults setBool:autoRotationEnabled forKey:kAutoRotateKey];
	[defaults synchronize];

	// Close!
	[self.parentViewController dismissModalViewControllerAnimated:YES];
}

In your app delegate, declare a method to get the current global auto-rotation value.

- (BOOL) shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation
{
	return [[NSUserDefaults standardUserDefaults] boolForKey:kAutoRotateKey];
}

Finally, in each view controller that should obey the globals, ask the app delegate for the scoop.

- (BOOL)shouldAutorotateToInterfaceOrientation:(UIInterfaceOrientation)interfaceOrientation
{
	PillowTalkAppDelegate *appDelegate = (PillowTalkAppDelegate *)[UIApplication sharedApplication].delegate;
	return ([appDelegate shouldAutorotateToInterfaceOrientation:interfaceOrientation]);
}

Here is a quickie example project that illustrates the concept: PillowTalk.zip

Here is a patch for the Erlang Portfile that will let you build on pre-GM 10.6.

Save the patch to ~/Desktop/erlang.diff

Patching icu

You might also have to patch icu. To test, run:

sudo port install icu

If it errors, grab the unified diff patch file and save it to your ~/Desktop as “icu.diff” and run:

cd /opt/local/var/macports/sources/rsync.macports.org/release/ports/devel/icu

sudo patch < ~/Desktop/icu.diff

sudo port install icu

Patching Erlang

To run the Erlang patch and install the port, just do the following:

cd /opt/local/var/macports/sources/rsync.macports.org/release/ports/lang/erlang

patch < ~/Desktop/erlang.diff

sudo port install erlang

CouchDB?

I can get CouchDB to build, but not to run. I think I'll let someone else solve this one. Maybe you?

Still, I like two things about this blog post about their Office web apps.

First, I like that they are officially focusing on (admittedly, a subset of) modern browsers for their very dynamic web apps. Developers and designers at Microsoft are just like the rest of us, after all: they want to do great work and hate clunky platforms and unfortunate constraints. Bravo for continuing the baby steps forward.

Second, I like that they aren’t blocking or filtering user agents. They are offering “unofficial” support to semi-modern and modern browsers. They aren’t showing upgrade notices that make users feel like losers. They aren’t blocking access as some goofy religious mission. They’re just being practical.

From the post:

If you prefer to use another browser you should still give the Web Apps a try. While we cannot officially support all browsers, customers will not be blocked from using them. It is a goal of the Web Apps to have broad compatibility and reach.

I hope (oh dear lord am I gonna say this?!?) others can follow in Microsoft’s footsteps here and be respectful to users.*

* Yes, I also know Microsoft isn’t the first to do this. I’m being snarky.

It’s shorter than I would have liked, and took longer to write, but it’s nice to have it in my hands.

You can buy it at Amazon.

I killed a good chunk of time at the bus station listening to an episode of FLOSS featuring David Heinemeier Hansson. For those not in the know, he’s the very bright and ambitious gent behind the Ruby on Rails framework.

FLOSS stands for “Free, Libre, Open-Source Software” and is a great way to either catch up on OSS you may not have encountered in the wild or dig into the people behind OSS you already use.

My Rails History

I was a really early adopter of Rails for professional work. Having spent my time with Struts and similar frameworks – the inspiration for Rails – I saw the familiar patterns and liked the quick bootstrapping. The Barbarian Group was, as far as I know, the first advertising/marketing shop to deploy Rails apps – back in the 0.12 days. I wrote an early intro article about Rails in .net magazine and was scheduled, along with the former CTO of the company, to speak at the first RailsConf, in Chicago. (Unfortunately, some sudden staff changes at TBG forced us to cancel.) So, yeah – to paraphrase a t-shirt, Rails had me at, “Hello, world!”

I always loved the full-stackiness of Rails: from the generators, to the testing tools, to the console, to the plugins and helpers. It’s great to go from concept to boilerplate in under an hour. The Rails folks inspired people, divided the fuck out of people, and helped make OSS contributions massively hip. All in all, I’m really glad Rails came about and objectively support most of the hype.

Gripes

Subjectively, over time, I got pretty frustrated with Rails for the type of work I was doing. It’s really great for start-ups and clean room builds, but was always a little inflexible when special considerations popped up. For a long time, fitting Rails projects into larger ecosystems tasted quite strongly of vinegar. There is an amazing amount of flexibility in Ruby, and hot-patching the shit out of Rails is very easy. There’s a point at which you kind of pause and ask if you’re building on the wrong foundation for the job at hand.

For a long time (and maybe today), that kind of question would get you tarred and feathered in the #rails world. I got sick of the quasi-religious bickering between “Rails developers” and “web developers” at large and dropped out. Drama around a web framework? No, thanks.

We still run Rails projects and use it often, but we do so with a certain emotional detachment. We also do our best to be agnostic, which means giving an honest evaluation to the decision of a toolset for each and every project.

When we do pick Rails, we try to focus on the engineering and ignore the drama in the greater community. This has always meant, in large part, ignoring DHH and almost every Rails blogger out there. That choice means I occasionally miss out on some true gems (heh) of knowledge or interesting arguments, but I’ve rarely regretted dropping out of the conversation.

Enter FLOSS

I thought DHH did a killer job on FLOSS. He’s one of those folks who comes across one way in print and another in person. It’s not an inconsistency as much as a lack of nuance in the written form. I’ve never liked the written form of Mr. Hansson but he and Randal Schwartz had a blast during the interview and it was very endearing.

So DHH got me inspired about Rails again. Not converted to the golden path or anything, but a renewed interest in the future of the framework beyond keeping a competency for client needs.

Getting Sidetracked

As an aside, he also made me wonder if he really understands the architectural style he promotes so heavily: REST.

In the podcast, he explains REST to Randall Schwartz (the host) by describing “the four verbs” used to operate on resources. It seems like he’s still confusing CRUD with REST. Oddly, the Rails source doesn’t really make the confusion.

Maybe this explains little mysteries, like the default Rails asset helpers appending “cache buster” query strings to support files (like Javascript, CSS, and images) in production environments. REST is about using HTTP to the fullest – including caching.

It could be that he really understands REST, but chooses to dumb it way down for his audience. That seems a bit risky, though. Developers hate that.

Getting Real?

In either case, I won’t get too wrapped up in the dude. I will say, kudos to adding some much-needed sugar to balance out the vinegar. Rails PR could use some attention and clarity along with a taming of the “opinionated software” side of things.

I hope the conversation around Rails stays creative but keeps growing up – even if DHH wants to avoid being too “professional.”

Yes, creating cross-browser experiences can be painful when support for Internet Explorer 6 (IE6) is required. There are dozens of hacks to get around certain issues, and it is possible to design experiences that are functionally identical on IE6 and more modern browsers. It may mean designers don’t have carte blanche, but that should be fine if their companies or clients mandate full IE6 support. Any good experience designer can work within constraints and still kick ass.

Still, a lot of folks are lobbying their companies, clients, and partners to drop support for IE 6.

My issue is how they’re doing it. The more dickish folks are throwing up an insulting roadblock, patronizing IE 6 users.

A more practical approach is to encourage users to upgrade with prominent, consistent notices. This angle isn’t terrible, but still alienates users and disrupts the experience for those users almost as much as a modified or “broken” IE6 experience. It’s just not friendly, or consistent with the brand message that usually mandates an identical UI across target browsers.

Another Option: Boring but Practical

My suggestion is to take this to the contracts. Redefine the word “support” as it applies to user agents (like browsers). Look at the cost/benefit of all types of support for all types of user agents. This should be a part of your business modeling.

Instead of refusing content to IE6 users or breaking brand guidelines by disrupting their experience with a patronizing notice, why not relegate them into a tier of Content-Level Support as opposed to Design Support?

Good sites already do this with a stylesheet for print: we don’t penalize printers for their lack of a good box model. The same is true of screen readers and most RSS readers. Maybe you can think of IE6 as a perfectly viable user agent for consuming content, but cost prohibitive for rendering top-tier experience design. Serve your print styles to IE6 if you don’t want to offer design support. Or serve a basic white-on-black stylesheet. Or no stylesheet. Pretend IE6 is the Googlebot or JAWS or any other non-graphical user agent. Just don’t punish people or talk down to them.

Channel Your Frustration Properly

You don’t have to be a dick to your less-endowed users. Shift them, officially, to a tier you, your clients, your company, and your partners agree upon and move on. Just make sure you’ve built an economic model that includes the IE6 users and estimates the cost of all possible decisions. Look at the realities of IE6 users of Digg to understand the complexities facing the people your cocky designers and lazy developers want to patronize or abandon.

Justify relegating IE6 with real numbers or choose to give it design support and force your designers to work within the constraints. They do get paid to work, after all. If they can’t create great experience design that doesn’t fuck over the people coding those experiences, fire them. Hire designers who understand browsers.

No matter what you do, keep your users’ needs first. They’re the ones you can’t replace.

A Great Resource

A few months back, I started up a GitHub project to create a baseline CSS file for all legacy browsers. Around the time I got contributions from folks at work, I found out about similar (but completed) projects out in the wild. One such project can be found here: http://code.google.com/p/universal-ie6-css/.

Who wouldn’t jump on a goofy bandwagon to get those kinds of numbers? Engagement rates of 0.00015% are a sure sign this Flash-based AR thing is going to take off. Or am I reading that wrong?

Read more on Flash-based AR in advertising.

Generally, the presence of brands and their representatives on social sites is well-tolerated. Everyone is used to the fact that brands are jumping in. We consumers have large, high-res displays and we’re great at building selective blindness. When brands participate in social media, though, we don’t necessarily need that blindness. They’re automatically invisible unless we want to see them.

The Honeypot

A honeypot is an attractive trap used to embargo a threat. In information security, a dummy server might be placed on the periphery of a network and left somewhat hackable. The dumber crooks break into the honeypot, thinking they’ve silently compromised a network, only to be kept at arm’s length and watched. A thriving, sensitive network might exist right behind the honeypot, but the attacker never knows. He’s satisfied with himself for breaking in and stealing (what he thinks are) the keys to the castle.

On social sites, we only engage with brands if and when we want to. We don’t bother following @zappos if we don’t want to interact with Zappos. The model keeps the power dynamic shifted the way it should be: in the favor of the consumer.

In a way, a brand presence on Twitter is the antithesis of display advertising. Rather than covering every visible surface in a shotgun effort to sneak into the minds of consumers, social media advertising is more passive.

Twitter and Facebook are honeypots for brands, keeping consumers protected from the annoying noise we see everywhere else. We reach in and pull them out when we want, but otherwise keep them at bay.

Twitter is better at this role than Facebook because Twitter lacks display ads. I think that fact alone makes us love Twitter, where we simply tolerate Facebook.

An Olive Branch

So, to brands, I say, welcome. Don’t screw it up, and don’t speak unless you’re spoken to. You’re not “going where the conversation is happening” – you’re going where people are, and letting them talk to you if, when, and how they prefer. Play by the rules and you will, over time, build a community. You’ll earn a voice. Just don’t be insulted if we tune in and out at will. It’s better for all involved.

An Example

Ok, so R/GA is about to bring Taco Bell all up in our grills on Facebook and Twitter. God save us from the chalupa and volcano nachos.

Luckily, I can opt out by not opting in. We all can.

It feels good, doesn’t it?

I think iTunes has become the main interaction platform for Apple. Given the popularity of the iPod line and iPhone, combined with iTunes for both Windows and Mac OS X, I’d bet more hours are spent using iTunes than Finder every day.

As with the App Store, Apple seems to be stumbling over itself with the iTunes experience. They need to slow down, reset, and rethink the experience promised by the Apple brand.

We know that iTunes is slow. The UI is inconsistent. The store feels completely alien to the main UI and experience. The app does far too much, plays too many roles too slowly. iTunes is more Wal-Mart than Apple Store.

People tolerate iTunes because it isn’t unbearable. It does work, after all. We all know the flaws I’ve mentioned and begrudgingly accept them because iTunes is the only choice we have. Another case of Software Stockholm Syndrome, I guess?

But here are two new (to me) insights.

1. iTunes focuses on multiple mobile devices paired to one computer rather than treating all Apple machines as peers. If nothing else, Apple should invert the model they currently use. Instead of one machine and one or more peripherals, they should focus on the more common case of one device and multiple computers.
2. Syncing a device to iTunes gets more painful every day, pushing users away from iTunes. Syncing a single podcast from iTunes to an iPhone takes fifteen minutes. It’s painful. This is a big threat the the Apple halo effect.

Mobile devices are for mobile people. Most of us operate in at least two computer-focused environments: home and work. Apple lets us buy, download, and sync content (apps, podcasts, audio, video) on a single computer, but on multiple iPhones or iPods. We still can’t easily add content – with or without DRM – to our devices from work and home. Aside from risky hacks to trick the phone into seeing multiple libraries as one, there are no practical ways to keep the whole digital lifestyle in sync.

My wife has stopped plugging her iPhone into her computer. In fact, she’s stopped opening her computer, save for writing posts on her blog. I asked why.

“I can do everything I need to do on the iPhone. I can get podcasts and music and apps, and iTunes freaking sucks, so why bother?”

The Apple lifestyle brand and experience is amazing when it’s strong, but like so many other things, it’s a bubble. iTunes is a thorn. Apple peripherals once caused a halo effect, but as they get better and iTunes gets worse, the iPhone and iPod Touch might cannibalize the Apple (desktop, laptop) computer market for lifestyle users.

If you are trying to raise awareness, forcing a user to work is generally a bad idea. You have to give users something of high value while minimizing their effort if you want to build a better reputation.

If your goal is conversion, you should be especially careful of the barriers to entry and usage. This seems obvious, but brands consistently require too much of users in their digital marketing efforts.

Augmented Reality in Ads

Industry rags and blogs have spent months reporting on a steady stream of augmented reality (AR) ideas in marketing ever since GE launched their Smart Grid AR site.

A recent entry into the pool is for Always Infinity. The site claims to show you a magic trick.

All you have to do is follow the instructional video and simple two-step process of printing a graphic out on a sheet of paper and holding it up to the camera while it superimposes the magic. What’s the magic in this case? A 3d animation of a rabbit in a hat. It’s cute, but fluff. The real magic trick is making 5-10 minutes disappear with nothing to show for it – including a greater appreciation of their new pads.

This is how most of these campaigns work. I think they’re mostly flops. They’re ideas pulled out of the bookmarks bar of a desperate art director, sold to a client as the next big thing, and supported by an industry press with a shortage of interesting topics.

There were two instances of this particular form of webcam-based AR in recent marketing efforts that were successful. The first was the aforementioned GE project. This was the first big brand use of AR and it seemed like advanced – if novel – tech coming from GE. It was cool and not overtly pushing a product.

The second was a project developed by AKQA for the United States Postal Service (USPS) that let users hold items up to their camera to find the best Priority Mail shipping box. The damned thing had a purpose, and used the tech in an interesting way.

Everyone else doing this stuff has been trying to fit in, adding to the noise. They’ve expected users to find inspiration in the declining novelty of webcam AR, put in the work of printing an image, engage in the theatrics, and eagerly send to a friend.

Instead of patronizing your audience, pushing this gimmick as new to them, why not find a real reward for engagement? Make the payoff ten times as valuable as the work users put in. Only the first project to use a gimmick gets to call the work itself the payoff.

Let me repeat my new rule to the consumer brands out there looking for gimmicks that make demands of people: If it’s easier to buy your product than to engage with your marketing, you’re doing it wrong.

Currently, systems deliver recommendations (like search results, products, or compelling content) based on two types of user input: explicit and implicit.

What You Tell the Robots

Explicit input is what you do to purposefully tune a system. You might opt out of tech news and opt in to sports. You might type in a couple of your key stock symbols. Explicit input is configuration. The cynical idea behind configurable services is that users will interact more with a tool they’ve spent time customizing. This can be true, but it can also alienate non-tinkerer audiences. More importantly, forcing someone to create their own portal removes any kind of authority from the service in question. It exposes the robot behind the curtain.

The Robots are Watching You

Implicit input is what you do without knowing you’re tuning a system. Where you click, what you search for, and what you ignore all contribute. Coming into a magazine site from a particular Google search might change the content you see on the page. Banner ads are usually served based on what you’re reading and what the ad network knows about you. On Amazon, anything you look at feeds into the recommendation system that shows you products that (may) interest you. In fact, I love pranking people by sending links to enema kits on Amazon. It pollutes their recommendations for a while. This is implicit input at work.

The Robots are Watching Everyone

An additional way that sites make recommendations is based on the stuff you tell them you want (explicit input), the stuff you show them you want (implicit input), and the input from other people like you. There are some sweet algorithms out there for determining that people are alike and using the tendencies of members in a group to recommend things to other members in the group.

In theory, the idea is compelling. Unfortunately, most of these algorithms end up turning individuals into caricatures of themselves or of their demographic group. It’s infeasible for a system to know enough about an individual to make consistently great recommendations. No computer will ever be able to recommend a book or a date or a pair of shoes with the same accuracy as a friend. More importantly, they can’t deliver the same accuracy as a casual acquaintance.

Humans can fill in gaps and infer rich meaning from subtle body language, tone, and personal experience. Those factors are noticeably absent in most online recommendation, search, and content delivery systems.

The Perfect System

I don’t think people want to interact much with systems to find information. Weird view, I know.

Some systems are certainly popular (Google) and and very successful (Amazon), but the affinity people feel for those systems is a form of Stockholm Syndrome.

What we all want is to have our grandfather (or an equivalent symbol of infinite wisdom and no-bullshit-taking) sitting on our shoulder, pointing us in the right direction at all times. We don’t need confidence in recommendations (of content, purchases, people) as much as faith. We want to Ask Jeeves, but we want Jeeves to have a clue – not a hundred page slush pile of possible hits.

Bad or boring recommendations lead to a lack of faith in recommendation systems in general and contribute to an overall fatigue. Recommendations need to inspire either confidence or faith. Confidence comes when you’re 100% accurate at all times. Faith comes when I feel like you understand me. Your “you might like…” recommendations are something I care about because I empathize with you. Confidence is for robots. Faith is for humans.

Enter Social Networks

There is a lot of potential in the networks of people we curate online, the reviews we write, the reservations we make, the choices we make on the spot in stores. The data doesn’t say who we are and how we feel, and no machine can step in to fill in the gaps and make the proper inferences.

The best system will have hints of the “#lazyweb” approach to Twitter. I ask my curated audience for advice. Even if I don’t know them all personally, and thus have little confidence in their individual experience and knowledge of my personality, I have high faith in the mechanism. I ask, and I receive. From people.

It’s a model as old as language. Until computers can empathize, algorithms need to shift their focus. Instead of attempting to make recommendations, technology should attempt to facilitate recommendations.

Twitter is on the right track with the new focus on search. I’ve long maintained that the best source of purchase advice is Twitter search. Twitter is a barometer. Nobody searches Twitter to find out definitive, high-confidence information. Instead, we search to get a feel for what people seem to know. We read short statements and either empathize with them automatically or shut them out. We have faith in our ability to read between the lines and derive answers. We use personal brands as clues to authority, bias, and brilliance.

It’s very personal and all too human.

With the insanity around the Yahoo and Bing/Microsoft relationship, I wonder if Twitter – or an app built around it – won’t become the search and recommendation tool we all really want.

The newest example: Mastercard Priceless Picks.

Their location aware social review sharing tidbit finder app is a cute, ephemeral trinket (at best). It would have made a rather interesting location-aware banner ad. Unfortunately, someone told them they should ship an iPhone app instead of a ton of banners. Hey, why not, right?

Here’s one reason: installing an iPhone app is work. If you make users work, you owe them something valuable.

Despite the attempt at “one-click” installation, the App Store is a nightmare. iTunes is still slow and unwieldy. Installing, updating, deleting, and managing applications is still quite a bit of work.

Contrast this to banners. A banner loads when a page loads. Users don’t have to do anything. Actually, users don’t get to do anything – including disabling ads or opting-in – but that’s a post for another day. Unlike iPhone apps, the barrier to entry for a banner is very low. Your debt to users is lower.

They’re fast to develop, cheap to run, and simple to measure. They probably get more traction than iPhone apps, especially as the “first in my category!” novelty slots are snapped up. But alas, the creatives are bored with them.

These days, many digital agencies won’t touch banners. They relegate banner work to a production ghetto, churning them out when they have to, and apologizing to the creatives forced to touch such dismal fare. They blame the format for the lack of satisfying creativity instead of looking at themselves.

Hey, don’t get me wrong: I agree that banners, as a format, are terrible. I want online display ads to die as much as the next normal, sane human – and with them, their concepts.

There is a class of creative concept that belongs in a banner/widget, if anywhere at all. Most of the iPhone apps spit out by brands belong in that class. Transposing formats is a distraction. Sleight of hand. Another paycheck.

The Mastercard app shows the warm reception from the public.

Would so many agencies pitch iPhone apps if their compensation was usage-based? I don’t mean downloads, either. I mean repeat launches, with the first dozen per device being free.

A Mantra

Ad world creatives and strategists, repeat after me: My iPhone app idea sucks. It belongs in a banner. Leveraging the accelerometer, magnetometer or location API doesn’t change that.

If you’re the exception, I’ll buy you a pint. Of gold.

Brand App User Scenario

To those who will pitch their dumb ideas despite my sage advice, I offer a token of friendship: your primary user scenario.

The user will follow these ten steps.

1. Hear about the application.
2. Search App Store or come in via link.
3. Click install, wait for download.
4. Plug in phone.
5. Sync. Take nap while backup and sync complete.
6. Find the app on the many screens of icons.
7. Launch it.
8. Close it.
9. Delete it.
10. One star.

Ouch. I’m sure you’ll win an industry award, though.

According to AdMob, a large portion of iPhone and iPod Touch users claim to use their mobile devices to browse the web more often than they use their desktop or laptop computers. This number is undoubtedly going to grow.

Combine that with an article in AdAge this week examining the problems with Google’s AdSense for Mobile product, and you see the current, expanding dark period for users (victims?) of mobile ads.

Mix in Noah Brier’s thoughts on Google as a market leader and we see a larger risk: if Google ignores UX right now and users acclimate, nobody will have the weight to course-correct where the experience is concerned.

Admittedly, my opinion is that mobile advertising should shrivel up and die. That said, if it’s going to exist, the UX should be at least tolerable and, preferably, stellar.

This is the kind of problem that arises when engineers don’t obsess over UX.

Strategists everywhere are pushing companies to add APIs to their online properties. Job postings for web developers and architects invariably require experience working with and developing APIs. It comes up in sales meetings, pitches, and casual conversations with industry folks all the time. I’m often left wondering if the term “API” has lost its real meaning and become sort of a stand-in for a handful of fuzzy concepts.

REST APIs are Buzzworthy

In the API chatter, there’s a huge focus on RESTful APIs. Everyone wants a RESTful API. Web developers love REST architectures because the fixed semantics and stateless mapping of resources to URIs lowers the barrier to entry for integration tasks. Devs no longer have to struggle to understand proprietary architectural touches. No WSDL files need to be parsed. No expensive, scale-resistant state-managing caches need to be added. The URI we use in the browser is the same URI our apps use to read JSON or XML, etc. It’s a glorious thing, REST. I absolutely love the style, and preach the benefits to clients whenever possible.

Another thing I peach, when I can, sounds scandalous at first. That message: If you’re adding a REST API to your site, you’re probably doing something wrong. Maybe.

REST APIs are Everywhere. Right?

All the big sites are exposing REST APIs. Twitter has on. Flickr has one. Netflix. Microsoft SharePoint. Everyone, man. Everyone.

But how many are as RESTful as they could be?

If you see the value in a REST API, the last thing you want to do is create something separate from your “main” site or service. Your site is your “API” if you’re being RESTful. If you force a separation or bolt on a separate chunk of URIs meant for API clients you’re probably wasting resources and muddying your domain.

With REST, you should have a distinct, stateless URI for each conceptual resource you provide and should respond to the appropriate HTTP verbs (most commonly, GET, PUT, POST, DELETE, HEAD, TRACE, and OPTIONS).

For example, if you have the concept of a user profile for someone named “TobyJoe” you should have a single URI that represents that profile and that URI should serve any supported format a client application requests. It doesn’t matter what the URI looks like, but there should only be one way of accessing that conceptual resource. You can serve up XML, JSON, HTML, plain text, SVG, or any combination of formats you want. HTTP and the REST style already accommodate for this using certain HTTP request headers. This problem has been solved since the Web existed (basically). And yet, we see a lot of big sites offering two distinct sets of URIs: one for their “site” traffic and one for their “API” traffic.

Really, it shouldn’t matter if someone is requesting the resource at a URI from Safari, Tweetie, cURL, a Flash RIA, or any other HTTP client. The REST style can cover all the content switching and access management you need and you can have a single set of URIs, a single set of semantics, a single engineering team, and a single set of resources to support. The user experience for your third-party development partners will be improved as well.

Twitter: An Easy Example

So why are there two URIs for my Twitter status feed? One for the Twitter-branded HTML (with great microformat support!) at http://twitter.com/tobyjoe and one for XML at http://twitter.com/statuses/user_timeline/tobyjoe.xml?

It’s the same data, in different formats. It’s the same concept: status messages for tobyjoe. Most of the formats Twitter supports are available at the http://twitter.com/statuses/user_timeline/tobyjoe.{EXTENSION} address. Why not the HTML version with the sweet microformats?

Note: I’m sure Twitter has many reasons for this separation. Legacy clients, their ever-changing architecture and unprecedented growth, organizational investment in this style. They have an amazing team over there. I’m only using Twitter as an example because so many developers are familiar with their API.

Still, as both a user and client developer, I’d prefer to see a single URI (or at least one URI template) for each conceptual resource rather than one URI for “people” and one URI template for “machines”.

It’s Not Always That Easy

I know that there are lots of hurdles with development around live products. I don’t discount the operational challenges. I don’t necessarily chastise folks who stray from REST. I would love to see the concept of the RESTful API default to a slightly different meaning that what I see on the web today. Instead of saying, “We are going to add a REST API to our site!” I’d love to see companies say, “We are expanding the choice of representation formats and verbs for some of our URLs!” Not as sexy sounding, but way sexier.

There is a common pattern in the contemporary interactive digital art world: artists’ tools are getting more hardcore under the hood.

A lot of the current stars cut their teeth (and still make their living) on Flash. I was a very active member of a messageboard in the late nineties geared towards web and interactive design and development – a distinction I share with many of the current stars. The messageboard (dreamless.org) is long gone, but most everyone is still in touch, still sharing code and competing or collaborating. It’s nice to a fairly constant community, even if their tools have changed.

A lot of people moved from Flash to Processing – a great Java-based framework and IDE – as their interests moved away from wide distribution (via the Flash player) towards lower-level access to the hardware. Being able to work (almost) directly with OpenGL, for example, was a huge benefit. Processing provides a set of capabilities that is different than that offered by the Flash player, making it a great supplement for digital artists.

These days, the most adventurous (Flash-using) artists are venturing outside of both Flash and Processing. They are leaving their virtual machines behind, diving down into C++, OpenGL, OpenAL, and raw C code. This is a scary place for a lot of digital artists, who often lack CS degrees. Instead of taking the usual CS approach of learning from the hardware up, touching higher level languages (like Java and Actionscript) and virtual machines (like the Java VM or Flash Player) dead last, artists start at the top and move down, stepping into dark, complex, fault-intolerant waters only when they need access to more powerful APIs or direct hardware access. Knowledge is built pragmatically instead of comprehensively – a fact that keeps their perspective unique and their work fresh.

The top toolset for the hardcore digital artists right now is OpenFrameworks. It’s a great C++ library with a passionate community, not at all unlike, or separate from, the Processing and Flash communities. This summer, The Barbarian Group will be announcing a (possibly open) framework with a similar purpose. Flint is a framework for C++ and Objective-C development, allowing cross-platform development that is still platform-specific (if that makes any sense), and includes support for a certain popular mobile device…

These frameworks are vital for the progression of digital artwork because they take very tedious, daunting tasks and boilerplate code and wrap them up in attractive, semantically-appropriate domain-specific languages. In other words, they solve for the user experience of the digital artist. They help minimize painful context switches and free artists up to focus on the art. Instead of trying to remember all the arguments and gotchas with creating double-buffered windows on different operating systems, the artists can spend time creating textures and thinking of new interaction models.

For a framework to succeed, it has to become almost invisible to the coder. This is true of all assistive technologies, and, in my opinion, all technologies should be assistive.

Check out Robert Hodgin’s newest work, using Flint.

Mobile users are often on the move while interacting with their devices. By definition, their environments change almost constantly and often introduce unforeseen obstacles. Mobile conditions can place limits on many user attributes: focus, input precision, network connectivity, available time, personal space, and patience. Yet mobile devices are becoming as robust and powerful as laptops, inspiring tons of new, high-end functionality. The challenge is to reconcile the two factors, creating a helpful user experience that uses the new tech to the benefit of the largest number of users and the detriment of none.

User-centered designers face some interesting questions: How do you design an interface that allows someone to find directions or call a cab while carrying bags of groceries home from the market? How can an interface accommodate limited agility, gloved hands, a jostling subway train, or fat fingers? How do you let users subtly compose, edit, and erase email messages while in a long, boring meeting? (Hint: shake-to-edit or shake-to-delete or shake-to-anything are not very friendly requirements.) How do you model user behavior when the nature of mobile use is unpredictable and endlessly diverse? How can you solve problems as unobtrusively as possible?

I hear questions like these very often these days. Designers and developers who never paid much attention to the usability of their web or desktop applications are suddenly quite concerned about the UX of their mobile applications and mobile-optimized sites. I welcome the new interest in the topic, as I’ve always been a bit UX-obsessed, but I have to wonder about the inspiration. I think I’m witnessing a new empathy for users and a shift from the assumption that users crave every complex, novel, “innovative” idea a designer can throw at them.

Progressive Enhancement to the Rescue

One of the topics covered in my iPhone book is progressive enhancement. For those unfamiliar with progressive enhancement, it is the art of providing baseline value to all users and additional value to those in favorable environments or with extra abilities. A strong, accessible functional baseline is important for all software products and interfaces because we want our products to be user-centric.

Progressive enhancement patterns are familiar to a lot of web designers. I think a lot of folks kind of fudge the topic, though. They meet their stated requirements (such as 508 compliance), but often ignore the art. They provide baseline functionality, but they make it clear it’s only baseline. They passively penalize the audience that can only meet the minimum requirements and focus all elegance, fun, and inspiration on the most capable users.

Building Empathy Through Adversity

I think the growing importance of mobile devices in our everyday lives can give a new perspective on baseline users, perhaps leading to more time spent providing amazing, elegant assistive applications and reducing the importance placed on gimmicks.

Think about it: these days, we are all mobile users. As such, we all face adverse conditions for use. Suddenly, we all understand what it’s like to have external conditions impose limitations on our abilities. We are all handicapped in one subtle way or another as we go about our day. All it takes is a taste of frustration to ignite passion for assistive interfaces.

The applications we truly appreciate in the mobile space are those that enable us to accomplish our tasks no matter what our environment. We can compose emails in the absence of a network connection–they simply send when we are back online. The better Twitter clients and RSS readers store data on the iPhone to provide some value when users aren’t online. The better interfaces allow us to perform tasks with one free finger and minimal attention. They don’t impose gestural abilities on tasks for the sake of novelty. Or, if they do, they treat the novel interaction as an enhancement, allowing us to accomplish the same goals with the tap of a button.

In interactive design, including software and web design, progressive enhancement is often treated as an annoying requirement. Designers can now tap into their own experience using mobile devices to better empathize with users who lack full control of their environment, tools, and body, leading to a new respect for baselines and a shift in attention from the secondary enhancements to the primary use cases.

The article is Jeff Goodby: We are Becoming Irrelevant Award-Chasers.

There are some real gems in this article and I agree with his core position. It echos something a friend of mine told me. He’s the Worldwide Creative Director at one of the world’s largest agencies. His group focuses on the shopper space and measures success in terms of direct sales. The motto he and his team operate under is, “We don’t take gold. We make gold.”

They focus on activation more than awareness, and obsess about ROI. Cases moved, not trophies from their peers. Definitely more MBA than MFA, though they’re no slouches on creativity.

This is a different position and purpose than awareness-building groups and campaigns, but I think the two are artificially separated.

My favorite paragraph from Mr. Goodby’s article sums up a problem a lot of folks joke about: using client dollars to build an agency brand first, client brand second.

It’s a warning that we are, in effect, making things that serve our own agency brands instead of serving our clients and making a difference in the minds of the world.

I see this all over the place. It’s an industry-rag myopia that often leaves consumers/shoppers/users out of the equation. It’s more prominent in the awareness-building side of advertising, because it’s easier to get away with there.

What I don’t agree with is the call for famousness as a driving force – at least not for the agencies themselves.

I want us all to be famous again, outside the walls of our agencies. How can we accomplish this?

I’d rather see the brands made more famous, the agencies fade into the shadows, and awards focus exclusively on metrics. The problem, of course, is finding new ways of measuring success.

In Which Toby’s Optimism Takes Over

If each major agency donated the time and brainpower of one pointless microsite or social network spam tool and focused on using technology to prove efficacy as it relates to activating sales all the way from display media to the credit card machine, they could transform the industry.

We’re all digital-obsessed anyway. Why are all the lines of code squandered on ephemeral campaign collateral? Why not come together and create standards that unify as many digital outlets as possible? Unify digital cable to mobile to web to shopper loyalty programs to e-commerce to out-of-the-home to in-store displays?

It could be awesome… A lot of work, for sure. A lot of ego set aside. Great care to liberate consumers/shoppers/users from privacy concerns, bad UX, and fatigue. A massive battle against inertia. But the payoff could be the ability to tune messages so effectively that we reduce the noise, stop fighting for eyeballs, and help people make decisions.

In Which Toby’s Cynicism Takes Over

But then, who wants to create tools that can measure success accurately? Who wants awards to go to campaigns that help move units if those campaigns end up straightforward and unobtrusive and inexpensive? What if your pet client is pushing a shitty product and user-centered advertising exposes it as worthless? Ouch.

And who can be famous for helping their clients get richer?

What if cabbies are unimpressed?!?!

In Which He Makes a Call to Action

So who wants to discuss the overall role, and future, of technology and user experience in advertising? Who can think outside of their current assignment? Who among us would like to be the Tim O’Reilly of ad-tech? Where are the visionaries?

Most folks will eagerly update their devices as the new OS is truly stellar.

Many applications will be updated to take advantage of new features like the Push Notification Service, In-App Purchases, and Bluetooth-powered Private Area Networking (with GameKit).

I can’t wait to watch the Twitter chatter.

See, I’m obsessed with UX – especially on the iPhone. I get bent out of shape about ugly applications, hijacked gestures, disruptive branding and flippant differentiation. I fully acknowledge the delicate bubble Apple has created in the form of the iPhone UX, and I hate to see folks pushing blindly at the edges. The aesthetic and experience are what really differentiate the platform from similar devices, and it’s worth maintaining.

Cocoa Touch developers, like Cocoa developers, spend a lot of time thinking about user experience. With Cocoa Touch, there is an additional onus on folks to think about the experience outside their application because the device has limited resources: memory, CPU, battery life. Mobile users also have more limitations than desktop users: attention, coordination, time, tolerance, physical ability.

With iPhone OS 3.0, I am especially worried about the Push Notification Service and its potential for misuse, abuse, and overuse. Without consistency in the meaning of push messages, we might collectively burn users out on notifications.

Notification Misuse: Audio and Text Alerts

Developers can use the push service to send three types of notices to devices: short audio events, strings of text, and a number shown in a red circle (aka badge) on the application icon. Each of these has a place, and Apple cautions developers against using notification mechanisms that are disproportionate to the importance of messages.

For example, you should avoid sending audio alerts unless users are in the application context (that is, the application is running and users are interacting solely with it) and have opted into receiving audio. Nobody wants their phone to chirp away with random noise when they’re trying to listen to music or play a game.

Text alerts can be used to communicate very important events, but they too should be used with care. Text alerts trigger a full-screen, modal alert box that not only steals the focus of the entire phone but requires users to dismiss the alert by tapping a button. It’s pretty cocky to hijack an iPhone for a trivial note, so make sure the message is worthy.

Notification Abuse: Audio and Text Alerts

Don’t flood devices with flippant text or audio push notifications. Understand the disruptive impact of those messages and avoid them unless they are absolutely necessary. And repeat this mantra: “Push notifications are rarely necessary!”

Consider an asynchronous chat service in a social application. It might be awesome to use the push service to send messages to users, SMS-style, even when the app isn’t running. Now mix into the equation the presence of other applications. Most of us have at least two social apps on our iPhones. Suddenly, modal alert messages are popping up for each of them. God forbid you have multiple Twitter clients installed that send alerts for direct messages – redundant popups flooding in would be pretty annoying.

Don’t fall into the “I can, so I should!” mindset. Applications have worked well without notifications thus far. You won’t increase stickiness by pushing notifications to users, catching their attention and helping your icon stand out on the screen. Stickiness is a terrible concept carried over from the ad-driven web and is the banner under which advertising ruined online UX. Even if your application is ad-supported, your best bet for success is to create a tool that fits into the whole iPhone experience rather than trying to use every feature available to you in hopes of standing out. Beat your competition by doing less, better. Don’t steal focus. Earn it.

Notification Overuse: Badges

You should also avoid overuse of icon badging. Think about mobile development holistically. Every badge added to an application icon impacts the overall user experience. It’s your duty (yes, duty) to play nicely and work with the iPhone developer community to create a strong experience. You are not an island. Your app is nothing without the experience provided by Apple, and that experience must be ruthlessly maintained. Your application is a guest on a very expensive, aspirational fetish device. Don’t trash the place, lest you be trashed.

Badge Blindness

So why should badging be limited? Overuse of badging will lead to badge blindness. Badge blindness occurs when users lose faith in the importance of icon badges. RSS readers provide a really great example of this phenomenon.

Imagine you subscribe to 50 feeds – a modest number – and have your feed reader set to poll for updates every hour. If your reader shows a badge that reflects the current number of unread stories in your collection of feeds, you can almost guarantee that you will always have a badge present. Often, it will have a very large number inside. You will never reach zero, and the badge will never disappear. The badge becomes a permabadge – an annoyingly persistent reminder that the application wants your attention. You will probably declare RSS bankruptcy – marking all feed items as read – just to get the satisfaction of seeing the badge disappear… for less than an hour.

Imagine that, on the Mac desktop, several applications in your Dock show badges. Mail, iChat, NetNewsWire, iCal, and Xcode. Suddenly, you don’t feel as though your computer is trying to direct your attention towards an important, but non-critical, focal point. Instead, you feel as though your computer is constantly nagging you.

Now picture the equivalent on your iPhone. A screen of greedy little icons, all raising their hands wildly, begging for attention. You’ll start to ignore the mechanism. You’ll stop seeing the badges.

You’ll delete the annoying apps and leave one-star reviews on the App Store.

Advice

Imagine you’re in a crowded coffee shop. A friend is across the room, reading a book, or chatting with a crush. You think of something you think they may, possibly, maybe want to know. Would you shout the message out across the room? Wave your arms wildly, hoping they make eye contact? Send them a text? Email them? Leave a note with their server?

Whatever your message, make sure the transmission protocol is suitable. In some cases, this will mean badging. When badging, make sure the badge will be invisible more often than not, or it will lose its impact. If the message merits completely stealing focus, send a text alert or sound. Do so only in the rarest of cases, unless users have opted-in and can just as easily opt-out. Be nice. Don’t pop any bubbles.

For those not in the know, Twitter uses an incrementing integer as an identifier for each message on the site. On June 12, 2009, a message crossed the maximum integer value that could be stored in a 32-bit signed integer (2,147,483,647).

All messages created after that moment had integer values that would overflow the space allocated to the id.

This wasn’t a problem on Twitter.com. They’re surely on some rockin’ 64-bit systems and are continuing along as always.

The problem is with third-party applications using their API. When an application requests a list of status messages from Twitter, it receives the data in a format like XML or JSON. All values are stored as strings in those formats.

When the response is parsed, the string representing the status message id will be converted to a number. Applications that still use signed 32-bit integers will not be able to properly convert the string to an integer and will probably crash.

This problem is hitting a few Cocoa Touch applications. Tweetie seems immune, but the current release of Twitterrific and the in-beta Birdfeed both suffer. This is through no fault of either Craig Hockenberry or Buzz Andersen, though.

Buzz’s app, Birdfeed, is still in beta. Those of us testing it understand that beta means beta. He’s cracking on a fix now.

Craig preemptively fixed his issue well in advance, but – as I understand it – Apple is sitting on it instead of pushing it into the App Store.

This is just one of many ways Apple continues to please developers endlessly with their transparent, fair, open distribution channel.

Lots of folks want to blame Twitter, or shift some of the blame to them.

This is not a Twitter problem. They adapted their system and encouraged developers who use the Twitter API to remain in parity.

It’s probably true that Twitter could have made a bigger deal of the issue, but I think they did a solid job of keeping people informed.

Most people had ample time to update their code, and many of them did.

Daniel Jalkut suggested that Twitter might have provided an endpoint for the API that simulated large integer values, so application developers could test against the newer ids. I heard similar statements by folks attending WWDC.

I think this exposes a slightly dirty secret in the Cocoa world: most Cocoa and Cocoa Touch devs avoid automated testing. Unit tests are few and far between. From what I hear, Apple doesn’t even enforce units.

When you see regression bugs in Cocoa apps, you can assume the issue is in a lacking test suite.

The Cocoa community should learn two things from the Twitocalypse:

1. Write your units.
2. Submit to the App Store at least time * infinity in advance.

I’m about 50% on having test suites in my (admittedly, unreleased) iPhone apps. The half that have tests have strong coverage, though. Those that don’t are from the early SDK days, when the only way to test was with the Google Toolkit.

Wow, long time no write… Typical of me.

I’m wrapping up my newest tech book. Programming the iPhone User Experience will be released by O’Reilly this July.

I spoke at the Web 2.0 Expo (SF) this year on the subject of iPhone UX Anti-Patterns. It was the highest-rated mobile session. Great validation, and I think it’ll go a long way towards squelching the desire to jump off a building every time I have to get on stage.

After the book wraps, I hope to write more often here, on InsideRIA, and for other publications.

Or, I may just drink a lot and lay around.

near ")": syntax error

Check to see if you have any models declaring themselves as DataMapper::Resource but WITHOUT any property declarations.

No meaningful error is reported for this case at the moment (with HEAD as of last night) so it’s a weird one to debug – especially if you generate a bunch of model classes ahead of defining their behavior.

I understand the irony of complaining impotently about an impotent complainer, naturally. Hey, that’s what blogs are for, right?

describe "Filtered fields" do
it "should filter content on save to cache expensive transforms while preserving source" do
# do it
end
end

Doing this in xUnit would probably cause you to have a camel-induced nervous breakdown.

Though I’m a recent convert to rSpec for my Merb work, I actually prefer to unit test Objective-C with OCUnit. I think it’s just part of that prejudice that tests should be written in the language of the app. Also, the more ‘natural’ it feels to write tests, the more likely folks will do so. In my experience, a great number of Obj-C developers have no interest in writing tests in the first place…

Still, rbiphonetest seems like a great project and I imagine several of the “pure” Web developers on my team who are itching to get into Objective-C will quite enjoy a familiar testing framework.

Like everyone else who prefers clean over clever and true pragmatism over dogma, I prefer Merb over some of the other options out there for day to day Web apps.

That said, I’ve not done any major work with the two yet. I have some of my long-shelved personal apps being rewritten/written on Merb master and DataMapper master, but I am kind of holding off on larger commitments until the 1.0 release.

If you haven’t checked out Merb and Datamapper > 0.9 you should.

I’m even coming around on rSpec, though I still prefer xUnit style testing because the language and flow is the same across all the types of development I do (PHP, Ruby, Objective-C, Java).

I found a Google project that looks promising, but haven’t looked into it.

Do my footwork for me!

Coding blind (no tests) is causing my ulcer to flare up.

Please, dear God, let Frontline start releasing content under iTunes U. And MIT Media Lab, and…

All I can hope is that they don’t kill the series before I can download it all.

The write-safety mechanism provided by attr_accessible doesn’t help in this situation, but having to write a custom to_xml method that steps through each of these already-whitelisted attributes is a bit silly and not very DRY.

My solution is to do something like:

def to_xml(options = {})
    super({:only => self.class.accessible_attributes}.merge(options))
end

Breaking that out, as I do, into a SecureModel mix-in seems like a good move.

For a living, I program computers. I use a dozen or so made-up, unspeakable (well, except for Ruby) languages to write stories that tell electricity how to flow across networks, through processors and from one magnetic point to another. Because I work in advertising, the last page of each of these fairy tales is (hopefully) a swarm of consumers choosing one breakfast cereal or male body spray over another.

I also dress poorly, by most non-nerd standards. No, I’m not fat. Nor am I especially thin. My clothes aren’t dirty. But aside from those clichés, I have an Aspbergers-like lack of comprehension of fashion. My ideal outfit is a plain black t-shirt, slim jeans, and the least-memorable sneakers available. On its own, my fashion sense doesn’t make me sound especially nerdy – just boring. It’s more than the choices, though – it’s the driver behind them. I dress myself by way of negation. I imagine everyone I see in a typical day, and I reduce and reduce by eliminating anything that stands out from one person to the next. Dressing seems to be, for me, a passive act of nihilism.

In fact, I am downright angered by the ironic trendwhores and hypebeasts and whatever other terms you want to use for idiots who spend good money on overpriced haircuts and clothing in order to eschew sincerity. It drives me wild. And yes, somehow I still manage to live in Greenpoint. But I digress…

What else makes me a nerd? Hrm. We have computers, we have lack of fashion passion.

Growing up, I was in gifted classes from second grade on. I competed in Olympics of the Mind (later Odyssey of the Mind due to a litigious IOC) and usually won on the conceptual events and never on the performance-based events. Yeah, that’s right: I was the kid with stage fright AT THE NERD OLYMPICS.

Other nerdlies:

• One of my better friends releases software under the name Bytes of Spring and I will never, ever stop chuckling proudly about that fact.

• I have a brass bell on my bike. Ding-a-ling.

• I have Robert Frost poetry tattooed on my arms.

• I’ve never danced, and, in fact, can’t watch people dance without burying my head in a pillow for shame.

Pretty nerdy stuff.

Non-Nerd by Omission

The subject of this post, really, is about the things that make me a bad nerd. The truth is, I have very few items on any of the requisite cultural consumption lists: the nerd list, the indy list, the political conscience list.
In my younger days, I might have obscured this fact in order to seem cooler. You know – the way you grimace dismissively when someone mentions a band you don’t know, implying something along the lines of, “Meh.” but really meaning, “Meh. I don’t even know what that is, but all ‘Mehs’ are the same to you, ya idiot.”

Well, I’m gonna fess up. Slightly. It would take forever to list the consumables I’ve not yet consumed. The meat is here. The exposed truth of the matter. The details are unimportant.

So let’s have a list, yeah?

Missing from the Geek Checklist

• 2001: A Space Odyssey
• Gremlins
• ET before the re-release in 2002(ish)
• Anything Star Trek
• Any Star Wars OTHER than Episode 1, which I saw in a theater a few years ago
• Most every video game ever made. I love games, but am non-committal. I own last-gen systems and like one game for each.
• Commodore 64 and other classic computer systems. I began “doing computers” in like 1997. What can I say? I was a poor kid growing up…
• Thinking 9/11 was a government conspiracy
• Like the item above, visiting digg.com
• Using Quicksilver for the Mac
• Ever liking They Might Be Giants
• Buying stuff from ThinkGeek
• Being a fanboy of any type
• Going to a LAN party
• Reading a graphic novel
• Collecting anything at all
• Playing any MMORPG, any RPG, or Zelda
• Reading Douglas Adams, Tolkien, Vonnegut, or Heinlein
• Ever seeing an episode of Dr. Who
• Being able to quote any Monty Python (movie, show, book, actor)
• Ever seeing an episode of Freaks and Geeks
• So very, very, very many more.

The Road to Recovery

I received Freaks and Geeks, Season 1, disc 1 in the mail recently from Netflix. I can’t stop reliving every moment of all three of the episodes I’ve seen thus far. I can’t believe how awesomely funny and perfectly tuned that show was.
Freaks and Geeks has joined The Wire and Dexter in my Best Stuff Ever on TV list.

I’m inspired, folks.

I’m gonna watch the rest of Freaks and Geeks. When I’m done I’m gonna start exploring some of the other omissions. Maybe I’ve found the tip of an iceberg here.

This must be what it feels like to get sucked into a cult, like Scientology or Reagan Republicanism.

It feels mighty fine.

My main gripes with the RSS/Atom support in Mail on Leopard are:

• It’s a pain to import OPML files. I posted a fix for that, though.
• The arrow keys aren’t incredibly useful for navigating between panels, through feeds and items, like they are in NNWL. Having to use my trackpad is lame. Having to tab focus on panes is bad.
• I haven’t yet seen any way to customize the display of feeds in Mail. Not a biggie, but the default view is kind of blah.
• Sorting seems to be alphabetical only.
• When Mail is handling more than a couple of accounts (especially IMAP with server-side folders) it’s invariable that you’ll have to scroll to see your feeds. I’d rather Apple+Tab over to NetNewsWire Lite or Vienna.
• It’s called ‘RSS’ instead of ‘Feeds’ or similar. This might seem nit-picky, but it’s like calling all computers ‘Windows’ instead of… computers.

I like the idea of having feeds in my Mail reader, aggregating the bulk of my passive reading. It’s kind of like using Adium to group all IM-type accounts (I don’t, but I see why folks do it).

Currently, the feed support in Mail is fine if you subscribe to one or two feeds I guess. The UI just isn’t conducive to someone with hundreds of feeds that are updated frequently.

During my evaluation, I also found a few gotchas, tips, and compile tricks that might have been useful to others.

Given that the Apple NDA very clearly prohibited writing about Leopard before the release, I filed these things away.

A couple of the topics I didn’t write about were building ImageMagick and RMagick on Leopard and a how to on executing the Widget ‘flip’ with CoreAnimation.

Install RMagick on Leopard

The RMagick stuff seems mostly figured out now, as MacPorts has stuff updated pretty well. My instructions after that first release included compiling everything by hand with special flags and a sacrificed chicken. Now it’s as simple as:

sudo port install tiff -macosx
sudo port install ImageMagick
sudo gem install rmagick

Hopefully, someone can get FreeImage working soon… But I digress.

CoreAnimation Widget Flip

The CoreAnimation tip is something I’ll cover soon, once I confirm that everything is teh same on the official Leopard release.

Import OPML Into Mail.app

Today, I wanted to write about the pain in the ass of RSS on Mail.

I decided to export all my feeds from NetNewsWire Lite to OPML in hopes of giving Mail’s RSS features a shot. After all – mail, plus to-dos, plus iCal integration, plus RSS could make Mail my main app for non-dev work.

The main complaint I have is that Mail doesn’t support OPML. In fact, it doesn’t support any form of mass-import of feeds or bookmarks, aside from a klunky Safari-as-proxy import.

Safari, of course, doesn’t support OPML. Instead, it uses Netscape bookmark files (NETSCAPE-Bookmark-file-1 DTD). Yay, cutting edge!

It’s dumb, but here’s what you have to do:

1. Export to OPML from NetNewsWire Lite (or Vienna, or whatever you use)
2. Run the PHP script at the end of this post with php convert_opml_flat_to_nbm.php MySubscriptions.opml > MySubscriptions.html
3. Import MySubscriptions.html into Safari
4. In Mail, go to File > Add RSS Feeds…
5. Check the radio button for Browse feeds in Safari Bookmarks
6. Check whichever feeds you want added

Wow. That was simple. And painless. OMG TOTALLY NOT PSYCHE YOUR MIND!

Before you do all that, though, let me point out an apparent failure on the part of the Mail RSS reader: it doesn’t pass the referrer on requests for assets. This sucks because mihow.com, along with tons of other sites, turn off hotlinking.

What’s interesting about this, to me, is that Safari sends referrers. I’d have thought Mail would have used the same lib (or functionality) as Safari for request management. Seems like a WebKit no-brainer to me.

PHP Script to Convert OPML to Netscape Bookmarks

Save this to your machine as ‘convert.php’ (or whatever you want to call it). If you export your OPML to your ~/Desktop, you may as well save this as ~/Desktop/convert.php, which will enable you to easily run the command from Terminal.

<?php
    function usage(){
        return "Usage: php convert.php /path/to/opml_file.opml > output.html\r\n";
    }
    #    Print usage if need be.
    if(count($argv) < 2) die(usage());
    #    Grab the file path.
    $f = $argv[1];
    #    Load it into a SimpleXML.
    $xml = simplexml_load_file($f);
    #    Output buffer
    $out = '';
    #    Run through the nodes in the OPML and buffer the Netscape output
    foreach($xml->xpath("//outline") as $outline ){
        $title = htmlspecialchars($outline['title'], ENT_QUOTES);
        $feed = htmlspecialchars($outline['xmlUrl']);
        if($feed){
            $out .= "\r\n\t" . '<dt><a href="' . str_replace("http://", "feed://", $feed) . '">' . $title . '</a>';
        }else{
            $out .= "</dl><p>\r\n<dt><h3>$title</h3><dl><p>";
        }
    }
    $out .= "\r\n"
?>
<!DOCTYPE NETSCAPE-Bookmark-file-1>
<title>MyBookmarks</title>
<h1>MyBookmarks</h1>
<dl><p>
<?php echo $out; ?>
</dl><p>

Alternate Method for Importing Feeds

I can’t believe I didn’t try it first, but as someone commented, you can just drag feeds from NetNewsWire or Vienna into the accounts area of Mail and BAM – feeds. Man, what a simple solution. Oh well, given the traffic to this post, I’m not the only idiot out there

As much as I want to see friends out there, the workload and short duration of the trip might limit me to dinner on Thursday evening.

I hate flying, but at least I’ll be on JetBlue and will have a few hours of podcasts (Rachel Maddow, Intelligence Squared) to catch up on.

We’re doing the Hybrid Web/Cocoa Application Development Lab and Designing and Developing Hybrid-Web/Cocoa Applications session.

In this installment, I’ll give a bit of insight into some of the publishing/blog software out there. I’ll focus only on the ones I’ve used, of course.

Before discussing specific packages, though, I guess I should touch on what software is, how it relates to resources (like pages), and where a database fits into everything.

I’ll also tell you how to set up the very cool Mint stats package on a host running PHP and MySQL.

The Server

Remember in Part 1 when I described a server as a computer that sends information out in response to requests from a Web browser? I was totally telling the truth. I was also totally skipping an important, yet confusing distinction.

The actual hardware is called a “server” but so is a piece of software running on that computer. Maybe it’s best to say that the combination of the two is really what constitutes a server versus a normal computer. A server is a computer running server software, in other words.

Most Web servers are running the Apache HTTP server. Apache is great. It’s a classic. It’s a workhorse. There are alternatives, of course, but Apache is sort of king.

Static vs. Dynamic

Generally, there are two ways in which a given resource (like a blog entry) can be served: statically and dynamically.

A static resource is a file living inside a folder. When the Web server software receives a request for a file (represented by a URI, like “tobyjoe.com/about/index.html”) it looks inside of a given folder, finds the file, and sends it to the browser that requested it.

Dynamic resources are the results of programs and are often recreated every time a user sends a request. Leaving a comment on a blog or performing other operations that add information to a page is a good example of a dynamic request.

Databases

You may wonder what happens when you add a comment to a blog and where the comment is stored so that other folks can see it. The answer is that most dynamic content is stored in a database.

A database is any collection of persisted, or stored, data. A text file can be considered a database, though most folks prefer to use a more complex system for storing their data.

On most Web servers, the database of choice is a special software package called MySQL. There are lots of different database types and systems out there, though. Another excellent database system is called PostgreSQL. It’s not quite as popular as MySQL, but it’s catching up. A few others you may have heard of are Oracle, MSSQL, Sybase, SQLite, and Access (yuck!)

In all likelihood, your shared hosting account will use Apache, MySQL, and a scripting language.

Scripting

When a dynamic request hits a server, the server software needs to know how to respond. The most common and essential functionality, like sending an image file, is usually handled by Apache. It’s excellent at doing the cookie-cutter stuff that all sites need to do: sending files, recording a log message for every hit to your site, and deciding what type of resource is needed by a given request.

Because Apache is so solid, we developers don’t like to go fiddling with its insides. It’s just not that fun. Or safe.

So how do we write programs that can do whatever we want if we aren’t modifying Apache? As you may have deduced from the title of this section (you’re so clever!), the answer is to use server scripting.

The most popular scripting language for the Web is PHP. It’s so popular, in fact, I decided to write a book about it.

You can think of PHP (or server scripting in general) as a simple way to write a custom application for processing Web requests. When Apache sees a request for a PHP script (usually ending in “.php”) it will use its PHP interpreter to read the script and perform whatever actions are inside before sending the result back to the browser.

Common tasks of PHP are to do things like connect to a database system, retrieve all the blog posts that mention pizza, create a page that shows a list of links to those posts, and send the resulting dynamically-generated page back to the browser.

I know, it’s daunting.

Some of the common languages used to write Web applications are: PHP, Ruby, Python, Java, C#, and perl. There are, of course, more – but who cares?

Publishing and/or Blog Software

Now that I’ve described all that semi-technical crap, we can get to the point: Unless you’re a developer with an itch to scratch, you should consider using established and respected software written by other folks and reviewed by endless smarties before writing your own. That isn’t true for everything, but this also isn’t an article for developers, so I’ll digress.

I’ve installed and used a few of the popular self-publishing packages and can speak fondly of a couple of them.

Most of them are fairly similar to a newbie, and you will probably be fine with whichever you choose.

The big players are:

• Mephisto
• MovableType
• TextPattern
• WordPress

I’ve had experience with each of these. Honestly, they’re all just fine and have active development communities adding plug-ins and enhancements.
I used TextPattern back when Ian Kennedy and I were running FiftyMillimeter. It worked fine, but the UI wasn’t great.

I personally use Mephisto, but that’s in large part because it’s written in Rails and I’m a pretty active Rails developer.

Check out the sites for each, peep the screenshots, and check around on sites that you enjoy to see what tools they use. It’s often mentioned somewhere in a footer or sidebar.

Stats

I work in advertising, and build sites for giant brands, small hip brands, and have done just about every-damn-type of project on the Web. One consistent desire, naturally, is to monitor stats: how many people visit, how many come back, where they’re from, how they found you, etc.

There are too many reporting packages out there. Most of them were ‘designed’ by developers and are clunky and geared towards information you probably won’t care about.

Enter Mint.

Mint was developed and designed by Shaun Inman and reflects his interests (and yours, I bet): good UI, good usability and good info design. The code is pretty solid and the plugin architecture is nice. I have a few nitpicks, but what geek doesn’t nitpick EVERYTHING under the sun?

I wholeheartedly endorse the use of Mint if you have access to a server that runs PHP and MySQL. It’s $30 for a license, but worth it.

Next

As you can see, there are so many options at every turn that writing a general tutorial is daunting if not impossible. I think the next steps are to cover Google Adsense. What else?

Holler.

So here I am, giving away some GEMS of knowledge for nothing at all. The trade-off is that I don’t know what format to use here and will probably edit and refine this a bit to impart some grace. Take a moment now to screen-cap anything you want to hold against me in the future.

Oh, and for the geeks – I know this shit inside and out, and am taking some liberties with simplification for the sake of clarity here.

(Much thanks to Jon Vanasco for helping me see that my narrative for DNS queries by browsers was kind of obtuse!)

The Domain

Here’s the scoop on how domain names work. Consider these two statements.

• Every site lives on a server. A server is a computer. Every computer has a number used to reach it.
• TobyJoe has a phone. A phone is a computer. Every phone has a number used to reach it.

Much like the numbers we use for our phones, computers use IP addresses. An IP address is a set of numbers with some dots tossed in to make it techy-looking.

Because it’s tough to remember IP addresses, people create nicknames for them. The domain name ‘tobyjoe.com’ is a nickname for an IP address. You already use nicknames in the phonebook of your cell phone. Domain names are just like those entries in your phonebook.

STEP 1: Find yourself a domain name. Think something up. Make it good.

Registrars

Now that you have an awesome domain name picked out, I’ll tell you how to find out that it’s already taken and that you’ll have to find a less-awesome replacement.

To check on the availability of a domain name, the easiest thing to do is go to a registrar.

You might ask, “What is a registrar?”

Registrars are companies that overcharge you for something that actually costs fifty cents. Seriously. Registrars can seem kind of sleazy (and some are) but there are a few out there worthy of your trust and cash.

For no great reason, I use GoDaddy. They have a few downsides, sure. They’re far too aggressive in trying to trick folks into buying stupid options and upgrades. Their site is cluttered and tacky as hell. But you know what? They’ve never done me wrong.

Use whomever you want, of course. Try to stick with someone you’ve heard good things about.

Just keep this in mind: skip all the bull. Don’t go for multiple years. Don’t go for anonymous registration. Don’t go for adding .net, .org, .blah to the order. Don’t add site hosting. Just get the domain. That’s all. Seriously.

STEP 2: Register your domain with a registrar.

Hosting

Remember all that stuff above that you read entirely and comprehended completely? Well, the server living at a certain IP address and pointed to by a domain name has to exist or your site is nothing. Nada. A blog.

To get access to a server, you have to pay. I recommend a shared hosting plan from TextDrive. There are lots of good hosts out there. These two are recommended by me, so they’re better than others, obviously.

STEP 3: Set up a hosting account. Use RailsMachine if you’re doing a Rails site (like a Mephisto blog). Use TextDrive otherwise. Or whatever. You’ll need a credit card, your domain name, and email address. Pick a Linux hosting plan. Stay away from Windows. It’s just trash, IMO.

Setting Your Nameservers

Nameservers, or DNS servers, confuse a lot of people at first. Hell, a lot of people have had sites for years and still have no idea what DNS servers do. It isn’t really required knowledge, but it’s good to have.

DNS servers are where you set up an entry saying “The computer address for ‘tobyjoe.com’ is (209.59.180.50).”

To stick with the metaphor above, a DNS server is the phone book on your cutsie-wootsie wittle blinged-out Sidekick. You pick a name, it knows the number. You never have to know the number. You become dumber. It’s awesome.

Your browser and mail client and most every other networked app refer to DNS servers when they don’t already know the address for a domain. For new domains, like yours, most machines will have to grab the entry from a DNS server the first time a user tries to visit. This all happens behind the scenes and usually takes only a few milliseconds. Neat, eh?

The way the DNS (aka, global domain phonebook) system was designed allows for changes on one server to propagate to all DNS servers within a day or two. This is good because it means everyone will have a DNS server nearby that can be used to find the addresses for a given domain name. If there were only a small number of DNS servers, they would be overwhelmed immediately.

When you set up your hosting plan, you will receive one or more (usually two) DNS server names. They might be something like “ns1.blahblah.com” or “192.168.1.3″

You will need to use your registrar’s site (like GoDaddy) to set the nameservers for your domain to whatever your new host sent you. Each registrar is different, but it’s usually pretty clear. Often, you’ll select your domain, and click something like ‘Edit Nameservers’ or ‘Add Nameservers’ and just paste in the “ns1.blahblah.com” or “192.168.1.3″ bits.

STEP 4: Set the nameservers for your new domain at your registrar.

Waiting

The world-wide domain name system will have to be updated to reflect this new domain-to-IP address relationship you’ve created. To stick with the cell phone metaphor, all the phonebooks in all the cell phones in the world will automatically receive your name and number combo. You’re gonna be SO POPULAR!

This process takes around 24-72 hours. It takes roughly the same amount of time to die from acetaminophen toxicity, btw.

STEP 5: Wait. Every few hours, anxiously type your domain name into a browser and see if you get something other than ‘not found’ in response. When you do, come back here for part two of this enthralling series.

I guess it was put online as well as in print (in a tough-to-find import mag). I just stumbled across the link tonight.

The formatting doesn’t seem to be there, but the info is clear enough.

I don’t get a chance to write on tech topics as frequently as I’d like. I should work on that.

I first picked up Aaron Hillegass’ book, Cocoa Programming for Mac OS X, back in 2001, immediately after it was published. I’d been on OS X since the earliest public builds, and loved it. The underlying tech – from the kernel to the app frameworks – was exciting to me as a relative newbie to both the Apple world and desktop app development.

I’ve since owned every edition of the book, and almost every other Cocoa/Obj-C book out there, but have never taken a class on the subject. I did attend WWDC last year, but the topical sessions aren’t the same as an in-depth classroom experience (though they are quite valuable).

One of the benefits of a session at BNR is that all distractions are removed for a week. Students are taken away from their families, comfy chairs, favorite bourbons, loud offices, DVRs and insane clients and locked away at a remote facility for five days. They are forced to learn, taking breaks only for meals comprised of fried food and iced tea so sweet the supersaturated sugars crystallize in plain site.

Another benefit of the Cocoa Boot Camp is that Aaron guides you through his book from start to finish, lecturing and answering questions as he goes. The structure, immediate feedback, and question sessions are worth the cash on their own.

Three of us from The Barbarian Group attended (Ashley Holtgraver, Keith Butters, and myself) and I think we all found the class inspiring, educational and fun. I’d recommend any of the BNR courses to folks without a second thought.

I’ll write a more in-depth review of the class soon.