Meet CRAPCHA.

CRAPCHA doesn’t serve a dual purpose. It barely serves a single purpose. And it isn’t to keep spammers out.

What CRAPCHA does is annoy users by presenting a CAPTCHA with indecipherable text. Nothing new so far? Well, CRAPCHA attempts are posted to the CRAPCHA board, providing amusement for all. You can even click on a timestamp to save one for posterity. Try it out for yourself:

Add To Your Site

If you run a site and want to spring this on your unsuspecting guests, simply copy and paste the following code.

Word of warning, CRAPCHA doesn’t actually validate anything. In fact, it’s very likely drive away users, and will cause mixed content warnings on HTTPS. On the other hand, it’s fun.

Notes

CRAPCHAs are created using a mix of weird Unicode and Font Awesome characters that have undergone CSS3 transforms.

Attempts are saved and retrieved using the lovely service provided by Parse.

You can check out CRAPCHA’s source on Github.

Naturally, my mind went to how this feature could be used for a prank: Replace legitimate app with fake. The fake looks exactly the same, but takes you to an annoying video instead. If you’re feeling really cruel, you surround the one real app with a screenful of imposters.

Spot the Instagram that doesn’t take you to a rendition of “Never Gonna Give You Up”.

I started by making a one-off site, but as programmers tend to do, I decided to generalize it. The result is iRoll.

How to Use

First, choose an app or enter a custom app ID — it uses this to grab any app’s name and icon. To find an app ID, go to the app in iTunes, right-click on the icon to copy the link, and then get the 9-digit number in the URL. For example, the app ID in the link below is 585259203.

Next, give iRoll a destination URL. This can be a Rick Astley video, a Rick Astley image, or anything else on the web.

Then, open the generated link on the target iPhone or iPad. You can email or manually type the shortened URL, or snap the QR code using a QR reader app.

Finally, open the link in Safari and save it to the home screen. In Safari, you’ll find the option by tapping the Send button, which you might have used before to email or tweet a link.

Let’s Talk Design

Technically speaking, iRoll is simple. It takes two inputs, app ID and destination URL, and formats a webpage with the app’s title and touch icon, and a redirect to the destination URL.

But using iRoll can be surprisingly complicated task, especially for the average end user. Sit Grandma down, and have her find an app ID, copy a link from her laptop to phone, and add the page to her home screen. See how that plays out.

So how did I design iRoll to simplify the task for users?

Progressive Disclosure

iRoll takes advantage of progressive disclosure. The task of creating a fake app is presented in simple, discrete steps. As you complete one step, the next comes into view, avoiding the overload that might come with presenting them all at once.

Take advantage of the third dimension. By that I don’t mean the z-axis — which is often ill-advised, but time.

Sensible Presets

iRoll’s design started with two input fields, for the app ID and destination URL. Simple! But getting an app ID is fairly involved, from the nonobvious way to copy an app’s link, to visually parsing the 9-digit number from it. On top of that, there’s a great deal of cognitive load in choosing an app.

To address this, iRoll provides a few preset options for both app and URL. They lower the bar to getting started with iRoll, and signal to users how it can be used.

Provide options that cover what you assume to be the “fat head”, while offering freer input for the “long tail”.

Little Big Details

Finally, the main use case for iRoll is generating a link on your PC, and then copying it over to your iPhone or iPad. Unfortunately, moving digital data like a URL from one device to another still involves a great deal of friction. Recognizing this, I provided a shortened URL and a QR code.

Look for the little touches that can oil the wheels, or simply delight.

It goes to show that what’s initially a simple app to build can morph a great deal once the user experience is taken into consideration.

Notes

App names and icons are pulled from Apple’s iTunes Search API.

URLs are shortened using the is.gd API.

There are a few JavaScript libraries out there for generating QR codes, but qr.js by Kang Seonghoon worked best for me.

Check out the source code on GitHub.

Cinnamon.js prevents just this situation, taking some of the pain out of naming things. It allows users to find links, images, and other content by their synonyms, using the browser’s built-in Find function.

Demo

To see it in action, search this page for “Twitter”, “Spice”, “Email”, or “Contact”.

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Pellentesque cursus orci ut mi laoreet rhoncus. Pellentesque congue urna tincidunt tortor rhoncus dapibus. Duis faucibus dolor a sem ultrices at facilisis risus cursus. Cras vel euismod nisl. Ut vitae risus et libero sagittis ultrices et vitae ligula. Follow me at @thomashpark. Aliquam at turpis id diam placerat consequat at vitae est. Aenean tellus magna, lacinia vitae facilisis facilisis, egestas ut sapien. Pellentesque habitant morbi tristique senectus et netus et malesuada fames ac turpis egestas. Reach me here. Donec tincidunt dapibus dui luctus rhoncus. Nam sagittis egestas blandit. Nulla imperdiet tincidunt enim, a tempus sapien volutpat a. Maecenas sed elit ipsum, ut tristique odio. Suspendisse potenti.

Photo by kobiz7

Download

You can download the script or view it on GitHub below.

Usage

Add Cinnamon.js just before your body’s end tag. Then wrap your element of choice (span tags are recommended) and give it a data-cinnamon attribute with a comma-separated list of synonyms as its value. If you wrap an image, its alt text will also be used, as in the image above. Cinnamon.js works on modern browsers and IE8+.

Here’s an example:

Notes

This is meant to be a proof of concept, and you probably shouldn’t use it in production. Hidden text, used deceptively, can be penalized by Google. Precisely what’s counted as deception is anyone’s guess, but there’s a risk that it’s deemed a dirty SEO tactic even if it is not intended as such.

Cinnamon.js doesn’t hurt accessibility; it uses aria-hidden to tell screen readers to ignore the synonyms.

In the course of testing, one thing I discovered was that Safari handles in-page search quite differently from other browsers. Safari doesn’t search for strings mid-word unless the word uses CamelCase. When highlighting matched text, it ignores certain CSS properties like overflow, opacity, and z-index. Highlighting is semi-disabled by setting -webkit-user-select to none.

Check out the source to see how it works.

Some questions: Do regular people even use their browser’s Find function? Is the user’s reliance on the Find function a symptom of poor design, or is there room for better in-page search as there has been for site and web search?

Updates

• 26 February 2013: I wrote an article with Robert Nyman about this for Mozilla Hacks.
• 5 March 2013: David Artiss has packaged Cinnamon.js up as a WordPress plugin.
• 25 March 2013: Michael Kutschall is making some promising strides with an empty font approach. He goes into more detail in a blog post.

With books, there are downsides to going digital, but perhaps the greatest upside is that they become omnipresent. You can load up all your books on all your devices. A thousand ebooks weigh the same and take up the same physical space as one. Anyone who’s dealt with textbooks or moved recently will attest to the value in that.

Unfortunately, not all books are available in digital format, and may never be. And you’ve got all these expensive books already sitting on the shelf. You could DIY and build your own book scanner (costing anywhere from $300 to $1,500), but is there an easier way?

At Your Service

Enter 1DollarScan. As their name suggests, books can be scanned for as little as $1. How it works is that you mail them your book, and they scan it and send it back as a PDF.

This is a destructive process, where the book spine is cut off to improve and expedite scanning. In other words, you won’t be seeing your book again. If that’s a dealbreaker, there are services offering a non-destructive option, but expect to pay a premium.

Pricing is $1 per 100-page “set”. Options include OCR for $1 per set, high resolution (600 dpi) for $2 per set, and touch-up such as angle correction and compression for $2 per set. There’s also a free automated feature called Fine Tune that optimizes scans for target devices like the iPhone, iPad, Kindle, and Nook.

A First Pass

I have several books I’d like to digitize, but started with Interaction Design: Beyond Human-Computer Interaction. It’s a book I use at regular but infrequent intervals, weighs in at a hefty 3 pounds and 600 pages, and for which an official ebook is not available. This makes it a prime candidate.

Quality

Here’s how the scan turned out. The PDF shows exactly how it looks. As you can see, it’s very good quality. My only criticisms are that the scan is slightly askew, and the text is fainter than I’d like it to be (possibly due to the slightly glossy finish of the pages). There’s the touch-up option that promises to be even better, but I was satisfied without it.

Just for fun, here’s what you get with Google Books, who does their own scanning:

And the scan of the 2nd edition I was working with before:

OCR

OCR is key for being able to search within a book and copy text out of it. I sprang for the option so I could compare their job (top) with my own using Adobe Acrobat Pro 8 (bottom). Both do an excellent job, with only an extraneous space added in the header by Acrobat. However, notice that 1DollarScan’s OCR leaves hyphenation as is, while Acrobat joins each word together. This gives Acrobat the edge in finding these words in a text search.

11.7.1 Design Patterns for Interaction Design

Design patterns capture experience, but they have a different structure and a different phi-
losophy from other forms of guidance or specific methods. One of the intentions of the pat-
terns community is to create a vocabulary, based on the names of the patterns, that designers
can use to communicate with one another and with users. Another is to produce a literature
in the field that documents experience in a compelling form.

The idea of patterns was first proposed by Christopher Alexander, a British architect
who described patterns in architecture. His hope was to capture the 'quality without a name'
that is recognizable in something when you know it is good.

11. 7.1 Design Patterns for Interaction Design

Design patterns capture experience, but they have a different structure and a different philosophy
from other forms of guidance or specific methods. One of the intentions of the patterns
community is to create a vocabulary, based on the names of the patterns, that designers
can use to communicate with one another and with users. Another is to produce a literature
in the field that documents experience in a compelling form.

The idea of patterns was first proposed by Christopher Alexander, a British architect
who described patterns in architecture. His hope was to capture the 'quality without a name'
that is recognizable in something when you know it is good.

Here’s another comparison of 1DollarScan’s OCR (top) with Acrobat Pro’s (bottom), for a different font. They make the same four errors.

Figure 11.23 The LilyPad Arduino kit. lt comprises sensors, actuator boards, and conductive threao.
Online tutorials are available that enable anyone to build their own (see web.media.mit.edu/-leah/
LilyPad/build/turn_signaljacket. html)

Figure 11.23 The LilyPad Arduino kit. lt comprises sensors, actuator boards, and conductive threao.
Online tutorials are available that enable anyone to build their own (see web.media.mit.edu/-leah/
LilyPad/build/turn_signaljacket. html)

My advice is to skip the OCR option and run it yourself if you have a program for it.

Fine Tune

Fine Tune is a free service offered by 1DollarScan that targets specific devices through compression, margin removal, resolution optimization, and character optimization. The original scan comes in at 332 MB, compared to the iPad at 88 MB, iPhone at 63 MB, and Kindle at 30 MB. The iPad-optimized version looks pretty close to the original. On other devices, there are more substantial changes.

Here’s a comparison for the iPhone, with the original on the left and the fine-tuned version on the right. The margins, including running headers and page numbers, have been cropped out. It doesn’t account for the iPhone 5′s larger screen yet however.

And here’s a comparison for the Kindle Touch.

It’s a tough call. The optimized version has a smaller file size and makes better use of screen real estate, but there is noticeable artifacting and distortion. Since it’s free, you can try both out and decide for yourself.

Price

With 6 sets and the OCR option, the total came to $12. Shipping via media mail tacked on $3. Not one dollar by any means, but not costly either. And by far the cheapest book scanning service out there. For a 200-page book without OCR, you’re looking at about $4 including shipping.

Turnaround

1DollarScan is located in California. With media mail, it took 8 days for the book to reach them from Philadelphia. Once it arrived, turnaround was a single day.

Legality

Scanning a book you have legally acquired for personal usage would appear to fall under fair use, just the same as ripping a CD you’ve bought. 1DollarScan requires you to include a signed agreement form with the book declaring the same.

Parting Thoughts

For certain books, there’s no substitute for touch of the printed page. But for most, the convenience of an ebook trumps all. And as the technology and design of ebooks marches forward, while publishers use cheaper and cheaper materials for print, this will increasingly be the case.

If you’re considering digitization, 1DollarScan is a good choice. In fact, I’ve got a few more books on the shelf that I intend to get scanned in the near future.

Similar to folders in iOS, this effect lets users to scan a list of items and open one up in place. This has advantages over more traditional pop-up windows and mode changes, which can obscure content and cause the user to lose their place in the list.

A second aspect of this feature is that it uses content to enhance the chrome. In the detailed view, the background and text colors are generated algorithmically from album art. This not only serves a practical purpose in making the detailed view stand out from the list, but creates a nice (in most cases) aesthetic effect and a sense of feeling that differentiates one album from the next. The intrepid Seth Thompson and Wade Cosgrove have already recreated this, using Mathematica and Cocoa respectively. Apple’s algorithm, it turns out, is pretty sophisticated.

Here’s my take, using HTML, CSS, and Javascript.

And you can check it out for yourself here:

Details

The demo is built with App Folders, with behavior and style modified to mimic iTunes. Color Thief is used to derive colors on-the-fly from album art using a median cut algorithm. On top of this, I selected colors for acceptable contrast by converting RGB to YIQ, a color space that better reflects human perceptions. Last but not least, Mustache is used to pull album data from a JSON file into templates.

I got to play with several exciting HTML5 and CSS3 properties in making this demo, including text-overflow, multi-columns, transitions, animations, and canvas. Unfortunately, this means the demo requires a modern browser. The future can’t come fast enough.

Inside Apple, tension has brewed for years over the issue. Apple iOS SVP Scott Forstall is said to push for skeuomorphic design, while industrial designer Jony Ive and other Apple higher-ups are said to oppose the direction. “You could tell who did the product based on how much glitz was in the UI,” says one source intimately familiar with Apple’s design process.

But before Forstall, it was Steve Jobs who encouraged the skeuomorphic approach, some say.

Skeuomorphism can be a powerful thing. It can communicate purpose and create emotional resonance. But it can go too far, focusing on how the software looks at the expense of how it works or feels. Apple has been criticized for just this with its recent offerings. Reportedly, they’ve gone so far as to demo a virtual paper shredder used when deleting e-tickets.

Now we’re seeing things shake out. Forstall is being “phased out” and Jonathan Ive, known for his understated hardware designs, is adding UI to his responsibilities. This move signals that the pendulum of skeuomorphism is about to swing back in the other direction, though it probably won’t be as extreme as Microsoft’s flatland or Google’s whiteout.

If all the wood, suede, felt, and yes, even linen, are to go the way of brushed metal, Ive has a lot of work ahead of him. For some apps, it might be a matter of reskinning the interface. But for most, whole models of interaction, currently built on strained metaphors, will need to be rethought. The following apps should be at the top of Ive’s to-do-list.

Podcasts

The tape reel, while well-made, is a waste of real estate and confuses what is and is not an active element. For instance, would you have guessed from the screenshot that you can drag the thin red scrubber, but can’t tap the progress bar to jump to a different spot? All the while, basic functionality like shuffling podcasts or sorting them from oldest to newest is absent.

Game Center

Like the Podcasts app, it’s not evident in Game Center what’s interactive or not. The ribbons at the top aren’t, while the ribbons at the bottom are. So is the photo at the top. The felt and wood theme is cheesy, fitting for a 99-cent poker app rather than the official hub for games of all types.

Find My Friends

The less said about the stitched leather, the better.

iBooks

While the skeuomorphism in iBooks isn’t quite as objectionable, it has represented a philosophy of keeping faithful to the dead-tree analogue. Contrast its page effects with the Kindle, where everything besides the text fades away. The scroll mode recently introduced in iBooks 3 suggests that Apple’s philosophy may have already started to change.

Calendar

With Mountain Lion, the stitched leather is thankfully gone but the torn paper remains. The desk calendar metaphor, unfamiliar to anyone under 20 anyway, falls aparts immediately with radio buttons, check boxes, and scroll lists.

Contacts

Similar criticisms to Calendar can be applied to the OS X and iPad versions of Contacts. The heavy-handed interface screams “book”, but it turns out to be a magic book with scroll lists and embedded buttons that slide panes in and out of the page.

Photo Booth

Fortunately Photo Booth is not a critical app, but the velvet curtains and gold thumb-wheel rank with the stitched leather.

One Last Thing

iTunes doesn’t deserve to be on this list, but warrants special mention. Over the years, it’s grown from an MP3 player to Apple’s most important application. But this growth has been organic, and new functionality has been layered atop the old, creating a complicated interface in desperate need of overhaul.

In fact, Apple announced in September that a completely redesigned version was coming this month (though it looks like that target will be missed), and posted a preview on their site.

The new iTunes, as they call it, is minimal. It shows no symptoms of extreme skeuomorphism. And perhaps it will be the first real taste of things to come under Ive’s reign.

Getting your content on the HN front page can be a big deal, a fact that hasn’t escaped spammers. To keep them at bay and maintain the quality of the site, moderators have had to be quite active. And whether you’re in agreement with it or not, it’s fair to say that they’ve operated opaquely, from hellbans to the slap — where a submission rises to the front page, and just as quickly vanishes from it.

Mods can kill a submission and instantly send it into oblivion. But more marginal submissions can also be flagged by mods or users for being off topic, low-content fluff, spammy, or otherwise poor quality — or perfectly valid submissions by those who disagree with it. This can even happen to articles occupying the coveted top spot, with plenty of points and a lively discussion. If enough mods and users flag it, it’ll quietly slip down the rankings and off the front page.

From the perspective of the community, these are silent failures. They’re a missed opportunity to learn how the flag feature is being used and what content the community does (or more to the point, does not) value. If you’ve been visiting HN for awhile, you might feel that you’ve already developed a sense for how things work. But as a recent analysis of HN shows, the reality can surprise you.

A User Script

I wrote a user script that highlights the submissions that have been on the receiving end of the slap. The script inserts scores based on the HN ranking algorithm, a function of each submission’s points and age. Submissions ranked below others with half their score are highlighted in red; a rough heuristic but definitely indicative of being slapped down. Weaker candidates are highlighted in orange; while they may have penalized, it could also be explained by the algorithm being out-of-date or incomplete (it is).

The script also works on the Hourly HN Snapshot archive. Try it out on past frontpages, like October 27, 2011.

Installation

You can get the script here: http://userscripts.org/scripts/show/150452.

Install it in Chrome either by downloading the file and dragging it into the Extensions tab (sadly, user scripts can no longer be installed directly), or through the extension Tampermonkey. Firefox users can install through Greasemonkey.

It seems as long as there’s been the web, there’s been text tutorials on coding. But now we’re seeing the rise of lecture videos (see iTunes U), massive open online courses (see Coursera), and interactive tutorials (see Codecademy). I’ve sampled them all, but what’s hooked me lately is watching pros at work — most recently 37signals designer Ryan Singer as he designs and prototypes a UI.

Aside from the satisfaction of watching a master of his craft, these videos offer learning opportunities that would be edited out in more structured tutorials and polished lectures. Here are a few things I picked up from the screencast, things I wouldn’t have gotten from other sources on the subject.

Taking in the Environment

Many tutorials skip over the tools, provide their own simplified version, or go with the standard and most widely used. And this may well be the right approach for beginners. But for those with a bit more experience, it can be both fascinating and instructive to peer into the environments that developers have shaped to their needs and idiosyncrasies.

• Ryan carries out the screencast on his own machine (or at least his loaner). For prototyping, he uses Rails to take advantage of SCSS and templates, along with the hassle-free dev server Pow.

Tricks of the Trade

While small tricks make good blog fodder, tutorials usually don’t leave room for them. Screencasts bring them to life, set in a greater context.

• Ryan would switch from code editor to Photoshop depending on what he wanted to mockup. On his Mac, he copied the browser window directly to clipboard a la Windows. I was familiar with command-shift-3 to save a screenshot to file and command-shift-4 to save a region, but didn’t know you could skip the file by adding control to each key combo.
• In Photoshop, he experimented with the width of elements by selecting an edge, holding down command-option-shift, and then arrowing in the direction he wanted the element to expand. Another must-know for designers.

Resolving Issues

Screencasts often center on ill-defined problems that are rife with unanticipated issues. These issues can make for teachable moments in how to troubleshoot and resolve them effectively.

• At one point, Ryan wasn’t happy with where the header was breaking into two lines, but wanted to avoid a break tag if possible. The facilitator mentioned the HTML5 word break opportunity element, which neither Ryan or I were familiar with before.

As an Aside

Given airtime, most pros will inevitably expound on some higher level-issues about the field or community. In measured doses, these asides can be thought-provoking and reveal the bigger picture.

• Ryan discusses patterns for marking up sections like the one below. Do you tightly wrap the section content, or include the section header so the whole section is neatly encapsulated? He proposes a solution that’s sometimes used at 37signals, but explains that a good pattern hasn’t really been established yet.
• A few minutes later, he talks about the semantic baggage that ordered and unordered lists bring compared to divs.

Conclusion

I hope we see more of these videos of designers and developers in action. With so many people relying on online learning and parlaying that into professional work that might also be remote, these videos help recover some of the tacit knowledge that’s been lost in other, more refined resources.

If you haven’t already, check out previews for the rest of PeepCode’s Play by Play series. Minecraft-creator Notch’s marathon livestreams are an epiphany, and Chris Coyier’s redesign of CSS Tricks, which has been successfully funded on Kickstarter, is another one to look forward to.

If I knew so many eyeballs would be on it, I’d have spent more time getting things right. It looked nice enough, but I knew that it didn’t work right. After that initial wave of attention subsided however, I decided to leave well enough alone, apart from adding the odd new store. It was a side project after all.

And that went fine, until Apple revised their site with high-resolution images. Now the images were larger and cropped wider, meaning new stores no longer fit with the rest. So I started digging into Apple Storefronts again last week. At first, it was just to update it with the new images. But then I couldn’t help myself, and it snowballed into more.

More Changes

With the new, larger images, you see the trees more so than the forest. To address this, I added a toggle between two sizes, as well as a toggle for the labels.

In addition to the old country and state filters, you can filter by year now, and sort by oldest or newest. And these views are mapped to different URLs, meaning you can save and share them.

Then there’s the interface. I wanted the site to work better on mobile, so I adopted as my framework the tried-and-true Bootstrap. This also allowed me to use the Slate theme I created on Bootswatch for the visual design.

The new features forced other interface changes. The old navbar was overloaded with links, and now I needed to make room for more. Where to put it all, especially on mobile? My solution was to move primary filters to a drop-down menu, but keep secondary filters out. Instead, they can be accessed by clicking a particular state or year on a label.

Lastly, there’s been a host of performance improvements and a streamlined update process, thanks to Google App Engine and Django’s templating system.

So tweaked images… and then all this: version 2.0 of Apple Storefronts.

What’s Bootstrap Again?

Bootstrap is a popular web framework made by some talented people at Twitter. It allows even the most time-constrained and design-impaired to create nice-looking sites.

As more and more sites adopt Bootstrap though, a growing issue is the uniformity between them. You might already recognize the signature black bar and blue buttons. Here are a few examples, taken from Built with Bootstrap.

My goal with Bootswatch is to enable developers using Bootstrap to try on a new look, without investing much time or energy. The best thing about it is that it doesn’t significantly alter your code or your workflow.

So how do I use Bootswatch?

First, head over to Bootswatch and pick a swatch. Download the bootswatch.min.css file associated with it.

In Bootstrap’s CSS directory, you’ll find a stylesheet in full (bootstrap.css) and minified (bootstrap.min.css) forms. Rename them or move them to a safe place. Then drop in the new CSS file and check that your HTML points to it. If you ever change your mind, simply drop in another swatch or switch back to the original.

What if I want to extend Bootswatch?

Bootswatch is an open source project, and you’re welcome to modify the swatches further or create your own. If you’re interested, fork or follow the GitHub repository.

Each raw swatch consists of two LESS files. One is variables.less, which is included by default in Bootstrap and allows you to customize these settings. The other is a new file called bootswatch.less that introduces more extensive changes.

First, add these two files to Bootstrap’s own LESS files. You’ll be overwriting the default variables.less.

Next, open up bootstrap.less and just before the line “Utility classes” at the end, add @import "bootswatch.less";. This command includes bootswatch.less when compiling the LESS files to CSS, and placing it near the end overrides earlier styles with the same CSS selector specificity.

Now you can start customizing variables.less and bootswatch.less. You are also free to modify the other LESS files, which in some cases will be easier, but your swatch may become brittle to future changes in Bootstrap itself. When you’re ready to test your code, compile to CSS and enjoy!

Update

Check out my article on Smashing Magazine about Customizing Bootstrap.

This got me to wonder how startups are dealing with this. From reading the news, it seems as though more and more are going with alternative TLDs like .me and .us. Many are even using domain hacks to turn this weakness into a strength. Are we reaching a tipping point with alternative TLDs, given their increasing visibility and viability?

To find out, I went to CrunchBase and collected the domains of 1,000 companies founded in each year from 2005 to 2011¹. Of course there are other factors at play in this sample, but it’s a fairly good way to uncover domain trends in the startup world.

What I found was that .com (in blue below) dominates, same as it ever has. The recognizability and prestige of .com is a powerful, self-perpetuating thing. For the past seven years, it’s hovered at 85 percent with little sign of dropping. About 50 other TLDs nibble on the leftover slice of pie. Mouse over the graph for more details.

Have startups been using the B-list TLDs, .net and .org? Only a bit. About 2 percent of startups use each, although while .org is finding a niche with NGOs and the like, .net may be falling out of vogue (relatively speaking) in recent years.

And here’s a closer look at an assortment of TLDs that seem to be popular with startups. Ironically but perhaps unsurprisingly, .biz is a flop, while .me, .io, and .co enjoy upticks in the last year. It remains to be seen if this is part of a larger trend.

For startups, one strategy might be to grab an alternative domain cheaply to start with, and to acquire the .com version when you get funded down the line. But with alternative TLDs hardly making a dent, it’s evident that having a .com is a priority right from the start, and that they’re perhaps willing to compromise their name to ensure that they land one.

Despite the crowding on .com, it turns out that domain names aren’t getting any longer. Here’s a graph showing that there’s even a slight decrease in the number of characters since 2009.

To keep domain names short, there’s certainly much of the same creativity with naming startups today as Paul Graham noted back in 2006. And despite the influx of alternative TLDs, startups are, for the time being, still dotcoms.

What makes a badge well-designed is that it communicate a bit of timely information in a punchy way. This is accomplished through consistency and contrast. Consistency helps users to recognize a badge by sticking with a standard look and position. Contrast helps users to notice a badge by choosing a color and shape that stands out from the content.

Facebook is one example that achieves both consistency and contrast, though they have it relatively easy. Given the monochromatic context, nearly any splash of color will do.

Apple and Netflix have a tougher job because their badges are applied to wildly varying content. In iOS, Apple overcomes this in two ways. First, they give the badge a drop shadow and border that contrasts with the badge itself, making it stand out whether it’s applied to an icon that’s dark, light, or nearly any combination of colors. Second, Apple offsets the badge to a position that’s outside the bounds of the icon. This alters the icon’s silhouette and, more importantly, creates a separation between metadata and object.

Netflix does neither, and the result is that as you scan through their offerings a screenful at a time, the badges hardly stand out.

A challenge faced by Netflix stems from the semantics of their badges. Instead of communicating a number or simple alert, they need to depict “New Episodes” and perhaps other meanings like “New to Netflix” and “Expiring Soon”, for which there aren’t standard symbols, yet¹.

Netflix’s has an amazing track record, designing slick interfaces for over 400 different devices. They can do much better with their badges.

Tap

Kindle Touch uses a system of invisible tapzones called EasyReach.

Tap right zone: Next page
Tap left zone: Previous page
Tap top-right zone: Toggle bookmark
Tap top zone: Book options

Hold

Hold: Dictionary + text options

Hold and drag: Text options

Swipe

Swipe right: Next page
Swipe left: Previous page
Swipe up: Next chapter
Swipe down: Previous chapter

Pinch

Pinch together: Decrease font size
Pinch apart: Increase font size

The values are dubbed manliness, maturity, bling factor, ageness, fun, volume, complexity, and in-your-faceness in the source code, and they’re input via sliders on an integer scale from -5 to +5.

The sliders seem like a good idea, but I began to wonder about them. To what extent do contest holders really use them? What values do businesses wish to communicate? Are they useful to designers?

All of the design briefs on 99designs are publicly accessible, so naturally the research side of me took hold. To get at the questions above, I ended up scraping slider data for the last 999 contests¹.

To what extent are the sliders used?

I’m starting with the assumption that a slider left at 0 is unused, in the sense that the contest holder doesn’t particularly care either way about that value. The table below tallies up the number of sliders used in each contest.

It turns out that in 95% of contests, at least one slider is used. However, the modus operandi seems to be to pick a few values to emphasize, while skipping over the rest. Only in 9% of cases are all eight sliders used. On average, it’s closer to five sliders.

Is there variety in the responses?

Even if contest holders are using the sliders, it’s not very informative if they’re all using them to give identical responses. Here’s a breakdown of how each slider is used by percent and standard deviation, which gives a taste of how diverse the responses are.

Far and away, 0 is the most popular choice for every value, reaching 50% for a few. None too surprising given that it’s both the neutral answer and the default. Still, there is a fair deal of variation.

Some of the values are heavily skewed (e.g., ageness, complexity). This could be a matter of terminology (“complex” might hold a more negative connotation than a term like “detailed”), or simply the prevailing trends.

How do values relate to one another?

To explore correlation between values, here’s a table of pairwise comparisons.

As you can see, fun tends to be associated with youth and masculinity. Volume & in-your-faceness also have substantial overlap.

If a value needed to be made redundant, a strong case could be made for either volume or in-your-faceness, given all of the data above.

What else?

Of course looking at how contest holders use the sliders is only half of the conversation. The other half is to ask as designers: Do you actually pay attention to these sliders? Is it only when a response is at an extreme? Which values contribute most to your practice? Would any other values would be useful to you?

It may seem like a totally unremarkable feature. But here’s why Google deserves credit for it.

It’s Uncommon

Density control is surprisingly rare. It’s not to be confused with zoom, which is found in all sorts of applications from web browsers to Office. Zoom enlarges everything, whereas display density changes only the spacing between things. In Reader for instance, comfortable, cozy, and compact all use a 13-pixel font, but give items a height of 37, 31, and 27 pixels respectively

Only spatial file managers come to mind as another example. Though I’m sure there’s a laundry list of others I’ve forgotten.

It’s Useful

The old Gmail and Reader were most like the compact setting, packing lots of information into the available space. Yet it’s apparent that Google’s designers now prefer comfortable as the default for desktop resolutions.

Many power users want information density at all costs, while others want the greater accessibility or readability or aesthetics that spacing brings. People can be extremely sensitive to these preferences, especially when dealing with changes to a familiar interface (the Twitter iPhone client is a recent case of this). And this is where density control comes in.

Instead of a temporary measure meant to appease a grumbling user base, I hope this is a sign of what’s to come in other Google products. Users of Search, Docs, and News could also benefit from density control. In fact, it’s something we should see more of in general, particularly for information-dense applications.

With that said, here’s my quick review of it so far, with a few ways Amazon could make it that much better.

Touch

Most smartphones and tablets rely on capacitive sensors embedded directly in the display, but the Kindle Touch has infrared sensors set in the bezel. Whereas capacitive touch can distinguish skin from other forms of contact, these infrared sensors detect nearly anything as a touch event. The upside is that you can use the Kindle Touch while wearing gloves or with any pointy thing as a stylus. The downside is that other materials like the fabric of your sleeve can accidentally trigger it. These are more side effects though, of Amazon using infrared sensors to preserve the quality of the E Ink display.

The Kindle Touch touts a range of multitouch gestures. Taps are used for page turning, item selection, and the soft keyboard. Swipes can also be used to turn pages, and to scroll elements that extend offscreen. Pinch allows you to adjust text size and zoom into a webpage. In terms of recognizing these gestures as input, it’s fairly reliable and precise.

One thing that has made iOS so successful is its use of direct manipulation — that is, fine-grained (essentially continuous) gesture input, mapped closely to the system’s feedback, which models some physical phenomenon. Apple was able to create the illusion of manipulating elements as if they were physical, and they accomplished it having iOS be extremely responsive to the user’s gestures.

However, the Kindle’s E Ink display, you may be aware, is slow. Refresh rates measure in the hundreds of milliseconds, compared to 17 milliseconds for devices like the iPhone and iPad. So with the Kindle Touch, Amazon has wisely used multitouch gestures more to invoke discrete commands than for continuous direct manipulation. What this means is that a swipe, no matter how fast or far, moves the carousel of books three places; each pinch enlarges text by one size. The exception is the web browser, and there’s a reason that’s still experimental.

Form Factor

My first thought upon opening the package was that the Kindle Touch is even smaller than I imagined. With each successive model, Amazon has shrunk the form factor down while keeping the 6-inch display intact. It’s gone from 8.0 × 5.3 inches in the first two generations, to 7.5 × 4.8 in the Kindle 3, to 6.8 × 4.7 in the Kindle Touch (Kindle 4 is smaller yet).

While greater portability is nice, it’s past the point of diminishing returns. I’d like to see the next version of the Kindle Touch return to the original form factor – with display enlarged – making it roughly the size of a large paperback. Reading books would be made more comfortable, navigating the library and store even more so.

Home Button

Setup is dead simple, but afterwards I got stuck for longer than I care to admit on how to access my library. I eventually realized that what I had assumed to be a speaker was no speaker at all.

A silly oversight on my part to be sure. But as bad as it is to make buttons non-obvious in software, it’s that much worse in hardware. TV makers, are you listening?

Book Covers

I was disappointed to learn that the library can’t display book covers. I don’t know where I got that idea from.

Oh, right. Amazon, please add this option for when we’re using your books, not just when you’re selling them to us.

X-Ray

One of the value-added features the Kindle Touch offers is X-Ray. Amazon analyzes each book and presents key people, places, and things, background information on them, and where they show up in the book.

Not all books support it yet, but Amazon doesn’t tell you which do and don’t. (As of this writing, The Man Who Mistook His Wife for a Hat does, Consider the Lobster does not). Under the “Text-to-Speech” bullet point seems as good a spot as any.

The Other Kindle

Overall, I’m highly satisfied with the Kindle Touch. But if you’re in the market for an e-reader, the Kindle 4 is also worthy of consideration.

At the time, most analysts considered Apple’s fledgling retail initiative to be doomed. But though Tysons Corner seemed like a modest start, it was a blueprint for big things to come. 357 stores and counting later, Apple is tops in sales per square foot, and they did it by applying many of the same principles as they do to their products: natural materials, understated aesthetics, and innovative processes.

Anyway, one thing I wanted to do was go back and see how Apple storefronts have evolved over the past decade. I couldn’t find anywhere to do this easily, so I decided to create a gallery myself. Check it out here:

http://applestorefronts.appspot.com/

Scanning the gallery, you can see that Apple follows certain conventions, but isn’t shy about breaking them. They’ve tweaked things here and there, and are quite audacious with their flagship locations. (By the way, is “flagship” a formal designation, and is there a list of them somewhere?)

What are your most or least favorites? What do you love or hate about them? Do you notice any trends? What do you think is Apple’s next step?

Notes

Images collected from Apple.com with Beautiful Soup. Opening dates courtesy of ifoAppleStore. The gallery uses Lazy Load by Mika Tuupola and is hosted on Google App Engine.

1. Reader: read RSS items
2. Linkroll: share RSS items with friends
3. Social network: converse on these shared RSS items with these friends

What was nice about this is that you could exchange and comment on posts within the flow of reading them.

Unfortunately, Google has cut the social features from Reader in an attempt to funnel users to Google Plus. I’m only annoyed, but it’s left some people really upset. Here’s a way to restore some of this functionality, until a suitable replacement comes along.

A Workaround

First, you’ll need an account with a bookmarking service. Delicious is free, but Pinboard is well worth supporting. After you’ve signed up, go into “Reader settings” in the top-right corner, click “Send To”, and “Create a custom link” at the bottom. Add one of these as your URL:

If you want to go all in, name it “Share in Reader” and give it this icon URL:

Get back to Reader and now you’ll have a familiar “Share in Reader” option at the bottom of each article. When you share something, there’s a field to enter comments, although two-way conversation isn’t possible.

You can also use bookmarklets to share any page you happen to visit, just like old times. Drag Delicious or Pinboard into your bookmark bar.

Give your friends your new feed, which will look like one of the following:

If you want to keep your shared links from being discoverable, you can dig up a private feed link for these services as well.

Have your friends create their own, store them in a “People you follow” folder, and you’re back to good.

A downside of this is that it can take an hour or two for the feeds to refresh. But if you want to resist the will of a mighty company like Google, while continuing to use their service, it’s going to be an uphill battle.

Our point of view is that both portrait and landscape orientations are important, and experiences can be great in either orientation. Rather than picking a posture and orientation for optimization, we designed an experience that makes sense regardless of how the device is held, one that feels tailored for the app and its content.

Ignoring that the first Windows 8 tablet from Samsung has its hardware button positioned to make landscape the default, and the packaging to reflect that (in contrast to the iPad), Sinofsky’s response still rings true. This informal survey from Ben Brooks further underscores his point.

This naturally leads to questions about when and why people might favor one orientation over the other. Most users probably hold their tablets in landscape to watch videos and in portrait to read long-form text. But what about for all of the other ways tablets can be used?

Some Stats

Since I’m not privy to data that might answer this, I thought an interesting proxy might be to look at how apps are presented in the App Store. Do apps tend to feature screenshots in one particular orientation? Are there patterns among certain classes of apps? This reveals a bit about how apps are designed to be used or how the developers idealize it.

I went through the top paid iPad apps, as well as the top 25 for each App Store category, and classified each into one of five categories: all of the screenshots are portrait, or landscape; most (all but one) are portrait, or landscape; and they’re about even (more than one of each).

Here’s how the 200 top paid apps look.

Surprisingly, only 21 percent show off their app in both orientations.

Despite the primacy of portrait in Apple’s iPad marketing, the majority of top paid apps use landscape in theirs, at least within the App Store. That’s no guarantee of course that this is how people spend most of their time on their iPads, using these and other apps.

Not all categories are represented equally in top paid apps, which happens to be extremely game heavy. By looking at each App Store category individually, a better picture emerges of the diverse ways that iPads are held and used.

Platforms today are recognizing that great user experiences have the potential to be created in either portrait or landscape, and this is certainly an important first step. But this graph renews questions about when and why developers choose one orientation over the other, and what opportunities there are for both new and existing apps to make better use of the available space, however the tablet is held.

Given how only 21 percent of iPad apps show themselves off as fluid between landscape and orientation, one wonders if Windows 8 developers will be up to the task of building apps in both orientations, plus the snap and fill views, for so many resolutions and aspect ratios — and doing it well.

It begins with a discussion on how Windows Explorer is used today. Through telemetry data — “based on hundreds of millions of individuals opting in to provide anonymous data about product usage” — Microsoft finds that the top 10 commands make up 81.8% of use, and that these commands (e.g., paste, properties, copy) are primarily accessed through the contextual menu.

The development team combines this with customer feedback on the top requested features, and uses this to justify the changes from Windows 7…

…to the design below.

It seems that essentially, every single command that customers have used or requested has been moved into a ribbon or wedged into some corner of the chrome. And many are rightfully lambasting it.

But, you might protest, they did research! With users! And got a ton of data! So how did it go wrong?

The IROP Keyboard

By focusing user research on low-level operations with the old system, and using that as the starting point for the redesign, you end up merely resizing, rearranging, and removing parts of the interface. You don’t make the quantum leap, and you sometimes make things worse.

I’m reminded of a recent paper by Andreas Zeller, Thomas Zimmerman, and Christian Bird (the last two authors from Microsoft Research, ironically) titled Failure is a Four-Letter Word: A Satire in Empirical Research.

In the paper, the authors collect keystroke-level data in Eclipse and correlate it with programmers’ errors. They find this data to be an excellent predictor, with the letters “i”, “r”, “o”, and “p” guilty of the strongest correlations. Based on these findings, they come up with a cheeky solution for reducing programmers’ errors:

The IROP keyboard addresses the data, quite directly. But it obviously misses the deeper problems.

From Actions to Activities

In the vocabulary of Donald Norman, operations combine to make actions, which make tasks, which make activities. According to this scheme, Microsoft has with their data looked at actions. The key is to start higher up this hierarchy, considering the activities users are engaged in and the goals they’re trying to achieve.

Windows Explorer is gradually being sunset, so they get some slack here. But I sure hope they aren’t being steered wrong elsewhere by their user research.

I learned that this is a common way of randomizing things in Asia. In Korea it’s called 사다리, in China 畫鬼腳, and in Japan 阿弥陀籤. The Korean and Chinese translate to ghost leg, their poetic word for “ladder”.

How it works is this. You list the things you want to randomize at the top of your paper. You write the categories you want to randomly place them into at the bottom. Draw vertical lines connected each pair — these make up the “legs” of the ladder. Then randomly draw in “rungs”, or you can fold over the options to cover them up and have someone else do it. Once that’s done, follow each path down the ladder, taking every rung you reach. This post gives a visual step-by-step of how it works, and this paper offers a mathematical analysis.

What I decided to do was create an interactive web version of this. I started with an HTML table, which leads to a few benefits. Since a table is already a grid, it’s straightforward to style it using CSS. The image above shows the result.

Also, instead of dynamically creating the table, I made it so anyone can easily make their own table with labels and as many columns and rows as they like. Then by simply assigning it to the “ghostleg” class and copying over the JavaScript and CSS (which you’re welcome to do), they can have their own customized version. By using thead and tfoot, the section of the code to input all your labels is right at the top, not buried in the table markup.

I looped through each table row, counting the number of cells and picking a random place to draw a rung (or skip the row). Finally, a hover function was attached that highlights the path from each item to its random outcome.

Play around with Ghost Legs, or have a look at the code.

This sounds simple, and it is if your circles are static. But things start to get hazy when your circles have changing memberships.

Is posting to a circle like sending email? In this model, each message is sent off to everyone who’s in the group at that particular time. When you add someone to the group, they get access to messages sent only while they’re a member. When you remove them, they get to keep those messages but nothing more.

Or is it more like giving out keys to a locked diary? Facebook walls and protected Twitter feeds fall into this category. When you add someone to the group, they get access to all of the accumulated content up to that point, past and present. When you remove them, the system revokes their access to all content.

It turns out that when you add someone to a circle in Google Plus, they get access to all of the content that’s ever been posted to that circle, if not in their stream then by drilling into your activity. This kind of falls in line with the locked diary model. But unlike this model, removing someone from your circle does not revoke their access. Instead, a number of scenarios can play out.

Compare what you expect to happen in each of the following situations with what actually occurs.

1. You make a post to a circle, but realize you don’t want Alice, who’s in the circle, to see it. You quickly remove her from the circle.

   Google Plus indicates to you that Alice no longer has access to the post, but if it made it into her stream, she can continue viewing it! Alice can even see comments made by others after she was removed, though she cannot make comments herself or share it with others. What does and does not end up in a person’s stream is not entirely clear.

2. You post to a circle, and Bob replies yet again with a drama-filled comment. You decide to remove him from the circle once and for all.

   Because Bob has commented, he now keeps full access to the post. In this case, Google Plus correctly indicates that he has access. He can continue adding comments to the post, and he can share it with others outside the circle by default. And on top of that, he can see subsequent comments made to the post.

3. You posted some personal things to your circle, but that was awhile back. You add Carol, who you’ve just made friends with, to your circle. Unfortunately, she starts to act creepy and so you remove her.

   These old posts most likely did not make it into Carol’s stream. Even if she went into your profile’s activity and commented on them there, she will lose access to them. If the posts did make it into her stream though (which might be possible if they’re not that old and/or her stream is not that populated), she keeps access. You just have no way of knowing which case it is.

Granted some of these are most certainly due to bugs, but this serves as a reminder that Circles are not as airtight as you might think.

And though not as farcical as Wave, the model Google has created here is still complex, confusing user expectations for how the system works and social norms for how it should be used.

This confusion will inevitably lead to gaffes. Even if these boil down to user error and not some technical failure, Google should not be entirely free from blame.

And while I described the problem in some depth, I glazed over any solution. So here I am to expand a bit on how Unity’s menus, and menus in general, might be improved, once again applying the angle of escape concept and pulling examples from the Mac.

Recap

I observed that when trying to select a menu item in Ubuntu, it’s quite easy to accidentally trip another menu. Due to the aspect ratio of Ubuntu’s menus, which tend to be taller and thinner, their angles of escape are often smaller than their Mac counterparts. Highlighted yellow in the screenshot below, you get 65 degrees with the Apple menu, compared to 50 degrees with Ubuntu’s system menu. This difference seems to have a noticeable impact.

Further, let’s assume that users have two tendencies: to target the text of a menu item more than the whitespace, and to move in a straight line to their target. I believe these are reasonable hypotheses, at least for novices who haven’t trained themselves out of this behavior yet. Then due to Ubuntu’s placement of the menu item text in the example above, the problem is only compounded.

Resize the Menu

So what can we do about this? A straightforward approach is to increase the width of the menu. This helps the menu both as a target (invoking Fitts’ Law again) and as a point of escape, a double win.

But while it helps visibility and targeting to a lesser degree, increasing the height of a menu actually hurts escapability. This is something to consider when comparing OS X’s 21 pixel menu bar to Ubuntu’s 23 pixels.

Buffer Time and Space

Since the ’80s, both Apple and Microsoft have dealt with escapability in the context of hierarchical menus, each addressing it in their own way. If you were to treat hierarchical menus at face value, the user would have to steer carefully across the width of a menu item to avoid triggering a neighbor.

Microsoft’s solution was, and continues to be, to keep the submenu displayed for an extra split second, regardless of your actions. If you’re quick enough, you can get to the submenu taking any path you wish.

Apple’s solution in Mac OS was to widen the angle of escape to 90 degrees, so that as long as your movement was more horizontal than vertical, the submenu would stay open. Bruce Tognazzini, the original drafter of Apple’s HIG, talks about both approaches here under question 6.

This went away in the transition to OS X, but has since returned in a smarter form. Now the angle of escape is based on the size of the submenu, as long as you maintain a certain speed. Ubuntu takes a similar approach, but none of the OSes apply it to the main menu bar.

In the image below, you can see how the naïve, classic Mac OS, and Mac OS X approaches compare in their angles of escape.

Make the Menu Sticky

Another approach is to make the menu sticky. Once clicked, it stays activated until you click elsewhere, maximizing the angle of escape. The tradeoff here is that it prevents you from performing the “piano slide” to scan multiple menus quickly. This makes it best suited for specialized menus.

Likely for technical reasons, third-party menu extras on the Mac take on this property, though Apple’s own menu extras do not. Apple’s Spotlight menu (which, it should be noted, is in the same position as Ubuntu’s system menu that started this whole discussion) quite intentionally gets the sticky treatment.

Ubuntu might find good use for this approach in the right half of their menu bar.

Change the Target

A final approach is to offer visual cues for staying within the angle of escape. This might be achieved by keeping the menu item area narrow, dropping wider items further down the list, or lengthening the text of shorter items to fill the space.

Strong highlighting, as found in OS X and Ubuntu, also encourages users to use the entire width of the menu item. While the highlighting in Windows 7 is more subtle, menu items are rendered as buttons on hover, similarly signaling that the whitespace can be clicked.

To wrap up, let’s take a look at the volume controls in Mac OS X, Windows 7, and Ubuntu below. On Mac and Windows, the control stays within the angle of escape (though it doesn’t matter on Windows because theirs is sticky). On Ubuntu though, it extends well beyond it. This video demonstrates the problem in motion.

The obvious solution is to make Ubuntu’s volume control vertical. But we don’t necessarily have to follow the convention of other OSes to make it usable. We could make the menu sticky. We could add a time or space buffer. We could reorder the menu items. We could resize the menu or slider control. Or we could do some combination of these.

Sure, this is all sweating the small stuff. But multiply that over a whole operating system, and that’s how you end up creating a great user experience.

What follows are my first impressions of Ubuntu 11. And I mean my very first impressions, after using it for just a few minutes, taking on the persona of a lifetime Mac user.

And these impressions come from someone who’s used mostly Windows at work and Mac at home. Sure, there’s a sprinkling of Solaris, IRIX, and Linux mixed in there, but I haven’t used Ubuntu, and haven’t had to adjust to the changes that Unity brings (such as moving the window controls). So I’m just the user that Ubuntu is targetting.

I hope you find this perspective of interest, whether you’re curious about an alternative operating system, or are a seasoned Linux user, developer, or advocate who wants to see things through a fresh set of eyes.

The Good

My greatest concern was that I’d have to do a lot of installing and configuring before I could get anything meaningful done. All I wanted was a standard setup, and to not derail focus from my work.

Fortunately, Ubuntu presents a familiar interface and is ready to go right out of the box. It doesn’t take much nowadays given how many of our applications are web-based, and on Ubuntu, Firefox comes pre-installed (more on that later). Remote desktop is built-in, which made it a breeze to set up VNC with my Mac. Window management a la Windows 7 Snap was a nice surprise; this requires a third-party app on the Mac.

The Bad

Like Mac OS X, Ubuntu puts the active application’s name in the menu bar. In OS X, this contains a menu of application-level functions like About, Preferences, and Quit. In Ubuntu, this is a non-clickable region (highlighted red), despite being nestled among and pretty much indistinguishable from the clickable ones (highlighted green). There’s something jarring about clicking something expectantly and not having it respond.

I can see that the designers are trying to establish a hierarchy here, from the Ubuntu menu (which aligns with the dock) to the active application to the application’s menus. Still, there should be a stronger visual indicator that the application name is not clickable. Or you could just turn it into a menu, taking a page from Mac OS 9.

You might have noticed that Ubuntu’s menu bar is more tightly packed than OS X’s. A problem here is that while trying to select an item from a drop-down menu, it’s easy to accidentally trip another menu. This is most problematic with the system menu in the top right corner.

Mac OS X’s Apple menu gives you a target of 45 by 21 pixels, compared to Ubuntu’s 28 by 23 pixels. These areas are highlighted green above. But as Fitts’ Law reminds us, these corner targets are both effectively infinite in size.

More important than size is the angle of escape — the number of degrees you can move the cursor out without activating an adjacent menu. You get 65 degrees in OS X versus 50 degrees in Ubuntu, as highlighted yellow.

In fact, Ubuntu should have an even bigger angle than OS X. Due to the placement of the icon on the right and the left-justification of the menu items, you can’t travel in a straight line to click the first few pieces of text — this will activate the next menu. Instead, you have to perform a loop-de-loop. Widening the clickable area would help somewhat.

Now onto my next set of gripes, which center around managing new software. As I mentioned earlier, Firefox comes preinstalled. When I checked to see which version was installed, I was presented with the window below.

Version 4.0 is several major bumps behind the other platforms, which are sitting at 7.0.1. Below that is the text “Mozilla Firefox for Ubuntu canonical – 1.0″. Is this the 1.0 canonical version of Mozilla Firefox for Ubuntu? Or Mozilla Firefox for Ubuntu canonical version 1.0? And how does that relate to version 4.0? Apparently, I’m not the only one who finds this confusing.

And worse yet, there is no obvious way to update. I’m still not clear on whether there’s a newer version available, and how to update if it’s the case.

Anyway, the main reason I opened Firefox was to install Google Chrome (sorry Mozilla!). Fortunately, the latest version of Chrome was available to download. Double-clicking the package doesn’t take you to a standalone installer, but to Ubuntu Software Center.

Here, software is listed at two level, technical items and what I presume to be applications. But what’s classified as each can be a surprise. In the application list are items like Input Method Switcher and Multimedia Systems Selector, things most would consider system extensions more so than apps. On the other hand, Google Chrome is listed in technical items with a nondescript icon and label, along with 1,303 other things. Can you spot it in the image below?

After installing Chrome, the natural next step is to open it. Yet, there’s nowhere in Ubuntu Software Center to do this directly. Contrast this with Windows, where you’re asked if you want to start the program, or the new way in OS X, where an application installed from the Mac App store jumps right into your dock.

The Beautiful

Despite these issues, I give the designers major props. Open source software has a reputation for being ugly and catering only to the power user. But based on my initial experiences, they’ve created a polished user interface that’s beautiful and user friendly in Ubuntu.

I was curious how Devour produced the blurred effect and so I took a look at their code. It turns out they simply preprocess the images in something like Photoshop. Sure, that may be the most bulletproof approach, but where’s the fun in that?

What follows is a comparison between Devour’s approach and four other, more programmatic techniques, including a pure CSS solution. The ones that utilize canvas or SVG are based on Matt Riggott’s work. And as a point of reference, you can see the actual rendering from Devour above and what an unblurred version looks like below.

Preprocess with Photoshop

As I mentioned, Devour creates blurred stills in advance. The text is then overlaid by assigning it a negative top margin. I’ve recreated this here. The only difference to the actual rendering above, you might notice, is that I use Futura since I don’t have access to Proxima Nova Condensed.

View the code and live render.

Blur with Canvas and JavaScript

An alternative approach is to create a canvas element and embed the image in it. JavaScript can be used within a canvas to manipulate images, from scaling or rotating all the way down to pixel-specific operations. This is precisely how the blur action in Pixastic works. Here, the blurring function loops through the image several times and averages each pixel’s color value with that of its neighbors.

View the code and live render. You might notice that the image here is Base64 encoded. This is to overcome a cross-domain security issue with JS Bin. You should be able to reference the image in the normal way.

Blur with SVG and XML

SVG is an image format that has a number of filter effects built right into it. While SVG is normally reserved for vector graphics, you can also embed a bitmap image in it. Then all it takes is a few lines of XML to apply a Gaussian blur to it. One thing to note is the weird glow around the border.

View the code and live render. If you were to open the SVG file in a text editor, you would discover markup like this.

Layer with Canvas and JavaScript

In contrast to the pixel-based algorithms used in the previous techniques, the final two use a simple trick to blur more efficiently. Copies of the image are stacked upon each another, offset by a few pixels and partially transparent.

Here, a canvas element is created and the image is embedded at full opacity. With each call of the blurring function, copies of the image are stacked on itself recursively, set at an opacity of 12.5 percent and offset in each direction by a pixel. Each iteration results in an increasingly blurred image.

View the code and live render.

Layer with CSS

Finally, I wanted to see if I could achieve a similar effect using pure CSS — that is, without the aid of JavaScript, canvas, or SVG. Here, copies of the original image are set to an opacity of 12.5 percent and offset from the original by two pixels in each of eight directions.

A couple of remarks about the code. The copies are all given absolute positioning, meaning they are positioned relative to their common parent. CSS classes are used to set the offset of an image in a cardinal direction; a combination of these classes is used to offset an image diagonally. Finally, in order to use z-index to keep text at the top of the stack, all of the elements using z-index are given a position other than default static.

View the code and live render.

Conclusion

So how do these approaches measure up? As you can see from the side-by-side comparison, they all do an adequate job. Click to enlarge.

If you don’t want to bust out Photoshop and wrangle with a bunch of images, or you want to create a dynamic effect, try one of the alternative approaches. If, on top of that, you’re not comfortable programming, you can get by with just CSS.

But if you want what’s speediest and most robust on the client, do as Devour does.

You can try Trebek out below. For best results, load it in Safari on your iPhone or iPad, then add it to your home screen.

http://thomaspark.me/project/trebek/

What I want to do in this post is share some simple things I did to give Trebek a more app-like experience, despite it being a mere HTML/CSS/JavaScript bundle. If you’re interested in web development, read on.

Tailoring the interface by scaling elements

Trebek’s primary use case is leaning back on a sofa and pulling out your smartphone just as the show’s about to start. But it’s meant to be usable for – and therefore scales to – a full range of devices. You can test this out by loading it in a browser window and resizing to various shapes and sizes.

There are several ways to achieve this, but what I recommend is setting the font-size of the body to 100% and then using em as a unit of measure throughout the rest of the code.

The size of em depends on the font-size of the element. By default, 1 em equals 16 pixels. But by changing the base font-size, you can scale all properties that are using em simultaneously. With the following jQuery, you can update body’s font-size, and therefore all of these properties, whenever the window is resized.

You can see why using pixels instead might be a bad idea. As an absolute unit, you have to recalculate and update the pixel size of each property individually, each time the window is resized.

On the other hand, using percent to size things is appealing since it’s relative by its very nature. Using percent also means you no longer require an update function for when the window is resized. If you set an image’s width to be 25%, it’s always going to be 25% of whatever, you might assume. However, keep in mind that percentages are local, meaning they’re based on the element’s parent and not a global value. While they’re useful for site layout, they’re less effective for fine-tuned properties like padding and text-shadow. Just try using percents to set the same padding for multiple elements, when their parent elements are different sizes.

While I simply scaled the interface, you might consider media queries for more custom interfaces conditional on resolution, aspect ratio, and orientation. For example, you could provide a one-column interface for smartphones versus a two-column interface for tablets.

Cutting the cord with local storage & application cache

Local storage allows you to store data on the client in much the same way as a browser cookie. It allows you to avoid databases — nice for a lightweight app, particularly one you intend to work offline. One word of warning though: clearing the browser’s cache results in the data being lost. Trebek uses local storage to save scores and keep a history of a user’s performance.

To use local storage, bundle up your data into a JavaScript object and use the following code. First, it checks that local storage is supported. Next, it checks if a data object has been saved under the key ‘trebek’ before and if so, assigns it to a variable. In the second part of the code, a function is bound to the save button. This function adds a new entry to the data object using the current date/time as key and current score as value, and then puts the whole object in local storage under the key ‘trebek’.

Application cache stores your essential files so your web app can work offline, useful when your smartphone is in airplane mode or you have an iPod touch sans wifi. For Trebek, the greatest benefit regardless of whether the device is offline or not is that application cache improves startup speed.

The main thing you need is a cache manifest, which is a text file that specifies the resources to be cached for future use. Name this file “cache.manifest”, with the following content, and place it in the root of your web app. Under the CACHE section, you want to list all of the assets you wish to be cached except for the manifest file itself.

Each time the web app is opened while online, the cache manifest is checked to see if it’s been changed (such as by updating the version number comment). If a change has been made, this triggers the browser to re-cache the rest of the files. If not, the cache continues to be used.

With the cache manifest in place, you want to declare it in one of your pages by adding the following attribute to the HTML tag.

Finally, make sure that your web server is serving files with the manifest extension as type “text/cache-manifest”. It won’t work otherwise. You can check this using your favorite browser’s developer tool. If the file type is not correct, add the following line to the .htaccess file in the root of your web server.

That covers the very basics of using local storage and application cache to enable offline functionality in your web app. Obviously much has been glossed over, so if you want to learn more, check out Mark Pilgrim’s chapters on local storage and application cache.

Putting on the finishing touches for iOS

Here are a few more steps you can take to put some polish on your newly offline-capable web app. First, save your favicon for multiple resolutions: 48, 57, 72, and 114 pixels. Not only are browsers making greater use of large favicons, but they can be used as icons when your web app is saved to your home screen, giving it a bit more of that native feel.

In the header of your page, add the following elements. The first specifices a favicon for web browsers, and the next three are for the iPhone, iPad, and iPhone retina display respectively. You can skip the -precomposed tag to have iOS automatically add its customary gloss to your icon.

If you want to give your web app a custom splash screen, add the following tags as well. The images you reference must be exactly 1004×768, 768×1004, and 320×460 pixels respectively. As far as I can tell, iPhone 4′s retina resolution is not supported yet.

Add the following code to tell Safari that your site is intended as a web app, change the menu bar to black, hide the chrome to display the app full-screen, and prevent pinch-to-zoom.

So there you have it. It’s great to see the progress that’s being made with the web in recent years. Although it hasn’t quite reached parity with native apps, for many of the simpler apps you find in the App Store, it’s now possible to create an equivalent experience using HTML5.

With the programmatic approach, the main function takes in a set of objects, each of which represents a device with corresponding specs: display size (diagonal in inches), display resolution (height and width in pixels), and physical dimensions (height and width in inches).

Each device is then rendered as a div. The aforementioned specs are used to determine its size and shape, with the content area of the div acting as the display and its border serving as the bezel. The display size is also used to determine the horizontal position of each device.

There are also three optional parameters. Scale factor defaults 1 millimeter to 1 pixel, but can be varied per device. Vertical shift centers the display in the bezel by default, but can be tweaked for certain devices such as the Kindle. Finally, curve factor can customize the roundedness of a device using the border-radius property, useful for devices like the Veer, although there are some kinks with that.

Below is a screenshot of the results, and you can view the live version here. You can also have a look at the code, but pardon the cruft as this is just a proof of concept.

As you can see, while most companies have two distinct classes — a smartphone at 3-4″ and a tablet at 10″ — Samsung is offering several ‘tweeners that bridge them. Note though that they still have a gap, which I expect to be filled shortly with a Samsung Galaxy NoteTab 6.5. In all seriousness, it’s surprising that they haven’t targeted that particular size given Amazon’s already found a market there.

One thing’s for sure. It’s going to be interesting to see if any ‘tweener devices eventually gain a foothold, and it looks like Samsung’s in vivo experimentation will be showing us the way.

It’s also to reflect on them. How did my draft selections ultimately turn out? Which players ended up being disappointments, and which were bargains or outright steals? Who ended up contributing most to this season’s success?

A slopegraph is an interesting way of capturing the answers. Below is one I made of my players: their rankings (against all other players) at the end of last season on the left, the draft picks I used to select them at the start of this season in the middle, and their ranks as of this week on the right¹. Players released at some point in the season are gray, while those picked up as free agents are green. Click for full size.

Apple is renowned for its excellent design. But with the Apple TV remote, they’ve made a number of missteps.

• It’s too small. Forget losing it between your couch cushions, how about between the pages of a magazine? At 6 millimeters, it’s so thin that it never fits comfortably in one’s hand, and is awkward if not painful to use for a significant length of time. There’s a limit to how small handheld devices should be, and it’s been exceeded.
• It’s short range. The remote is infrared, meaning it requires a direct line of sight. The Apple TV can’t be tucked away, and at certain angles, the remote is unresponsive.
• It lacks buttons. While other companies continue to make remotes overly complex, Apple goes the opposite extreme. Six buttons do the job most of the time, but not always. One of the things I miss most is a dedicated power button. If you’re in the Netflix app for instance, you have to exit out of it to the home screen with multiple “menu” clicks before you hold the select button for two seconds to power down the Apple TV. Not exactly intuitive or convenient.

Small and unergonomic. Tethered to a short range. Not enough buttons. Sound familiar? The Apple TV remote is the new puck mouse.

The so-called “hockey puck” mouse was included with the original iMac in 1998 and stubbornly thereafter for more two years. With its release came a chorus of complaints. It was too small for comfort, they said as they bought third-party plastic shells. The round shape meant that it was constantly getting turned around and losing orientation. The two-foot cable was too short for most setups. And of course there was that old chestnut about the single button.

Eventually Apple gave up on the puck mouse, though they still were never able to get the mouse quite right. Last year, they ditched the “faster horses” approach, going in a completely different direction with Magic Trackpad.

If, then, the current Apple TV remote is the puck remote, what would it take for it to become the magic remote?

The boundary between computers and TVs is blurring. TVs are becoming increasingly connected and “smart”, while personal computers are becoming a platform for obtaining, viewing, and serving video content. This follows the convergence of mobile phones and computing, and a shakeup of the mobile phone industry since 2008.

While the hardware specs of current TVs are decent, the user interface leaves something to be desired, both in terms of software and hardware. Think of how poor the remote control, built-in Internet “apps”, channel guide, and configuration settings are on most TVs. There is room for improvement in the user experience, and no doubt Apple believes it can do much better.

In markets that Apple does enter, they favor streamlined integration, from the original Macintosh to the current iMac. Not only does this integration lead to simplicity and elegance, but it opens doors to new possibilities, some of which I’ll talk about in a later post. This also includes the aforementioned TV remote, channel guide, and settings. Having a standalone device like the current Apple TV doesn’t fit with this philosophy.

There are still compelling reasons to offer a standalone device: to reach those who’ve already bought an HDTV, and to allow people to upgrade their Apple TVs without tossing out their perfectly good TV sets. As to the second, upgrade concerns will soon become irrelevant. Once cloud-based storage and 1080p resolution are rolled out fully, only software updates will be needed to stay relatively up to date. They are nearly there. As to the first, Apple might offer a standalone device alongside the integrated model.

But only as a reluctant, and perhaps temporary, measure. To Apple, the standalone model is only a step toward their vision of an integrated one, the true Apple TV.

Once upon a time, men used briefcases to carry around their contracts, bundles of cash, and nuclear launch codes. Over the years, these morphed into laptop bags and messenger bags. In the meantime, many have gotten quite used to the convenience, if not essentiality, of having things beyond their keys and wallet on them.

Until the state of the art reaches a point where pockets are pointless, the need for such a bag remains. But the requirements are changing. Convergence means fewer devices to carry around; instead of a PDA, MP3 player, and camera, you have a smartphone. Miniaturization means the devices you do carry around are getting thinner and lighter; 15-inch behemoths make room for subnotebooks and iPads. Digitization means fewer documents printed on paper; paperbacks are replaced with a Kindle.

What’s needed is a smaller bag. And whether you can come to grips with it or not, let’s accept that we’re entering man-purse territory.

As with economic inflation, more versions means that each version holds less significance. It seems that this is precisely what Google and Mozilla hope to achieve, deemphasizing “What version are you on?” in favor of “Are you up to date?” Silent, automatic updates and hidden version numbers certainly support this notion. Perhaps more people will stay up-to-date, benefiting both security and standards, but we’ll have to wait and see the impact it has on web development.

Mozilla hasn’t always had this approach, but when Firefox and Thunderbird asked me to update to 6.0 today, I had to take pause. “Am I going nuts, or did I just update to 5.0 last month?” It turns out I hadn’t lost it yet.

I went back to compare the release schedules of the major browsers. You can see them plotted by year…

…and by months since initial release.

There are clearly two schools of thought, the traditional versus the rapid releases of Chrome and Firefox as of late. Projecting with a simple linear regression (I know), here’s what’s in store for the year 2020.

• Internet Explorer 13
• Firefox 10.4
• Safari X
• Chrome 55.1.531.866
• Opera 17 Series

But with the latest change in policy from Mozilla, and perhaps other organizations following suit, version inflation may be much greater, if they even matter at all.

Starcraft units aren’t too far off from animals — Zerglings are reminiscent of dogs, ultralisks elephants, and archons big, white fluffy bunnies — so what collective nouns would capture the spirit of each? Searching the web, I found that the question had been posed before, with lots of ideas but no consensus.

I conducted a survey to settle the matter². Each SC2 unit was given five options (plus “other”) that were culled from various sources. In all, 764 people (40% Zerg, 27% Protoss, 19% Terran, and 14% Random) took the survey over the span of three days.

Results

The top vote-getters for each unit are summarized below.

Some Notes

The most consensus was for “pack” of MULEs. Ravens were the other unit named for an animal; its official collective (unkindness) actually came in last place, while it received the most write-ins with “murder” and “flock.”

The most contentious units were banelings (#1 and #4 separated by 6%), immortals (#1 and #2 by 2.4%), phoenix (#1 and #3 by 2.0%), and colossi (#1 and #3 by 1.4%). Protoss units in particular seem far from settled.

For Zerg units, “swarm” fared well both as an option and as a write-in. Should all Zerg units simply be considered “the swarm”?

Generally one can’t have more than one mothership in-game, which led to some interesting write-ins: paradox, singularity, singleton, FOREVER ALONE.

“Other” honorable mentions: a flower of vikings, a nevermore of ravens, a clutch of larva, a grack of zerglings, a useless of hydralisks, a gaggle of mutalisks, a bronze league of observers, a gathering of immortals, an imbalance of colossi, a wing of phoenix.

Finally, a creative exercise for the reader: given the units of your domain, can you come up with collectives that capture their spirit?

Appendix

Here are the full results for Terran, Zerg, and Protoss.

The Method

From each of the twenty iTunes categories (e.g., books, business, education), I collected the icons of the top 30 paid iPhone apps. I used the Python Imaging Library to run through these images pixel by pixel, classifying them into 11 main colors and tallying them up.

Here are a couple of examples shown by percentage. Chat for Google Talk:

And Angry Birds:

At this point, I could have aggregated all of the pixels across all icons and counted their colors, but that didn’t seem very informative. Instead, I focused on the major colors of each icon, which I defined as making up at least 30 percent of the pixels. With this criteria, the Google Talk icon is white and gray, and the Angry Birds icon is blue.

The Results

Here’s how the colors broke down for each category (click to enlarge):

And the aggregate:

Blue icons were indeed the most common. But while I expected half or more of the icons to be blue, it came closer to one-third. Even at that level though, blue far exceeded the other colors. This is a shame, given that some of my favorite iPhone icons (e.g., Delivery Status, Instagram, Paprika) use little to no blue. The worst offenders in this regard were travel and navigation apps, half of which were blue.

Black was the least common color for an icon. There were also very few yellow, purple, pink, or white icons, so if you want your app to stand out, there you go.

Pink was most popular with health & fitness apps. Make of that what you will.

A couple of things I took away from the process. First, I couldn’t find much help in the way of information or software for reducing a million colors down to the ones you’d, say, find in a Crayola 12-pack. You can accomplish this by carving out the color space, but as this chart from the xkcd color survey shows, the colors we define are quite idiosyncratic, both as a product of human perception and as an artifact of human culture. I ended up converting from RGBA to HSL, which made it a bit easier to come up with clunky heuristics to classify the colors.

Second, the illusory nature of color. Juxtaposing different colors skewed them, the sizes of the backgrounds were overestimated, and shadows threw perceptions off. A case of the human mind outsmarting itself. This makes it tough to give an accurate account, when a pixel is technically one color, but people all perceive it to be another. Most of the time, it’s the perception that matters.

This version apparently replaced the old one back in 2005. No doubt the actual content of the original was highly dubious, but it’s hard to argue against its memorability. I can still picture the carb foundation and fatty capstone like it was yesterday.

Unfortunately, with the new version, a lot of what made the original effective was lost. Let’s run through the issues from an information design perspective.

Mixed Signals

Is the new pyramid just a logo, or is it conveying more specific information? It’s not clear at first glance. The old pyramid communicated its purpose as an information graphic and primed the mind for interpreting it this way.

Missing the Point

The value of a pyramid diagram is in using its shape to represent hierarchical or proportional information — large bottom to small top. In the new pyramid, the sections are proportional but drawn as vertical bands! The USDA give two reasons for this change. First, to emphasize variety, that you should have something from each food group every day. Fair enough. Second, to emphasize moderation, the wider base of each band representing that you should have more foods with low fat and sugar from that group, and the narrow top meaning less foods with high fat and sugar. I kid you not.

Not Enough Info

Sometimes a picture is worth a thousand words, but a bit of text can have a multiplicative effect. The widths of the colored bands vary and are meant to be general guidelines. But precisely what is anyone’s guess. Should we strive to balance the food groups equally, or cut down on meats and beans? Should we have more grains than anything else, as clearly suggested in the original? And what is the yellow band?

Hidden Messages

Did you realize that the white tip of the pyramid represents discretionary calories, such as from candy and alcohol? Me neither.

Jack of all Trades, Master of None

The food pyramid is supposedly a “food guidance system,” yet crammed in is Clippy McClipartson scaling it to symbolize the importance of physical activity. Let’s work on the “food guidance” part.

Chartjunk

Giving examples of each food group is a great idea, but the execution needs improvement. The cluttered layout and horrible quality of the clip art make it more distracting than informative.

The bottom line is, does the new food pyramid help people make informed decisions about the nutritional value of their meals? I would argue not. Effective information design hinges on a message that is consistent and focused. The new food pyramid, which reeks of design-by-committee, fails on both accounts.

What can be done then? I suggest stamping the pyramid in big, bold text with “MyPyramid.gov” and moving the Daily Food Plan to the front page of the website.

Whether that turns out to be the case or not, it raises several interesting questions. With so many computer icons based on specific technology, what happens when that technology fades from public consciousness? Does a lack of familiarity with that technology create usability problems with the icons? Should new icons be devised? And are they?

All English speakers understand the word window to mean an opening designed to let in air or light. But only the geeks among us know the rich history of this word. It originates from an Old Norse phrase describing an opening in a building’s roof as a wind eye. This poeticism was important early on for understandability and communicability of a new idea. But as the word took hold, it established a meaning of its own that transcended its legacy. Today, a window is no longer thought of as the metaphorical wind eye — a window is a window.

Icons are also a language, of the visual sort. In the early days of the graphical user interface, the desktop metaphor was heavily relied upon to communicate new ideas about computing. This was essential to its success, as the nascent GUI made a newbie out of everyone.

However, GUI conventions have since become engrained in our culture, and the meaning of terms like desktop, file, and trash in a computing context now transcend the original metaphors. We are in an age where people interact with digital folders much more than manila ones, where they know how to search without having ever handled a magnifying glass, and where they adjust their volume control without realizing it depicts a speaker cone.

And just as these icons live on beyond their origins, I say long live the floppy disk!