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.

I’ve often wondered about the gap between the story an author creates and the experience had by readers. I’m not thinking of the changes that come at the hand of editors, but rather the effects of the design and marketing process. The number of words per page, the typography, the stock, the cover – all variables that shape the reading experience.

The Kindle – and probably other e-ink readers – displays all books with the same detachment. All texts are reduced to…text. The typefaces are basically standardized and the font size is under the control of the reader. Even the display of the reader’s current “position” in the story is abstracted from physical page count and instead shown as a percentage. Reading on the Kindle is – and I say this with endearment – like reading a digital copy of the original manuscript on a word processor.

This consistency of presentation along with the nearly non-existent display of covers and marketing effort in the Kindle store leads me to pick more widely than if I were ordering a hard copy online or standing in a bookstore. There’s no distraction. No salesmanship or reification of marketing fluff via design.

I’m sure there is a downside to this, but so far, as a reader, I can’t find it. Each book I read stands on the merit of the words, and the words alone.

It actually feels more intimate, in a way. The reader and the author communicating without much noise in between and around the channel separates the story from the package. It’s cool.

Enter iPad?

Surely, the iPad will help spark new forms of storytelling the same way hypertext helped inspire lit movements. I can’t wait to see the first few generations of touch-based, mobile literature. My mind races happily along each time I imagine journalism, poetry, and prose five years from now.

But, much like a time machine – only able to travel back to the moment it was invented – I think there will always be a place for Kindle-like devices because new interactive platforms will probably just get in the way of texts developed for plain-text display and that classic format is both intensely front-loaded and clearly here to stay.

Amazon was nice enough to give me a link to download Internet Explorer, so at least their user agent sniffing is tuned to perfection!

I don’t believe this will be the case. It’s not so much about the pros and cons of e-ink, backlights, or screen resolution.

To me, the Kindle DX is a brilliant device because it forces me to read a f’ing book.

No dock icons blinking. No compulsive checking of Twitter, email, or stock quotes (or Texts from Last Night).

By offering a limited set of functionality and doing less, better, the Kindle forces me to eschew the kind of distractions that make me curl up with a book in the first place.

Apple can create the be-all, end-all Surface or Canvas or Slate or whatever. I will buy it. I will buy the shit out of it. I’m a developer and UX geek (and yuppie hipster scum) – I have to.

I won’t use it to read novels, poetry, or prose. Magazines and news? Sure. Tech books? Maybe, if live docs and errata were part of the mix. But then, that type of reading is work, not pleasure. Not therapy. That’s where the Kindle shines.

I have looked at (an early version of) the Kindle development kit (the KDK) and though I’m tempted to create apps focused on distraction (Twitter client, anyone?) I don’t think I’d run them. Instead, I’m trying to dream up apps that boost the escapism the Kindle already affords me.

So far, nothing beats the core function: making me crave reading as much as my first library card did.

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?

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.

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.

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.

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 ;)