For our Google I/O 2013 talk, we needed a way to seamlessly showcase live demos on an Android device. Projector switching was clunky, so we pre-recorded the demos for smoother transitions. This post details our process. We used a Blackmagic Intensity Shuttle to capture high-quality HDMI output from a Galaxy Nexus (which thankfully doesn't enforce HDCP on HDMI). This setup, along with the Orientation Control app to maintain portrait mode, allowed us to create polished, in-line video demos. While this solution isn't cheap, the quality and seamless integration were worth the investment.

In this blog post, I share a simple shell script to help you create your own mobile web testing lab for Android. The script uses adb to connect to attached Android devices, sets up port forwarding for Chrome DevTools, and opens the browser on each device. It's a starting point towards my goal of using a Raspberry PI to host adb and all connected devices, simplifying multi-device testing.

I wanted a traffic light system on iwanttouse.com to visually represent feature support. Initially, I used simple CSS classes like .good (green), .ok (amber), and .bad (red), but this required clunky conditional logic to handle the color transitions based on percentage support. Paul Lewis suggested using HSL which allows for smooth transitions between red, amber, and green by adjusting the Hue value (0-359). Now, I can dynamically set the color using element.styles.color = \"hsla(\" + ((percentage / 100) * 90) + \", 50%, 50%)\"; which maps the percentage support to a Hue value between 0 (red) and 90 (green).

AppCache, while crucial for offline web apps, has significant issues. One major problem arises when integrating with APIs like registerProtocolHandler or registerContentHandler, which use query parameters. AppCache caches each unique URI, including query strings, separately. This is fine online, but offline, only previously cached URIs with specific query strings will work. Updating the app cache also causes every unique URL stored in the app cache group to be re-downloaded, even if they're not in the current manifest, potentially leading to server overload. This post highlights these issues and calls for better documentation and patterns for offline app development.

I love Posterous, but it's time for my blog to move on. I'm looking to hire someone to migrate my blog to a new platform. Must-haves include: static site generation, git integration, markdown/text/HTML support, preserving my current URLs and all imported posts, and full template control. Ideally, it won't be Ruby-based. I'm not concerned about hosted solutions, a fancy CMS, or comments.

Apple has a clever naming strategy with "The New iPad." Customers naturally ask for the "new" version of products, avoiding confusion and instantly clarifying which model they want. This approach bypasses complex product names and generations. I predict Apple will continue this with other products like the iPhone, simplifying their branding and customer experience.

LocalStorage is a flawed API with poor querying, performance issues, limited storage, inconsistent event handling, and locking problems. Its only advantages are its simple semantics and browser support. Continued use of LocalStorage hinders the development of robust offline and client-side web apps. We should transition to IndexedDB, a superior alternative. I've demonstrated this by converting the BackboneJS TodoMVC example from LocalStorage to IndexedDB using Julien Genestoux's adapter. This involved a few configuration changes, highlighting the ease of adopting IndexedDB, which is our only viable path forward for client-side storage. Let's abandon LocalStorage and embrace IndexedDB to unlock the potential of offline web apps.

I'm excited about Mozilla's consideration of implementing webkit prefixes and starting a conversation around this. I believe that switching prefixes should only happen if the vendor is willing to drop their existing prefix in favor of another for the sake of standardization. Developers often target specific prefixes based on the dominant browser for their target audience (like WebKit for mobile). While I appreciate Remy Sharp's take, I disagree with his proposed solutions. I think prefixes should be dropped only when committing to another, and that the "production ready browser" idea is unrealistic. We should focus on educating developers on tools for handling prefixes.

Chrome Dev and Canary (18+) now support Web Intents! Currently, intent registration is done via the Chrome apps manifest (not the intent tag) to allow the user agent to determine available services (including those on the local network or external native apps). The manifest entry specifies the supported action, data types, title, and path. Client-side code remains the same. Future support for declaring capabilities directly through HTML with the Intent tag is planned.

It's been an incredible two years at Google! The first year was amazing, but the second year was even better. I spoke at Google IO, traveled to numerous countries giving presentations, and saw Web Intents become a real project. I even got misquoted on TechCrunch! I also spent more time in Liverpool and worked with developers throughout the UK. I'm excited about the future and continuing to improve the user experience on the web.