DIVID Technology Riffraff & Whatnot

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% 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/}

“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

For early adopters that want to test webkit2 without upgrading OS X 10.7 Lion developer preview, here’s a way to build it from source and run it from the webkit nightly app. Before we continue, a little background on webkit2, from macrumors:

“Starting in Mac OS X Lion, we’ve learned that Apple has started utilizing WebKit2 in their Safari web browser. The advanced version of Apple’s Webkit engine was first announced in April of 2010. WebKit2 is described as a new API layer for WebKit that offers both speed and security improvements:

WebKit2 is a new API layer for WebKit designed from the ground up to support a split process model, where the web content (JavaScript, HTML, layout, etc) lives in a separate process from the application UI. This model is very similar to what Google Chrome offers, with the major difference being that we have built the process split model directly into the framework, allowing other clients of WebKit to use it.

For the end user, the result should be a faster and more stable browsing experience. If a webpage crashes or hangs, only that single tab is affected rather than the whole browser. Subjective reports from early end users have indicated that the new Safari seems to run smoother.”

Before we start, a little disclaimer. This build will not show the new 10.7 UI changes that feature multi-touch and disappearing scrollbars, zoom to text, etc. because those are handled in the application interface and probably rely on frameworks only available in the developer preview version of Lion. As far as I can tell, downloading a nightly binary is the same as building it from source, but this is just for those who want to do it anyway.

1.) Download the standard webkit nightly build as an application. (you can stop here, or go on to build from source and we’ll use this application to run the compiled result)

2.) Run this in terminal, or use an SVN client. “svn checkout http://svn.webkit.org/repository/webkit/trunk WebKit”

3.) Run the “build-webkit” script, which builds webkit2 by default: “./WebKit/Tools/Scripts/build-webkit” —This takes a while

4.) Make an Automator action, choose “run shell script”, paste this code, and save as an application: “

#!/bin/sh
~/webkit2/WebKit/Tools/Scripts/run-webkit-app /Applications/Webkit.app
exit 0

5.) Enjoy the fruits of your compute cycles. You can verify it worked by checking your user agent string at a site like http://whatismyuseragent.dotdoh.com/

Everyone does this, but I’m not seeing MY favorites out there, so here goes. You’ll have to fetch the details yourself, I’m lazy today. Oh ok, if you insist.

Isolator, Nocturne, Quicksilver, Pathfinder, Transmit, Coda, Adium, Fluid, Motion, iStat, Blitz, Times, Bodega, Writeroom, VMware, and Automator is great too, but that’s a given. I also would mention the Webkit backend and all of unix, but that wouldn’t really be considered an app, but I digress. I’m sure I left several out, but these are the suprisingly enjoyable examples to remember.

For some time now, script kiddies have been able to read history from browsers by reading visited links. http://wtikay.com/docs/details.html This is where I found the best background information. http://startpanic.com/ Can tell you if you are affected. So I whipped up a userscript for that, should work in Firefox, Safari, and Chrome.

Download the userscript here: http://userscripts.org/scripts/show/77120

Posted here.

Hack day is in full swing after some interesting API announcements yesterday including “user streams” that allow location related twitter information to be run in realtime. Looks like fun.

Friend got an evo and showed me live 4g streaming on Qik, so I had to try it. This is from an original iPhone on wifi: http://qik.com/video/6959319