Great overview of current options for recording screencasts on iOS.

◆ Permalink

Potentially Related

• Review of Captio for iPhone

The iPhone and iPad have proven to be very popular gaming devices. The App Store’s overall top 10 regularly lists several games and some of the most successful apps have also been games. But iOS lacks something that could make it even more popular as a gaming platform: an API to support physical controllers like gamepads and joysticks.

Some games just seem like a touch interface is their natural habitat. Board games, Flight Control, Plants vs. Zombies, Angry Birds, Fruit Ninja, time management games and others work incredibly well controlling them with your fingers. Playing them with a controller would feel like playing them by proxy. But whenever I see a game with virtual controllers on the screen, to me that’s a virtual shrug of the developer, effectively saying: “This is the best we could do.” Virtual D-pads or “analog” controller sticks are a crutch at best. I’ve tried playing games that use this type of UI but the lack of physical feedback makes most games all but unplayable for me.

Some examples of where the touch interface falls short:

• A racing game that has virtual gas and brake pedals and wants me to steer the car using the iPad’s accelerometer.
• A flight simulator that uses the accelerometer for controlling the aircraft.
• A first-person shooter that wants me to tap to shoot and move around the environment using virtual sticks on the screen.
• An adventure game that requires me to tap to make the character walk or use gestures to manipulate objects.

Some people wonder why consoles like the PS Vita or Nintendo’s 3DS still exist in a world where multi-functional devices like the iPhone, iPod Touch and iPad are all the rage. But they’re selling well (at least the 3DS is) despite prices for games that by far exceed the average price of an iOS game. I think physical controllers are at least part of the answer.

Third-party solutions like the iCade and the iControlPad are indicative of a need that currently is not being served. These devices are great, but they need game developers to implement a separate API for each one. Apple needs to create a standard controller API that supports devices hooked up via the dock connector, Bluetooth or Wifi. Their platform will greatly benefit as will the quality and selection of games on the App Store.

Potentially Related

• Papa Sangre game submitted to Apple for review
• Virtual City HD for iPad
• Where are the Android killer apps?

MacPorts, a suite of tools to make Unix command line tools available on OS X, relies on Xcode to build the Mac versions of these tools. Since I updated to Xcode 4.3 the port command is showing lots of warnings and errors, failing to build several tools. I did some research into the issue and it seems that the current release version of MacPorts (2.0.3) does indeed not yet support Xcode 4.3. There seem to be some workarounds that involve editing the MacPorts configuration file and creating some symlinks to deal with the fact that Xcode is now installed in /Applications and everything that used to be in /Developer is now inside that Xcode.app application package. Unfortunately, though, none of these workarounds, including issuing sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer/, did anything for me.

My advice would be to either stick with (or downgrade to) Xcode 4.2 if you can, otherwise you’ll just have to wait until MacPorts releases a version that’s compatible with Xcode 4.3. The MacPorts team is aware of the issue and already working on a fix. As of today, though, it’s not clear when that fix will become available.

Potentially Related

• TerminalColours SIMBL plugin under Lion
• Single or Multiple Screens?

I’ve had a love/hate relationship with OmniFocus for the Mac ever since the 1.0. It’s probably one of the most powerful task management / GTD apps available for the Mac, yet it always seemed too bulky and dense for me to really enjoy using it. I checked out Things while creating a dashkards cheat sheet for it and while it felt lighter and more elegant than OmniFocus, the whole GTD concept still felt rather restrictive and burdensome.

A day or two ago, yet again mulling over OmniFocus alternatives, I started thinking about what I actually require from a task management app. I quickly realized that the reason I disliked OmniFocus wasn’t that it lacks anything, in fact the opposite is the case. OmniFocus, Things and another GTD-friendly app I had been checking out, The Hit List, all have one thing in common: They’re simply too much. So I asked myself further why exactly these apps are “too much” for me. After a long afternoon dog walk I had whittled down the list of common task management features to the handful I really need. And now it’s pretty clear why I’ve struggled feeling at home with any of the aforementioned apps.

For me, a task management app needs no more than the following features:

• Hierarchical list of tasks
• Due dates and recurring tasks
• The ability to attach notes and clickable links to tasks

I don’t need different “perspectives” on my tasks, I don’t work from what GTD calls “contexts”, I don’t need to attach files to tasks, I don’t need to sync with iCal or an iOS app, I don’t need a review process and I don’t need the 143 other features full-fledged GTD apps probably offer. No wonder I never felt at home in OmniFocus – I was always trying to work within a system that was doing way too much and all those features were constantly getting in my way (I’ve never found a good use for contexts, for example, yet without them OmniFocus doesn’t really work very well).

TaskPaper

I briefly considered using a barebones text-file-based system, such as Gina Trapani’s todo.txt. But that proved to be too barebones pretty quickly (no notes, no clickable links). Then I remembered that a long, long time ago, I had registered TaskPaper. And after re-familiarizing myself with the app, I knew I had found my new task management app.

TaskPaper files are completely text-based, so you can edit them with any plain-text editor. The file “format” basically consists of some formatting rules, similar to Markdown, which work both in plain text format as well as inside TaskPaper’s user interface:

• End a line with a colon (:) to make that line a project (or header).
• Start a line with a dash (-) to make it a task.
• Do neither of the above to create a note.
• Add as many tags to a task using the @ symbol.

That’s the gist of how TaskPaper works. There are of course some finer details, such as the ability to add parameters to tags (e.g. @due(2012-02-20) or @priority(1)), extensive support for AppleScript (you need a script for recurring tasks), lots of keyboard shortcuts and a powerful search feature. But with just the basics TaskPaper does everything I need in the simplest way possible. It also lets me organize my projects into separate files, whereas OmniFocus and the other apps mentioned above stuff everything into a single database (which you then have to maintain to keep it working smoothly).

I’ve already imported my current projects into TaskPaper files and started working with the new app. So far it feels liberating. TaskPaper combines the simplicity of text files with the power of a good Mac app UI. I have a feeling I’m not going to miss OmniFocus anytime soon.

P.S.: There’s also versions of TaskPaper for the iPhone and the iPad which can sync with the Mac version via Dropbox or a similar service.

Potentially Related

• Learning OmniFocus
• Sciral Consistency
• Getting Back on Focus

Opening a new tab or window in Safari is a pretty straighforward thing and the intention of the user should be pretty clear: to visit a website or to initiate a search. Oddly enough, though, the Mac, iPhone and iPad all behave in subtly different ways when you create a new tab.

Safari’s behaviour on the Mac makes the most sense to me: When you open a new window or tab the address bar receives the focus so you can immediately start typing a URL. If you want to perform a search, just hit the ⇥ key once and you’re in the search field. You could of course also pick a destination from your bookmarks, in which case it doesn’t really matter where the focus is.

On the iPhone, however, creating a new page (Safari’s equivalent of a tab on the iPhone) doesn’t set the focus at all. So if you want to type a URL or perform a search, you have to make an extra tap to focus the approriate text field. It’s just one tap, but an unnecessary one.

Safari’s behaviour on the iPad also forces an unnecessary second tap in many cases: After creating a new tab (here you actually do have real tabs, just like on the Mac), the search field receives focus. I type in URLs way more often than I use the search field, and for search I prefer to use the google.com page directly because I have more control over the search (for example, I can add /ncr to google.com to force Google to let me use the US version instead of redirecting me to the local – German – Google.de). So each time I create a new tab in Safari on the iPad, I have to tap a second time to focus the URL field.

You could surely argue over which behaviour makes the most sense for most users. My preferred behaviour is that of Safari on the Mac: When opening a new tab/window focus the URL field by default. But whatever behaviour is “right”, implement it indentically across all platforms. There are sometimes differences between platforms that constitute different behaviours, but I don’t think that’s the case here. Opening a new tab or window in Safari means the same thing no matter which plaform the user is on. So Safari should behave the same on the Mac and both iOS versions.

Potentially Related

• Location Tracking on the iPhone
• Yojimbo for iPad Review
• iPhone WiFi Sync Drains Battery

Excellent advice for all software developers.

One thing I’ve learned (the hard way) developing software since ca. 1995: If you don’t do what you know is the right way the first time, your “quick fix” will come back to bite you in the ass and it will do so when it’s least convenient.

via Brent Simmons

◆ Permalink

Potentially Related

No related posts.

While migrating a client’s WordPress-based website to a new domain today I noticed a feature that I had left enabled when I first set up the site a while ago: revisions. WordPress by default comes with revisions turned on but you can disable them by adding the line

define('WP_POST_REVISIONS', false);

to the wp-config.php. I usually disable it for my own sites but for this client I decided it was a feature he might find useful. I was fully aware of the fact that WordPress stores revisions alongside the regular posts and pages and that, over time, the table might grow to an unwieldy size and force me to do some database cleanup somewhere down the road. Yet I anticipated the client wouldn’t be publishing too much new content, so it might have been years before this issue surfaced.

Today, though, while doing a mass find-and-replace on the database’s sql dump (changing the local development domain to the live one before I import the database on the live server), I realized that the string I wanted to replace appeared a lot more often than I had thought it would. Looking more closely, I noticed that a fair amount of entries in the posts table containing the string were actually revisions of the original post. Figuring that now was a good time to purge some or all of these revisions, I googled a bit to find out the most elegant way of doing this. Then I find this page in the WordPress Codex. There it says:

Revisions are stored in the posts table. I don’t yet know what kind of impact that will have on post queries. We’re going to turn the switch to “on” on WordPress.com sometime soonish and we’ll have a better idea about what kind of damage, if any, it does.

Seriously? This is how you do things over at WordPress? Not enough that it doesn’t take a genius to figure out that storing revisions in the posts table will lead to table bloat and most likely a decrease in performance over time, your way of “testing” is to implement a new feature on a production site and see what “damage” it does to customer data?

It gets better though. My goal was to find out how to delete revisions and on this topic the Codex has this to say:

Deleting: There is an API function to delete revisions, but there is no UI. That can certainly change.

Revisions were introduced in WordPress 2.6 (we’re at 3.3.1 at the time of this writing) and there’s still no UI to delete them. Awesome.

But I don’t want to make this post just a rant, so here are two plugins that should help you delete revisions:

Delete Revision
Better Delete Revision

Cleverly named plugins, I must say, especially the second one. I haven’t tried either of them yet, but let me just say that it’s not guaranteed that they’ll work correctly on your setup (not even the “Better” one). So be sure to backup your database before you run these plugins.

Potentially Related

• Custom Post Types coming to WordPress 3.1
• A lesson in inventory management for geeks
• WordPress vs. Tumblr

Dave Winer:

If you install even one app on your iPhone or iPad, all your data is compromised.

That’s just not true. An app cannot access data other than its own or what the API exposes. An app cannot, for example, access your notes or browsing history.

◆ Permalink

Potentially Related

• Address Book uploading apparently common practice
• A truly honest privacy policy
• 10-year anniversary of David Pogue’s NY Times column

Ben Brooks on the whole Path/Address Book kerfuffle:

The fact is, that in this instance, Apple broke that trust.

Queue a crying Meg Ryan.

◆ Permalink

Potentially Related

• Address Book uploading apparently common practice
• Address Book tips

I came across this Kickstarter project called the Elevation Dock a while ago. Apparently, it’s currently the most-funded Kickstarter project ever. It’s a dock for the iPhone that solves a problem that pretty much every iPhone dock so far hasn’t been able to solve (I don’t think anyone ever even tried): Getting your iPhone out of the dock with one hand.

Most docks are so light that when you try to pull your iPhone out you lift the dock up in the process. You can then either wiggle and jiggle till the stupid thing (the dock, not the iPhone) falls off or use your second hand to hold on to it while you remove the iPhone (the video for the Kickstarter project illustrates this very nicely). Apple’s own dock is the prime example of this problem, especially the most recent dock. It’s so light there’s absolutely no chance in hell of getting your iPhone out with only one hand (the iPad 2′s dock, while being significantly heaver, has the same problem by the way).

So while the Elevation Dock does indeed solve a real problem, I’m going to pass. Firstly, it’s expensive. $59 + $20 for international shipping is more than I’m willing to pay for what, in the end, is essentially just a dock. I don’t dock my iPhone often enough to justify the expense, even though the undocking process infuriates me every single time.

Secondly, I think the Elevation Dock is ugly. This is just my personal taste, of course, but to me the dock looks comically clunky, despite being made from milled aluminium. I totally get that it probably needs to be as big as it is to perform its primary function of staying put when you undock your iPhone. But that doesn’t make it any more pleasent to the eye.

I clearly seem to be in the minority, though. The project has over 9,000 backers and is just short of $1M in funding at the time of this writing.

◆ Permalink

Potentially Related

• Steve Jobs’ Android rant on Q4 earnings call
• Ben Brooks on the mobile device market
• Getting Back on Focus