In a sense, desktop applications could be designed without context in mind, because there really was only one context: the user is sitting at a desk working on the computer. In this context, and because the PC only worked using abstractions upon abstractions, it was okay for the user interface to dominate what we were doing. Everything was artifice anyway, so it only made sense for artifice to dominate.

That isn’t the case with mobile devices. What’s powerful about mobile devices is that they exist to complement what we are already doing, rather than be our primary focus. Whereas users mold themselves around how PCs work—users only work on PCs while their focus is entirely on them—mobile devices are used while doing other things. They’re used while waiting in line at the grocery store, when out to dinner, watching television, driving somewhere (by passengers!), or walking somewhere. Mobile devices are used almost entirely while doing something else, for relatively short periods of time, and usually, to accomplish a very specific task. What groceries do I need to buy? What time does the movie start? How do I get to that restaurant? What’s the weather going to be like? etc.

What this means is that designing applications for mobile means that context—for what purpose it will be used, how, and where—should be the first and primary consideration. It must define everything about how the application is designed, from the application’s concept to the physical design itself. It also means, though, that mobile applications are tools, a means of accomplishing a task and getting on with what the user is doing. Mobile applications should be cogs which seamlessly fit into an existing process—say, finding a restaurant to eat at—and make it better.

That’s precisely what a tool is: something which requires very little explanation for how to use it, because it is designed so precisely for its purpose, that how to use it is obvious. If you’re trying to dig a hole with your hands, you don’t need much explanation for how to use a shovel. “This is the handle” is about the extent of it.

There is no interface, in other words. There are no complicated concepts to learn first, no keyboard commands—just something which makes immediate sense, because it was designed precisely for what the user is trying to do. The application’s underlying concept should match the user’s.

Of course, there are cases where this really isn’t possible. Some purposes are so complex that even the best solutions are too sophisticated to be immediately understood, and even in simpler cases, it’s difficult to achieve. But that should be the goal.

What we should be trying to create are applications that are designed so specifically to the user’s context that the application ceases to feel like software—a finicky piece of artifice that we have to strain to understand and play with to get it to do what we want—and begins to feel like a physical object, something that just is and just works a certain way and we know will work that way.

In Path 2.0.6, released to the App Store today, you are prompted to opt in or out of sharing your phone’s contacts with our servers in order to find your friends and family on Path. If you accept and later decide you would like to revoke this access, please send an email to service@path.com and we will promptly see to it that your contact information is removed.

That’s the right thing to do. They did make a mistake—a mistake, it’s worth pointing out, that I think most applications with this sort of feature probably also make—by not requesting permission first. I don’t have a problem with a service I trust uploading my contacts for that purpose, but doing it without notifying me, let alone asking my permission, doesn’t engender trust.

What they’re doing now does. My view is Path was doing the wrong thing for the right reasons, and while that doesn’t excuse a mistake, it does mean that when they say they screwed up, they’re sorry, and they’re fixing it, there’s no reason not to accept it.

Well done, Path, for doing the right thing.

Goodbye, Twitter for iPad.

You can watch it on the AppleTV by selecting “iTunes Live” from the Internet menu. It’s worth pointing out that isn’t an option right now, so Apple will be adding it to the list—which means Apple has the ability to add new options to the AppleTV on the fly without issuing updates. That’s certainly a nice capability to have if you want to stream other events—like, say, sporting events.

The last year or so has, at least on the hardware side, been nothing but a big, pregnant pause for Apple. I knew that Jobs’s death would have an impact, but I never feared Apple would be rudderless without him. Current Apple CEO Tim Cook is a good manager with a deep understanding of Apple, but I do not think he has Jobs’s innate vision.

I know all this will change in short order. Before his death, Jobs and his team laid the groundwork for a host of new products. Apple will unveil an iPad 3 as early as March. We could see the iPhone 5 in June. Then, perhaps, it’ll be business as usual for the wildly successful tech company (which now has a boatload of cash to spend—certainly enough to afford every single Super Bowl XLVI commercial). Whatever Apple introduces this spring, it will be the company’s first hardware introduction since Jobs’s death: in other words, a huge test for Apple and for Cook.

So, because Apple released the iPhone 4S—which merely has a dramatically better camera, Siri, and a much improved processor—Apple is “rudderless” without Jobs. Okay. Fine. Let’s leave that fish alone in the barrel.

But then, in the next paragraph, Ulanoff then states Jobs and his team laid the groundwork for a host of new products before he died. So let me get this straight, Ulanoff: the lack of “new” devices since Jobs’s death indicates that Apple is in trouble without him, yet Jobs also helped create a pipeline of new products to be released after his death.

Perhaps in his bizarro reality these two statements make sense together. Whatever the case, this is the garbage which passes as analysis on Mashable. Not that you needed an excuse not to ever read that site again, but here’s as good a reminder as any of why it’s a waste of time.

Traditionally, developers aren’t great designers, and vice versa. There are many exceptions (ahem), but generally the art of one group is a mystery to the other – yet we routinely have to collaborate on projects. As someone who has worked in both areas, I’ve put together a list of tips for designers, on how they can make life easier for the developers who have to bring those designs to life as apps and web sites.

If you’re a designer (or developer, for that matter), and are working on a project or will be, go and read this.

When the market is that big of everybody that uses the Internet, any little differentiator can get you enough of a customer base to support yourself and a few other people.

Marco says that the ease of purchasing applications on iOS—and the number of users who do purchase applications—means that running a relatively small business is possible, which wasn’t really true on the web just a few years ago.

It seems obvious, but it’s a very big deal that a multitude of people can create businesses that do very niche things and be successful, without worrying about getting big. They can just focus on making their product better for their very specific customer base, and make enough money to support themselves comfortably.

I argued a year ago that this is important, too, because it allows a number of businesses doing similar things to co-exist. When a market’s economics force businesses to take a majority market share to survive—depend on getting big—they necessarily preclude other businesses from surviving in that market, too. This is true of most advertising-supported businesses, because making decent money from advertising requires significant scale. But for paid-for applications, you don’t need that scale. You just need a loyal group of customers who pay and tell other people about your application.

That allows a much more diverse and unique market to develop, because developers are (relatively) free to experiment. Markets that depend on advertising should become relatively homogeneous while markets where customers pay for the products should be relatively more diverse.

Awhile back, Jacqui Cheng from Ars Technica contacted a bunch of folks (including me) for a story she was putting together about what iOS devs would most like to see from Apple in 2012. Unfortunately I never got around to responding (sorry Jacqui—the holidays were crazy), but if I had, one item would have stood an order of magnitude above everything else on my list: better rich text formatting support in the middle layers of Apple’s development frameworks.

Now this may sound like a surprisingly mundane request considering the number of whiz bang things people are expecting from Apple in 2012, but if you’ve ever tried to develop a native iOS applications that present textual content downloaded from the Internet, you probably share my frustration.

So, so right.

I look at iBooks Author and wonder if it might be, even now, an alternative for publications that don’t want to build an app—or feel that the app they can afford to build won’t be very good. What if periodical publishers could get access to Newsstand by publishing issues using a tool more like iBooks Author, to a standardized format? What if people could buy subscriptions to magazines and newspapers in the iBookstore? Instead of building an expensive container, we could spend our money on the stuff we put inside that container.

I think it’d be better if new editions showed up in the Newsstand folder, but that’s not the point: this is a really, really good idea. Publishing on the iPad right now is not very nice; magazines tend to be static images, even for text, and as you’d expect, the experience is terrible for readers. Creating a full-fledged application for their publication is prohibitively expensive and very difficult, so they haven’t done it. They’ve chosen a route which largely fits their existing workflow but results in a poor experience for readers.

iBooks Author could help eliminate that. Publications can create new issues that are really nice to read and are tailored to fit their own identity, without ever creating their own application. Publications would get the convenience and the unique design for their own publication, and readers would get a good reading experience.

Apple has to be thinking about something like this, because it makes too much sense not to. Building an application isn’t the solution for publishing on the iPad, because it’s not something everyone can do. Creating a workflow that is largely similar to a publication’s current one is. Working with iBooks Author, or whatever the application becomes, would be an addition to their work—additional work for sure—but it also largely fits what they’re already doing.

If you don’t have an iPhone 4S but want Siri-like functionality, you’ll want to check it out.