Thursday, December 29, 2011

Kindle Fire: Year-End Clearance

I got a Kindle Fire earlier in the month, mainly because it seemed like the best value you could get for an Android-based tablet and it would be useful for some HTML app testing. After a few weeks of playing with it, though, I've decided to return it.

The device itself doesn't inspire a lot of passion. It's just about half an inch too wide and much too heavy to be held comfortably in one hand--at least for me; perhaps Joe Flacco could palm the thing. That discomfort is compounded by the rather angular edges of the device. Now if you're going to want to hold it with two hands and/or prop it up against something, the tiny screen becomes a liability more than a benefit.

The Fire's ecosystem annoyed me right out of the box. To get started I figured I'd try some of the free books. When I tried to download them I got an incomprehensible message. Turns out you absolutely must have a credit card saved to your Amazon account, even for the "purchase" of free books. Then I decided to sample several "free" magazine apps (all Conde Nast ones BTW). Turns out that yes the app itself can be downloaded for zero dollars, but you have to pay for individual issues, get a subscription, or enter a code from an existing print subscription. Oooo-kay.

There wasn't a lot of passionate fire kindled for this device by any member of my family. My daughter took it out of my hand and immediately thought it was much too heavy for its size. My son said he preferred his Kindle Touch for reading books, especially since it's lighter and actually is comfortable to hold in one hand. My wife definitely prefers the iPad.

One of the device's major attractions to me was the Silk Browser. I'm still interested in how (and how well) Silk works, especially in the context of jQuery, but the Kindle Fire is not the kind of device I'd want to use to explore it. For now I'll wait for Amazon to come out with other form factors, hopefully one that is more like an iPad and less like a lump of coal.

Monday, November 28, 2011

This Hover Cruft is Full of Ills

Recently I spent time refactoring much of the event system in jQuery for version 1.7. Since we added some new event methods as well, I took another pass at the event-related documentation. It was an opportunity to rewrite the pages in a way that make more sense (at least, to me) and eliminate things that were important five years ago but not so much today. Just like code, documentation accumulates its own cruft over time. I also find that when things get ugly or inconsistent in the code, they often get ugly or inconsistent in the documentation as well.

Here's an example: In jQuery 1.4.2 we started allowing people to use the "hover" event name for the .live() and .delegate() methods. This is the equivalent of attaching a "mouseenter" and "mouseleave" event to an element. Really. That is all it does. If you said $("button").bind("mouseover mouseleave", myFunc) you can now say $("button").bind("hover", myFunc) and save 16 taps on your keyboard. Many people seem to just love it, and I don't understand why.

jQuery's hover event is not a hover event at all. First of all, unlike any other event, when the actual events occur the event.type is "mouseenter" or "mouseleave", not "hover". Then there is the API confusion, since there is also a .hover() method that can accept two functions (separate functions for each event). Some people expect that somehow the .live() event binding method knows about the powers of this magic hover event and thus it will accept two functions as well. But no. Thank goodness.

Then there is the question of what .trigger("hover") would do. Somehow this peculiar behavior didn't infect triggering, so that will truly trigger a custom event named "hover" and have no effect on the mouseenter-mouseleave "hover" that was bound. Of course, you'll have a mighty hard time binding an event handler to your custom "hover" event anyway. I suppose that for consistency and symmetry it should trigger mouseenter and mouseleave events in quick succession. But that would be silly, right?

More bothersome still is the misappropriation of the term "hover" for both of those cases. When an airplane flies through the airspace directly over my house, it's not "hovering" there. When a helicopter flies to the vicinity of my house and hangs out in mid-air over the roof, now that's hovering. The word "hover" implies that the mouse at least slowed down for a while and spent time over the element. With the current implementation, you'll know only that the mouse happened to touch the element for a fleeting time. You'll see many naive dropdown-menu implementations that use bare mouseenter-mouseleave events and act way too jumpy. Either they drop down as your mouse pointer flies by, or they quickly close if your mouse strays the slightest bit off course.

Brian Cherne's jQuery hoverIntent plugin takes mouse velocity and timing into account and follows that intuitive idea of what hovering really means. If your mouse-tracking needs exceed a simple mouseenter-mouseleave situation, the odds are that you need that plugin. One day I'd love to remove the "hover" hack and the special-case code that goes with it.


Wednesday, October 05, 2011

Steve Jobs

By all accounts, Steve Jobs was the kind of guy who you didn't want to work with. To put it bluntly, he was a perfectionistic pain in the butt, the Boss from Hell for whom good was never good enough. Yet that intensity was driven by a vision that has transformed technology in the past decade.

Many successful businesses make their fortune by carefully calculating how much people can spend and squeezing every bit from them via tricks, gimmicks, and sometimes even outright lies. Advertising and marketing create demand for a product that is often much different than it appears to be. When people find out that the reality doesn't match what they were promised, the outcome is bitterness and anger towards the company that deceived them.

Jobs was different in that he figured out what people really wanted--so often in sync with what he really wanted--and gave it to them. He seemed to figure it out not by focus groups or statistical analysis of consumer trends, but by a gut feeling that was in tune with the public's inner desires. For Apple the product itself, not the advertising, inspired good feelings. Those products are often defined by what they don't have, a Zen simplicity that lets their essential qualities shine through.

Plenty of companies take one idea and ride it for years, making only small tweaks to the formula. Not so with Jobs. He had no problem branching out from Apple's core business of personal computers. First with the iPod, then the iPhone and iPad, Jobs put his company into markets against established players and blew them out of the water. He dived headlong into markets left for dead after multiple attempts by competitors who had nothing to show but a crimson balance sheet. He reminded us that a great product is the best foundation for a great business strategy.

Clearly, Jobs was not the only one responsible for Apple's past decade of incredible success. To his credit, he never claimed he was. In a "60 Minutes" interview, Jobs said, "Great things in business are not done by one person, they are done by a team of people." Yet he provided a successful vision the company could follow, and--to their credit--one they did follow.

Jobs passionately knew what he wanted, and wasn't happy with the people around him delivering anything less. Yet passion by itself isn't a recipe for success, especially when it creates such tension in the organization. Jobs was effective not just because he was passionate, but because the ideas behind his passion were so often proven right. No doubt there were stressful times inside Apple given Steve's style. In the end, however, everyone must be deeply satisfied with the success of the products they created under his leadership.

Running out of Lipstick

Over the past several months, I've spent some time fixing lots of jQuery event bugs related to Internet Explorer 6, 7, and 8 in preparation for the upcoming jQuery 1.7 release. Most of these were jQuery bugs in the sense that we didn't put enough extra lipstick on the pig to make it seem as attractive and standards-compatible as modern browsers. One phenomenon that interested me about these bugs was that they had all been reported in the past 18 months, but had been in jQuery for several years. So if that is the case, why were they just being reported now? I have a theory.

If you were a web developer five years ago, you had to really know the quirks and inconsistencies of the major browsers of the day, primarily Internet Explorer 6/7, Firefox 2/3, and Safari 2/3. Libraries like jQuery were created to help developers deal with those problems, but nearly all developers were well aware of the issues that were being normalized within the library. That usually meant their own battle scars prevented them from going into territories where they'd been burned before, so jQuery's valiant-yet-imperfect attempts to fix IE were good enough in most cases.

Today we're seeing a whole new generation of web developers. They write standard HTML, jQuery, and JavaScript with an expectation that all browsers obey the standards. They're developing complex pages and even full-blown applications using Chrome Developer Tools and Firefox with Firebug, often on their Macbooks. Late in the process they spin up a VM with Windows to test in IE6/7/8 and find that something breaks due to subtle differences in the way those older versions of IE disregard the standards. So they file a bug with jQuery, and we add more lipstick.

As the older IEs become less mainstream yet still important, it's probable that IE-related jQuery bugs will continue to come in as developers discover more ways that their standards-based hopes are dashed. If it's feasible we'll fix them, but that doesn't excuse any web developer from having a basic understanding of the quirks and pitfalls of IE. There will always be things that jQuery can't fix--eventually we're going to run out of lipstick.

The good news is that the rewritten IE event support in jQuery 1.7 closed many bugs and actually reduced the size of that code by nearly half, so the world is paying a much lower price for it. Only time will tell if that code meets the expectations of developers who expect strict standards compliance, even from browsers released in 2001.

Friday, September 09, 2011

Wake from Hibernate

Google knows me better than I know myself. While setting up my Google+ account a few weeks back, Google sorta "found" this old Blogger thing I created more than five years ago. Instead of trying to wipe those old posts off the face of the map, I decided to move back in and post some occasional updates here related to whatever I might feel like saying. Let's see how it goes.