Bleuprints

iBART: Actions vs. Options

Mon, 24 Jan 2011 02:00:00 -0800

The iBART iOS app is a great example of the do’s and don’ts of creating the look and text copy for your actions and options. What we have here is effectively a web form with select inputs, where the options are displayed on a second page. ”Show Trips” is effectively a button or an input of type submit. But as you can see from figure one, that distinction is not made very clear.

Figure 1: Before:

Figure 2: After:

The screenshot in figure one doesn’t quite capture the confusion, but “arriving: 8:00am” by default reads, “Departing Now”, which somewhat sounds like a call-to-action similar to “Show Trips” directly below. It doesn’t help that “Show Trips” is written in plural, misleadingly suggesting that it was another option instead of the button to see the final result of the singular trip you’ve just configured above.

The “Plan Trip” button equivalent in figure two solves that issue by first fixing the text copy, and by also providing the affordance of a clickable button with a call-to-action, in contrast to the row item that blended in as another row below “Departing Now”.

But instead of learning from the solution to their mistake, they’ve turned the crosshair and cycle icon buttons in the first figure (which looked deceptively like icons instead of buttons), and made them even less obvious as buttons.

The arrow “location” icon and cycle “swap” icon are juxtaposed with the identically flat arrow in the row below, making them appear as icons only serving to make each row more uniquely identifiable. Users arriving to this screen for the first time would have to accidentally discover that there were options when these icons were tapped. They share the same look as the icon-only indicators to the far left such that they provide no affordances of being buttons on the far right.

But to top it off, those empty and filled dots on the left being chosen to represent “from” and “to” is very unintuitive, as there is no association across these sets.

iBART is a great application for those using the BART system in the San Francisco Bay Area, so I hope they learn to get their most important page in their app done in a sensible way.

Tweetie vs. Twitter for Mac: A UI Oversight

Sat, 08 Jan 2011 17:02:00 -0800

A couple days ago, Twitter released the long-awaited update to Tweetie, the Twitter client for Mac OS X later acquired by Twitter. Tweetie 2, rebranded as Twitter for Mac, fixed some outstanding issues like the inability to delete tweets or mark tweets as favorites. But there were also numerous changes to the interface, beyond the more obvious visual differences, and this is where I started seeing the most problems.

There are some issues that carried over from the first version, such as the disabled zoom button beside the minimize and exit window buttons. There’s no excuse for why that has to be disabled - a Twitter feed isn’t a use case that can’t be resized to fit to the content, especially in the vertical direction.

Crouching Cursor, Hidden Taskbar

Among the newly introduced issues is the reply button. In Tweetie 1, every tweet had a permanently visible reply button on the top right. Without keyboard shortcuts, replying was just one click away.

In Twitter for Mac, the reply button has been moved to a toolbar hidden behind a hover state. In other words, the reply button is hidden for all tweets, meaning that in order to reply, you have to:

Hover over to the reply/favorite/retweet region to unhide it.
Shift your mouse cursor to readjust its position over the reply button’s target area, instead of the other target areas within the hidden toolbar region.
And then click the reply button.

Now you might argue that this is technically the same number of steps if you target the cursor over the reply button’s region every time. But don’t discount the significance of the half-second time delay of pausing and shifting your cursor over some more. On top of that, the reply button is on the far left side of the hidden toolbar, meaning that its exact hidden position is actually less predictable than if it were on the far right of the toolbar. Then at least in that situation, you could throw your mouse cursor to the right and guess the hidden target area for the reply button more accurately.

Every millisecond counts, especially with a task as frequent as replying.

An Indicator Well Missed

Let’s talk about the reverse situation - when someone sends a reply to you instead. In Tweetie 1, new messages were indicated with a blue circular dot by the Twitter user in the left sidebar (under the avatar in collapsed mode, or under the specific timeline/reply/message section in expanded mode).

In Twitter for Mac, this indicator has been replaced with a glossy bluish white light orb, partially tucked under the timeline to the right. It has taken on an oval shape, and while its diameter is roughly the same as the original’s dot indicator, the core is actually smaller than the original, and is surrounded by a dark blue halo that is more difficult to see.

This makes the new indicator much more subtle than the original, and while I’m generally a proponent of going for subtlety, this implementation was too subtle for the purpose it serves.

If I were in charge of the visuals at the time, I would have seen the new orb indicator in the isolated sidebar and also decided it was the right mix to be noticeable enough out of the corner of the eye without being distracting in its presence.

But that’s why I suspect that the designers who worked on this didn’t work with this indicator in the context of the full application. Take a look at the indicators in Tweetie 1 and 2 again with the timeline and its content beside it. Stare and focus on the timeline only, as though you were reading the tweets. In your peripheral vision, the circular blue dot in Tweetie 1 remains noticeable. In Twitter for Mac, the oval orb blends in too much and become easy to miss.

In a real-world situation, it will become even easier to miss because it won’t be in the front of your mind to look for it.

Bits and Pieces

There are plenty of other oversights all over the place that I won’t talk about in detail here, but they include issues such as not having any indicator that something has been successfully retweeted. This is in contrast to the Twitter website, which addresses the problem the same way marking a favorite is handled - creating a dog eared page corner with the reweet or favorite icon peeking from underneath the flap.

Or perhaps you want to launch the “compose tweet” window, and you liked having a dedicated button for it in Tweetie 1. In Twitter for Mac, it’s hidden under a menu at the bottom of the sidebar, making one of the most frequent tasks two clicks away instead of one. I would surmise that they did this to include a second option for “compose direct message”, which lacked its own one-click button before. But given that the other tasks in this menu (go to user, mark as read, preferences) aren’t high frequency tasks, it makes more sense to revert back to buttons for composing both kinds of messages.

I’ll give them the benefit of the doubt that perhaps this was rushed out the door to meet the Mac App Store opening date. I just hope they’ve thought about any of these issues at all.

Single-Step Dialing on the iPhone OS

Wed, 30 Jun 2010 22:44:06 -0700

On the iPhone OS, contacts grouped into the “Favorites” section of the phone application can be dialed with a single touch to the listed name, but for all other contacts in the “All Contacts” section, this is a two-step process. The first tap on the name instead opens the details page for that contact, and the desired phone number in that contact’s details page must then be selected by a second tap.

Out of habit, I find that I sometimes tap a name in the two-step “All Contacts” section, and hold it to my ear immediately, only to discover that the phone isn’t dialing. (I then have to lower the phone to glance at the screen, select the phone number, and raise the phone back to my ear.)

What should happen is that if this contact has only one associated phone number, the iPhone should automatically dial that number once the phone is held to your ear, using its accelerometer and ambient sensors. That way, selecting a name and bringing the phone to your ear results in the same device reaction regardless of from which of these two sections the dial originated (again, for single-number contacts only).

In the iTunes Store, you have the ability to redownload an app...

Thu, 24 Jun 2010 16:23:00 -0700

Current iTunes Store "Buy" Owned App

Proposed iTunes Store "Redownload" App

In the iTunes Store, you have the ability to redownload an app you already purchased, which is useful if you’ve lost the backup copies on all your devices. But it’s not immediately obvious to everyone, including yours truly, and people have to discover this by trial and error or by online resources.

Apple’s official docs on this issue are also ambiguous though, as a user trying to download an owned app will encounter the message, “Are you sure you want to buy and download [app name]? Your account will be debited for this purchase and your application will begin to download immediately.” Only after the user clicks “Buy” does a reassuring second message appear acknowledging a prior purchase - “You have already purchased this item. To download it again for free, select OK”.

This second message should have been the first and only message upon attempting the redownload. After all, the user is logged in with that account if this stage of the process is reached, so this can easily be determined.

A clearer approach would be to remove the price from the text copy of the button ($0.99 BUY) since the user will not be charged that price when clicking that button, as well as to remove the “buy” text because most people will interpret that word to mean an exchange of money unless $0.00 is explicitly written alongside it.

But writing ($0.00 BUY) is also misleading because the retail price of that item is not free. So an improvement would be something like my proposal in figure 2 (second image above), with the text (REDOWNLOAD). It could even be ($0.00 REDOWNLOAD) or (FREE REDOWNLOAD) to make it absolutely clear.

Tapping the buy button again in Mobile iTunes on iOS devices, on the other hand, is much clearer, as it first prompts the second of the two earlier messages. It still suffers the issue of saying “buy” though.

The best implemented example is the “Update” button for a previously purchased app. Updates are free for owned apps, so it gets to avoid the buying concept altogether and throws the message, “This update is free because you own a previous version of this item. To get this update now, select OK”.

These issues need to be fixed, and probably exist as a relic of the pre-app days of the iTunes Store, when users were not allowed to redownload music or other media. It’s your move, iTunes team.

When I first saw the picks and results board for Yahoo! Sports...

Thu, 24 Jun 2010 11:14:24 -0700

Current Y! Sports Fantasy World Cup

Proposed Y! Sports Fantasy World Cup

When I first saw the picks and results board for Yahoo! Sports Fantasy World Cup 2010, it took me a second to distinguish between an incorrect pick and the actual outcome between any given two countries. There was something counterintuitive about their choice of icons and color coding for each row’s status - it was using green checkmarks for wins, but gray checkmarks for selections, including incorrect ones. And it was using red X’s to mark the winner of the actual game outcome.

This meant that if you picked Italy to win against Slovakia (where Slovakia won), it would show you a gray checkmark on Italy to indicate that you picked it, which you might mistake as a winning result based on the similar green checkmark and background for actual winners. In this case, the actual winner is marked by a red X and background, which you might mistake as an incorrect pick, rather than a correct result. Seeing that the red X and background of the score prediction in the right columns actually do indicate an incorrect pick rather than result, this inconsistency only adds to the confusion. (See the first screenshot.)

What I’d propose (in the second screenshot) is a modification that clearly distinguishes all actual outcomes the same way, say, with a bounding border with a soccer ball (not a trophy, as only one ultimate team gets a trophy). The green checks and red X’s would then be reserved for what people associate with them - correct or incorrect - in this case, the correctness of your pick. After all, it doesn’t make sense to call a country’s actual win “incorrect”, so it’s best that the green/red system doesn’t correspond with actual results at all.

This has been bugging me ever since Google rolled out its outset...

Wed, 16 Jun 2010 10:55:04 -0700

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.

For a company with a reputation for quality and attention to...

Sun, 23 May 2010 10:33:00 -0700

Headlights On Indicator on Dashboard

Headlight Switch

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?

Demo: http://monstercyb.org/gordon/showandtell/collegeruled 2010...

Thu, 20 May 2010 09:07:30 -0700

Demo: http://monstercyb.org/gordon/showandtell/collegeruled

2010 May 12. College-ruled paper web form with infinitely expandable textarea and page.

Tested as working in: Safari, Chrome, Firefox, Camino, Opera, IE 8/7/6

Source: http://github.com/gordo/collegeruled

Demo: http://monstercyb.org/gordon/showandtell/flash 2010 April...

Thu, 20 May 2010 00:25:00 -0700

Demo: http://monstercyb.org/gordon/showandtell/flash

2010 April 30. The no-Flash-plugin-available blue Lego brick recreated using the canvas tag from HTML5.

Tested as working in: Safari, Chrome, Firefox, Opera 10.5+

Working except for lack of fillText support: Camino, Opera before 10.5, MobileSafari

Canvas not supported in: IE8/7/6

Source: http://github.com/gordo/flashgordon

Demo: http://monstercyb.org/gordon/showandtell/beachball 2010...

Thu, 20 May 2010 00:16:00 -0700

Demo: http://monstercyb.org/gordon/showandtell/beachball

2010 April 21. Beachballing. 2D transforms to create the spinning beachball cursor from Mac OS X.

Tested as working in: Firefox, Chrome, Safari, Opera 10.5+, MobileSafari. Should also work everywhere else once those browsers support 2d transforms.

Still image taken from Flash-based MarbleOfDoom.com, and Photoshopped to recreate the spiral stripes as a new layer while removing the original stripes.

Source: http://github.com/gordo/beachballing

Demo: http://monstercyb.org/gordon/showandtell/panzoom 2010...

Thu, 20 May 2010 00:01:00 -0700

Demo: http://monstercyb.org/gordon/showandtell/panzoom

2010 April 7. Ken Burns Effect with CSS3 (with WebKit keyframes for animation). Gecko, Presto, and Trident effectively have no equivalents, so it will not work in those browsers. This was a proof of concept.

Javascript was used to change images with alternating animations.

CSS3 animations are a part of the W3C spec, but were still in working draft at the time of this project. Much of the CSS is the same, sans the vendor prefix. (http://w3.org/TR/css3-animations)

Source: http://github.com/gordo/panzoom

Demo: http://monstercyb.org/gordon/showandtell/lost 2010 March...

Wed, 19 May 2010 23:49:00 -0700

Demo: http://monstercyb.org/gordon/showandtell/lost

2010 March 19: Recreating the LOST opening scene using WebKit CSS transforms and animations.

This was my first experiment with WebKit CSS animation. Other browsers like Gecko-based (Firefox, Camino) and Presto-based (Opera) support some degree of the transforms, scale, and skews that I tweak here, but as of writing this, only WebKit-based browsers support the keyframes necessary for me to animate this without using Javascript. To maintain the proof of concept, I opted out of a JS workaround for the other browsers, so this will only work in WebKit.

Tested as plays nice: Safari, Chrome, MobileSafari, Android browser (except this browser doesn’t support audio as of OS 2.1), webOS browser, and any other recent WebKit-based browser supporting keyframes.

Source: http://github.com/gordo/lostwebkit

Click to confirm shipment. Don’t miss!

Sun, 16 May 2010 20:50:22 -0700

Click to confirm shipment. Don’t miss!

http://monstercyb.org/gordon/showandtell/aero/ Aero from Windows...

Thu, 18 Mar 2010 09:34:00 -0700

http://monstercyb.org/gordon/showandtell/aero/

Aero from Windows Vista and 7 using CSS 3 only for visuals (buttons, windows, menus) (and to be nice to IE, filters for them). Javascript is added in for click interactivity that CSS cannot provide, such as triggering a select all or posting date-timestamps.

Progressively enhances as you use Webkit-based (Safari, Chrome) and recent Gecko-based (Firefox) browsers. Looks a tad plainer on browsers without as much CSS support, like Camino, Opera, and Internet Explorer.

Single-Line Calculators: Math Through Blinders

Sat, 13 Mar 2010 00:00:23 -0800

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.

Of Widgets and Apps

Sat, 27 Feb 2010 01:42:00 -0800

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

Sun, 14 Feb 2010 03:24:00 -0800

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.

Managed vs Unmanaged Libraries

Wed, 13 Jan 2010 14:00:00 -0800

In the olden days, our music libraries were primarily unmanaged. It was essentially the only option. If you wanted to listen to a song, you had “Eagle Eye Cherry - Save Tonight.mp3” or “01 - save tonight - eagle eye cherry - [desireless].wav” or something along those lines. You interacted with the file within the file explorer, such as Windows Explorer, and kept track largely by file name. Some people used meta data in one form or another, such as MP3 ID3 tags, but just as many of us ignored or actively removed those tags to force it to organize by carefully renamed filenames. Even more people just took the files as is, creating messes like “~ALLSTAR1.mp3” or alike.

Programs like Winamp, Windows Media Player, and RealPlayer provided the features necessary to organize libraries heavily on metadata, but they generally didn’t create much of an abstraction layer between the file system and the music library. Your audio files were linked, and its tags read, but the files were otherwise left alone where they were.

The Music Library: iTunes and Winamp

iTunes took a different default approach, and it made it a polarizing music library application. Unless settings were set otherwise, it organized your files for you by creating folders for each artists under a single parent directory, and sorting each song within appropriate nested folders named by album name. The song files themselves were renamed by track number, a comma separator, and the song name.

So on Windows, you might get:
C:\Documents and Settings\Gordon\My Documents\My Music\iTunes Library\Eagle Eye Cherry\Desireless\01 - Save Tonight.mp3

People either hated it or loved it.

This was managed music.

When the Windows port of iTunes came out in 2003, I began using it in parallel with Winamp, my incumbent music player of choice at the time. It was light, simple, and unmanaged. I had also stripped my entire library of all ID2/ID3 tags over the years, so it wasn’t optimized for iTunes.

I was a hater of managed music.

I wanted to organize these files myself. I had my own folder structure and naming conventions. Yet over time, I grew to like iTunes managing my music for me. With every new file, I could drag it into the library, and it would take care of the rest (making a copy, renaming the file based on the metadata, and creating appropriate folders). Then I could delete that original copy or what ever I wanted.

The thing was that, as much fun as it may be to have full control and say over how to manage your own music, it just wasn’t scalable to me past a thousand songs, much less several thousand. If the computer is so much better at automation than a human, I figured we should be offloading this tedious work to these machines.

The Photo Library: iPhoto and Picasa

If iTunes is to managed as Winamp is to unmanaged, then iPhoto and Picasa are the respective analogies for the photo library.

Like iTunes, iPhoto by default created copies of any photo you dragged into the application, but also like iTunes, you had the option of disabling copying to the photo library.

With the latter, iPhoto would simply link to wherever that file sat, and wouldn’t make a renamed copy. With the former, it would place a copy in a bundle “iPhoto Library” in the user Pictures directory, like this:

/Users/gordon/Pictures/iPhoto Library/Originals/2007/October 22, 2007/IMG_0001.jpg

This is nearly identical to iTunes behavior, with the one distinction that iTunes still involves folders that can be navigated through via UI the traditional way, instead of bundles that require “Show Package Contents” or a terminal.

/Users/gordon/Music/iTunes/iTunes Music/Coldplay/Viva La Vida - Prospekt’s March Edition/1-07 Viva La Vida.mp3

Picasa, on the other hand, offers iPhoto’s link-to-file option as the only offering, but differs beyond that for monitoring those watched locations for changes to the files (renamed, deleted, etc.).

As a Picasa user, I haven’t embraced iPhoto in the same way that I had with iTunes. I tried to determine why that might be, considering that I have a much more overwhelming number of photos than audio files to manage. It could be that the metadata in music files played a much bigger role in determining how to organize them. Many of us were already manually organizing by artist or album, perfect for metadata. Sorting and filtering by genre, beats per minute, length, and other attributes were perks, but the point was that a lot of us were already manually managing the same way auto-managing worked.

Whereas with photos, my guess would be that there is more fragmentation in the way these files are organized from person to person. Some might group by events (Graduation 2003, Italy 2002, Birthday 2008). Some might group by year, or month, or months nested within years. Or some might group by year, with the photos within each grouped by events. Some might not group at all.

iPhoto does allow you to create smart playlists a la iTunes based on criteria, so that you can do anything from creating playlist/labels filtering out all photos taken with a specific type of camera, or more usual things like grouping by year.

But these are folders. These are like, again, smart playlists in iTunes or IMAP labels in Gmail. And this may not work for everyone.

Ultimately though, I would venture to conclude that perhaps not as many people see a need for managed photo libraries, as useful as it is, because photos are much more visual by nature, and can be spotted in a grid of thumbnails. In time, with the ongoing release of new tools like facial recognition and geotagging maps, perhaps managed photo libraries will be compelling enough for more of us to alter our ways.

Keyboard-based File Renaming

Tue, 05 Jan 2010 04:54:00 -0800

There are subtle differences in how a file navigator handles keyboard-based file manipulation that are easy to overlook. They appear minor or trivial at a glance, but can be detrimental to usability with the sum of all nuisances, or with batch file manipulation tasks by hand.

There is a lot to focus on, so I will keep this one about file renaming.

Renaming in the Early Days

Back in the days up until and including Windows XP, if a user renamed a file (F2 by keyboard shortcut, or by “Rename” via right-click contextual menu), it would highlight the entire file name and its file extension. (This is, of course, unless known file extensions were hidden.)

This was a problem for a couple reasons. If you didn’t know what a file extension was, you would likely accidentally rename a file extension. If you did, it was an extra three or four keyboard strokes for each file to place the cursor to the end of the actual file name. It doesn’t sound like much, but you pride yourself on using keyboard shortcuts for the purpose of being fast.

Mom and Dad skiing.jpg

Fortunately, some years back, I noticed on Debian and Mac OS X that triggering a file rename highlights the file name only, with the option to move the cursor to the right into the file extension area.

Mom and Dad skiing.jpg

It was a huge improvement, but considering that most of the world was on Windows, it was important that this make it over to the Windows side.

Renaming Today: Cursor Placement

Starting with Windows Vista, this behavior was available in Windows Explorer. The only issue is that if you rename (F2 or by mouse) to highlight the file name only, and realize you want to append or delete characters from the end of the file name, you hit the right-arrow instinctively. That should place the cursor at the end of the name and before the dot of the file extension, right? This is the case in Linux and OS X, but not so in Vista or 7.

Before:
Mom and Dad skiing.jpg

After (Linux, OS X): Right-arrow places cursor before the dot:
Mom and Dad skiing|.jpg

After (Windows Vista, 7): Right-arrow places cursor after the dot:
Mom and Dad skiing.|jpg

What are the implications in this difference in behavior? Let’s compare this to the way you would normally rename a file with the file extension hidden.

Before:
Mom and Dad skiing

After (All OS’s): Right-arrow places cursor at the end of the file name:
Mom and Dad skiing|
Mom and Dad skiin|
Mom and Dad skii|

Without file extensions, the keys are F2, arrow-right, and then delete or append right away, in the case of Windows. So if we apply this with the incorrect behavior of placing the cursor right of the dot, we get this.

Before:
Mom and Dad skiing.jpg

After (All OS’s): Right-arrow places cursor at the end of the file name:
Mom and Dad skiing.|jpg
Mom and Dad skiing|jpg
Mom and Dad skiin|jpg
Mom and Dad skii|jpg

Screenshots after the break (note the text cursor placement):

Renaming Today: Cursor Jumps

What if I want to jump the text cursor to the beginning of the name? In OS X, hitting the “up” and “down” keys moves the cursor to the start and end of the file name, respectively. In Windows, it simply doesn’t register at all, so there’s some further improvement that could be made there.

DOWN ARROW ↓: Mom and Dad skiing|
UP ARROW ↑: |Mom and Dad skiing

Renaming Today: Shift-Selection

If there’s anything everyone seems to have implemented, it’s holding the “shift” key as you add or subtract characters from a selection of text.

Mom and Dad ski|ing.jpg

Batch Renaming

Unless you know what regular expressions are, batch renaming options leave a bit to be desired. On the one hand, you have nothing really built into OS X in Finder, and leaves this work to AppleScript in the form of a handful of pre-written automator scripts. On the other hand, Windows does provide a basic sequential batch renaming solution by appending numbers in parenthesis to an otherwise identical base name. This was available since Windows XP.

Ski trip.jpg
Ski trip (1).jpg
Ski trip (2).jpg
Ski trip (3).jpg

Otherwise, not much interesting is going on in the built-in UI file navigators.

Improvement and Progress

But OS parity aside, honestly, there have been some interesting solutions in third party file renamers such as batch renamer utilities. It pains me that there have been so few improvements implemented into the UI side for this tedious task. It could be something a little more inventive like predictive text entry or something as simple as the live spell check that exists everywhere else. It’s all in the details, folks.

Of Physical and Virtual Mobile Keyboards

Mon, 14 Dec 2009 20:48:00 -0800

Nearly three years ago, I watched as Steve Jobs presented a slide of images of existing smartphone physical keyboards, from the Blackberry to the Treo, and then reasoned afterwards that a touch keyboard held the advantage of being adaptable to any situation. This reduces clutter, saves space, and allows for a larger screen without the need to add physical bulk (even if it’s just millimeters) required to produce a slide-out keyboard.

Yet, a few years onward, there are people who still insist that a hardware keyboard is an advantage to a soft keyboard like the touch keyboard.

Tiny Plastic QWERTY buttons

I’m no stranger to the tiny plastic buttons comprising the QWERTY keyboards on phones. I expressed real interest in a Blackberry or Treo in 2005, and I composed emails on my father’s Blackberry Curve throughout 2008, one of them being 476 words / 1941 characters long without spaces. These keys hurt my thumbs during any extended typing, and this is speaking as someone with relatively slender fingers compared to the average person.

The iPhone keyboard, on the other hand, has never given my fingers any pain or strain, even with extended typing sessions. I don’t have to press down hard on each little plastic button far smaller than size of a thumb or fingertip. Now, how hard you have to press down on a key varies from physical keyboard to physical keyboard on a phone, but in order to maintain slim form factors, they typically won’t be anywhere near as easy to press as a keyboard on the desktop (where physical keyboards do make absolute sense).

Large Touch Key Sizes and Dynamically Resizing Landing Areas for Keys

Besides, the area for a touch key for an iPhone, at least, is larger to begin with. And beyond that, apparently the iPhone’s touch keyboard guesses what the next likely characters are, and enlarges the invisible touchable area beneath the visible key to give the user a more forgiving margin of error for that key. For example, if I’m typing “G”, the letter “I” will have a slightly larger tappable area because it is statistically likely to follow, whereas the letter “Q” will not.

Auto-Correction

In fact, the guesswork itself of the next probable character is nothing new, and has existed in the form of predictive text (such as T9). I could press 7(pqrs) 3(def) 2(abc) 3(def) to get “r-e-a-d” instead of pressing 777(prRs) 33(dEf) 2(Abc) 3(Def) with the delays between each numeric pad key. This was a form of auto-correction, which also wasn’t new when the iPhone came onto the scene, but it’s easy for people to forget the important role auto-correction plays when it comes to touch keyboards. This isn’t your typical shopping mall kiosk where the touch keyboard is just a literal software port of the physical keyboard.

It saves you time by automating capitalization, word completion, and punctuation. This all factors in when talking about the speed aspect of the keyboard.

Insertion Points, Selection, and Cut/Copy/Paste

But it doesn’t end there. If a user wants to insert a text cursor in a random location of a long line or paragraph, and select and cut/copy and paste a portion of the content, the touch-based selection holds a huge margin in ease and speed versus a D-pad or trackball. On a Blackberry Curve with a trackball, this requires moving the cursor incrementally character by character, and line by line. The physical setup on current phones doesn’t allow you to quickly jump across huge blocks of text with a tap, and or maintain a simple selection above and below the fold of the current viewport.

The touch-based setup also allows the developers of the operating system to write and add aides that assist with text selection. For example, in the case of the iPhone, tapping and holding down on an area of text places the cursor there and displays a magnifying glass over the selection. This is immensely helpful with accuracy at high speeds of movement across lines of text, and more so with small text.

Foreign Languages and Special Characters

With physical keyboards, for the most part, what you see is what you get. If you want special characters, you had better hope they’re hidden inside a symbols modifier key, but otherwise, you’re out of luck. The iPhone’s touch keyboard appears to also have special characters behind a numbers/symbol button on first glance, but you can additionally hold down particular letters to place special characters without ever leaving the QWERTY view. For example, you can access “ó” by holding down the letter “o”, “¿” by holding down the “?” key, or “€” by holding down the “$” key. The list goes on, and this is only for the U.S. English keyboard. Each of the international keyboards has its own version of this too, which brings me to the other special character advantage - foreign languages.

I’ve just illustrated how quickly accented letters could be added, which comes useful for romantic languages. But what about non-Latin-based languages? What about, say, Traditional Chinese?

This is where essentially all physical phone keyboards fall short entirely. Again using the iPhone as an example, you can use international keyboards, exclusively, in dual-mode with another, or in even higher multiples. In my case, I have the U.S. English keyboard in dual mode with the Traditional Chinese keyboard, which uses gestures to allow the user to literally write out the entire character on a virtual pad. The same guides apply - there’s its own form of auto-correction with its guesswork of what character you’re about to write. It can usually guess the character before you’ve fingered all the strokes, and it uses the best guess by default unless you tell it otherwise. The predictive text is also there, as it guesses the next likely character to follow the one you’ve just input.

You could even write your strikes in a relative mess, or even in simplified Chinese, and it would still figure it out. And the appropriate punctuation and everything else you’d want is waiting there right where you need them.

Adaptive and Future-Proof

I can easily concede that the lack of tactile feedback on a touch keyboard like the iPhone’s is no minor drawback, and it has appeared that manufacturers have attempted various ways to compensate, ranging from the iPhone’s audio click cue to the Blackberry Storm’s click screen (though a bit confusing with the flat/depressed split mode) to the Android phones’ vibrational tap feedback. From what I have seen in the patents, such as the pop-out surface bumps, the progress of the research looks promising, and I believe that it’s simply a matter of time for tactile feedback to be perfected on a touch key.

Yet, even when considering all these features, the characteristic of virtual keyboards that is most appealing is how future-proof it is. Not only does the touch keyboard adapt to any situation, but when there comes a need for something new in the future, perhaps a new currency symbol or an entirely new method of input, it’s ultimately just a software update away with the phone you already have.

* Footnote: There are phones that sport physical keyboards with touch screens, though typically a touch keyboard has either been nonexistent or hacked in, or tossed in as a poorly executed afterthought.