This overview is offered as a resource to help others skip some of the pain I encountered, though it should not be taken as a recommendation for production code. I am primarily a designer, and was trying to build a quick-and-dirty prototype. This is not a reference for programmers, but prototypers, and frequently glosses over Swift features that programmers would consider fundamental.

What we want to do is animate nicely between two views in the same window, with the window resizing as necessary to match whichever is the current view.

Launch Xcode. Select File > New > Project. Choose OS X > Application > Cocoa Application. Hit Next. Fill out the product details however you like, but make sure the language is set to Swift (I’m no use to you with Objective-C) and “Use Storyboards” is checked. After the project is created, select “Main.storyboard” in the Project navigator (folder icon in the left-most pane.)

To do this, we’ll need four things on our storyboard:

• The window controller, already provided. Its size doesn’t matter, but you need to turn off its “Resize” capability in the Attributes Inspector (that’s the fourth button in the inspector on the right side of the Xcode window.) View transitions within user-resizable windows are possible, but beyond the scope of this project.

  Really, turn off window resizing. It’ll be a big headache later if you don’t.

• A “container” view controller occupying the “window content” relationship to the window controller. Again, just use the initially provided view controlller. Its size doesn’t matter either – we’ll set that in code; but keep in mind anything you place within this view controller’s view will be visible in the app at runtime. (You therefore probably want to leave it devoid of content.)

• An “origin” view controller that will contain the initial view the user sees. The size you assign its view will determine the size of the window at runtime.

From the Object library in the lower right, find the View Controller and drag it onto the storyboard. Then find the Push Button and place one inside the view controller.

• A “destination” view controller that will contain the view at which the user arrives after interacting with the origin view. The size you assign its view will determine how the window resizes following that interaction.

Again, drag a view controller onto the storyboard and place a push button within it.

You’ve probably noticed the “origin” and “destination” view controllers display no obvious relationship to the window or “container” controllers. This is because making the transition happen requires both the origin and destination to be designated as children of the container, and this is not possible via storyboard manipulation alone.

We need to build that relationship with Swift code, and that means we need to be able to identify some of these storyboard identities in code. For that, we’ll need the name of the storyboard file – usually “Main.storyboard” – and a couple “Storyboard IDs” we’ll set. Storyboard IDs are set via the Identity inspector, the third button in the inspector on the right side of the Xcode window.

In my example, I’m identifying the “container” view controller as “containerViewController” and the “origin” view controller as “sourceViewController.” It’s not necessary to set a Storyboard ID for the “destination” view controller, which is lucky for us – it means we could set up an indefinite chain of destinations and not have to rewrite any code for the additional view controllers. For clarity’s sake, however, I will refer to the “destination” view controller as if we’d assigned it the Storyboard ID “destinationViewController.”

Assign Storyboard IDs “containerViewController” to the window’s attached view controller and “sourceViewController” to the first additional view controller you created. Make sure you’re selecting the view controller itself and not anything within the controller. Click the blue icon at the top of the controller if you’re unsure. The Storyboard ID field is found in the Identity inspector.

Building the initial parent-child relationship will only involve connecting containerViewController and sourceViewController. We’ll hold off on adding destinationViewController as a child until we really need it.

To do this, we’ll create a new kind of view controller – that is, a “subclass” of Apple’s own NSViewController.

That’s done with File > New > File and selecting OS X > Source > Cocoa Class. Use “ContainerViewController” for the class name and NSViewController for the thing it’s subclassing. Uncheck “Also create XIB file” and leave the language as Swift.

Set the containerViewController to use the ContainerViewController class by selecting it on the storyboard and entering “ContainerViewController” in the Class field on the Identity inspector (third inspector button).

We want the containerViewController to do several things when it first loads, so we’re going to add several expressions within the viewDidLoad() function. Everything we add should be entered following the // Do view setup here comment but before the curly bracket that follows it.

We want to point containerViewController at sourceViewController, which would be easy if they were connected on the storyboard. Since we can’t do it that way, we’re going to direct the ContainerViewController class to the storyboard instead. But the Main.storyboard file isn’t yet something ContainerViewController knows about. We have to “import” it, if you will, as an NSStoryboard object. That looks like this:

let mainStoryboard: NSStoryboard = NSStoryboard(name: "Main", bundle: nil)!

This is not a Swift language guide, but I’ll break this down a bit. let is a Swift keyword that means we’re going to create a new constant – a variable that doesn’t vary. mainStoryBoard is just the name of the constant, which could be anything, but we want the name to make clear what it is. : NSStoryboard signifies this constant will be of the type “NSStoryboard”. The equals sign means that constant will be made equal to what follows, and what follows is a method for getting the storyboard file named “Main.”

The exclamation mark is used to insist on something we know exists but which Xcode isn’t so sure about. As we said, ContainerViewController doesn’t normally know about Main.storyboard; so we’re telling Xcode to take our word for it that there is a storyboard named “Main.”

Programmers refer to this use of the exclamation mark as forced unwrapping, but I prefer to think of it as an “insist.”

Now we have the storyboard as a Swift object and can address anything within it that we’ve assigned a Storyboard ID. Handy!

Next we grab our sourceViewController off the storyboard and render it to another constant:

let sourceViewController = mainStoryboard.instantiateControllerWithIdentifier("sourceViewController") as NSViewController

Since we established mainStoryboard is an NSStoryboard, we can do NSStoryboard things with it like .instantiateControllerWithIdentifier(). That means we tell Swift to grab the view controller with the Storyboard ID in the parentheses – “sourceViewController” – and spin it up so we can put it to use.

(It’s also possible to use .instantiateControllerWithIdentifier() to grab that other kind of controller, a window controller. That may be why we need to specify as NSViewController at the end there.)

At last we can connect containerViewController to sourceViewController as parent and child:

self.insertChildViewController(sourceViewController, atIndex: 0)

Since self here is going to be the containerViewController, we’ve told it to insert sourceViewController as a child of itself. We have to provide the index value because containerViewController could have more than one child controller and we need to explain where in the stack sourceViewController is meant to go. Since it’s the first child controller it goes in at the first index, index 0. (Programmers always start counting at zero, just accept it.)

Interestingly, if you run your app at this point you won’t see sourceViewController get pulled in. That’s because while it’s being added as a child controller “in the background” we haven’t expressly said we want to make it visible yet. (Sigh, I know. Always explaining to computers the obvious…)

Tell containerViewController to show the view in sourceViewController as a subview of its own:

self.view.addSubview(sourceViewController.view)

Now it will show up, but it’s likely your window size will be out of whack. We fix that by getting containerViewController to resize itself according to the size of the view in sourceViewController. What we want to mess with is the box around the view, which is called the view’s “frame.” The frame includes both the view box’s point of origin as well as its width and height.

Here’s how we tell containerViewController to match its view’s frame to that of the sourceViewController:

self.view.frame = sourceViewController.view.frame

That’s all we need to do in ContainerViewController. If you run your app now, you should see sourceViewController appear in the app window; but the button you added won’t do anything yet. That’s next.

Return to Main.storyboard. Select the push button you added to sourceViewController. Hold down the control key and drag the blue connecting line into destinationViewController. Release the mouse button, then select “custom” from the Action Segue popup.

What we’ve done is create a new “segue” from sourceViewController to destinationViewController. Custom segues require custom code – that we haven’t written – so this won’t do much yet.

Next, select the push button in destinationViewController and control-drag back toward sourceViewController. Again, select “custom” segue.

A segue is just a transition from one view controller to another. Apple provides the built-in types shown in the Action Segue popup, but none of those will provide the kind of transition we want. That’s why we’re creating our own. Unfortunately this takes quite a bit of code. Hang in there.

We’re going to create another subclass, this time of NSStoryboardSegue, and call it CrossfadeStoryboardSegue.

Select File > New > File and OS X > Source > Cocoa Class. Use “CrossfadeStoryboardSegue” for the class name and NSStoryboardSegue for the thing it’s subclassing. Leave the language as Swift.

The first thing a custom segue has to do is pull in the identities of the controllers it’s connecting. We do that with the following block of code:

override init(identifier: String?,
    source sourceController: AnyObject,
    destination destinationController: AnyObject) {
            var myIdentifier : String
            if identifier == nil {
                myIdentifier = ""
            } else {
                myIdentifier = identifier!
            }
            super.init(identifier: myIdentifier, source: sourceController, destination: destinationController)
}

Now we’re going to customize what happens when our storyboard segue performs its animation. We do that by adding an

override func perform() {
}

function underneath the init function we just added. (Make sure both functions are still within the curly brackets which enclose the class definition.) We’re customizing perform() because it’s the block that will execute when the segue is performed.

At this point all three view controllers. (containerViewController, sourceViewController and destinationViewController) are hanging around in code, either initialized within ContainerViewController or connected by the segue. We’re going to create handy references to each. Note that at this point we can count on containerViewController already being a parent to sourceViewController, so we point Xcode to it as such.

let sourceViewController = self.sourceController as! NSViewController
let destinationViewController = self.destinationController as! NSViewController
let containerViewController = sourceViewController.parentViewController!

This last is an important line. My first instinct was to import the storyboard and re-initialize containerViewController by its Storyboard ID. But it seems that would actually create a second instance of the controller. By referring to it here via its parent relationship, we get the existing, already-initialized controller we need.

The exclamation marks are especially confusing here. What we’re saying is something like: for this to work, we really need sourceViewController and destinationViewController to be treated as NSViewControllers (rather than NSWindowControllers, which is the only other possibility). We also really need sourceViewController’s parent controller. So long as we insist on all of that, the rest of our code will work.

So sourceViewController is already a set as a child of destinationViewController. It’s time to do the same for destinationViewController:

containerViewController.insertChildViewController(destinationViewController, atIndex: 1)

We’re inserting at index 1 this time because we don’t want to lose our sourceViewController hanging out at index 0.

Because we’re going to resize the window to match the dimensions of destinationViewController, it’ll make our work easier if we store that size information in some handy variables now:

var targetSize = destinationViewController.view.frame.size
var targetWidth = destinationViewController.view.frame.size.width
var targetHeight = destinationViewController.view.frame.size.height

Remember, the view’s frame is its box containing origin, width and height. So from .view.frame we can grab .view.frame.size, which includes the width and height but not the origin. From .view.frame.size we can grab .view.frame.size.width and .view.frame.size.height, each one still more narrowly focused than .view.frame.size.

(If you wanted to get at the origin alone, you could do .view.frame.size.origin or – more specifically – .view.frame.size.origin.x and .view.frame.size.origin.y. We don’t need those in this case.)

We’re finally ready to animate our view controllers. First we have to prep each controller for animation by granting it a Core Animation layer:

sourceViewController.view.wantsLayer = true
destinationViewController.view.wantsLayer = true

And then we tell containerViewController to make the transition happen:

containerViewController.transitionFromViewController(sourceViewController, toViewController: destinationViewController, 
    options: NSViewControllerTransitionOptions.Crossfade, completionHandler: nil)

All that is just to say: have containerViewController transition from sourceViewController to destinationViewController with the Crossfade option. NSViewControllerTransitionOptions offers a few methods for animating this transition, including sliding the new view controller in from one side or another.

I can only guess at what a completionHandler is, but setting it to “nil” makes Xcode happy.

At this point we have a custom segue that will mostly work, though we have to establish that this is the segue we want our view controllers to use. Go back to Main.storyboard, click on each of the segue arrows connecting sourceViewController and destinationViewController, and in the Attributes inspector (fourth button in the inspector on the right side of the Xcode window) enter “CrossfadeStoryboard” for Segue Class.

You can now run your app and try the button in sourceViewController. It will at least animate the transition to destinationViewController, though you may not like how destinationViewController fits in the window. That’s because we haven’t told the window to resize to fit it.

Go back to CrossfadeStoryboardSegue.swift and add the following on the next available line of the perform() function:

sourceViewController.view.animator().setFrameSize(targetSize)
destinationViewController.view.animator().setFrameSize(targetSize)

Because we set up sourceViewController and destinationViewController with Core Animation layers earlier, we can now use the animator() feature on their views. animator() can do many things, but here we’re just using it to resize the frames for both source and destination controllers. Our end goal for both controllers is to be the size of the destination controller, which we captured earlier in the variable targetSize. sourceViewController needs to resize itself to match the size of destinationViewController as that controller fades in.

But why does destinationViewController need to resize itself to match the very size we grabbed from destinationViewController? I’m not entirely sure, honestly. My best guess is somewhere in the process destinationViewController adapted its size to that of its parent, containerViewController, requiring us to get it straightened out here.

All that remains, really, is to resize the app window. First, we need to get the current size and location of the window by storing its frame:

var currentFrame = containerViewController.view.window?.frame

containerViewController is still the window’s main view controller, so it’s the best controller to ask about the current window size. view.window means something like “the window containing this view.” And what we need is not the window but its location and size – its frame.

Why the question mark? Question marks in Swift indicate a value that is optional. We’re indicating that containerViewController’s view may or may not be in a window at runtime. It’s almost certainly going to be in a window because of the setup we’ve done elsewhere, but Xcode can’t know that just looking at our custom segue code. So we tell Xcode to relax a little.

What we’re going to do with the next several lines of code is manipulate this currentFrame and then pass it back to the window so it resizes the way we want. There’s a catch, though – we can’t readily manipulate currentFrame in its current form. We have to convert it from its current form (NSRect, the usual for a view’s frame) to a CGRect.

var currentRect = NSRectToCGRect(currentFrame!)

This time the “insist” is required because we indicated window may not be available (window?), but currentFrame depends on window. We could have “insisted” on window instead – window! – and Xcode would have allowed currentFrame to stand without the punctuation.

So now we have the window’s frame stored as currentFrame and a CGRect version called currentRect. We want to resize this to match targetFrame (using targetWidth and targetHeight) but we also want to shift it along the x and y axes so the window seems to resize from the center rather than the top left.

Making that happen is a matter of shifting the frame one half of the difference in dimensions between the original currentFrame and the end goal targetFrame. We need to do the math to get those horizontal and vertical shifts first:

var horizontalChange = (targetWidth - containerViewController.view.frame.size.width)/2
var verticalChange = (targetHeight - containerViewController.view.frame.size.height)/2

horizontalChange is the difference between targetWidth (the width of destinationViewController’s view frame) and the width of containerViewController’s view frame, divided by two. verticalChange is the difference between targetHeight (the height of destinationViewController’s view frame) and the height of containerViewController’s view frame, divided by two.

Now we can take horizontalChange, verticalChange, targetWidth and targetHeight and make a new NSRect from them.

var newWindowRect = NSMakeRect(currentRect.origin.x - horizontalChange, 
    currentRect.origin.y - verticalChange, targetWidth, targetHeight)

NSMakeRect is a function for making rects, natch, and requires four components: the x and y for the upper left origin of the rect, and a width and height. We want our x and y to be the same as that of the current window, but adjusted for the difference between it and the destinationViewController frame origin. The width and height are just the targetWidth and targetHeight we’ve already established.

Finally we can resize the window:

containerViewController.view.window?.setFrame(newWindowRect, display: true, animate: true)

We tell containerViewController to set the frame of its window (which continues to maybe not exist, hence the question mark) to the newWindowRect we just created.

It’s fairly clear that setting animate to false will cause the window to snap to the new size instantly. It’s less clear what display is doing there. Setting it to false has no obvious effect. Well, we certainly want to display the new window so true it is.

At this point your view controller transition, complete with window resize, is finished. Since sourceViewController is no longer visible in the window, it might be wise to dump it from the hierarchy:

containerViewController.removeChildViewControllerAtIndex(0)

And Bob’s your uncle. For as much code as the custom segue requires, you only have to write it once — the same segue can be used anytime you want to create the same kind of transition — even if it’s in an entirely new project. You just have to make sure your source controller is connected as a child to a container controller first.

Download the example project (requires Xcode 6.2).

The short version of my reasoning is: in recent years I’ve seen the internet produce a tendency toward mob mentality that can accomplish scary effects.

The longer version is, I read this article about the lasting consequences for Justine Sacco produced by just one poor-taste tweet, and I got to thinking. Then I read this other article about twitter users who regularly prune their timelines, and got to thinking some more.

Then I decided to wipe out my Twitter history, and keep it wiped.

It’s unlikely I’ll ever post anything as instantly offensive to such a large portion of the web-using population as Justine Sacco’s heard-round-the-world tweet. But the thing with the modern internet is you can never tell just what’s going to set it off. What you might consider a harmless snarky remark (and, honestly, that’s about all for which I use Twitter) may offend the sensibilities of a stranger on the other side of the planet — and then the rest of the web will gleefully roast you over it, for the lulz.

Effectively, with never a shot fired, the internet has become its own police state.

Wiping my Twitter history doesn’t protect me from the web in all respects. But it should largely safeguard me against that particularly egregious online dogpiling tactic: digging up a remark made years ago in order to shame someone who’s only just become noteworthy.

(I do not foresee any reason I should become suddenly noteworthy in the near future; this is all done from an abundance of caution.)

How It’s Done

There are two stages to wiping one’s Twitter history — deleting the existing history, and “ongoing maintenance.” There are a number of tools which claim to be able to delete your old tweets in bulk, but after much trying I found only one that really works: the Twitter Archive Eraser by Martani Fakhrou. It does only run on Windows, but these days that’s no great hardship for the tenacious Mac user. Just get Oracle’s free Virtual Box and install on it the Windows 10 Technical Preview

Once you’ve signed in with the Archive Eraser it’s easy to delete tweets whole months or years at a time.

After wiping the slate clean, you need a way to make sure your history gets pruned on an ongoing basis. I use TweetDelete and set it to delete everything older than one week. Due to the frequency at which TweetDelete scans timelines, you’ll occasionally see an eight-day-old tweet even with this setting. That’s okay.

Short of shutting down Twitter (and, well, this blog) entirely, there’s no ironclad protection from the internet mob. But following the steps above have allowed me to continue tweeting with a new peace of mind.

Gaming Journalists Declare That “Gamers Are Over,” But They Are the Ones Becoming Obsolete

(It’s worth it for the last sentence.)

There are a couple angles to this assault on the gamer identity. The first has been floating around a while, but the second is new and more vehement. I’ll try to address each in turn.

You see, I am myself a gamer.

The concept of gamer has become obsolete

First, there is the notion that as gaming matures the need to differentiate the “gamer” from the rest of the populace will dwindle. This is clearly expressed in the work of Ian Bogost (sorry, Ian):

When we acknowledge videogames as a medium, the notion of a monolithic games industry, which creates a few kinds of games for a few kinds of players, stops making any sense. As does the idea of a demographic category called “gamers”€ who are the ones who play these games.

The issue I take with this is that “gamer” is something more than its base denotation of “one who plays games.” As Ian has himself said, “The problem with this ‘women are the majority of gamers’ line the press loves is that most women (rightly) want nothing to do with being ‘gamers.’”

So if a gamer is not just anyone who plays games, what is it? This turns out to be actually very simple: a gamer, I submit, is simply a gaming enthusiast. That’s all.

Do we need such a category? Well, we seem to draw the “enthusiast” distinction in many other areas of life. For example, there is no living man or woman who fails to eat on a fairly regular basis. Yet we would not consider every living man and woman a “foodie.” We have come up with the term “foodie” to describe those who do not merely eat, but display a refined and enthusiastic interest in their food. (And we’ve had similar terms, such as “gourmand,” for much longer.)

So the term “gamer” is not, in my book, terribly complicated nor especially redundant. And it’s certainly not derogatory, so long as you believe games can be worthwhile.

The concept of gamer describes a reprehensible segment of society

That brings me to the second, more current criticism: that “gamer” remains a useful category, but only because the body it delineates is one which ought to be singled out for censure.

This argument seems to have been first advanced by Leigh Alexander in her piece, ‘Gamers’ don’t have to be your audience. ‘Gamers’ are over:

[I]t’s not even culture. It’s buying things, spackling over memes and in-jokes repeatedly, and it’s getting mad on the internet…These obtuse sh**slingers, these wailing hyper-consumers, these childish internet-arguers – they are not my audience. They don’t have to be yours. There is no ‘side’ to be on, there is no ‘debate’ to be had.
There is what’s past and there is what’s now.

This distinction – between reactionary gamers clinging to a dead past and progressive… non-gamers who still enjoy games, I suppose, working toward a new future – appears again in a subsequent piece Alexander writes for Time magazine:

As video games unshackle from old constraints, traditional fans double down on keeping the treehouse sacrosanct.

(This is, by the way, the sort of “with us or against us”/“right side of history” triumphalist rhetoric that makes one devilishly hard to have a conversation with.)

What did gamers do to invite such vitriol? This is where some will accuse me of burying the lede, although anyone who’s followed this debate knew the lede already: certain game developers and critics have been taking tremendous heat for working to advance their causes within the games industry.

I don’t condone any of it. I’m especially distressed at the effect which this hostility seems to be having on games writer Jenn Frank. Anita Sarkeesian, who must have a skin of adamantium by now, is providing a useful critical counterpoint and ought to be allowed the space to continue doing so.

But a total conflation of “gamers” with the vocal mob will not withstand scrutiny. Some gamers are on the offensive; others are rallying to the affected. To ignore this fact would be to stoop to a level of broad-brush rhetoric no more sensible than the personal slurs which we decry.

As a gamer, I present the following principles for consideration:

1. Gamers should be free to advance their worldviews, even if those views are unpopular. That’s as true for feminism as for Christianity, or for Marixsm.
2. Gamers should be as free to advance their worldviews through game criticism as through the medium of games itself.

On the other hand, we need to make more careful distinctions. The gamer is not dying, nor does the gamer need snuffing out. On the contrary, I expect the gamer will only thrive. I love gamers. I’m proud to be one myself.

“For years I stuck with my iPhone, not because it was the best phone on the market, but because of the app selection. It’s absolutely second to none. But every year I watched a new version of iOS announced with a slew of new features I didn’t care about, while core functionality (flaws and all) was left virtually unchanged.

“Meanwhile, I watched from afar as Google was iteratively improving Android into the open, flexible, intuitive OS that it is today. I recently made the switch from an iPhone 5 to a Nexus 4 and I haven’t looked back. All the things that bugged me about iOS were non-issues on this new platform. I found great substitutes for all my favourite iOS apps and even adopted a few new apps that were missing on iOS. Sure, there aren’t dozens of options for each individual app, but the quality of the top apps available today is really impressive.”

“For the first time, I’m looking forward to Google I/O more than WWDC this year to see what’s next for Android.”

From Jason Sallis.

I’m not talking about skeuomorphism, which is a poorly-understood concept anyway. Probably any good touch interface is skeuomorphic by nature: this is not really a page under glass that you’re sliding around in Safari or Chrome.

Nor is this about the spectrum that lies between totally flat design and extreme texture realism.¹

Where I see Apple losing ground is in those areas which are really key to a user interface in the post-PC, touch-driven era. For me, that’s largely not about color, texture, shading or even icons(!).

Rather, interfaces succeed or fail on the basis of organization (of the whole), layout (of the immediate view), typography, responsiveness, constancy² and accessibility. By “accessibility” I don’t mean only access for the impaired, but access to the features or information the user needs at any given moment.

So while Apple’s graphical surfaces continue to outshine the competition’s in attractiveness, its interfaces could be falling behind in other areas.

One of the most important issues of accessibility for modern touch devices is the virtual keyboard. It’s an interface we use constantly: for searching the web, for sending a message, for entering a password, for adding an appointment to a calendar or for adding comments to a photo.

As it stands, I’d rate Apple as holding a solid third place in keyboards. While it’s fast and responsive, offers user-definable shortcuts and includes a sometimes helpful, sometimes maddening autocorrection system, the iOS keyboard has changed very little since the iPhone was released in 2007. (Text fields did gain copy and paste, which are both helpful and maddening in other ways.) Meanwhile, keyboards in Android and Blackberry have pushed ahead with predictive auto-fill capabilities. These systems hone in on what your most likely next word is, and offer to let you insert it with a tap or gesture. Since typing on glass is never without some frustration, requiring fewer taps means fewer opportunities for aggravation.

Andy Ihnatko switched to Android in part because of its superior keyboard offerings; while Ars Technica concludes “the BlackBerry 10 keyboard [with its flick-up-to-autofill feature] is one of the best virtual keyboards we’ve ever used.”

Good for Android and Blackberry 10. But it’s not just text entry where Apple is falling short; text editing remains remarkably painful on iOS. Having to fat-finger the insertion point into the hairline space between two letters so you can remove an unintended capitalization is a recipe for exasperation — and the need for doing so comes up multiple times a day. There are good ideas out there for how iOS editing could be improved. So far, Apple hasn’t shown much zeal here.

There are accessibility issues beyond the keyboard. Toggling wifi or bluetooth connections and adjusting brightness remain points of annoyance on iOS. Switching apps on iPhone requires a clumsy double-click on a button that was never engineered for that purpose. And even on the large, pixel-rich display of the retina iPad, there is no way to load a social stream alongside a live video (as I’ve wanted to do during political debates) or keep an online article handy while writing a response to it.

These are all interface issues that have been addressed to one degree or another on other mobile platforms.

Sharing data between apps, or between devices, remains a profound hassle. Using a photo from one app in another usually requires the ridiculous step of saving it to a third app — Photos — first. And if you want to move that photo to another device (or to your Mac), well… I hope you’re a Dropbox user, because Apple can’t help you.

Nothing here represents a problem beyond Apple’s ability to solve.³ Instead, what we seem to be seeing here is an example of Ed Catmull’s adage, “Success hides problems.” Apple continues to be monstrously successful across nearly every one of its product lines. If the iPhone 5 is the world’s best-selling smartphone and the iPad is the leader among tablets, what can there be to fix? My fear is that at some point these little niggling annoyances — each minor enough when taken on its own — will cease to be worth putting up with as a whole. If these are all solved problems on other platforms, customers will start to wonder why they have to keep tolerating them on an Apple device.

At that point, it’s already too late.

Apple does many things exceptionally well. Its industrial design and hardware engineering aren’t in danger of being eclipsed anytime soon. But competitors are chipping away at its lead in user interface. If Apple means to stay at the top of the mobile market, it needs to start closing these gaps.

In version 2.x, one could tap on a category — such as “Bakery” or “Health & Beauty” — then choose from a list of all known items in that category. As you can imagine, I never bothered with this approach. Instead, I used the search field. Start typing the name of your needed item, and Groceries would offer suggestions that matched your query. Tap to add the correct suggestion, then instantly start typing out your next item.

It was a fast input system, but there was room for improvement. Accessing the search field took one more tap than I preferred, and adding any information about the quantity needed (such as “2 dozen” or “1 gallon”) required backing out of the add-grocery mode and messing with the item you’d already added. Usually I just didn’t bother with quantities — too much trouble.

Enter version 3.0: autocompletion has now taken center stage. There are no categories to dig through — hitting the add-item plus sign button instantly lands you in the search field. Noting quantity is now integrated right into the grocery query. Typing “mil 2q” will offer “Milk (2 qt)” as the top hit. One tap adds both the item and its associated quantity. There’s no more backing out of the list-making process to add those details.

In my view, it’s hard to argue this isn’t a better system. It’s faster and requires several fewer taps per item. But the grocery-shopping public doesn’t agree. Since the release of version 3.0, Groceries has been hammered with 1-star reviews, and its rating stands at a positively-depressing 1.5 stars as of this writing.

What happened?

Incredibly, it seems quite a few users actually preferred digging through those old grocery store categories. They didn’t use the search field at all! And for those items which made the list frequently, they relied on the “Favorites” category to get at them without all the scrolling. Suddenly, that innocuous Update All button has completely changed the grocery game on these shoppers, and they are none too happy about it.

In the end, I don’t know how the update could have been better handled. There’s so much that’s better about Groceries 3.0, it would have been a shame to forego those improvements for the sake of maintaining the status quo. But one can understand why users who’ve come to rely on a particular interaction would be frustrated when that interaction changes with little warning. As Mike Hay suggests, this may just be an issue with how the App Store handles major updates. A user can be completely surprised by a strange, new version of an app; and she has no way to roll back to an earlier version.

I hope users of Groceries won’t give up on the new UI too quickly. It’s clever, easy to learn and more efficient once one gets the hang of it. It may be that Ms. Teutschler, the developer, can address some of the criticisms by adding a Favorites category back in somewhere. Meanwhile, I recommend you go try it out. If you come to it without preconceived notions of how a grocery list app should work, I think you’ll be very pleased.

Not every Pixar movie lends itself to extended discussion, but in my opinion two do: The Incredibles, and now Brave.

Based on its trailers, I think many of us were expecting Brave to deliver a typically American story: bold heroine rejects the outmoded strictures of her time, meets resistance, ultimately triumphs and leaves everyone else a little wiser in the end.

That’s not Brave.

This is a good thing; because once you think about it, that typically American story is not especially sound. Though we conceive of ourselves as individuals, we necessarily live in society. We have to contend with families, neighborhoods, governments, workplaces, schools, teams, industry associations and more. We don’t usually get to pick and choose which society’s rules we want to abide by. In fact, we almost never do. We can at best nudge them in new directions, very slowly.

But this freedom to “nudge” reveals a profound degree of responsibility. Because all these societies are made up of us, they can only be of our making. As children, our instinct is to refuse responsibility for anything we did not “directly” cause. As adults, we begin to comprehend just how much of the world is on our shoulders. As we learn from another Pixar movie, the first rule of leadership is “Everything is your fault.” But it’s also the first rule of adulthood.

I do not operate every vehicle on the highway. But I take advantage of and contribute to a way of life that depends on the automobile. Thus, traffic congestion and air pollution are “my fault.” I don’t employ underpaid third-world workers, but I buy the products they assemble. Thus, their situation is “my fault.” Maturity may be nothing more than embracing a wider and wider view of what ought rightfully to be considered to be my responsibility — including responsibility for institutions we did not choose and might never have chosen given the opportunity.

This is Merida’s journey in Brave. She must move from a position of “It’s not my fault” to “This is all my fault.” She begins with rejecting the fabric of her society (made very explicit in one of the film’s central metaphors!), but ends with both embracing it and nudging it along.¹ Merida’s tale is much more interesting than the mere iconoclast’s journey, because her story is ours too. Like Merida, we have to learn how to become our best selves within a wider society. What does it mean to be brave within that framework? That’s the question Pixar has put to us here.

(Besides offering food for thought, Brave is exciting, beautiful and touching. You should see it.)

I floated the idea on Twitter and gauged the interest level. There seemed to be some, so I packed my copy of Dominion — counting on other gamers to flesh out the supply.

We were going to need the help, because once a time and place were set (June 13th, 8:30 in Bil Moorhead’s luxurious hotel suite), word spread. At its height, Game Night saw over 25 attendees — not a massive party by WWDC standards, but certainly bigger than any social event I’ve organized. Dominion supports only four players. This could have been bad.

Fortunately, a number of guests showed up with games in tow. Ash Ponders brought Backgammon and Katrina Montgomery (who stomped over everyone in Dominion). Michael Fey showed up with Munchkin, which kept the bulk of the guests entertained. And Don Synstelien provided Cosmic Encounter, perhaps the only “true” board game featured that night. Big thanks to everyone who helped out — Game Night would have landed with a thud if not for you.

Will there be a WWDC Game Night 2013? Possibly. If you made it to WWDC 2012 you know how incredibly difficult tickets are becoming to get. There’s no guarantee I’ll make it back next year. But if I do, I’ll be bringing one game or another.

Dominion in progress. Katrina, on the right, was the winner by a mile.

Munchkin was able to entertain a small crowd.

Cosmic Encounter is a good game for making friends… and enemies.

Web standards wonks are hashing out a new standard for serving the appropriate version of an image given the resolution of a user’s device. Unfortunately, that single standard has turned into two competing proposals, feelings are hurt, etc.

If we’re going to improve web images, these two assumptions seem sensible to me:

1. One should modify the <img> tag as little as possible. Web designers know how the <img> tag works. It’s not the most elegant thing imaginable, but it’s familiar. We should work with what we’ve got.
2. The new syntax should be as compact as possible. <img> tags get used a lot. Anything that gets added to <img> could potentially need to be added to a page dozens of times. We should save ourselves some keystrokes.

Let’s look at the contenders. First, the offering from the Responsive Images Community Group, the <picture> element:

To me, this looks like a pain. It requires the new tags be wrapped around every <img> element which needs to be made responsive (likely all of them). The <source> has to be spelled out for every alternate version. And while the “min-width” and “min-device-pixel-ratio” syntax matches that of a media query stylesheet, in a media query stylesheet these need only be typed once per media type. With the <picture> element proposal, those queries will need to be added to every image.

Below is the version Apple suggested, “img set.” And let’s just acknowledge the elephant in the room: iOS retina devices are the entire reason this conversation is going on. Giving Apple’s proposal a little extra weight may not be unreasonable.

Hey, this looks pretty compact by comparison. It only requires a new attribute on the familiar <img> tag. Think about that: it’s just one tag. (I count four in the alternative, excepting the closing tag.) Using “w” and “h” for width and height is unusual in web development but easy enough to remember. To me, this looks like a winner.

(Update: it’s worth noting that both specifications are still in flux and at least in the case of “img set,” some of the components may be optional. Imagine the following:

Now that’s nice.)

One of the arguments in favor of the <picture> element is that its syntax more closely matches that of the HTML5 <video> and <audio> elements. But this is a bad comparison. It’s fairly rare for video or audio to be embedded in a page more than once; while a single page, again, could contain dozens of images.

Whether or not Nintendo CEO Satoru Iwata ever referred to Apple as “the enemy of the future,” the sentiment is sound — casual gaming, so recently the key to Nintendo’s “blue ocean” strategy, is increasingly an iOS affair. And having all but abandoned the “hardcore” gaming market this past generation, Nintendo is left with very little room to maneuver.

As I see it, Nintendo has three options; and none of them easy. The first and, I believe, worst solution is to abandon hardware and transition to becoming a software-only company. It’s true that gaming properties like Mario, Zelda, Donkey Kong, Metroid and Pokémon are probably Nintendo’s best assets and could sustain a substantial game company. But without the hardware platforms along for the ride, I doubt software alone could fuel the Nintendo we know today. That way lies diminishment, and should be regarded as a last resort. Sega serves as a strong warning against this approach.¹

The second, slightly better plan is to confront the Xbox head-on. In fact, Nintendo has hinted it may be looking to do so with the beefed-up graphics capabilities of the Wii U. But graphics are a technology problem which is relatively straightforward to solve. Nintendo’s real handicaps against Microsoft are cultural: Nintendo does not value developer relations or online connectivity and Microsoft does. Core gamers want expansive third-party libraries and dead-simple online multiplayer; and Nintendo has a long track record of failing badly at providing either with its platforms.

The third option open to Nintendo is the most interesting and the riskiest: go after Apple on its own turf. Create a true, standalone tablet device that takes advantage of Nintendo’s strengths. Such a device — call it the “Nintendo iDS” for fun — would certainly require a world-class browser and support for the usual mobile standbys (like text messaging). But unlike the iPad, the iDS would feature integrated buttons and analog circle pads to make even the most “core” of gaming experiences possible.

It may sound crazy, but it’s not so far from what Amazon is attempting with the Kindle Fire. And Nintendo has a few tricks up its sleeve. As with the 3DS, it could design the iDS with a 3D screen and slider. (I’m not big on 3D in general, but if it makes sense anywhere it’s on a gaming platform.) Games could be temporarily shared with non-owners for multiplayer matches, as Nintendo already allows on its handhelds. But more than anything else, the iDS’ big feature would be one-tap access to both classic and brand-new titles in the Mario, Zelda and other franchises.

Do I think Nintendo will actually try to produce such a device? No. Nor do I expect them to get over their cultural handicaps or transform into a software-only developer. Nintendo will stick to its console hardware guns as long as it can; and it has the cash to be stubborn for quite some time. But the gaming industry is changing dramatically. Sooner or later, Nintendo will have to change too.