So yeah, Apple wants to remove the headphone port from the iPhone, apparently. Nilay Patel wrote a rant article on The Verge describing how removing the headphone port would be “user-hostile and stupid” (like, it’s in the title of the article). He makes a compelling, if incomplete, case for why it hurts you for Apple to force this change, citing the potential for a return of music DRM, need for additional pricey adapters, major compatibility issues, and the fact that nobody really wants this.

Nilay’s article is written under the argument that it would be “user-hostile” to remove the headphone port. I’m going to define this as acting against the user’s wishes, or being designed without the user in mind. It seems pretty reasonable that a user would not want hardware compatibility issues, DRM-encumbered music, or significantly more expensive headphones. And users already have lots of devices compatible with the 3.5mm headphone port. Therefore, to remove the port in a way that is not user-hostile and stupid, Apple would have to provide more value and benefit than they are taking away, on top of whatever new features they provide.

Following it up, John Gruber writes a rebuttal comparing this transition to Apple’s removal of floppy drives in the late 90s by writing about how this will be a positive for Apple. A rebuttal should address the core argument made, and John’s rebuttal completely fails to do that.

When I released the first version of Ohai a few months ago, it had a simple goal – to have a simple, beautiful place to keep track of memories. As with all first versions, it was limited; you could only capture location-based check ins with a comment and a photo. And as it was released shortly after iOS 7’s announcement, it quickly looked outdated and needed some visual touch-ups. Today I’ve released the first new set of features for Ohai to make it a better and more beautiful journal, with some of the most heavily requested features.

About three years ago, I had a simple idea. I wanted an app to keep track of the places I’ve been. Naturally I’ve tried all the services for this, jumping from Gowalla to Foursquare to Path. But they all want you to broadcast your location, all the time. They’re focused on the experience of letting other people knowing where you are. There’s certainly value in sharing your location, but I wanted something that benefited me first.

I built a prototype of this app a few years ago, but it didn’t go anywhere. The secret sauce behind any check-in app is a database full of points of interest (or POIs, meaning places like businesses, restaurants, tourist attractions, etc.), and mine was no different. I didn’t want to rely on a free API of places that could evaporate at any time. Buying API access to one was prohibitively expensive. And shipping without one meant checking-in became a huge data entry process that was not fun. The project got shelved.

Then, a few months ago, my friends over at App.net announced a new API for finding POIs, and attaching metadata about places to posts and private messages. A few months before, they released an API for, among many other things, creating a private timeline of posts for individual accounts. I saw both a way to get a sustainable POIs database and cloud storage for check-in data.

And thus, Ohai was born.

In the last few years, we’ve seen a pretty significant shift in how we use computers. We’ve gone from primarily using one Internet-enabled device (the PC) to using two (PC + phone) to using three (PC + phone + tablet), and who knows what else we’ll add in the next couple years. Not only are we looking up our data and documents on all these devices, we’re creating data and documents on them, and the time we’re spending to do it on the PC is getting smaller. Effortless and ubiquitous access to data is increasingly important to people.

If your app deals with user’s data, building cloud sync into your app should not be a feature you bolt on to an app – it is the feature. It’s why you will beat competitors or lose hard to them. It’s what will make your app feel effortless, thoughtless, and magical. It’s what will gain a user’s trust, and once you have that, they will sing your app’s praises and never give it up. But to earn that trust, you have to account for sync at every step of the design and engineering of your app.

Developers have a number of choices as to how to build an app around sync. You can use iCloud, you can use a hosted service like Parse, or you can build a custom sync service for your app. Each solution has trade offs. So what should you optimize for?

Smartphones have replaced lots of types of small devices. iOS and Android have made it easy to build apps that perform all kinds of functions, replacing other standalone devices like media players and GPS. It’s been wondered if they would replace handheld gaming devices, and for many people they have. For awhile, I thought they had, at least for my needs. But after trying to play games on touchscreen-only devices for years, I’ve largely felt unenthused about the deeper and more engaging games that would come from big studios. These games required a higher level of precision control that touchscreens just couldn’t deliver.

The PS Vita caught my attention about a month before its launch in the US. It combines a lot of the best features of smartphones with the controls of console games. It has a gorgeous, large, high-resolution touchscreen (and a back panel that is touch-sensitive), as well as a tilt sensor and cameras for augmented reality games. But it also has almost all of the buttons of a typical PS3 controller, including two analog sticks. Sony managed to cram all of this functionality into a device that, while large, is not too big to fit into my pocket, and with long enough battery life for a busy day interspersed with some gaming. The combination of apps and games (which I will describe as just “apps” for the sake of this review) is powerful, and the hardware power and display size make it a compelling device.

Adobe is finally putting an end to Flash Player. They’ve announced they’re stopping development of the mobile Flash Player, which is where the future of tech innovation is heading, and the writing is on the wall for desktop Flash Player as well. This is a good thing for a myriad of reasons, both technical and political.

However, it is important to remember that Flash drove much of the innovation on the web as we know it today. When Flash was conceived over a decade ago, the web was a glimmer of what it is today. Creating something visually impressive and interactive was almost impossible. Flash brought the ability to do animation, sound, video, 3D graphics, and local storage in the browser when nothing else could.

Without Flash, MapQuest would not have been able to provide maps for years before Google did in JavaScript. The juggernaut YouTube would not have been possible until at least 2009, four years after its actual launch. Gaming on the web, which has been around as long as Flash, would only now be possible a decade later. Flash enabled developers to create rich user experiences in a market dominated by slow moving browser developers. Even in 2011 Flash exists to provide those more powerful apps to less tech-savvy people who still use old versions of Internet Explorer.

Flash Player itself seemed like a means to an end. Macromedia, and then Adobe who acquired them, sells the tool that you use to build Flash content. Thus, Adobe’s incentive was not to build a great Flash Player, but a pervasive one that would sell its tools. Its technical stagnation provided a market opportunity for browser developers to fill in the gaps that Flash provided. As a result it has a huge market dominance in tools for building rich apps for the web, tools HTML5 lacks.

This puts Adobe in a unique position. As HTML5 continues to negate the need for Flash Player, Adobe has the tools for implementing Flash within HTML5, and the market eager for those tools. Hopefully this move signals that Adobe will be moving in this direction. Because the web DOES need great HTML5 tools for people who aren’t savvy in JavaScript, especially for the people who used Flash to do it previously.

HTML5 offers developers the ability to build high-performance, low-power apps and experiences. Browser innovation has never been faster; Apple, Google, Microsoft, and Mozilla are all competing to bring the best new features to their browsers in compatible ways. But they’re just now filling in many features Flash Player has had for years. Adobe can harness this to help build a better web, and few others can. Hopefully they seize this moment.

JailbreakMe.com is a website that offers visitors the ability to jailbreak their iPhone without a computer-based tether. It does this by exploiting the system-wide ability for applications to read PDF files, where an incorrectly-formatted PDF file can lead a hacker to do anything they want to your system. While this bug CAN be used maliciously to steal all the personal data from your phone, the developers in this instance used it to enable jailbreaking.

Others will tell you why you should or should not jailbreak your iPhone. Others will decry the developers for bringing to light a serious vulnerability in the iPhone OS. In this blog post, I won’t do any of that, but will instead point out some things you should and shouldn’t do if you decide to jailbreak.

iPhone had the first two store UIs; the iTunes Store for content like music and movies, and the App Store for software. The iPad will add a third, the iBookstore, for buying eBooks. These stores all provide content for users to extend the utility of their device. But each has a pretty different user interaction model for accessing, purchasing, and consuming that content.

• The iTunes Store is a separate app that is completely distinct from the iPod app. When you find something to buy, prompting you for your iTunes account password. It then adds the purchase to the app’s Downloads tab. Once you have purchased the content, you must then switch back to the iPod app to listen to or watch it.
• The App Store is a separate app. When you purchase something, it prompts you for your iTunes password, and then exits to the home screen, switching to the screen where the app will live. The state of the download is reflected in the app icon. When the download is complete, you tap the icon on the home screen to use it
• The iBookstore (the one word is the official name as used by Apple) is not a separate app, but lives within the iBooks app on the iPad. Purchasing content prompts for the iTunes password and downloads in-app, which can be directly accessed after it has finished downloading.

Each type of content follows a different workflow when going from access to purchase to use. If a goal of the iPad’s low price is to drive content sales through the three stores, as some speculate is the case, then the purchase model should be as streamlined for the different types of content. Forcing different workflows will only confuse users who can’t remember which type of content comes from where.

We’ve all got our thoughts on what the Jesus Tablet will be, so here are my guesses. I fully expect to be completely wrong on all of this, as many of these answers are completely blind shots and that Apple will blow my expectations out of the water.

There’s been quite a bit of misunderstanding about what Palm’s new WebOS is, versus what it isn’t. So I’d like to dispel some of the questions surrounding it from the information I’ve been able to find on it. There isn’t much I was able to find (not surprising, as the thing was just announced today), but we can draw some conclusions from the information.

From Web Apps to Widgets

Many people will respond with derision at the fact that applications in WebOS are built with HTML, CSS, and JavaScript; given the state of most web applications today, this isn’t hard to understand. However, the biggest reason web apps are crap compared to their desktop equivalent is that web apps have no integration with the host OS. Which means that web apps have a tough time dealing with multiple OS windows, the clipboard, and offline access.

When Apple released Tiger, they shipped with it the popular Dashboard interface. Inside were miniature applications which were also written with HTML, CSS, and JavaScript. There was a slight difference, however; Apple included the means to integrate the Dashboard with JavaScript. One example is how a Dashboard widget will display its settings via a smooth, GPU-accelerated 3D animation where the 2D widget flips over. This is possible because Apple included JavaScript hooks to perform this animation. But the core tools were just the same – HTML, CSS, and JavaScript.

The Mojo Framework

WebOS applications are much more sophisticated than Dashboard widgets, and certainly more so than regular web applications. This is because WebOS includes a set of tools for creating apps, called the Palm Mojo Application Framework. This, at its highest level, is conceptually similar to Cocoa Touch on the iPhone; it provides common functionality to all applications. It’s what will provide all the common code on the device, from data manipulation of stuff like your calendars to the whizzy animation effects you’ll see throughout the interface. It’s the reason that, in most iPhone apps, the scrolling behavior feels exactly the same.

So, from what I can tell, the Mojo framework is an implementation of all of these ideas, using JavaScript as the programming language, and using HTML5 and CSS for drawing to the screen. Despite there being very little information, they do mention the following features on the developer website:

• apps are installed and run on the device,
• apps are designed to be multitasked and run in the background,
• apps have full access to gestures and the touch screen,
• apps can use a Growl-esque system to display user notifications,
• apps will have access to sqlite databases for data storage (part of HTML5), and
• apps can exchange data via a common messaging mechanism.

The Performance Argument

“But won’t it come down to speed?” Yes, it will. However, WebOS is based on WebKit, and likely is using the latest enhancements from the SquirrelFish project. There is a battle royale going on right now between the developers of WebKit, Firefox, Chrome, and Opera for fastest JavaScript interpreter, which means that JavaScript is only going to get faster and faster.

Why go with JavaScript? It provides a low barrier to entry; nobody really needs an SDK to write apps. It makes it very easy to sandbox apps, as the underlying operating system is still invariably written in some form of C, and JavaScript provides no way to break that barrier. And many other reasons, which I talked about last year before the iPhone SDK came out.

tl;dr: JavaScript is just a language. Palm used that to build a system for making applications. They’re nothing like web apps.