Highly visible

This has been bugging me ever since Google rolled out its outset text input fields site-wide - the vertical alignment issue.

Someone's container and input heights aren't playing nice.

Headlight Icons on a Car Dashboard

For a company with a reputation for quality and attention to detail, it's surprising to see Honda's oversight of its headlight "on" indicators on the dashboard.  There are three modes for headlights on a Civic - off, daylight lamps on, and headlights on - each with its own distinct icon on the switch, as pictured in the photo.

However, the daylight lamp icon (pair of opposite lights) on the switch is the only one that lights up on the dash in both cases of daylight lamps being on and headlights being on.

The icon for the headlights on the switch has a matching icon on the dash, but that one only lights up when the high beams are on.

So here's the summary, from top to bottom on the switch:

• Off icon on switch: nothing lights on dash (correct).
• Daylight lamps icon on switch: daylight icon lights on dash (correct).
• Headlights on switch: daylight icon lights on dash (incorrect).
• High-beams mode, headlights on switch: daylight and headlight icons light on dash (partially correct).

What should happen is that there should be a dedicated icon for high beams, so that the headlights can reclaim its own icon on the dash.  You could make the counterargument that after the first time, the driver will get used to this behavior, and that it wouldn't be an issue at that point.  But if you can achieve excellency in the design, why not?

Amazon's tiny target areas

Click to confirm shipment. Don't miss!

Single-Line Calculators: Math Through Blinders

Ever since my first time using a TI-82 calculator in middle school, I've despised single-line calculators and the usual limitations that come with them.
The TI-82, TI-83, and many other graphing calculators made by Texas Instruments, Casio, and Hewlett Packard, sported large square screens out of necessity to accommodate the graphing functionality.  As a side benefit, this provided room for arithmetic expressions in a multi-line input.
Multi-line inputs are particularly useful for viewing the history - the last few lines of expressions and values.  With this visual feedback, it was much easier to reference the answer to the last expression, as well as the expressions themselves (seeing the latest assignment of values to variables, reusing parts of the last expression, etc.)  This was much better than a single or dual memory slot under the MEM/recall approach on most typical calculators. And working with single lines (or at most, dual lines on scientific calculators) was like performing computations through blinders.
The graphing calculator was a godsend.

What vexed me was why I could only enjoy this in the tangible world.  Personal computers are even far more powerful computational devices, and yet, bundled calculators on just about every operating system mimicked the feel of the real world (that's fine), but chose the limited calculators as their models (not good).  As a result, they were a pain to use for anything more than a single calculation.
They were workarounds across the years - spreadsheet programs like Excel, full-blown software like MATLAB and Mathematica, online search bar calculators like Google's, offline search bar calculators like Spotlight in Mac OS X - but none of these quite fit the use case.
It had me scrambling for third party calculators, none of which were remotely famous in the mainstream and therefore niches that most people couldn't enjoy.  The Power Calculator from the Windows XP PowerToys was my first good find.  SpeedCrunch was the my first find for other platforms, if you don't count the partially usable paper tape feature for history on Calculator.app in Mac OS X.
But the first one that truly comes close something light and powerful like the TI-8x series was Soulver for Mac OS X.

Like those aforementioned graphing calculators, this provides the multi-line input to display all variables set, expressions written, and answer values resulting.  There are plenty of other useful things it can perform on these beyond the physical limitations of those calculators, ranging from referring to more than one stored answer value (ANS on the TI) with its ability to reference any line, to going into previous lines and editing.
It is well-suited to perform the tasks without the extra weight of larger applications that would be overkill for this situation.
This is how I believe a standard calculator application should be done in personal computing.  We could still strive to implement visual and interactive elements for the real-world analogy, but if they keep in mind the advantages in usability a computer can offer over the physical calculators, we can have the best of both worlds.

Relocating.

I'm moving Bleuprints from Blogger to Tumblr. The Blogger platform is not very appealing to me anymore. Find all of the original archives, and every post after today at bleuprints.tumblr.com or http://bleuprints.monstercyb.org once the DNS changes propagate.

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.