Why iOS Is Pulling Ahead in the Enterprise

Apple Insider has a thought provoking piece about how iOS is enjoying much wider adoption in the enterprise market than Apple has traditionally seen with the Mac. Further, where Android numerically gained a lead on Apple in the consumer handset market, a trend that shows every sign being upended now that the iPhone is available on all three major carriers in the US, Android never outpaced iOS among corporate buyers.

The article is a good read, but I'd like to focus on this graph in particular:

Perhaps to most signifigant difference between the two platforms here is that Apple continues to release updates for iOS devices for at least two generations after the device hits the market. The total number of iOS phones and tablets (leaving aside 3G connectivity and storage variations) are roughly four: the iPhone 3G, 4, and 4S along with the iPad 2. The original iPad raises the number to five devices that IT has to actively support, all of which are running the same iOS version.

If you were supporting staff, would you rather have this or any number of Android phones and tablet running any number of versions of Android, knowing that you might be able to update a few and knowing that any custom Android software deployed across the company will have to work in this situation?

Scroll Reverser for Mac - On Demand Scroll Control for Lion

http://www.macupdate.com/app/mac/37872/scroll-reverser

Programming Shows Us Programmers Can't Design Products

TL;DR:

When someone claims that engineers and developers aren't good product designers, no one should understand that better than the engineers and developers themselves. After all, much of the pain we experience in the course of doing our work comes from using tools written by our peers.

Full Post:

I've been fighting off the urge to start a new side-blog called "All Technology Is Terrible" to give me a firewalled space to vent about just how awful things are in the current state of web development. Since "Stark Raving Logic" was inspired by considering how bad most companies are at designing good technology for ordinary users, I didn't want to confuse the space by dropping a ton of programming jokes into the mix.

That said, I think this does dovetail for this blog since what most programmers complain about is essentially a species of user experience. Right now, it doesn't feel like there's One True Language for the web, but rather a Byzantine marketplace ringing with the cacophony of various pidgins, trade tongues, and imperial languages that must be employed in the course of doing business.

Without further ado, I submit the following list of complaints about the tradeoffs that come with some web development technologies I've encountered in the wild:

First we'll consider a couple of the powerful Actual Programming Languages that CS students bump into. Why not use a well-designed language I already know, right?

Java

Rapid prototyping in Java is like sprinting while tied to a water heater because you are literally dragging a half-ton of boiler plate with you wherever you go. Yes, it scales. Yes, it's performant. Yes, you spend as much time wiring things up as you do actually making your application do something. Now Oracle's in charge of the language, which has caused some friction with the FOSS arm of the community in the way that making Ghegis Khan the leader of a peace rally might cause some friction.

C++ 

On the server, it's fast, it's powerful, and debugging it can be like reaching into a running blender because you think you dropped a hair into your smoothie. It's native code running directly in system memory and you can seize the box up with a memory leak. As the old saying goes, C++ won't just let you shoot yourself in the foot, it'll hand you another clip. Most CS grads leave it behind when going into web programming because they can. Like with Java, you tend to mostly see this one crop up with enterprise-level projects for a reason.

What about a couple of other currated, vendor-driven solutions? Why not spend money to save time? That must be the ticket...

C# 

Shamelessly steals some of the best ideas from C++ and Java to build a beautiful language for use on a web application server that will cost your company its entire IT budget to license from Microsoft. I'd love nothing better than for the Mono project to gain some steam, but I'm not betting my career on it.

ColdFusion

CFML and CFScript are the redheaded stepchildren of Adobe, a company that released Dreamweaver with a busted FTP client and left it on the market. The language had no IDE to call it's own until Adobe released a $300 plugin for Eclipse called CFBuilder that lacked real auto-complete or a syntax highlighting that wasn't easily confused. I'm sure they're going to keep doing a bang-up job, so go ahead and cut them a check for thousands and thousands of dollars for the server. If you want a free version, you can check out Railo or Open Blue Dragon and hope your code base is compatible (though Railo does actually look promising if you must).

Ok, well surely there's something new and shiny or old and reliable we could try instead. What about...

Ruby on Rails

I don't have enough experience here to weigh in, but the fact that there's a well known phrase floating around about how you'll be happy if you do things the "Rails way" should let you know that it's built for certain use cases more than others. Nothing wrong with that, but you might want to keep it in mind.

Node.js

is cancer. (Seriously.)

PHP

No debugger, thousands and thousands of keywords, the necessity for using a framework (yours or someone else's) to manage a web app of any significant size, objects (not really, well kinda, hold on)… Where do I sign up? PHP is like a set of server-side options that metastasized into a programming language. Your project will run fine on PHP if you use it for small things, but will need professional help to survive a heavy case of it.

The server looks like one set of tradeoffs after another. At least the native languages on the browser are all established and well-known. Let's see, there's...

HTML, I mean XHTML, hold on… HTML5

If ever there was a cautionary tale against creativity by committee, it should be the HTML5 spec. Some of it feels like semantic markup, some of it like container markup, big chunks are deprecated but still parse, and the exciting bits are unevenly implemented across the squabbling vendors' browsers. For example, HTML5's video and audio tags can parse the MP3 and MP4 files your authoring software export natively! …If you're using Webkit. Unless it's Google's version of Webkit. Mozilla, on the other hand, supports free codecs no one uses. (Urge to kill rising…)

CSS

Separating out the style aspects of the webpage into their own files allows for us to write and manage our content in one place, while using another set of files to style our page into a tangled morass of "Why is this div tag overflowing and breaking my design!?!" It was supposed to make everything simpler, but we ended up with a heavy declarative markup language that allows DOM elements to inherit properties and styles in a way that's not unlike how some children end up inheriting recessive traits that give them clubbed feet or sociopathic personalities. It acts on a set of nodes but is not itself expressed nodally, so there's little visual relationship between an HTML file and the CSS file that just gave it a pronounced stutter. Plus, you can always just tack something on the end of a stylesheet. Which never goes wrong. Ever.

JavaScript

Developed in Hell by murderers sent there for killing joy, JavaScript's feature set reads like a list of everything you generally want to avoid in language design. Global variables by default, unconventional behavior for common keywords, inconsistent references, inconsistent implicit casting between datatypes…

This list goes on and on, but most of the rough spots amount to the language flat-out lying to you. It's designed to be C-like, but only starts to behave itself if you tie your JavaScript into a set of functional knots to enforce a kind of ad-hoc variable scoping. I do believe Douglas Crockford deserves a warm round of applause for rescuing developers with his "Good Parts" approach, but seriously how damning is it that to use this piece-of-%&#$ language you have to reduce it to a subset and stretch it into a weird shape?

Yes, you can get real work done in JavaScript, but only in the same sense that you can use a rock and some screws to hang a sheet rock wall: the tool you're using isn't all that helpful and the results can be suspect.

What further proof do you need that JavaScript is awful than that everyone and their pet monkey is either trying to constrain it into a consistently usable library (jQuery, Dojo, YUI) or are trying to write their client-side dynamic code in better languages (CoffeeScript, GWT, Dart) that compile back down to it? Do people take the hint? Nope. Pride in knowing JavaScript is spreading like Communism across the developer community. As the saying goes, "When you're a hammer, everything looks like a nail"; JavaScript has even established some beachheads on the server side.

I recently attended a talk at Strange Loop where a very nice man who edited the ECMAScript 5 project modestly proposed we consider JavaScript the lingua franca of the web on tablets, phones, devices, and appliances in the coming "Post-PC" world of ambient computing.

I think I just threw up in my mouth.

Robert X. Cringely once quipped that:

If the automobile had followed the same development cycle as the computer, a Rolls-Royce would today cost $100, get a million miles per gallon, and explode once a year, killing everyone inside.

I think it's closer to the truth that if the automobile had followed the computer's public development, we'd have cars that only mechanics knew how to drive.

Engineers and developers aren't good product designers, and no one should understand that better than the engineers and developers themselves. After all, much of the pain we experience in the course of doing our work comes from using tools written by our peers.

Wristband Radio: Thank You, Steve Jobs

(The following is a repost from my other site, Wristband Radio.)

‎Remembering that you are going to die is the best way I know to avoid the trap of thinking you have something to lose. You are already naked. There is no reason not to follow your heart.

— from Steve Jobs' commencement address to Stanford in 2005

When Josh and I started Wristband Radio, we wanted to take advantage of how far the Internet had come in order to create a local radio station that served a local audience. The insight that made this focus so clear for me had come from a moment I had two years before. On the day the iPhone 3G launched, I was taking my new prize home from the Apple Store and had stopped for groceries. On the way in, I downloaded the Pandora app, installed it, and started to listen to it as I walked through the frozen food section.

I stopped short (next to the frozen peas) as I realized what I was doing: I was enjoying a channel that was playing nothing but great Jazz bassists. It was streaming to me not over a wire or even on my home wireless network, but in the frozen food section at the grocery store. I thought, "That's it. Traditional radio is dead. We're just waiting for the body get cold." So when the opportunity to work on Wristband Radio came up, there was no doubt in my mind how to proceed.

If you go to our How to Use page, you'll see that there are apps that allow you to listen to WBR on every major smartphone. But at the top, you'll also see that you don't need any of them to listen to Omaha's great local musicians on an iPhone or an iPad. Apple's consistent support for HTML5 meant that I had a proof of concept for this station working in a single line of markup code. If all I needed to worry about were iPhones, iPads, iPod Touches, and the Safari browser, I could've written and tested our player in less than a day. Most of the work I've done on the technical client-side code has been to detect and support everyone else.

I can't tell you what a thrill it was to hear my station on the same iPhone that had inspired me to realize how the world was changing. During testing, WBR "just worked" right from the browser on every iOS device, from my Dad's original iPhone, to both iPads, to my current gen iPhone 4. When the iPhone 4S ships later this month, I already know that WBR will be ready for users to enjoy.

This kind of direction doesn't form in a vacuum. It came from Apple's commitment to supporting some of the best new web standards. In turn, Apple's vision for the browser came from the man who gave us the iPod: Steve Jobs. Music is in that company's DNA because it was so important to its co-founder and two-time CEO. Jobs dragged the music industry kicking and screaming into the 21st century with the iPod and with iTunes, the first legitimate venue for buying digital music to gain traction both with the labels and with users.

If it hadn't been for Jobs, it would be a different world for musicians and music-lovers. If the the industry had its way, we would still be listening to a handful of artists over the air and buying plastic discs as listeners. As artists, we'd still be scraping at the door for a handful of records deals. As it stands now, WBR artists have many of their albums in the same iTunes and Amazon stores that sell songs by whomever was just splattered all over the cover of Rolling Stone.

The world has changed and we are better for it. We listen to whomever, wherever, whenever.

On behalf of myself, my wonderful business parter Josh, the 150 talented local artists we play, and the listeners who've made this project worthwhile, I want to say from the bottom of my heart, thank you, Steve Jobs. Thank you for everything.

Andrew Neely

Technology Manager, Wristband Radio

Amazon Silk - Questions and Opportunities

TL;DR

In the wake of the Silk announcement that Amazon made as part of their Kindle Fire unveiling, I'm left with a couple of questions and pondering further opportunities this new browser might have. Does it work at all without AWS? Would Amazon consider releasing it for the desktop? We know the privacy implications are worth considering, but what about security?

Full Post:

It seems that Amazon has chosen Webkit as their rendering engine, which is good news for web devs and designers. Unless they've chosen to deprecate features, the support for HTML5 is good in Webkit and fairly advanced. At any rate, it's a known quantity, so if your site is standards compliant, you might consider getting a Kindle Fire for testing but probably won't need one for development. I've seen speculation that we'll want to see if the parallel fetching and cloud-side rendering might break certain kinds of AJAX, but that remains to be seen.

What I'm more curious about is whether or not Silk will work if AWS is down, which has been known to happen now and again. Is it capable of reverting to plain vanilla HTTP requests if the connection to the mothership goes down? If so, is it fast enough to give users an acceptible experience with JavaScript rendering? Flash support has been mentioned but not emphasized. Does a Flash object benefit from the AWS rendering support? We know that Flash is a mixed bag on Android right now, often impacting battery life and device responsiveness. Has Silk solved this issue?

I'm further interested in knowing whether or not Amazon has any plans to release a version of Silk for Windows, Mac, or Android. I'm sure they've at least considered it, given that they have to be aware of the fact that Silk will turn their AWS aggregator into a flesh-driven web scraper. Amazon will have no need for spidering or search algorithms to be held close to the vest as Google does; they just have to let their users do all the work of surfing the web while letting AWS monitor what page they load and what they click on next. Of course, in the short term, Silk will help Amazon move Kindle Fires, but Jeff Bezos has to be aware that making this browser availble to laptops and smartphones would only extend their reach as your new gatekeeper to the Web. Again, Google should be deeply concerned that Amazon's long term ambitions might include usurping them as the go-to search engine.

This leads me to my curiosity about security. Just this past Monday, Oracle's MySQL website was compromised and breifly serving malware to Windows visitors in the form of a JavaScript file that downloaded and ran executables without the visitor's knowledge or permission. Google was made aware and flagged the site in their search results with warnings. But a desktop version of Silk might have taken a different approach. After flagging the site, Silk might have chosen to keep serving the site but simply not include the malicious .JS file in the result passed back to its users. Of course, Oracle would still need to clean their site and fix their vulnerability, but in this scenario, Silk visitors might have simply gone about their day with no need to worry.

Of course, that sword cuts both ways. If they become the de facto gatekeeper for a large number of browsers, Amazon might find themselves under pressure from law enforcement groups, civil lawyers, or dictatorships to simply refuse to serve certain websites. We know that AWS bowed to pressure to refuse to host Wikileaks' website. No one would object to Silk's blocking child porn, but what about a Libiyan protest site? Regardless, this new approach to browsing has many wrinkles to it that I have a feeling we're just starting to consider as potential users. The next four months should be interesting to say the least.

Disintermediation: The Next Trend for Mobile Platforms?

TL;DR:

We're beginning to witness the rise of vertically integrated devices-as-experiences that are consciously trying to keep users engaged with the platform specifically instead of acting like delivery mechanisms for others' web services.

Full Post:

Unless you're living under a rock, you'll have heard by the end of the day that Amazon has indeed delivered its Kindle Fire tablet, widely regarded as the worst kept secret in the technology industry. The $199 price point is going to move a whole hell of a lot of these. Like the Kindle 3, I think it's a safe bet that there will be a healthy market overlap with iPad owners. In other words, if you can afford an iPad, you can probably pick up a Kindle Fire as well.

But why would you? For me, the answer is unquestionably Amazon's Silk browser. As a web dev, for starters, I need to know how my sites and web apps are going to perform. But honestly, I'm curious about Amazon's technical strategy of running all of the device's HTTP requests through AWS will pay off. For a good explanation, check out this video:

Along with the device's price point, this is by far the most interesting curveball of Amazon's whole announcement for several reasons: 1) It means that all traffic will be fetched in parallel by the fat pipe(s) connecting AWS to the Internet, 2) the Kindle Fire's browser is now a thin client for EC2, and 3) it means that Amazon will now know as much about what you do with your new Kindle Fire as your ISP supplying the connectivity to your Wifi network at home.

If the Kindle Fire gets traction, and it will at that (probably subsidized) price point, Amazon will effectively be between you and any third party web services, like those provided by Google and Facebook, for example. This cannot have them pleased, nor can Google be pleased that they've inadvertently furnished the code-base running the device. If its strategy pays off in a couple of years, Amazon will effectively be funneling a small chuck of all internet traffic through AWS.

It also looks like Apple might be starting to move a bit in this disintermediation direction themselves. Dan Frommer is running an article over on Splat-F titled Apple is quietly disintermediating Google in mobile search. In it he describes the new "Assistant" feature rumored to depend on the iPhone 5 that will allow users to make natural language voice search of the web directly from the iPhone's interface. Again the implication for Google is that an army of iPhone 5 users will start to think of search as something they do with their phone rather than with Google on their phone. It's a subtle but important distinction.

Google is still on strong footing in mobile phones thanks to Android's heavy reliance on Google's services, but it currently lacks a good content consumption path for Android users. In the tablet market on the other hand, Android is dead in the water. The Kindle Fire's code-base does Google no good at all without the Android Market Place and the other integration with Google's services. This thing was built from the ground up to literally put you into Amazon's walled garden and keep you there. When other platform vendors see this device succeed, I think we'll see more attempts at good vertically integrated devices that try to keep the users on the platform wherever possible.

Too-Realistic Home Theater Experience

Chuck & Beans

Why, Exactly, Are We Letting Browser Vendors Choose Which Codecs We Use?

TL;DR:

Why on Earth does a browser vendor get to play stupid about something my machine is already setup to do?

Full Post:

I've been thinking about why Chrome's decision to drop native H.264 decoding in favor of Google's own WebM for HTML5 video rendering bothered me so much when it was announced. It didn't hit me until they apparently dropped another feature recently: reliable audio decoding for MP3 streaming in the HTML5 audio tag.

"But This Was Working Last Week"

A few weeks ago I was working on browser playback options for my site Wristband Radio and HTML5 decoding for our MP3 audio stream was working fine in both the Windows and Mac versions of Chrome. A couple of weeks ago my partner, Josh, called me to let me know that our player was broken in Chrome on his Windows box at the office and at home. I double-checked and, sure enough, our HTML5 player wasn't working any more on Chrome.

I changed the JavaScript logic that determines who gets what to load Flash on Chrome again and Chrome's embedded sandboxed copy of Flash was once again in charge of serving our music to those listeners. It was a small fix for a small problem, right? Maybe, but the whole thing left a bad taste in my mouth. This was working just fine a week before and was easier on the user's system to boot.

The Browser Plays Dumb

The reason all of this bothers me so much, is that on every system where these decisions are being made, there is usually already a layer of software that knows how to parse and decode H.264 and MP3. It's gob-smackingly backwards for Chrome to behave less usefully than the audio and video layer of my operating system. Both Windows and Mac OS X are both capable of previewing both H.264 and MP3 files. The average iOS and Android device is capable of decoding both in hardware. Add choices if you must, but don't deprecate them once we expect them.

I do want to be clear that I understand that security is why Chrome seeks to sandbox things running in a browser session away from the OS. I appreciate that and do think it's a step forward. What I don't appreciate is my software getting less useful over time. Nor is it helpful to me as a web publisher to have a feature on my site suddenly break without warning. My users didn't care how or why it broke and I'll bet money they didn't blame the browser. From what I've been able to tell, WebKit, the engine Chrome is based on, includes native support for AAC, MP3, and H.264. If any of this is missing from Chrome, it's been deprecated.

Walled Gardens Also Keep People In

Web publishing is a complicated stew of what's running server-side, what's dynamically running client-side, and how the content being pouring into this mess behaves. We have years of legacy code and outdated approaches further complicating things. The sheer volume of crap that I have to spin up to support a Flash object simply to play sound running on a port on my server looks ridiculous compared to the single line of HTML5 markup that accomplishes the same thing with far less memory and CPU usage.

So right now Safari gets HTML5 audio on our site. "Open" browsers like Firefox and Chrome get a proprietary Flash plugin because it's the simplest way to serve everyone the same MP3 stream. This is exactly backwards. I'm still serving the "closed, proprietary" codec, I'm just invoking a "closed, proprietary" plugin to do it. Chrome even comes with its own copy pre-installed. Ugh.

Chrome and Firefox: If you don't want to "encumber" your browser with an icky standard that every content producer out there can create and every device can decode, then figure out a way to pass it through to the OS and get the hell out of my way. Don't tell me about innovation when my stock OS knows how to read a file your browser forgot how to open. Your intentions may be good but the current state of things is madness.

Apple's 30% "Platform Tax" Is the Company's Largest Gamble Yet

An Android Defector Critiques Android UI