Many times we solve design problems with reciprocating solutions rather than creating new, innovative ways to do things. Irene Pereyra, Global director of UX and strategy at f-i.com suggests, “If you were redesigning the toothbrush, the brief wouldn’t be “Redesign the toothbrush”. It would be, “Redesign the way you clean your mouth”.” In other words, try to redefine the problem as a simpler, profound issue to solve for. Be sure to address the appropriate business goals, user needs, and market positioning. The key is to start with design triggers based on transformational thinking. Now go create!

Aside from critically important factors like user experience and usability, the launch point needs to support the ultimate goal as a business, which is likely centered around conversions. A while back, there was a study that showed Android users converted equally between native and web apps, but iOS users were a different story, with native apps converting as much as 30% higher¹. This of course should not be taken out of context, because each industry and target will have unique characteristics to consider. For a targeting a retail customer, some platforms are more prominent, so choosing a platform may not exclude the target. Also, making an application available to many platforms certainly has it’s advantages, but marketing it outside popular app stores may not bode well without a good launch strategy.

“faster product delivery, more effective products, and bigger yields”

Time is another factor. Generally speaking, native apps have a longer time to develop, and by effect are more expensive to the product owner. In many cases, beginning with an online version of a mobile application can have several efficiencies, because the same system can serve not only mobile devices, but also full websites. If an app needs to be in both places, this may be a first step, followed by a push to the application marketplace. But how many users can be reached? By getting the right message to the right people, the cost of development will be far outweighed by the benefits. There’s merit in taking user feedback from usability tests, focus groups, and multivariant testing. A good way to fine-tune feature priority is through end-user discovery.

So when deciding if your team needs to build a mobile web and/or native app, we borrow a page from Agile product development. Leverage can be made along the evolution of a product or idea as it is developed, and seeing a plan out iteratively also nets better results overall; more effective products, faster product delivery, and bigger yields. Launching your application should never be intended as a monolithic block of effort. So then it comes down to knowing who it is you’re speaking to, and how you can best serve them effectively.

^{1. Mobile commerce, David Eads – http://blog.mobilestrategypartners.com/2011/05/15/mobile-web-is-only-half-of-retail-mobile-commerce/}

Read the whole article: http://www.markshuttleworth.com/archives/1085

More: Shawn Blanc’s Review

$: git filter-branch -d /dev/shm/scratch –index-filter “git rm –cached -f –ignore-unmatch ‘filename.ext‘; –tag-name-filter cat — –all
$: git push –force –all

Working with the Rails 3.2.1 has been a great experience for me, but not everyone shares this sentiment. Here are some interesting insights from Rob Connery about the state of things after the Rails 3 dust settled regarding the asset pipeline. I share this because, in short, I agree and believe upgrade struggles are likely well worth it. Users ultimately benefit, and I appreciate the rails team pushing Rails engineering in this direction.
http://wekeroad.com/2012/01/12/understanding-the-rails-asset-pipeline/

Terminal command:

sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.dynamic_pager.plist

(Bear in mind, this won’t do much if you don’t already have both Coda and Webkit nightly installed. edit: removed download)