Of Widgets and Apps

One of the primary advantages of Apple's approach to widget engine implementation was that their engine (Dashboard) was based on HTML, CSS, and Javascript, which appeals to a wider spectrum of web developers out there.

Widgets - the idea itself - is nothing new. They were thought up long ago as mini applications with very specific purposes. For example, one such widget might deal with displaying a typical six-day weather forecast. Dashboard's offerings included widgets such as Weather, Stocks, Clock, and Calculator.

A couple years later, when the iPhone debuted, there was apparently news that these same aforementioned widgets' iPhone app counterparts were originally written in a manner similar to the HTML/CSS/Javascript-based Dashboard widgets, but that within the six months between announcement and release, they were redone natively in Objective-C for performance.

But Javascript performance has improved remarkably in the few years since then, with the improvements in Javascript engines from Safari to Chrome to Firefox, and while Apple's stance on native webapps was put aside for the timebeing with the release of the SDK, the webapp idea still lives on in various online and offline forms in Palm webOS apps, Chrome OS apps, and even iPhone MobileSafari's webapps. And it will be interesting to see how further performance improvements increase the viability of the webapp, and by extension, expand development opportunities to a massive number of eager web developers out there.

One Step Backward

It vexes me that some browsers today still assign the "back one page" function to the backspace/delete key. Even in the auto-draft-save era, accidental page backs are still an issue as partially-filled form fields are often out of focus. There are ways to disable it in some browsers, though it's debatable whether such a crucial key should be dual-purpose.

Backspace back-deletes text when form fields in the page are in focus, but goes back a page otherwise. These fields frequently come in and out of focus, which just increases the likelihood of the mishap of losing unsaved form data that much more. (Not every browser remembers unsaved form data when returning forward one page.)

Did someone think it was a good idea to use "backspace" because it reminded them of "back"? Backspace/delete keys suggest something destructive - it doesn't just move the cursor in a text context, but removes characters along its way too. Navigating back one page is not a destructive act. It's navigation, much like moving a cursor with the left arrow key.

All we have now are website-implemented safeguards - your auto-drafts, or perhaps JS detection of the "back" key to prompt the user when forms are on the page. But these aren't solutions because you can't depend on every site to be designed well to begin with.

There has to be a better way.