You probably know this, but just in case you are out of the loop, I’ll give some quick background.

Apple’s trackpads – obviously including the iPad – can support up to eleven distinct touchpoints per touch sequence. In other words, you can use both hands and…your nose? On the iPhone, and mostly on the laptops, we use one or two touches most of the time.

On top of the number of touchpoints, multitouch development uses a concept of “touch sequences” to track a discrete series of touches over a short period of time. In English, that means you can put ALL ELEVEN FINGERS on an Apple touch screen, twist, twirl, and swipe, and apps can respond accordingly.

This is fairly new to personal computing. We’re used to a keyboard, a mouse, occasionally a trackball or trackpad. We point, we click, and we drag.

Now we can do more. Much, much more. Obvious, yes? Yes.

Today

We’ve all seen touch-and-drag. We’ve seen flicking through a collection, or flicking to activate supplemental controls on a cell. We’ve seen pinch-to-zoom and reverse-pinch-to-zoom-out. We saw these on the most well-funded educational video series ever: Apple’s own iPhone TV commercials.

Apps mostly stick to the meaning of those gestures, and users benefit from that fact. Collectively, we developers and designers have self-regulated in a fairly organic, reactionary way. But with the larger screen on the iPad, can we unify sooner? Preemptively?

Just wait until people begin using the iPad. Think about that form factor, about the usage contexts. It wouldn’t shock me if a QWERTY keyboard disappeared from the device in a couple of years, replaced by something brand new…something one-handed and elegant. If so, the new *thing* should be leveraged across apps to the benefit of everyone. Novel gestures are a fleeting competitive advantage.

Why Collaborate?

In the sort of wild west that popped up around the iPhone – and will likely pop up around the iPad – the earliest adopters gained footing and market share (by virtue of a smaller market) while users floundered in a Stockholm Syndrome situation. Consumers were captive to the limited array of apps that existed in the early days and were willing to invest time learning how each app worked. A lot of folks are still quite flexible, but I wonder how long it can last.

The tipping point between critical mass of users and critical mass of apps happens quickly, though, and we product designers have to make sure it tips the right way. That is, in favor of users. And reciprocally, in favor of product developers. We can do that by lowering the learning curve for each new app that pops into the store.

A Warm and Comfy Blanket Statement

It’s a mistake to hijack established gestures, just as it would be a mistake for every computer to have a different keyboard layout.

I wrote about this in my book on iPhone UX hacking, and still abide by it.

We owe it to users to collectively invest the same meaning in each new gesture we invent/acknowledge, unless there’s a great reason to change established gestures. If that’s the case, we should register the change with other product devs/designers and move everyone else in the right direction.

We should also focus on bringing new gestures to market in a way that prevents confusion. It would be great to share feedback from our users on input gestures. I can even imagine a choreographed A/B test among competing apps. (KUMBAYA!)

Right now, though, there’s no easy way to share. No grand central dispatch. No forum.

We can read the iPhone and iPod Human Interface Guidelines, copy the earliest players, and bank too much on “common sense” (a problematic concept if ever there were one).

Instead, maybe we should talk about this. Contribute. Debate. Share code. Share artwork. Share labels. Share translations.

The Gist – CommonUX

To get to the point, I want product designers to collaborate and focus competition on features that don’t alienate users. I want us all to share our concepts for gestural input, share the iconography that represents actions (and more), and focus our innovation on the features that matter. Let’s assist users by assisting each other, reduce barriers, and make for a great platform where product designers can spend time where it pays off.

I’ve created a GitHub site and have purchased a domain that could – if folks choose to participate – act as a central repo for collaborating on common user experience elements. This post is to get the word out and figure out whether folks care.

Elements we can standardize include:

• Gestures for common actions
• Apple-friendly icons representing common concepts or objects
• Code and icons for both Cocoa and Android (and…?) for handling common gestures
• Colloquial names for gestures

So, welcome to CommonUX. Let’s sort it all out.

What is ChatSnapper?

ChatSnapper lets you view ChatRoulette in a dedicated window and use the Apple+S command (aka, “Save”) to save a screenshot to your computer. It will save to your ~/Desktop in the most coarse fashion you can imagine.

Next up: image upload (waiting on a YFrog API key), tweeting of links, save preferences, etc. Also, an icon and Sparkle support.

Download

Get the alpha/preview/whatever here: ChatSnapper-alpha.zip

No warranties, people. Troll at your own discretion and sue yourself if something goes wrong. This is the sum total of about 2 hours of work (while watching Olympic snowboarding), so ignore the rough edges.

Though not a new phenomenon, we think we have a solution.

If pressing a lit elevator button were to cancel the call and simply send the machine to the nearest floor in the current direction, there would be a penalty to pressing it more than once.

The interesting thing about this idea is that it need not be universal. Instead, elevator designers could follow the lead of Jeremy Bentham and create a panopticon-style system in which some small portion of elevators operate this way. It only takes the fear of looking like an idiot to regulate behavior (most of the time).

ChatRoulette Weirdos

As ChatRoulette takes off, it’s becoming plagued by pervs flashing their junk or otherwise being slimy. It’s certainly expected, as the anonymity provided by the web brings out that side of people. It’s just a fact of life on the Internet: if there is an opportunity for a guy to flash his weiner anonymously, he will.

And that’s fine. It’s the way of the world. It’s the way of the web.

But so, my friends, is community moderation.

Enter ChatSnapper

Let’s try an experiment.

1. Follow @ChatSnapper on Twitter.
2. DM or @reply to @ChatSnapper with a link to a screenshot from ChatRoulette (or other online chats) showing offensive (or just weird) behavior.
3. Check posted links and help shine a light on the offenders.

Let’s see if the existence of a rogues’ gallery has any effect on the actions of folks.

If this works, I’ll start calling elevator companies.

ADDENDUM

Alex Bisceglie alerted me to a similar effort: ChatRoulette Cock Map. It includes an app that can track the IP of offenders as well.

The very moment that Alex sent that, I was working on a WebKit browser with screencap and yfrog upload. For now, grab a build at: ChatSnapper – Alpha.

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.

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.”