'A large percentage'

‘A large percentage’

Ben Kuchera on the Nintendo 3DS XL:

Nintendo can count on a large percentage of customers upgrading their existing 3DS hardware to the XL, which means moving your content is an important feature.

This quote perfectly illustrates the insular nature of the tech and gaming press. Kuchera’s friends and associates–the people he talks to regularly–probably upgrade to every minor hardware revision of every major console; if it doesn’t seem worthwhile, they might grumble a little, but they’ll still buy it anyway.

Most people do not do this.

Right now, Nintendo’s biggest hurdle is still in informing their customers that the 3DS even exists; ‘a large percentage’¹ of DS owners, even if they’ve heard of it, do not even understand that the 3DS is a separate and incompatible console from the one they already own. (The Wii U will have this problem as well, which is not helped by Nintendo’s baffling naming choices.)

---

1. This data point is backed by the same rigorous level of research as Kuchera’s original assertion. ↩︎

Amazon Game Studios

Amazon Game Studios

Why is Amazon making social games, you ask? Good question! We know that many Amazon customers enjoy playing games – including free-to-play social games – and thanks to Amazon’s know-how, we believe we can deliver a great, accessible gaming experience that gamers and our customers can play any time.

Of course, it’s so obvious! Amazon is the perfect company to make games, because… uh… wait, whaaat?

Prepaid Cellphones Are Cheaper. Why Aren't They Popular?

Prepaid Cellphones Are Cheaper. Why Aren’t They Popular?

‘Right now, consumers don’t do the math, and they have a lot of resistance to paying $500 to $600 upfront, and they’d rather pay $100 upfront and then overspend,’ he said. ‘That psychology has worked for hundreds of years, and it’s still working.’

Justifying the existence of New Super Mario Bros.

Scott Thompson:

New Super Mario Bros., as a series, is stuck in neutral. The games function well enough and there is fun to be had, but if you’ve played one, you’ve played them all. That couldn’t be said about the games in the ‘80s. That’s the problem right there: Nintendo has become complacent, implementing only incremental upgrades from game to game. In the latest Iwata Asks, the team behind New Super Mario Bros. 2 talked about the Mario Cram School, where employees from several different departments come to learn how to create 2D Mario levels. It would appear to me the Mario Cram School needs to offer some extra courses, because the students have been turning in the same assignment for the past seven years.

Nintendo is obviously doing this intentionally. One could hardly accuse them of being lazy as a game designers, and NSMB, for what it is, remains incredibly well-polished compared to what everyone else is putting out.

Here’s my theory on this: NSMB is not for Mario fans.

The mainline Mario series is for Mario fans, of course. By ‘mainline’, I mean Super Mario Galaxy and Super Mario 3D Land: the games that inherited directly in the line of succession from Super Mario 64; the ones that try all of the fun new ideas that Miyamoto and his team come up with. And by ‘Mario fans’, I mean the people who have been following these games the entire time, who have played all (or most) of them as they have been released. Mario fans are the ones who never gave up on Mario, never got bored of it, never grew out of it.

I think all Mario fans know intuitively, without having to be instructed, which games are the ‘real’ Mario games, and which ones are a side-show. I don’t think they need it explained to them that New Super Mario Bros. Wii was not a sequel to Super Mario Galaxy.

I think Mario fans aren’t necessarily expected to buy and play every NSMB when it comes out, if ever. Why would they? There’s very little new or exciting in any of them. And thus, the ‘New’ in New Super Mario Bros. is ironic in a way that I’m not sure Nintendo intended: the thing that distinguishes them is that there is nothing new about them. The only reason for the fans, the people who have seen it all before, to play a game like NSMB is for a quick dose of indulgent, low-nutrition nostalgia, before they move onto their next ‘serious’ game.¹

And why must Nintendo cater this particular series to that particular audience, anyway? They already have a series tailored for them: the mainline series. No, NSMB is made for a different audience: one whose attention Nintendo has been trying to gain for some time now.

Walk around the entertainment department at Target, and what do you see? This, for $149:

NSMB exists to be a system-seller to people who played NES or SNES many years ago, and have never picked up a Nintendo game since. It’s for the ones that got away. It’s Nintendo standing in that aisle with open arms, saying, ‘Hey, remember us? Remember how much fun you used to have with us? You can have literally that exact same kind of fun again, right now.’ And then, once this person owns the system, Nintendo has their foot in the door–’You know, we’ve made some other games recently… they’re not quite the same as you remember, but they’re fun too…’

I think Nintendo has found, with the first two NSMB titles, that this is working, and that they need a NSMB game on every Nintendo console in order to sell to these people. This is sort of like the blue ocean strategy, but slightly modified: instead of reaching out to people who have never played video games, Nintendo is trying to get people to come back, who used to be customers but haven’t been in a long time. And I think it says something about the popularity of the SNES that this is the specific period of time in history that Nintendo chose to focus on.

And that’s why we’re seeing two NSMB games, one for 3DS and one for Wii U, coming out so close to each other. Mario fans are not expected to buy both of them, or even one of them. If they do, great, but it’s not for them. It’s to sell the consoles to people who wouldn’t otherwise buy into the platform at all.

Why can’t NSMB appeal to both audiences? Quite simply, you can’t please everyone. If I’m right, Nintendo believes there is a large number of ex-Mario fans out there who got lost somewhere along the way. If Super Mario Galaxy was already winning them back, then NSMB wouldn’t have been necessary in the first place. One way to look at this is that we should be happy that Nintendo decided to create a new series, rather than ‘dumbing down’ the mainline series. And yet I doubt they would ever seriously consider such a thing–not while Miyamoto’s influence still lingers.

So no, NSMB never was, and never will be, a stroke of Miyamoto’s masterwork. And, guys, this is okay. Just like the industry making more games as a whole means there will be a larger quantity of bad or mediocre ones, there’s no reason that would diminish the quality of the really good games. This is evidence of the market expanding, which logically should be a good thing for Nintendo. And by extension, what’s good for Nintendo is good for Mario fans. One would hope.

---

1. For what it’s worth, I occasionally enjoy playing the NSMB games–just not as much as I enjoy the mainline series. ↩︎

In defence of Duplicate

Since Lion was released with a Duplicate command instead of a Save As command, there has been a lot of consternation. Mountain Lion has tried to assuage the concerns of those who miss the Old Way somewhat, by bringing back Save As, hidden behind a modifier key. Much of what I’m reading still expresses bewilderment that Apple ever tried to get rid of Save As in the first place, but I think it made sense, and still does.

The problem with Save As is that it has no real-world analogue. The only reason we’re all used to it is because it has been part of graphical computers for 28 years.

Consider the traditional Save As workflow:

1. Open an existing document
2. Make a bunch of changes to it, without saving the original.
3. Choose ‘Save As’ from the File menu, which simultaneously does three things:
   • Creates a new copy of the file
   • Saves your most recent changes in the new copy
   • Replaces the file you were looking at on the screen, which until now was the old copy with unsaved changes, with the new copy–although, given that the old copy with unsaved changes (which now no longer technically exists) looked the same as the new copy with your new changes, the only indication of this on the screen is the change of name in the title bar

How would you do this with a piece of paper? You couldn’t. For starters, step #2 is impossible to do in the real world - there is no concept of ‘saved’ or ‘not saved’. If you scribble on a piece of paper, you have immediately committed those changes to permanent storage. There’s no way not to. But the even bigger problem is step #3, which does several things at once - this is very confusing to someone who has limited or no concept of the computer’s file system.

So here’s a modified workflow that works with a physical piece of paper in the real world:

1. Take an existing document out of your file cabinet
2. Walk it down the hallway to the copying machine, and make a copy
3. Scribble some changes on the new copy

Much simpler, and it just so happens, this is the workflow that Apple is trying to use for the ‘Duplicate’ functionality:

1. Open an existing file
2. Choose ‘Duplicate’ from the File menu (now, both your original file, and the new file are still on the screen in separate windows)
3. Make a bunch of changes to the new file
4. Choose a name for the new file

Notice what’s missing in this? Just like in the real-world example, the concept of ‘saved’ or ‘not saved’ is gone.

However, something else got added: a fourth step. That, in a nutshell, is what people seem to be so bent up about: Apple made the same operation take longer. Apple broke their muscle memory.

Disrupt all the things

Save As was always too abstract, too automatic, too hard to see what’s going on unless you have already learned something about the file system. Apple’s goal always has been that you shouldn’t need to learn how a computer works in order to use one.

At this point in computing history, I feel like I shouldn’t really have to justify that the pros of being easier for new users outweigh the cons that the smaller pool of seasoned veterans will experience. Isn’t this a given by now?

Like every other trivial software (or hardware) change we’ve ever collectively thrown a tantrum about over the past three decades, I think we’ll all find that after we get used to it, we won’t even notice it any more. Just like switching from Windows to Mac, or from the command line to a GUI, there is very little about the old way that was actually ‘better’, aside from the fact that we were used to it and already understood it.

So, try finding a way to disrupt your workflow today, and see if you’re not better off for it. Make a radical change just because. Unlearn what you have learned. Maybe you’ll decide it’s better, and maybe you won’t; the process of experimentation, not the end result, is what matters. Train yourself to adapt to changes. That way, when the world changes out from under you, you will be able to see things for how they are, not for how they always used to be.

I dub thee

You’ll notice that I put the ‘choose a name’ step at the end, when technically you can do it at any point after step 2. If you try to close the duplicate file without choosing a new name, the app will give you a choice between picking a name immediately, or deleting the file. Mountain Lion tries to streamline this somewhat by, immediately after step 2, highlighting the titlebar and allowing you to type a new name right then and there, suggesting that, y’know, maybe it would be a really good idea to do so. However, it is still optional at that point: if you decline to type a name, you will be prompted as soon as you try to close the file–the same as in Lion. But if you do make any change to the highlighted titlebar, you will not then later see a prompt; it will be saved automatically to the same location as the original. And it’s worth noting that, in Lion or Mountain Lion, regardless of whatever choices you make about naming or not naming, you can quit the app or yank out the power cord at any point, and when you launch the app again, everything will be right back where it was.

The point is that choosing a name still doesn’t require you to know anything about the ‘saved’ or ‘unsaved’ state of the file. The fact that you still have to choose a name at all is the only remaining part of this process that has no real-world analogue, since pieces of paper don’t have metadata (the justification for which is another topic entirely).

Re-skewed

‘Skeumorphic’ is a term that’s been widely used lately to describe how Apple’s apps, like Contacts, Calendar and Notes, are taking on more of the visual appearance of their real-world equivalents. But this effort culminates in more than just a graphical veneer.

Design is the way it works.

Launchpad Editor 1.0.2

Launchpad Editor 1.0.2

Changes in this version:

• Fixed a bug that would sometimes result in a crash or freeze when dragging an item to the last position in a page or group
• Fixed compatibility with Launchpad on OS X 10.8 Mountain Lion
• Added compatibility with Gatekeeper

Update note: Some people have had issues with the ‘check for updates’ menu item (Sparkle) in the past. It seems to be working now, but if you don’t see the update, you may need to download the new version manually.

Developer note: The source code for this version is not yet public, because the 10.8 GM is still NDA’d. When 10.8 is released to the public, I will upload the source code to GitHub.

The gated road to the future

Let’s talk about that last change.

Developer ID is Apple’s new program that allows Mac developers to sign apps for Gatekeeper without going through the Mac App Store. As we know, 10.8’s Gatekeeper feature will, by default, only allow users to install apps that are either (1) from the App Store, or (2) signed with Developer ID. This has been widely hailed as a developer-friendly move, allowing us to continue to create apps (such as this one) which are not possible in the App Store and do not go through Apple’s review process. (Much more in-depth explanation here from Steven Frank.) Up to this point, I have felt that it is a good solution.

But for some reason, I was under the impression that Developer ID was available to anyone with a free Apple Developer account¹. In making my app ready for Gatekeeper, I discovered that this is not the case; it requires a $99 annual Mac Developer Program membership, which is the same program that allows you to publish to the Mac App Store. I have not seen it reported anywhere, but it seems significant that Apple has quietly started requiring $99 from all Mac developers who publish free apps, including those outside of the App Store.

This presented a quandary for me: I was not already a member of the Mac Developer Program, only the iOS Developer Program, which is a separate $99; I have no plans to put anything in the Mac App Store; and I obviously don’t make any money from Launchpad Editor. Is it worth it to me to pay $99 to have my silly hobby app keep working for a year? This is a question I imagine many other developers are asking themselves right about now.

I could do nothing, and allow my users to see scary blocking errors when they try to download my app; this will surely be the case for many existing free apps that are floating around out there and will never see another update. I could even give specific instructions on how to override the errors and install it over the operating system’s protestations–I am sure some developers will try this technique, too, and test their users’ trust in Apple versus their desire for free stuff. Or I could just leave to the user to figure out on their own–considering Launchpad Editor’s primary audience (technical users), this probably isn’t a giant leap. But either way, I would consider the result to be an unacceptably bad user experience. I decided I would rather remove the app entirely than allow this to happen.

So it was kind of a toss-up, but in the end I decided that $99 isn’t a terrible expense for a hobby²…for now.

Curiously, the Developer ID certificate I was issued lists an expiration date five years from now–this is in contrast to the App Store certificates (for both Mac and iOS), which expire after one year. My Mac Developer Program membership, however, expires in one year. So I’m not entirely sure what will happen if I let the program membership expire and then try to use the certificate again. In theory, it should still work, but I have not been able to find any documentation about this.

So, honestly, I don’t know what will happen a year from now. I joined the program mainly to avoid feeling like I was losing the work I have already put into it, but at some point, it’s not going to be worth it any more.

Planned obsolescence

Finally, as a registered Apple developer, I can’t yet talk about what I may or may not have seen in Mountain Lion, since that’s still under NDA. But I will say, based on what Apple has publicly revealed about Launchpad in 10.8, I’m disappointed to see very little apparent progress–only one change is listed on that web page, and it’s only a search feature, which is redundant to Spotlight. The whole reason I use Launchpad is because I don’t want to type! I was hopeful last year when I first created Launchpad Editor that the need for my app was temporary, and it would soon be made unnecessary. Sadly, that does not seem to be happening. It’s hard to imagine that Apple can’t think of any way that Launchpad could be improved, so I guess the other explanation is that they just don’t care very much about the feature.

---

1. This is one of those maddening times where I’m sure I read this somewhere, maybe even just on Twitter from someone whom I considered a reliable source of information–but I can’t find any trace of it any more. (Of course, Twitter’s horrible search combined with their lack of anything resembling an archive doesn’t help.) If anyone can find a citation for this, it would make me feel less crazy. ↩︎

2. Insert Apple TV joke here. ↩︎

CocoaPods: The Objective-C Library Manager

CocoaPods: The Objective-C Library Manager

Found this today when I was troubleshooting some Xcode linker problem. If only I had known about it sooner!

Ruby on Rails developers will be immediately familiar with the concept: It’s basically Bundler for iOS and Mac development, even down to the fact that it’s written in Ruby¹. In fact, after I learned Rails, Bundler was one of the things I realised was painfully absent from my Cocoa workflow, and I have been wishing for something like it for some time now.

For the uninitiated, here’s the gist: Instead of downloading random code from all over the internet and copying it into your Xcode project, you specify the name and version of the library you want in a config file, and CocoaPods does the rest.

The advantages of this are:

• You know where your libraries came from, and which version they are currently on.
• It’s easy to automatically update to newer versions of the libraries. Or not; you can specify on a per-library basis which ones should be updated, or even that some of them should receive minor updates only, but not major updates, based on the version number. So you can get the benefit of bug fixes, without worrying about the API changing under you.
• CocoaPods does all of the Xcode configuration for you. If you’ve ever tried to set up a static library in a multi-project workspace, you know what I’m talking about with this: It’s one area where Xcode is still really buggy and randomly blows up for no discernible reason. The CocoaPods people have apparently figured out how to work around these bugs and make it Just Work.

The main difference between Bundler and CocoaPods is that Bundler saves you from having to check all of your libraries into source control; the only thing you need to check in is Bundler’s config file. This allows you to keep your repository a clean, sacred sanctuary, reserved solely for the purpose of your code. This is possible because Bundler is part of the standard Rails toolchain and workflow, and Rails developers know to run bundle install, which re-downloads all of the libraries from their original web sites, immediately after checking out a project. CocoaPods, on the other hand, is obviously not standard or included with Xcode, and many people don’t know about it yet, so it’s still advisable to check in all of the third-party code to your repository. This will allow even developers who don’t know about CocoaPods to check out, compile and run your project, without needing to learn about or do anything extra², at the cost of continuing to have a bunch of code that doesn’t belong to you in your repository.

---

1. I mean… what else are you going to write it in? Objective-C? Ha! ↩︎

2. If you work with a team of developers, you probably know how difficult it can be to get everyone to use any given developer tool that isn’t part of the standard toolchain. This is also one of the reasons I like git-subtree, although it looks like CocoaPod just replaced the majority of my use cases for git-subtree, at least as far as Objective-C is concerned. ↩︎

Die, contracts! Prepaid mobile phone use surges

Die, contracts! Prepaid mobile phone use surges

I hope this becomes a trend.

With such low-cost prepaid service available, what possible reason is there to sign a contract? Not being able to get the phone you want might be one, but that is seemingly becoming less of an issue.

Good riddance.

What is a property?

Brent Simmons has a plea to use dot notation properly:

1. Use dot notation for properties.
2. Do not use dot notation for non-properties.

First, I agree that there should be a convention behind one’s use of dot notation, as with other syntax.

However, this plea is predicated on the notion that a property is determined by a particular syntax in Objective-C: in other words, a property is the thing you write by typing ’@property’.

But a property is really a conceptual thing: it represents the state or condition of an object. It’s easy to imagine an Objective-C without ’@property’ syntax; you would simply write all of the instance variables, getters, and setters by hand. Writing ’@property’ is merely a shortcut to doing this.

So what makes a property different than any other pair of methods, one of which takes a value and the other of which returns a value? It is the idea that a property shouldn’t have adverse affects beyond getting or setting the value. This is fundamental to the separation of concerns in object-oriented programming: each method is only concerned with the barest minimum unit of work, and complex software is made of many tiny parts that each do one simple thing very well, instead of long methods that do many various tasks that are only tangentially related.

So what does it mean to say that dot notation should only be used for ’@property’ declarations, and not for other things that conceptually behave as properties? Not very much, really: you’re only saying that the thing you’re calling was defined with a particular syntax; you’re not saying what it actually is or does.

Moreover, I disagree that facilitating search-and-replace should be one of the primary goals of structuring code. In principle, code should be written, above all else, to be read and understood by humans, because reading code is harder than writing code; appeasing the mechanical tools should always come after this goal. Tools may come and go, but people might have to read and maintain that code for many years. We can always write new tools to help us refactor code; for example, why couldn’t Xcode have a more intelligent search that finds calls of a given method regardless of which (valid) syntax was used?¹ If the compiler can understand it, IDE search should be able to as well.

So here’s the rule I use. I’m not saying it’s the best way or the correct way, but it works for me:

Use dot notation for methods whose primary purpose is to retrieve or modify a discrete, specified element of the state of an object, while having minimal side-effects on other objects.

A simpler way of phrasing it:

Dots are for getting and setting ; brackets are for doing.

You will notice that this rule includes methods like count, because conceptually, it is really just a getter; the fact that the value it returns is likely to have been calculated on-the-fly, rather than retrieved from an instance variable, is an implementation detail that API consumers like myself need not concern ourselves with.

I have also been known to use dot notation on class methods like NSBundle.mainBundle and UIApplication.sharedApplication, because these too are getting methods. Xcode’s auto-completion doesn’t (yet?) recognise these, but they compile and work as expected. But I avoid using dot notation for removeLastObject on an NSMutableArray, even though I technically could, because that is a doing method.

---

1. If Apple doesn’t want to make it, someone else can. There are already powerful external code search tools like ack. And mogenerator is an example of a developer external to Apple improving an area where the Xcode tools are lacking. ↩︎

Dash - Mac programming documentation browser

Dash - Mac programming documentation browser

Speaking of programming tools, here’s one I found a little while ago on the Mac App Store, when looking for something to replace the broken and neglected Ingredients. I started out kind of ’m’eh’ about it, but it’s improved rapidly, to my surprise and delight. Has docs for Objective-C/Cocoa, Ruby, Rails, JS, jQuery, and just about every other language you can think of. I have a keyboard shortcut (by default, Opt+Space) set to bring up its window for quickly searching in a Spotlight-like way. It’s mainly good for this purpose–quickly looking up methods or classes you already know the names for–but not as good for reading longer tutorials or articles, since the section navigator doesn’t work for those. It also has some kind of snippet functionality which I haven’t really used.

It’s free for now, with some kind of paid version coming later. Not sure of the details on that, but it’s another app I’ll be happy to pay for.