Deallocated Objects

Protect Your Users' Privacy With DTSHashedContacts

2012-02-15T22:26:00-06:00

As I'm sure many readers have heard, there has been some public outcry lately on the subject of iOS apps accessing the Address Book contacts of a their users and then sending the whole lot of them off to their servers, to accomplish their "friend matching" features.

Many companies have already corrected the error in their ways, (partially), and even Apple has stated that a future iOS release will lock down Address Book access, in the same way that permission is required to access a user's geographic location now.

In the meantime however, if you'd like a quick, easy and safe way to build a "find my friends" type of feature into your app, I'd recommend looking at DTSHashedContacts.

It's is a drop-in iOS library that provides a wrapper around the Address Book frameworks designed to ensure the privacy of user data. Before access is ever made to the Address Book the user will first be prompted for permission with a customizable UIAlertView prompt. Once access is granted the library returns hashed tokens representing the user's private data rather than the data itself.

Here's what it looks like to use it:

[hashedContactsProvider emailTokensWithConfirmation:^(NSArray* tokens) {
//When permission given
} whenDeclined:^{
//When permission denied
}];

Building Xcode Projects from the Command Line

2012-02-11T13:24:00-06:00

Building iOS and Mac projects from the command-line could be a lot easier to work with.

Hopefully this post will give you a couple ways to make that happen.

I wanna talk about two different little tools that help ease the process of scripting or working with Xcode projects from the command line.

xcodebuild-rb

xcodebuild-rb is a neat little ruby gem that lets you create a Rakefile inside the root of your Xcode project's folder that looks like this:

require 'rubygems'
require 'xcodebuild'

XcodeBuild::Tasks::BuildTask.new

What does that get you?

Well, after creating that Rakefile, running a quick rake -T (which will list all available rake tasks) will output something like this:

rake xcode:build       # Builds the specified target(s).
rake xcode:clean       # Cleans the build using the same build settings.
rake xcode:cleanbuild  # Builds the specified target(s) from a clean slate.

One of the coolest features of xcodebuild-rb is it's use of "formatters". One of my favorite formatters is called "progress". You can enable it like this:

XcodeBuild::Tasks::BuildTask.new do |t|
  t.formatter = XcodeBuild::Formatters::ProgressFormatter.new
end

Then when you build using xcodebuild-rb, your output will look something like this:

Building target: ExampleProject (in ExampleProject.xcproject)
=============================================================

Configuration: Release
..............

Finished in 2.226883 seconds.
Build succeeded.

xcodearchive

Apple ships Xcode with a command line tool called xcodebuild, which as the name suggests, builds an Xcode project. One drawback about the built-in xcodebuild tool is that it can't create .ipa archive files.

Well, enter xcodearchive.

Unlike xcodebuild-rb, xcodearchive isn't a ruby gem. It is just a .rb file that you can put anywhere you'd like and run.

xcodearchive has a ton of great features, check out the USAGE output:

Usage: xcodearchive [OPTIONS]
        --version
                                     Show version number
    -v, --verbose                    Output more information
    -g, --growl                      Show growl alerts to inform about progress of the build
    -n, --do_not_keep_dsym_symbols   Do not keep the dSYM symbols
    -s, --show                       Show archive in Finder once created
    -c, --clean                      Do a clean before building the Xcode project
    -o, --ipa_export_path FOLDER     Set the path of the folder where the ipa will be saved. Default is '~/Desktop'
    -i DEVELOPPER_IDENTITY,          Force the developper identity value
        --developper_identity
    -p, --project PROJECT            Specifiy xcode project
    -h, --help                       Display this screen

If you aren't already automating the tedious parts of your build and release processes, you are missing out. As any iOS developer knows, building and releasing can become some of the most monotonous and annoying parts of our jobs, hopefully these little tools will inspire you to start scripting your way to a smoother build/release cycle.

Phantom Buttons on the iPad's Split Keyboard

2012-02-11T13:19:00-06:00

Yet another example of details that 99.9% of users would never notice but use constantly.

The iPad’s split keyboard has phantom buttons. If you’re used to typing Y with your left hand, you can.

To enable this keyboard, tap-hold on the “toggle keyboard” button in the lower right to get a menu, or tap-hold on it and drag upwards. Reverse that to reunite the two halves back to normal at the bottom.

I love discovering little tid bits like this. Apple (among others) manage to sprinkle them in the strangest and most obvious places.

The Apple Voice

2012-02-11T13:12:00-06:00

Zach Holman does a great job of succinctly describing something that I've been having trouble quantifying into words for a while now.

Apple commands their words exceedingly well. They aren’t the originator — or even the owner — of their particular voice, but they are the most visible.

Mechanically, The Apple Voice is characterized by short, declarative sentences that are informally and personally delivered to you with a hint of smugness.

The Apple "voice", as Zach names it, is probably one of the most underrated parts of Apple's success.

Zach goes on to talk about how you can shape and choose your company or product's "voice".

The upshot: You need to do this. This matters, a lot.

Parse JSON Directly into NSManagedObjects

2012-01-22T14:39:00-06:00

Tom Harrington brings us another insanely valuable little bit of code that does some simple, yet awesome things with a parsed NSDictionary of JSON content:

Provide a safe, generic alternative to Cocoa’s -setValuesForKeysWithDictionary: for use with NSManagedObject and its subclasses

Handle cases where JSON data didn’t match up with what the managed objects expected. Getting a string where you expect a numeric value, or vice versa, for example, or getting a string representation of a date when you want a real NSDate object.

Basically Tom is examining his managed object's defined properties, and then looking into the NSDictionary he got when he parsed some JSON, and if any of the property key names exist in both structures, he sets the value.

The end result is being able to do something like this:

[myObj setValuesForKeysWithDictionary:jsonDict];

I love little tools and case studies like this as they always help to enlighten more of us to the awesomeness that is the Objective-C runtime.

QuickLook Plugin for Mobile Provision Files

2012-01-22T14:30:00-06:00

How many times has this happened to you?

I received the new mobileprovision file.

Great.

No.

What?

You still haven’t added my UDID in it.

I have.

No you have not.

Yes I have.

No you haven’t.

Yes.

No! Why don’t you just…

…

Look, I’m sure. Can you generate it again?

Ok, I will. Wait… ok, it’s done.

Let me check. No, sorry, still not ok.

Are you sure? [END OF CHAT CONVERSATION CENSORED]

MacMotion brings something to relieve the pain (slightly) of dealing with Apple Provisioning Profiles, and it uses one of my favorite OS X features, QuickLook.

After installing MacMotion's new QuickLook plugin Simply press the spacebar on any .mobileprovision file in the finder and instead of some boring 1 line summary, you'll get something like this:

It also has some great enhancements to Finder icons to quickly tell you if a profile is valid or not.

You can download the plugin here (at the bottom of the post).

iPad Retina Images Found in iTunes U and iBooks 2 Files

2012-01-22T14:17:00-06:00

This one is sort of a given these days, but appears we now have even stronger evidence that the almost-certainly forthcoming iPad 3 will have a Retina class screen.

Shown here is an iPad bookmark image resource with an @2x version:

We have been finding references to 2X iPad images for well over a year (including iBooks 1.2), (...)

I'm posting about this as a nudge-nudge to my fellow iOS developers to keep this in mind if you are starting out on any new iPad projects, you'll need to whip up a new 2048×1536 resolution Photoshop document.

Should make designing iPad apps a little more interesting.

Misconceptions About iOS Multitasking

2012-01-02T14:59:00-06:00

Fantastic writeup from Fraser Speirs about iOS's multitasking capabilities and behavior. He goes into great detail about the ins and outs of things and covers all the different scenarios really well.

The problem is this:

If someone tells you that all the apps in the multitasking bar are running, using up memory or sucking power, they are wrong.

I too have heard the "advice" quite a bit recently that users should "clear out" their multitasking tray to "free up" memory and improve performance. This would be bad enough coming from "your buddy who read it on some forum", but apparently there are reports of Apple Genius Bar employees feeding this crap out to members of the unknowing public.

For the last time, (Fraser puts it perfectly):

The iOS multitasking bar does not contain "a list of all running apps". It contains "a list of recently used apps". The user never has to manage background tasks on iOS.

Most iOS developers know this stuff like the back of our hands, but it's important to remember that most of your users have no idea how any of this stuff is "supposed" to work.

Zucchini: iOS Testing Written in Ruby & CoffeeScript

2011-12-23T11:47:00-06:00

Zucchini is an awesome cucumber-like visual testing framework for iOS. It works in a pretty awesome way by compiling CoffeeScript down to UIAutomation-compliant Javascript, and then running the test with Instruments.app's command-line tool.

Also, As their site describes further, the whole system works very much like Cucumber, the popular ruby/rails testing gem:

A Zucchini feature file consists of sections bound to contexts of different application screens. Every screen you proceed to needs to be backed up by a CoffeeScript class describing all UI elements you want Zucchini to interact with as well as custom actions you feel like performing on that screen.

Here's an example of one such class:

class PostScreen extends Screen
  anchor: -> view.navigationBars()["Post"]

  constructor: ->
    super 'post'

    extend @elements,
    'Post': -> view.navigationBars()["Post"].buttons()["Post"]

    extend @actions,
    'Type "([^"]*)"$': (text) ->
      messageArea = view.elements()['Message Text Area']
      messageArea.setValue text

Zucchini has an impressive set of features including:

Using a natural language for interaction scenarios, such as Then on the "Menu" screen:, etc.
The ability test/compare against screenshots.
Integration with Jenkins for full-on regression testing.

Zucchini only runs on Mac OS X 10.6 and 10.7 and requires XCode 4.2 as well as Ruby (at least 1.8.7).

The Zucchini site is full of really helpful links and installation instructions, so check it out, you can also find the Zucchini project on Github here.

Creating the iOS 5 UITableView Bevel Effect

2011-12-15T21:34:00-06:00

Oh man, I wish I had found Tim Oliver's writeup about this sooner (includes diagrams and sample code).

I just wrote all of this code myself, and had to do all of my own research. Serves me right for not properly Googling.

Pro Tip: Google everything before you begin coding a solution for a problem you assume everyone in your field must have.

You see, in iOS 5, Apple refreshed the look of a standard UITableViewStyleGrouped style UITableView. (You know, the ones with the rounded corners).

No longer were they actually white (like 255, 255, 255 or #FFFFFF). They were now a refreshing shade of 255, 255, 255, 0.8. That's still pure white, but with an opacity of 80%. Also, they added a 1 point tall drop shadow, as well as a 1 point tall inner shadow to each UITableViewCell. They've also still got a 1 point border around them.

I actually think the new cells looks much better, but they definitely break any custom code anyone had written to make their own custom UI or buttons match UIKit's.

I can't tell you how often I need to replicate this look and feel. Glad someone put together a comprehensive article about the topic.

Pro Tip #2: This is a pretty small detail, and sure, most people probably won't even notice. However, in my own anecdotal side-by-side tests, I was able to get an Oh this looks much better! reaction out of people by simply making my custom drawn stuff correctly match the system drawn bits.

Connect, Discover, Edit, Inspect, Customize

2011-12-13T14:03:00-06:00

A brilliant article by my buddy Ted Howard on the trials and tribulations of properly naming pieces of your user interface.

We needed a name for the button that brought up the stack editor. We wanted to convey to the user that launching the editor was a safe operation, that any changes they made would not be applied to the stack they were viewing. For that reason, we didn’t want to use ‘Edit’, because ‘Edit’ made it sound like you could modify something that someone else had made. We had many long conversations and debates about what to call the button. The thesaurus was consulted. Finally we chose a word: ‘Customize this stack’.

A good user interface can be killed by forgetting to think about these crucial details. Kudos to Ted for reminding us.

Using Blocks for Drawing

2011-12-11T01:52:00-06:00

I'm absolutely in love with the technique David Hamrick lays out in this post.

Instead of subclassing UIView every time we need to draw something what if we were to have one subclass that allowed us to pass in a block that performed the drawing code. So I’ve created a class called DrawView that does exactly that. It also passes itself and the graphics context since that was going to be needed in every block’s implementation so including them as parameters reduced the amount of boiler plate code needed.

It's a pretty simple idea: you shouldn't need to subclass just to do a tiny bit of custom drawing. Now you don't have to. With David's simple DrawView class, you can do your drawing like this:

DrawView *drawableView = [[[DrawView alloc] initWithFrame:CGRectMake(0.0 ,0.0, 320.0, 50.0)] autorelease];

drawableView.drawBlock = ^(UIView* v,CGContextRef context)
{
    CGPoint startPoint = CGPointMake(0,v.bounds.size.height-1);
    CGPoint endPoint = CGPointMake(v.bounds.size.width,v.bounds.size.height-1);

    CGContextSetStrokeColorWithColor(context, [UIColor grayColor].CGColor);
    CGContextSetLineWidth(context, 1.0);
    CGContextMoveToPoint(context, startPoint.x + 0.5, startPoint.y + 0.5);
    CGContextAddLineToPoint(context, endPoint.x + 0.5, endPoint.y + 0.5);
    CGContextStrokePath(context);
};

[self.view addSubview:drawableView];

I wouldn't be surprised to see something like this show up in a future update to UIKit. Apple is starting to use blocks everywhere. This is just good sense.

Attaching a UIView to the UIScrollViewIndicator

2011-12-11T01:31:00-06:00

Here's a neat little write up (sample code included) from Florian Mielke of how to replicate Path 2.0's neat behavior of "attaching" a timestamp indicator that follows iOS's built-in scroll indicator as you scroll.

The basic idea is to add the info panel’s root layer as a sublayer to the indicator’s root layer. With that, the info panel scrolls smoothly and stays in parallel to the indicator automatically. In the case were the scroll view hit the edges, we want the info panel to stay visible at the top or bottom of the screen, so we need to do some extra calculation to let it stay centered.

Love the technique, can't wait to see something like this start showing up in more apps. I think anything that intuitively allows developers and designers a way to remove ugly information like timestamps from rows of data is awesome.

Update: Here's a web-based implementation of the same effect.

Remote Debugging UIWebView

2011-12-06T20:33:00-06:00

Hiedi Utley has completely brought the awesome with a way to use desktop Safari's WebKit inspector to debug iOS UIWebView objects:

Wow! What a day! While researching debugging techniques for an upcoming training class I am teaching on PhoneGap, I stumbled over a couple of blogs about a private API in iOS5 that will allow you to debug your UIWebViews right inside desktop Safari using the Web Inspector!

Enabling the trick requires part of a private API in iOS 5, so don't ship it. It does seem to work great though, and it's pretty simple:

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions {
    // Uncomment to enable remote debugging
    [NSClassFromString(@"WebView") _enableRemoteInspector];

    return YES;
}

Then open up desktop Safari and head over to http://localhost:9999. It requires that you be running iOS 5 and running inside the iOS Simulator, but still, what a HUGE help.

(via Mike Rundle)

Update: Turns out Nathan de Vries did a lot of the original research and discovery on this one, here's his original (and in-depth) write up of it: Enabling Remote Debugging via Private APIs in Mobile Safari

Android Graphics Truth Facts

2011-12-06T19:54:00-06:00

Andrew Munn points out a simple truth about Android vs. iOS graphics rendering:

It’s because on iOS all UI rendering occurs in a dedicated UI thread with real-time priority.

He also clarifies:

Compositing and previously set-up animations—all the stuff that involves the Core Animation rendering layer tree—do indeed happen on a background thread.

Drawing new content into Core Animation layers and setting up their animations happens on the main thread. This is the same thread that user interface actions occur on.

In naively written code, all developer-written code would occur on the main thread. However, Apple provides very easy APIs (Grand Central Dispatch and NSOperation) to move things into system-managed background threads. In iOS 5, you can even declare that a Core Data (object-relational database) context cannot be used directly on the main thread.

I love that we're finally starting to see some in-depth writing about the meat of these issues.

Pretty much everyone I speak to on a regular basis tells me "Android just feels laggy" or something of that nature. I can't speak to the specific causes of Android's hiccups in this department, but Andrew's post sounds pretty accurate to me in regards to Core Animation and UIKit rendering behavior.

Gradient.app

2011-12-01T09:05:00-06:00

A fantastic little OS X app here for configuring CSS gradients. The interface of Gradient is really fantastic and pretty close to perfect of this simple task.

You simply choose your color, and generate the CSS. It has all sorts of configuration options to support every modern browser.

Love little tools like this. It's $4.99 in the app store, grab it here.

Compiling Doom 3 in Xcode 4

2011-11-27T16:31:00-06:00

Fabien Sanglard brings us an extremely comprehensive guide to getting the recently open-sourced Doom 3 source code up and running on OS X using Xcode 4.

Love it:

SNRFetchedResultsController

2011-11-27T16:18:00-06:00

SNRFetchedResultsController is a "port" (not exactly) of NSFetchedResultsController from iOS to OS X. It is not a drop in replacement for NSFetchedResultsController, but performs many of the same tasks in relation to managing results from a Core Data fetch and notifying a delegate when objects are inserted, deleted, updated, or moved in order to update the UI.

As someone who is primarily an iOS guy, having this class around makes the thought of doing some larger Mac OS X and AppKit-based stuff much more inviting.

Implementing it is this easy:

NSFetchRequest *request = [[NSFetchRequest alloc] init];

request.entity = [NSEntityDescription entityForName:@"Car" inManagedObjectContext:context];
request.sortDescriptors = [NSArray arrayWithObjects:[NSSortDescriptor sortDescriptorWithKey:@"year" ascending:YES], nil];
request.predicate = [NSPredicate predicateWithFormat:@"wheels.@count != 0"];
request.fetchBatchSize = 20;

self.fetchedResultsController = [[SNRFetchedResultsController alloc] initWithManagedObjectContext:context fetchRequest:request];
self.fetchedResultsController.delegate = self;

NSError *error = nil;
[self.fetchedResultsController performFetch:&error];

if (error) {
    NSLog(@"Unresolved error: %@ %@", error, [error userInfo]);
}

- (NSInteger) numberOfRowsInTableView:(NSTableView *)aTableView
{
    return [self.fetchedResultsController count];
}
- (id) tableView:(NSTableView *)aTableView objectValueForTableColumn:(NSTableColumn *)aTableColumn row:(NSInteger)rowIndex
{
    return [self.fetchedResultsController objectAtIndex:rowIndex];
}

- (void) controller:(SNRFetchedResultsController *)controller didChangeObject:(id)anObject atIndex:(NSUInteger)index forChangeType:(SNRFetchedResultsChangeType)type newIndex:(NSUInteger)newIndex
{
    switch (type) {
        case SNRFetchedResultsChangeDelete:
            [self.tableView removeRowsAtIndexes:[NSIndexSet indexSetWithIndex:index] withAnimation:NSTableViewAnimationSlideLeft];
            break;
        case SNRFetchedResultsChangeInsert:
            [self.tableView insertRowsAtIndexes:[NSIndexSet indexSetWithIndex:newIndex] withAnimation:NSTableViewAnimationSlideDown];
            break;
        case SNRFetchedResultsChangeUpdate:
            [self.tableView reloadDataForRowIndexes:[NSIndexSet indexSetWithIndex:index] columnIndexes:[NSIndexSet indexSetWithIndex:0]];
            break;
        case SNRFetchedResultsChangeMove:
            [self.tableView removeRowsAtIndexes:[NSIndexSet indexSetWithIndex:index] withAnimation:NSTableViewAnimationSlideLeft];
            [self.tableView insertRowsAtIndexes:[NSIndexSet indexSetWithIndex:newIndex] withAnimation:NSTableViewAnimationSlideDown];
            break;
        default:
            break;
    }
}

SNRFetchedResultsController is created by Indragie Karunaratne. He has been rocking the Mac OS X open source stuff lately and this latest one doesn't disappoint.

iOS Settings Shortcuts

2011-11-18T19:12:00-06:00

From the uber-talented Jeff Broderick comes this beautiful and awesome collection of iOS homescreen shortcuts to the major parts of iOS's settings app. Finally, you can have beautiful, quick ways to get to the parts of Settings.app you use the most.

Also make sure to check out Jeff on Dribbble, his work is awesome!

Scrapbook of an Advanced Core Animation View

2011-11-18T14:20:00-06:00

Found this article that Drew McCormack put together while searching around for some CoreAnimation techniques this afternoon.

It basically covers the process of conceptualizing, imagining, wire framing, designing, implemented, performance tuning and testing a really awesome CoreAnimation interface.

These type of complete, comprehensive guides are quite rare in the Mac/iOS world and Drew really brings the awesome with it. I highly suggest you check it out.

On Skeuomorphism

2011-11-03T21:37:00-05:00

Skeuomorphism is a fantastic technique and I couldn't be happier with how it is used in the design of some applications. When used both properly and effectively, I believe it can lead to some of the best user interfaces the world has seen.

The "official" definition:

A skeuomorph or skeuomorphism is a derivative object that retains ornamental design cues to a structure that was necessary in the original.

In our world it's actually something a little more specific. I think my buddy Mike Rundle summed it up best in his post on Hacker News today:

There's a difference between "looking like something I'm familiar with" and "working like something I'm familiar with". The problem with bad skeuomorphic design is when it looks familiar but doesn't act like the thing it's mimicking.

I couldn't agree more.

I would take it a step further and say that the interactions of such an interface need to be intuitive and discoverable on the platform. Take this app:

Yes, it does somewhat resemble a real world object. But, putting aside my own personal disdain for how hideous it looks, it has a major flaw: It is not usable. The minimum usable height for tap targets on iOS is 44 points. Take UIBarButtonItem for example, here's one:

The good folks over at Korg completely ignore this fact. They have many buttons that are only 20 points tall. This not only makes the buttons hard to tap, but their placement makes the virtual "knobs" quite difficult to interact with. Also, given the large and clumsy nature of our pointing devices (otherwise known as "fingers"), turning virtual knobs is a very non-intuitive method of choosing a value from a range of values on a digital screen. A better way of handling this type of interaction could be something like the iOS movie player, which allows you to intuitively scrub through the timeline of the movie at high and slow speeds depending on the vertical position of your finger after beginning your action.

My point is that an app doesn't have to completely replicate the real-world interface to which it's referring. You merely have to remind the user with subtle but recognizable visual cues, then embrace the platform.

The Early Edition 2 for iPad does a pretty great job of this:

Their story-sharing screen is one of my favorites in any app, you really have to see the animations and interactions to truly appreciate it. They remind the user of a newspaper, even allow you to pull down the corner of the page and turn to the next, but they don't go too far. They don't make you un-fold the paper, shake to make the ads fall out, or (an unrelated rant) throw in full page ads in between the content you're trying to read. Their sharing screen is so elegant. It sort of mentally nudges you into understanding what's going on by emulating a manila envelope, even taping it closed for you.

Then we come to this little bastard:

It resembles no actual recognizable interface or object (other than maybe a super shiny baseball glove or a native american friend-finding dreamcatcher). It is themed, at least it would seem, for the sake of being themed. At a glance, it doesn't necessarily look bad, it just doesn't make much sense. Apple has top-notch designers. I almost feel bad bringing Find My Friends up as it has been sort of hammered to death recently. However, I couldn't finish out this post without mentioning it.

If you aren't going to make a truly skeuomorphic interface, but are just going for a good looking app, then use textures and patterns with extreme care. Your users, and hyper critical bloggers like myself, will thank you.

Slide Design for Developers

2011-10-31T08:28:00-05:00

Great slides make for great presentations. But more than that, great slides really help people understand the information you're trying to present to them. Zach Holman outlines the finer points of this in a post on slide design targeted towards developers.

My slides are not designed for people who didn’t see the talk in person. They’re designed to support my words, not some online audience. What’s more, many commented that they found the design of the slides to be noteworthy. I’m expressly not a designer.

You really have to give Zach's post a read, there's a ton of great information in it, and to be honest, I'm loving the design of his slides, the typography really shines.

Linens 'n Things

2011-10-28T22:03:00-05:00

If you'll indulge me, I'd like to take a minute to talk about this little bastard:

In recent months, the conversation amongst many of my designer friends has often drifted to something like this:

What the hell is with all the crazy textures and patterns in Apple's user interfaces lately?

I personally don't really mind all the texture, it's usually used fairly tastefully, and doesn't bother me at all.

I gained some insight into Apple's use of texture by reading this post by Nevan Mrgan. Perhaps we can attribute everything back to the horizontal stripes of OS X's Aqua or the vertical pinstripes of iOS's UITableView to Steve.

However, ever since I first saw Notification Center, something didn't quite make sense to me. First, a couple of important user interface metaphors in iOS:

Notification Center

The metaphor of the main Notification Center panel is that it slides down over whatever content is currently on your device's screen.

Multitasking Tray

Here there's a similar interfacing layering metaphor going on. No matter what part of the OS you're in, double-tapping the home button causes whatever content is on your screen to slide up, revealing a "tray" containing icons of your most recently used applications.

Both of these interfaces have our friendly neighborhood linen as their background texture. On their own, this wouldn't be too much of an issue but consider what Apple's goals are with the linen texture. I would argue it is to establish a clear hierarchy of content and controls, from back to front. The linen was used early on as the "underneath" texture of UIScrollViews and UIWebViews.

Assuming these goals, take a look at what's really going on here:

The linen texture now shows up at multiple points in the hierarchy. This completely destroys the illusion of seeing behind or underneath the layers of the user interface.

I'd love to see Apple remedy this and assign clear layers to the different pieces of the interface.

It could be as simple as revising Notification Center to have a simple black background with beveled section headers, similar to what the fantastic Nik Radjenovic mocked up and posted on Dribbble. Shown here:

Something like what Nik has mocked up would easily establish a top position for Notification Center, thus restoring balance and order to the force.

Apple designers: please let the reign of the dark lords of linen end soon.

Subtle Design Changes in iOS 5

2011-10-28T20:03:00-05:00

I always find it fun to try to spot all the tiny design differences in Apple's user interfaces whenever a new update comes out.

A blog called Design Archive has put together some comparison shots of iOS 4 and iOS 5 highlighting some of the more fun differences. Normally I would quote the site I'm linking to, but this one is in Japanese, and Google Translate doesn't exactly offer grammatically readable sentences either, so here's a few of the fun ones they found:

I love that Apple's designers revisit things like this so often.

CSS4 Selectors

2011-10-27T20:07:00-05:00

Looks like the CSS Working Group has published their first working draft of how they'd like CSS4 selectors to work.

Here are some of the highlights:

var el = document.querySelector("#foo"); // returns first element with ID of foo
    var bar = document.querySelector(":scope > p", el); // returns equivalent of "#foo > p"

li a:matches(:link, :hover, :visited)

a:local-link /* Matches anything that links to the current page */
a:local-link(0) /* Matches any link that is the same domain */

There's tons more and David Storey does a great job of explaining stuff in his blog post.