For years, many designers have used Photoshop to save images for the web in what is largely considered to be “good enough” compression. There have been new formats that touted better compression but got relatively low adoption in the browser market and were never established as a W3C standard. Who cares, doesn’t everyone have broadband? Google recently implemented webp in the chrome store and saw great results. So although most browsers aren’t up for new formats, we could still serve images more efficiently by using better compression, caching and sprites. One could do batching on the server (jpegmini server, pngquant) but I think it’s up to content creators to make a choice. What do you think? Is it worth the trouble?
Getting a new mobile app into the wild can be challenging, especially when targeting a diverse audience that use many different devices. One common question we answer as a digital agency is whether to build a native app, a mobile app, or both. Unfortunately there’s no magic formula for arriving at this answer, but it’s good to start thinking about user’s needs and how they relate to a mobile rollout strategy.
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% higher1. 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/
“It’s only by looking at the whole, that we can design great experiences. And only by building a community of both system and application developers that care about the whole, that we can make those designs real.” —Mark Shuttleworth
Read the whole article: http://www.markshuttleworth.com/archives/1085
Found an interesting review of three mechanical keyboards from the perspective of a seasoned writer, and how he quickly becomes an enthusiast. More of this can be found if you look for it, but I wanted to share this for any of you who haven’t tried a clicky keyboard. He outlines his discovery and likes/dislikes, and includes one of my favorite keyboards, the AEKII.
More: Shawn Blanc’s Review
Here’s a quick and dirty way to clean particular items from Git history. In our case it was large files that were being scattered throughout capistrano deployments. We symlinked the folder and now treat it as content, and all is well. I read about a project called git-annex that I want to look into further that may be better suited for handling large files.
$: 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
If you find Apple Mail using high CPU because of conversation threading, either turn off “include related messages” or try archiving old messages. You can make a smart mailbox for old mails, then choose export mailbox. Before you archived messages from mail, you should be able to set your account settings so the archived messages stay on the server. Also remember, it’s always good to have a system backup to prevent loss of important data, just in case.
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.
If and only if you have enough memory (>8gb), you can experiment with disabling virtual memory to prevent swap paging. Beware, after doing this, overallocating memory by running too many memory-intensive apps could cause a system halt. You have been warned.
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.dynamic_pager.plist
Have you ever wanted to run the nightly version of Webkit inside Coda? This used to be possible with an app called CodaKit, but it no longer works in OS X 10.7, so I made a quick replacement in automator.
(Bear in mind, this won’t do much if you don’t already have both Coda and Webkit nightly installed.)
On a mac or linux computer, there’s a server-grade firewall that’s not enabled unless you elect to run it. Even the standard application firewall on a mac isn’t very robust in my opinion. So, for those of you who do use the unix ipfw firewall, this is a nice reference:
Although it looks a bit outdated, there are good examples here, and I found it more intuitive to setup as a reductive ruleset rather than the more discombobulated output from rulesets in waterroof (which is a great tool, btw). This method is legible and less error-prone even without a GUI helper.
Alternatively, you can edit the waterroof startup script file directly and then reload it in waterroof to keep them in sync.
Update: IPFW has been deprecated in favor of PF Firewall, which can be managed with IceFloor from hanynet.com.