Bleuprints

Relocating.

2010-03-12T19:53:00.000-08:00

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

2010-02-26T22:42:00.000-08:00

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

2010-02-14T00:24:00.000-08:00

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

2010-01-13T11:00:00.000-08:00

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

2010-01-05T01:54:00.000-08:00

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

2009-12-14T17:48:00.000-08:00

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.

In-Browser Search Engine Switching

2009-12-08T12:03:00.000-08:00

When I first used Firefox under the Firebird name, one of my favorite features was the ability to quickly add and switch search plugins for other sites. In the case of Firefox, you could type one query, and any other search engine or site search was just a click away. Or for keyboard shortcut aficionados, ctrl+k/cmd+k > ctrl/cmd + up/down > enter.

Safari didn't offer this feature, but years back, I discovered a third party Safari plugin called Inquisitor, at the time the work of an independent developer. Among the features it offered, it also allowed users to also add and switch between search engines with a single query.

But what I loved most was how easy he made it to add search plugins. You see, for Firefox, I wrote several search plugins starting at the end of 2004 and beginning of 2005, using the Sherlock format. Some of these (Yahoo! Movies, Yahoo! Widgets) have been replaced by OpenSearch versions uploaded by other people, but some of the early ones remain in case you want to see what I'm talking about (Cal Berkeley plugin from February 15, 2005).

With Inquisitor, on the other hand, we could simply use a variable representing the query within the URL parameter used in any given site search. For example, if I searched IMDB for "Memento", the URL ended up looking like this: "http://www.imdb.com/find?q=memento;s=all". At that point, I would be able to replace the "memento" search query with a variable in the Inquisitor settings to get this: "http://www.imdb.com/find?q=%@;s=all", where %@ just happened to be the variable used by Inquisitor.

Suddenly, I could add just about anything site within seconds, from Finance quote searches to torrent sites to corporate intranet searches.

It didn't cross my mind that someone could easily top this, but Google did just that with Chrome. When typing a domain like imdb.com into the hybrid URL-search bar, the right side of the bar hints that you can hit the "tab" key to type a search query for a search within that site (in this case, imdb.com).

Most major dedicated search engines try to facilitate site-specific searches these days, but for times when you want to perform a site search, the browser has evolved to help get you there.

Password Masking

2009-08-07T23:57:00.000-07:00

Caught in the ongoing tug between ease-of-use and security is password masking, a point of contention in the past with some of my colleagues working more closely with security related issues. Whether security and usability necessarily have to be inverses of each other is something to leave for another post, but what's clear is that it's certainly the case with our current form of masking typed text strings in password fields.There are three major types of password masking I've seen.

Full masking: Every alphanumeric character or symbol is represented by an asterisk or dot, effectively masking them.
Partial masking: All characters are masked, except for the last typed key. (Example: iPhone OS)
Invisible: No asterisks, dots, or replacement characters of any kind will display. (Example: Unix environments)

Full Masking

Full masking is the most common technique, and while it tells you where are you in the password you've typed so far, it also gives observers that information too. With this technique, the only way an onlooker can grab those passwords is by a combination of physically watching the keys typed and educated guesses based on what the asterisks hint about the password (its length, whether slowed down typing to enter numbers or symbols, and so on). Remember, I'm talking about what can be attained visually and audibly, as that is the point of password masking. Areas like keylogging, plaintext passwords, and such are another area of concern entirely.Now, when it comes to full masking, it generally works fine until something is causing typos, which masking will hide. This includes common mistakes like leaving the caps locks key on, or missing a shift modifier key, or general typos with commonly misspelled words or lengthy randomized text strings. It's worth noting that the caps locks issue is sometimes addressed by detecting that it's on, and subsequently warning the user when it is.

To deal with this issue, it seems that sometimes entirely masked passwords come with an option to toggle the asterisks on and off, such as with the WEP/WPA key fields in OS X. In other words, it's an override option to temporarily remove masking at the discretion of the user.

Partial Masking

But what happens when full masking carries over to a device where typos are far more frequent, such as a mobile device? The user could slow down immensely, or type at regular speed and hope that the login won't lock down or throw a CAPTCHA form after a couple invalid attempts.The iPhone OS addresses this by masking all characters in dots, except for the last typed character (for a couple seconds). It's an improvement, but at the expense of anyone peering over your shoulder seeing each last character. Anyone keeping an eye the entire time can thus see your entire password in the clear, and at a readable pace considering that even the fastest typists on mobile keyboards are a huge margin from the fastest on the desktop keyboards. I have mixed feelings about this, but then again, even fully masked, typed keys on touch keyboards display their character in a tab above the area obscured by the tapping finger. So any watchful person can still catch on that way, regardless of whether the password field itself is fully or partially masked. This is evident on such touch keyboards as the ones on iPhone OS and Android.

Invisible Masking

In a UNIX environment, you'll notice that password prompts give no feedback for what you're typing or what you've already typed, ironic given that this environment is where strong complex passwords are common. I've seen this confuse many, many users, and it's a commonly asked question that won't go away. Eventually, most people get accustomed to this, and it becomes just about as easy to use as full masking - for most cases, that is. But when it comes to lengthy randomized passwords, entering passwords becomes a snail-paced task, during which keystrokes become easier to observe and follow. (This is unless you happen to be a god at rapidly typing 40-character alphanumeric, mixed-cased passwords interjected with symbols with and without modifier keys.)

The Locks at Every Gate

As we raise the number and complexity of locks on a gate, we also construct higher and higher hurdles for intruders to overcome, but also for the people who have to encounter these security measures everyday, every hour, or even every few minutes. These measures typically work fine, but serve users poorly in intense cases to the point of inducing people to find less secure workarounds ranging from writing passwords to copy-pasting a password in the clear. (Try typing a 30 character alphanumeric, mixed-case Wi-Fi WPA2 key on a mobile physical or touch keyboard, and see if you aren't tempted to copy-paste too.) The less visual and acoustic cues there are, the more it slows everything down. You'll get used to it, but we just need to vary where to draw the line on a use-case basis because ultimately the most inconvenienced person is not the sinister characters - it is you.

Blast from the Past: SDI and MDI

2009-08-02T22:50:00.000-07:00

This is an entry I wrote on March 20, 2006 touching upon SDI and MDI:

Warning: This is a usability and interface topic. You may quietly exit through the back doors. No hard feelings. Otherwise...

I know that Adobe Acrobat 7 has been out for quite a while now, but I figure that I need to get the word out wherever I can. The following is a problem that's been bothering me since Acrobat 6.

Notice this. Earlier versions of Adobe Acrobat used a multiple document interface (MDI), where all documents resided within a single parent window. The problem was that they forgot to add "tabs" for easy navigation between the documents in this multiple document interface.

I wrote a complaint in the official forums a while back, and in version 7, it seems that they finally tried to solve the problem by switching to a single document interface (SDI), where each document has its own window on the Windows Taskbar. But the Adobe Acrobat team forgot something again. If you exit any given document with the Microsoft Windows [X] button (the red one in Windows XP), every single document closes. The expected behavior, based on other applications written for Windows, is that only that one document should close (not all of them).

Or perhaps the Acrobat team has a good explanation for this behavior? (I certainly can't think of one.)

My original entry: http://gordeonbleu.livejournal.com/20578.html

Inline Autocompletion

2009-07-24T15:18:00.000-07:00

Inline autocompletion is a common part of search bars, but for the longest time, autocompletion was anchored to the beginning of the URL in a web browser address bar. In the middle of last year, Firefox included an "awesome bar" in version 3, which allowed us to type: "lunar" to bring up a past history or bookmark of "http://en.wikipedia.org/wiki/Penumbral_lunar_eclipse", whereas other browsers required typing, "en.wiki..." (not even flexible enough to allow "wikipedia" to yield results). Over a year onward, and this still hasn't spread to other browsers.

Inline autocompletion

Anchored autocompletion

Seeing as most web browsers haven't integrated their search and URL bars entirely as Chrome has, this is one handicap of most browsers that maintain discreet address bars, as they miss out on one of the top usability benefits of unanchored autocompletion - lessening the requirement on the user to remember URLs.

Browser Sniffing on the Mobile Web

2009-07-15T17:21:00.001-07:00

Browser sniffing holds a level of stigma in the web development/design world, as we have been spending years and years creating cross-platform, cross-browser sites that use more robust techniques of singling out browsers, rendering engines, or platforms as a last resort through our knowledge of what's supported - CSS conditional comments, JS object detection, and various tricks and (if needed) hacks both client and server side. It has long been our practice to create a solid separation of presentation, content, and functionality in a way that degraded gracefully (or more recently, progressively enhanced).

This has worked well on the desktop platform, from desktop workstations to notebooks to tablets.

The Age of Rich Mobile Computing

So the question becomes, what to do with the mobile platform. For years, there have been very basic mobile-specific pages for basic phones with tiny viewports and browsers that couldn't handle much more beyond HTML, with notable omissions of support in areas like CSS and Javascript.

But ever since the iPhone brought fully-featured mobile browsers to the mainstream, there has been this huge trend of companies creating iPhone-tailored sites designed for the width of their viewports, and guaranteed to work on W3C standards-compliant browsers, including Webkit-based ones like MobileSafari, and soon after the ones on the Android and webOS platforms, which currently also have devices with similar viewports. Consequently, these iPhone-tailored sites generally automatically work well with most modern smartphones with full browsers, effectively creating a second tier of mobile sites for smartphones.

For the iPhone initially, it seemed both sensible and insensible simultaneously that people were creating sites that fixed themselves to a specific viewport width. One of the great abilities of MobileSafari on the iPhone was that zooming on small screens was finally easy with the pinch gestures, so coupled with the full HTML/CSS/JS browser, there would be little reason not to experience the same full website used on the desktop platform. Even considering this, however, people still designed sites that negated the pinch zooming.

Still, with a smartphone version of the site, you would ideally be served the same information you need in a way that didn't require any zooming at all, because the user is still otherwise pinching his way into a zoomed out preview of the page that he can't initially read. But sometimes smartphone sites aren't thought out as well, and information or features end up missing.

In some cases though, desktop versions of sites are so mobile-unfriendly (Facebook desktop site) that we pretty much have to rely on mobile sites or native applications to access them on mobile devices.

But there's a lingering question that we may all face in the coming years - at what point is a device considered a "mobile" device and not a desktop computing device?

Drawing the Line at "Mobile"

In late 2008, I had this discussion in an iPhone development forum where I wanted to know how to allow a user to use a link to exit a mobile page back to the full desktop site, without cookies and without having the desktop site's mobile browser detection causing an infinite cycle between the desktop and mobile sites. In other words, just as many sites were doing, I was automatically directing all appropriate mobile devices to the mobile site, but wanted to offer an option to return and remain at the original version.

We came up with a solution, but not before having a heated discussion over whether browser sniffing on the mobile platform was a forgivable exception. My point was that most phones beyond the iPhone did not possess easy pinch zooming, and magnifying with a trackball one square block at a time was not a pleasant experience. Beyond that, there were functions most mobile devices could not yet handle so smoothly, such as click and drag, and general mobile-specific features like data detection (phone numbers, addresses for maps, etc).

But the best counter argument I heard that makes me reconsider is that the line between desktop and mobile computing is not as clearly defined as we think, especially if you think about the smaller 7" netbooks in the middle of the spectrum with screen resolutions in the 800x480 pixels.

It's possible this gap could shorten and fill over time with in-the-middle devices like these and other devices with smaller resolutions. For comparison, the iPhone family of devices sports a 3.5" 480x320 pixels screen.

It's also possible this gap might remain as sparse as it is today, if we assume that the 7" netbooks are roughly the smallest non-niche form factor the mainstream is willing to bear on a desktop platform with a two-handed QWERTY keyboard, and that today's smartphones with thumb-based QWERTY keyboards (hard and touch-based) are in the upper bound for mobile to remain pocket-friendly.

Ideally, we do want our fluid layout pages to scale down well to the current mobile category of devices, and not to serve and maintain special mobile versions of our sites. As it stands, the gap still holds, and for the sake of the user experience in the present day, this is how many of us will approach it. We'll see where the future takes us from there.

Thoughtful Charts and Real-Time UI Feedback in Google Finance

2009-07-15T12:31:00.000-07:00

I'll have to admit that I've never been a frequent user of the advanced options of Yahoo! Finance, so the information that Google Finance provides is just right for finance users like me who just want the fundamentals, and Google Finance has provided excellent usability for that.

One of my favorite features that came out of Google Finance was the extended hours trading on charts of logged in users. Real time quotes in after hours trading was already common in both Yahoo!'s and Google's finance products, but visually displaying the pre-market and after-market movements diagrammatically was important because it displayed the history of the price movement per share of a stock, whereas beforehand, you only had the current trading price during active after-hours, or the last price after that session had ended. It has also been a particularly useful way to guess the trend to be at the opening bell.

A couple days ago, they introduced a tiny detail that I believe users will find helpful - any digits changing in the displayed price will flash green or red momentarily, depending on whether it's an upward or downward change. To put it in perspective, the norm before this was to only color-code the difference in points or percentages, not any part of the price itself. This is a small step, but it reminds me of the days in the late 90's when CNBC turned their navy blue change indicators and values to color-coded green and red values, a novelty that has long since become a standard.

Beyond that, still among my past favorite interface details are - showing news indicators on the charts at the point where news was announced, and transactions tracking to monitor gains and losses. The next step would be to somehow make this site scalable on a mobile viewport, the Flash support on various mobile devices notwithstanding.

Window Maximize and Zoom

2009-07-09T10:39:00.000-07:00

The other day, my friend Eugene and I were discussing zooming and maximizing with regards to window management, as he was looking around for workarounds to maximize windows in OS X. The zooming function in OS X, represented by the green orb button, is the counterpart to the maximizing function in Windows, represented by the maximized square. Yet unlike the parallel "close" and "minimize" functions, "zoom" and "maximize" are not equivalents of each other.

The "maximize" button in Windows expands the current window to fill the entire screen.

Whereas the green "zoom" button on the top left corner of every OS X window toggles between two window sizes. One is set by the developer, most commonly fit-to-content (e.g. Apple applications and most programs), but also fit-to-screen (e.g. Firefox). The other is defined by the user, so if you resize the window to 800 pixels wide and 600 pixels tall, that will be the saved setting whenever you toggle back to the user zoom.

Zoom 1: User-Defined Dimensions

Zoom 2: Fit to Content

This was one of my own habit adjustment hurdles when switching from Windows to OS X, and apparently, it was also one of the most common adjustments users migrating from Windows had to make. Coming from years on the Windows platform, we liked to maximize, maximize, maximize, and apparently it was a common complaint of those migrating from Windows.

And it made sense to me at the time when common screen resolutions were 640x480 or 800x600 or 1024x720, with average webpage widths keeping up with the accepted lowest common denominator of resolutions - less than 640, less than 800...

But as the average screen resolution in the mainstream grew beyond this point, especially with the transition to widescreen aspect ratios, webpage and document widths weren't keeping pace anymore because paragraphs of text become difficult to read after roughly 70 to 80 characters on a single line.

Maximizing a single document to fill a 1920x1200 would mean huge margins of whitespace, which is clearly a waste of screen real estate, which is why the zoom function in OS X I used to dislike has grown on me, as I do find myself frequently wanting to resize windows just enough to see the content before making room for another window on its side.

This is not to say that there won't be times that I'll still want to fill a window to the edges of the screen. Movies may have a full screen mode, but images in Photoshop or lines of code in an IDE are areas where that option would have utility.

User-Defined

Fit to Content

Maximized on a Modern Screen Resolution

Oddly, the pervasiveness of tabbed interfaces in recent years has meant more utility with wider windows, which goes against the grain of maintaining a limited width for readability in a document.

Oh, and if you're wondering what our conclusion was, we liked a third party application RightZoom for OS X, which provided the option to maintain a hybrid zoom/maximize function where one is accessible with an extra modifier key.

Thoughtfulness Zen of the Moment 3

2009-07-02T15:49:00.001-07:00

Probably one of the underrated parts of the third generation iPhone (3GS) is its digital compass, which may evoke questions about its utility until a user actually uses it on the road. The potential utility of this compass gave me some excitement when I saw the iPhone GPS navigation app demo by TomTom the day the iPhone 3GS was announced, because it completed the last requirement necessary to make turn-by-turn GPS work seamlessly - your car's heading.

Now, with location-aware devices coupled with a map like Google Maps, it was already possible to navigate with steps of directions and your currently tracked location. But as anyone who has tried driving with any navigational aid knows, knowing the orientation of the streets grid relative to your direction is immensely more useful than driving with north fixed as upward.

Unfortunately, the TomTom GPS navigation app is not yet released, but one of the most accessible sample implementations right now is in the bundled Google Maps application, which cleverly displays heading in the form of car headlight beams. Moment of zen.

30 Favorite Usability Aspects and Features of Gmail

2009-07-02T08:46:00.000-07:00

Five years ago, I finally received my invite to sign up for Google's new email service, Gmail. It was 2004, and I was loyal to Yahoo! Mail at the time for having the relatively cleanest UI and largest storage space (a whopping 6 megabytes) for a free major webmail provider.

There were plenty of gripes I had sent to the Yahoo! Mail feedback teams over the years - everything from the loss of free POP access since April 2002, to the extra step of having a forced home page before the inbox, to the little things like the promo tags appended to every outbound message ("Do you Yahoo!?" or one line ads for various services for Yahoo! or MSN in Hotmail).

Gmail addressed all of those, for free and immediately, and on top of that exhibited a friendly user interface and excellent usability. It seemed that everyone was falling head over heels over the 1 GB of space for a free webmail service, unheard of at the time, which was important too because with Yahoo! Mail at 6 MB and Hotmail at 2 MB, we were bound to be forced into deleting messages instead of keeping online archives. (This is largely why I no longer have my emails from 1998 in Yahoo! Mail or Hotmail.)

Ultimately, it's the little things that count, and Gmail was and remains the most well thought out webmail application out there. To celebrate my half decade as a happy user, here's a list of 30 reasons, one for every other month in the past five years, of what made me enamored with Gmail at its launch and thereafter. (There are more features than just these, but these were and are the ones that hold importance to me and won me over.)

1. threaded conversations
2. snippets previews of messages
3. labels (as opposed to folders, and color-coded) and advanced filters (and archive)
4. sending as custom address for outgoing messages
5. no promo tag lines appended to outbound messages
6. login goes straight to inbox, no home screen
7. no display ads, unobtrusive text ads
8. clickable textarea to reply in that part of the threaded conversation, without page reload
9. auto saving drafts as composing email
10. arrow indicators for which messages are directly to me, and which are mailing lists
11. search operators (is:unread, has:attachment)
12. attachments downloadable as a batch zip file with a folder
13. attachment previews for images and documents
14. single click to download attachment, instead of having to save as from browser
15. attachments upload in background as composing email
16. attachment upload progress bar
17. online viewing of documents via integration with google docs (doc, xls, ppt, pdf)
18. built-in chat (and later with AIM support and group chat)
19. server side chat logs (even when accessing via Jabber with clients or Meebo)
20. free POP access, including sent mail (later free IMAP, seamless with the labels)
21. POP fetching from other mail accounts
22. https
23. history details of IPs and method of access, and ability to sign off other sessions
24. notifications of live updates in threaded conversation while viewing/composing
25. unobtrusive confirmations/warnings as bars at the page top that gracefully disappear
26. mute conversations
27. google gears offline access
28. excellent spam filters (empirically far ahead of other webmail clients)
29. full css-based themes (as opposed to basic color switches), potential user contributions
30. drag-and-drop to move messages

It also had some behavioral side effects. I no longer used custom creative subject headers in replies, since we were maintaing RE: subject headers to keep messages organized in their appropriate threads. And because of their auto-reload of data and that they displayed the actual inbox count in the titlebar of the browser, I developed the habit of keeping my Gmail open, which made me spend far more time in webmail than ever before. This multiplied with built-in chat arrived in 2006 with sounds and flashing notifications. Meanwhile, the labels/filters/archives combined with the ability to send out as a different email address led to me sending and receiving all my Berkeley email through Gmail, and I soon expanded that to all my other email accounts until I had a central Gmail inbox with a vast collection of filters and labels doing all the sorting heavylifting for me. The GB+ of space also meant that I no longer had to delete email letters with large attachments, and could now keep all email online.

As a more or less loyal Yahoo! user from 1997 to 2004ish/2005, I anxiously waited for the invite-based Yahoo! Mail Beta and kept sending improvement requests such as #5, #6, and #9. Most of the requests I made never happened, and my invite arrived over a year after I had told all my contacts I had moved to my Gmail address. In contrast, #12 was one I sent to Gmail's feedback team, and maybe by coincidence, the feature appeared within a week. To give them the benefit of the doubt, they seemed like they were listening to their customers and were prolific with their continuous improvements of their product. It's worth noting that some of these were features at various points of Yahoo! Mail's heyday, such as #16 and the first part of #20. But as long as the Gmail team keeps this up, Gmail will remain the most useful and usable web application I've ever encountered in my online experiences.

The Global Inbox versus the Distinct Inboxes

2009-07-01T10:50:00.000-07:00

When it comes to organizing multiple accounts on an email client, there are two major approaches - one is to send them all to a shared inbox, generally called a global inbox. How emails get filtered or sorted at that point varies, whether by folders or by labels. The other approach is to keep separate inboxes and sent/outbox/junk/trash folders for each mail account set up in the application.

Most desktop email clients offer the option of both inboxes global and separate, but it gets trickier with the constraints of the small viewports on mobile screens.

The way the iPhone OS has been doing it these past couple years seems to be consistent with the way the original iPods menus were done - you start a root level menu, and drill your way down (visually to the right) until you reach the level you wanted to visit. For example, on the original iPods, playing a song from the main screen involved: Music > Artists > Jack Johnson > All Songs > Upside Down, and going back (up one level) was done by the menu button (or the equivalent home button on the iPhone OS devices).

This was part of the foundation of the famed ease-of-use menu/clickwheel navigation of the iPods, and to the extent of the menu/home UI breadcrumbs, the iPhones and iPod touches. However, for tasks where switching quickly between two children-level items, heavily nested levels can hinder that. For example, one classic task is to switch between folders in two separate email accounts. From the first inbox, this requires going back two levels up emailone@someprovider.com > Accounts > emailtoo@someprovider.com > Inbox. That's four steps.

Now try this on the Palm Pre's webOS. For those maintaining separate inboxes, the accounts are listed in collapsed folder lists, so if both accounts's lists weren't expanded already, two taps for expanding both are required, after which both inboxes are just a scroll away from each other, and one tap for going back to the accounts list. If that's not enough, this mail client allows adding folders from various mail accounts into a global favorites list on the accounts list page, reducing even the need for a scroll.

The fact that there's a global inbox view while preserving the separate nature of the accounts ("All inboxes" on webOS) is a huge side perk, and actually excels beyond what many desktop applications offer. This is a shining example of a solid mail client implementation for both global/distinct inbox camps that scales well onto the mobile platform.

The Case for Too Many Mobile Apps

2009-06-24T09:23:00.000-07:00

One point of contention with my usage of the iPhone is that I'm one of those people with so many apps, to the point of reaching the nine screens limit characteristic of the OS prior to the version 3.0 release last week.

One of the common rhetorical questions laid about before me was whether I actually use all the applications on my smartphone. This is a fair question, and the answer remains that it indeed comes down to a handful of applications I can honestly categorize under frequent usage.

The Desktop Analogy and Occasional Use

But that's the thing - frequency of use. Users like myself like to treat their smartphones more as portable computers than just powerful phones. That is, people like me want all the occasional-use applications on the phone, just in case. It would be analogous to the myriad of applications installed on a Windows, Mac, or Linux desktop environment. I may not burn DVDs or CDs on a daily basis, but I'm not going to reinstall Nero Burning ROM every other month for each time I need to burn an optical disc. Likewise, I'm not going to reinstall an ATM Hunter app or Starmap app every time I occasionally need it.

The last thing a user wants to do the moment a task needs to be done is to install and configure settings. (In general, desktop software and mobile apps lose some or all customizations and data upon removal.) Essentially, it's all about the convenience of having the tools and resources you need available to you, even if you only use them once in a while.

It can seem overwhelming to an observer seeing a user swipe across eight or nine screens of apps on an iPhone, and it's certainly valid that it can look like a random mess. It requires relying on memory of where a particular app sits (turns out to be easy for the primary user, but slower for guest users), as well as reorganization of their icon order on the pages. For example, there seems to be this trend of people sorting by a gradient of usage frequency, with the most used apps on the home screen, and gradually sorted towards the least used apps on the last screens.

Search versus Browse, and Low-Use Applications

In the case of this phone, there's no function to sort all apps by name or any attribute, but the default behavior is that any new app gets placed at the end, or in the first gap on a screen's icon grid. That effectively sorts by last added. If you're installing all applications in a huge batch, such as if syncing for the very first time with apps all sync-ready in iTunes, then they install in alphabetical order by name. Beyond that though, it's all manual sorting.

So when version 3.0 released with its Spotlight global search feature and removal of the cap on number of apps, the iPhone OS seemed to step closer to this desktop computing behavior. The search versus browse mentality is very much like the live global search on a desktop platform, such as with Spotlight on the OS X menu bar and Windows Search in the Windows Vista/7 taskbar. You still browse for applications (and anything else from emails to calendar events), but for anything further out of reach, such as low-usage applications, the search part of the hybrid system comes in handy.

Linear Browsing versus Planar Browsing

It's also worth noting that another suggestion I've come across is to allow vertical swipes for vertical pages/screens, whereas the iPhone OS maintains a horizontal row of pages that only move left and right, with dot indicators at the bottom to show the current position. This is a linear approach. It has its cons, but it's arguably easier to keep track. Typically, most other phones offer a single tall vertical page with scrolling for all applications, and movement is also linear, with the scrollbar being the indicator of position.

The Palm Pre takes a different approach with a grid of screens of icon grids. This could potentially mean less swipes when browsing, provided the user can keep track of position. There are stick indicators showing where you are on the grid. This remotely like organizing by workspaces in Linux or Spaces in OS X, and its only limit is how much the user can remember about the position of a specific app in a cartesian plane instead of a linear. The question then becomes what the threshold is for how much we can handle - 2x2, 3x3, 4x4? Will a user remember that the Pandora app was on the Marsha part of the Brady Bunch grid? Or was it the Cindy part of the grid? We risk confusion, but it's an expense for the gain of quicker movement on a 2D plane. In some ways, this kind of planar browsing is much like that of desktop computing, except with a much more limited screen size to do it, so we'll see how that plays out.

Convergence

For years and years, people and the media alike have been talking about the convergence of many different kinds of devices into one, for better or worse. In the case of the mobile devices, its evolution towards becoming more desktop-like is one part of this continual convergence, not necessarily towards one single device for all, but certainly towards the further blurring of the lines between them all.

Blast from the Past: Oversights in the Motorola Razr V3 Interface

2009-06-16T22:54:00.001-07:00

Before any organized effort like Bleuprints, I wrote these scattered design muses under the label "blurbs".
Here is one I wrote in 2007, towards the end of my experience with the Motorola Razr V3, and prior to owning the Razr V3xx (a future device that would finally fix some of the issues I mentioned). The iPhone solved many of the gripes I had with mobile phone UI's in general, which was largely why I loved it so much. Its announcement prompted me to write out what had been frustrating me about the status quo during my ownership of the Razr's.

"Oversights in the Motorola Razr V3 Interface"
August 3, 2007, from yours truly, Gordon

The following are some highlighted interface oversights I noticed when I first got the now widespread Motorola Razr V3 back in 2005. I've upgraded my firmware multiple times with the hope that perhaps Moto developers had addressed these issues since then, but to no avail. I've contacted Motorola directly, and they respond as though they don't see these as shortcomings.

Why is this important? Well, first off, Motorola clearly isn't listening, and hasn't provided easy feedback channels to their developers, and that's a shame because the shape of this anodized aluminum exterior and its keypad design are absolutely gorgeous. Yet more importantly, this mobile operating system appears to be used on most other Motorola phones, like the clamshell V551 that my sister owns.

Fig. 1

Fig. 2

Above: Clock hidden from view during phone call

During a phone call, someone might ask you if you can meet them at 4pm. You check down at your phone, your sole time piece nowadays, only to discover that the "Calling" half-screen is blocking the clock from view. Yet Motorola does not allow you the option to move the clock anywhere beyond the lower right hand corner. With all that space at the top, they could have allowed the time to be positioned anywhere at the top, where the date currently sits.

Fig. 3

Fig. 4

Above and Below: Inconsistency - Inability to rename pictures in viewing mode menu

You've taken some photos with your camera phone, and you want to name them. Yet sometimes the tiny thumbnails in the main pictures gallery (Fig. 3) are unidentifiable for naming, so you select a picture and "View". Now that it's clearer what this photo was (Fig. 5), you access this individual photo's menu (Fig. 6), only to realize that there's no "Rename" option. In order to name this photo, you must select "Back" twice, access the menu, and rename from this main menu (Fig. 4). That's two extra steps every time. If you're naming the last ten photos you just took, that amounts to a lot of wasted time and finger movements.

Fig. 5

Fig. 6

Fig. 7

Fig. 8

Above: Extra steps in saving freshly taken camera pics

Every time you've just snapped a photo with your camera phone, a screen (Fig. 7) pops up asking whether you want to "Store" or "Discard". This decision has some logic behind it, because you'd want to discard bad takes immediately. Some cameraphones prefer to save your snapshot right away and let you decide how to use it later, such as with Nokia. That way, you won't lose your snapshot if someone happens to call you right as you're trying to save it. Saving is not even a one-step process because Motorola assumes that you want to send every photo you take in a text/e-mail message. So to save a photo, you must "Store", arrow down to "Store In". If it's a passing moment you're trying to capture, you can forget about making the subsequent shots in time. Or let's take it up another level - about half the people I see on vacation snap photos with their phones. Imagine if you asked someone to take a photo of you, and then you wanted the conventional "one more" shot. Unless they're familiar with this Motorola interface, you're in for some extra minor hassles - "Did I take it? How do I save this?".

Exterior: Gorgeous and well thought-out

Quirks in the interface aside, this device's innards are housed in a slim exterior (finally, reduced pocket bulge), an anodized aluminum surface like the iPod Mini and iPod Nano 2G (finally, grease resistance and easier to the touch), no bulgy stick antenna on the top (finally built in as part of the look on the bottom), and a styled keypad (notice the consistent typeface usage, the green button symbolizing "talk" with a telephone icon with an emanating wave of talk, and the red button symbolizing "off" with the hung-up handset resting on the body of the phone), to name a few. Sure, there are a few decision quirks on the exterior end as well, such as the "Internet" key, which most people would find less useful than a "camera" key (later adopted on other Razr models). You can tell that the designers behind this weren't sloppy with the curves, as you can tell by how how neatly and naturally all the lines sweep and come together at the hinges/camera and battery door, and the between the top lid and bottom antenna. Nothing juts out, not even the integrated loop for string-attached decorations. This was the phone that melted away my original perception of the flip phone as a bulky, generic grease magnet of gray boredom, and I thank you Motorola for getting that part right. Now about that interface...

From Tabs to Thumbnails, and Back

2009-06-16T17:16:00.000-07:00

The screenshots tell it all. The Opera 10 beta browser has a vertically resizable tab bar that turns into page thumbnails as they are expanded. To me, this is the most graceful approach I've seen towards representing open pages as thumbnails because it doesn't interrupt the view of the current page beyond what you control, in contrast to a full page grid of thumbs. I'm curious to see whether this takes off beyond the web browser into other tabbed applications.

Working Within the iPhone OS Icons Restrictions

2009-06-15T09:32:00.000-07:00

One of the signature visuals of the iPhone OS is the simple half-gloss rounded rectangle shape every icon takes. When the phone came out a couple years ago, I had initial reservations about how this template might encourage developers to make every icon look too similar with regards to creativity. I tried to deduce a good reason why they might have chosen that route, and I concluded that perhaps they a.) wanted to lower the barriers by making icon development easier for developers, and b.) wanted to prevent certain arrangements of contrasting icon shapes from making any particular sequence look strange on a grid. There wasn't an answer in the Developer Connection Human Interface Guidelines either, but it did seem to suggest that developers were supposed to create non-glossy square images for (I assume) to be later processed for uniform corners and gloss treatment.

Nevertheless, I love the challenge of working with restrictions such as the rounded template, so I was struck in the very beginning over how someone used the rounded corners as the rounded edges of a retro television set for the YouTube icon, and then again just last week over the imeem icon using the tapered edges of an audio cassette.

This is not to say that people haven't broken out of the rounded boxes mentality (see the WordFu icon), but to maintain the exact template shape to make it work with your design is the best kind.

Am I the only one who noticed this? Safari 4's Tabs Bar Lost Multitasking

2009-06-11T10:03:00.000-07:00

I previously mentioned how Safari 4 Beta had stepped up their spillover tabs menu oversight by moving you to the area of the tab bar where your active tab sits, so that you could see its neighboring tabs. Suddenly, tabs that didn't fit on the visible part of the tab bar weren't segregated into an inaccessible menu.

This was what the Safari team gave us with Safari 4 Beta:

(To jog your memory, notice that wherever you are, the whiter part of the contextual menu shows which part of the tab bar is visible, and it would move you to that section of the tab bar.)

This is what happened when Safari 4 officially came out:

(Now we're back to being fixed at the front of the tab bar, and only one tab from the contextual menu can show up in the visible part of the tab bar at a time - at the very end of the tab bar. So if I selected the hidden spilled-over 16th "Flickr" tab, it would appear at the end of the visible tab section, beside the 10th "Google" tab. That misrepresents the sequence of the tabs, and reduces what we can do with it when moving tabs around.)

They quietly removed it, and while the blogosphere and media seem to be talking about the Safari 4 official release version, nobody seems to be talking about this. Am I the only one who noticed this? Surely I'm not the only detail-oriented person around here. Maybe all the designers out there just haven't noticed this yet. What a step backwards. My only redemption is that we now have access to the Chrome developer preview for OS X.

Thoughtfulness Zen of the Moment 2

2009-06-03T14:05:00.001-07:00

There are plenty of things I like about Google Chrome, but one of the things I just noticed was that if you maximize the window, the draggable area above the tabs vanishes. That makes sense because you can't drag around a maximized window.

Also on the list of reasons of why I still like Chrome as a general use browser:

download manager saves and runs files without extra popup windows or download list windows (without requiring plugins). Opera comes the closest to this behavior, but still lacks the bar at the bottom, which I've only seen in the form of third party plugins

color coding and fading of URL text to distinguish different parts of the address (protocol, secure protocol, main domain...)

main bookmarks are an extension of the toolbar bookmarks, instead of the other way around

easy tabs/windows management, thanks to the wide draggable tab areas and long draggable window area (example of badly done implementation: Safari 4 Beta)

right sizes, proportions, and colors of the minimalist browser chrome

and plenty of other little details, in both UI/functionality and speed, but who could forget one of my favorites: separate processes for each tab, because I've had single tabs crash my entire browser with ten, twenty, forty tabs open

Iconoclastic Friday

2009-05-29T09:44:00.000-07:00

Just a little fun, but I noticed the incandescent lightbulb icon was replaced with a CFL bulb icon after updating to OS X 10.5.7 from 10.5.6.

The Ballad of OS X and Windows 7 Docks

2009-05-27T14:50:00.001-07:00

The dock is one of the major approaches for windows management and application launching, currently most well known with its usage in OS X. With its grouping of documents by application, it stood in contrast with the dominantly document-by-document system found in the taskbar approach in Windows. The taskbar evolved into a hybrid system over the years with the addition of the Quick Launch bar and the tab grouping, as I previously discussed in fuller detail, and it has again evolved with the upcoming version of the taskbar in Windows 7 - into a dock.

Yes, there's a dock, and that implies that many more users worldwide will be interacting day in and day out with a dock. And Windows 7's dock is likely here to stay, given that the experience in a release candidate is essentially the same as that in the final release.

Now, that statement might stir some uneasiness among some people, as the knee-jerk reaction would be to point out that it actually isn't the same as a dock. In fact, my own initial reaction was the same when I first tried the Windows 7 betas - that it possibly only looked like a dock on the surface, but behaved very differently from one. Yet, after testing the UI and behavior, I've concluded that we now have both an OS X dock and a Windows 7 dock.

I'm particularly interested for one primary reason - the OS X dock is one element that hasn't evolved as quickly as I've wanted in the past decade, so some healthy competition is entirely welcome.

I actually miss the document-by-document organization by the original taskbar, since switching between any two documents is no longer a single click away, as there's an extra step every time I want to jump across windows either within or between applications. By switching to the dock, Windows now suffers the same tricky issues as OS X, such as the lack of text labels without hovering (so the importance of clear distinguishable icons is greater), the handling of minimized windows, and the switching of tabs within one or multiple windows.

But I can see why this move to a dock was necessary, considering that I saw extremely heavy multitasking on a taskbar as unsustainable after a certain threshold number of open tasks. (Imagine rows and rows of tasks on a taskbar, even if it's double-decked.) It would reach the point where we no longer could reasonably sacrifice more screen real estate, or even read the truncated text of each taskbar task efficiently, especially if many of them shared the same task application icon. It was a wall they were going to hit at some point, and the rise of widescreen resolutions only postponed that bump by making allowing more tasks to fit on a default taskbar.

Nevertheless, now that the dock is going to be a larger part of all of our lives, let's take a look at the docks.

Remove From Dock

On the Windows 7 dock, removing an application from the dock is labeled, "Unpin this program from taskbar", the equivalent of "Remove from dock" on the OS X dock. It's a bit of a lengthy way to say, "remove from dock", but I can imagine how it might be easier for a Windows user new to docks, assuming that they're familiar with "unpinning" applications from the Windows XP/Vista start menu. It's also arguably more explicit, at the expense of brevity.

Rearranging & Rearranging/Removing Dock Items

Rearranging dock items is pretty straight forward - just drag and drop where you want it placed. On the OS X dock, dragging motion is possible in all directions of a Cartesian plane, which requires less mouse precision (think of an arc), prevents obscuring of items underneath before releasing the mouse button, and allows items to be removed from the dock by dragging and releasing them off the dock in a poof (literally). Currently, the Windows 7 dock restricts movement to horizontal dragging, but I'll assume that's an oversight that will be corrected in the future (I hope). As a side note, I find it interesting how Windows 7's dock uses cascading squares to visually represent how many windows are open per application, but the limit seems to be at three overlapping squares, after which it only tells us that multiple windows are open. However, it's a thoughtful approach I'd find useful for distinguishing between applications with single and multiple windows open.

Open Windows and Tabs

Both docks allow new windows to be opened from the menus, and list open windows in each application. Neither dock, however, provides a menu list of tabs for each of those open windows, despite the pervasiveness of tabbed applications. So I was thrilled when I saw that the Windows 7 dock had a "New Tab" item on the Internet Explorer 8 item menu. The problem is in which application window will the new tab call home. I expected it to create a new tab in the current active window, but it instead creates new tabs in the last created window regardless of whether it's out of focus or even minimized. It seems more intuitive to me to have new tabs created in the window in focus, the window I'm most likely working with currently. Still, developers on both platforms have the ability to add custom functions on the menus, so we'll probably see developers implement tab lists and creation options in their item menus.

Tab shortcomings aside, I also found a pleasant surprise in how windows could be closed directly from the item menu in Windows 7.

As far as minimized windows, they get placed in a separated section on the right side of the OS X dock, which doesn't work so well if you have several similar-looking document thumbnails (all of which are unlabeled until hovered over). Normally, Expose in OS X would save us, but minimized windows obviously don't appear in the Expose overlay. Windows 7 doesn't seem to have a minimized distinction at all - minimized windows appear with open windows, but that's about it. Neither dock visually distinguishes minimized versus open on the menu list of windows for an application, which leaves us wondering if some shade color coding is in order.

Lists: Showing Frequent & Showing All

The Windows 7 dock displays a list of frequently used options (for example, the controls of a Control Panel), whereas the OS X dock displays the entire list (for example, the panes of System Preferences). This one's a matter of preference. If you liked personalized menus from Windows, you might like the frequents display, otherwise you might prefer having the full list.

My favorite part about docks is seeing what developers provide on their application's menus - new file by language in Coda, history and favorites in Transmit, playback controls in iTunes, bookmarks toolbar links in Camino, and so on. I hope the shortcomings in all docks are addressed, and we'll see where docks take us in the future.

When Browser Tabs Spill

2009-05-26T15:32:00.000-07:00

In the olden days, web browsers didn't provide us any real solution for tabs spilling off the edge of a tab bar filled with open tabbed pages. In the past few years, we saw multiple angles from the main Webkit/Gecko/Presto/Trident browsers. In the near future, these different approaches will likely merge, although you may be surprised by the results over which browser seems the closest there.

Safari 4 Beta: Menu of Visible and Hidden Tabs

Firefox 3.x/3.1-3.5 Beta: Scrolling Carousel Tab Bar + Menu of All Tabs

Chrome 1/2: Compact as Many Tabs in View As Possible (a.k.a. No Solution)

Opera 9/10 Alpha: Compact as Many Tabs in View As Possible (a.k.a. No Solution)

Internet Explorer 7: Scrolling Carousel Tab Bar + Menu of Visible and Hidden Tabs

Camino 1.x: Menu of Visible and Hidden Tabs

Surprisingly, Internet Explorer, the last of the current big browsers to implement tabs and generally seen as playing catchup with the rest, has shown the most complete system today for managing tabs in version 7, which naturally carries over to the recently released version 8. It allows both scrolling of tabs left and right, while distinguishing the visible and hidden portions of the tab bar in the tab list menu. Although it strikes me as odd that they decided to place the menu on the left, when tabs are created and spilled over on the right.

On top of that, it also offers a grid of thumbnails of the open pages, all out of the box. I'm not accounting for extensions or plugins for any of these browser comparisons because I'm concerned with what comes out of the box, which is generally what most users will use, and what you and I will use on a computer with restricted privileges, or a computer we're using as a guest.

Organizing Groups of Tabs in Windows

In the past few years, we saw browsers answer our micromanagement desires by finally giving us the option to drag tabs to rearrange their order. Some browsers took it a step further and allowed us to tear tabs off a window and onto another. Most mainstream browsers seem to have taken cues from each other and implemented this functionality more or less the same way.

Safari (3 and) 4 Beta: Draggable, Tearable Tabs with Preview

* The difference was that with Safari 4 Beta, the tabs could now only be dragged from the edges because of their new location at the top as both tabs and titlebar, contrary to Chrome.

Opera 9 (and 10 Alpha): Draggable, Tearable Tabs

* The behavior in version 10 Alpha is still the same. It remains to be seen whether the future beta and release versions will add previews.

Firefox 3.1/3.5 Beta: Draggable, Tearable Tabs with Preview

* Tabs could only be dragged within the same window in and before version 3.0.x.

Chrome 1 and 2: Draggable, Tearable Tabs with Preview

Internet Explorer 7: Draggable Tabs

Camino 1.x: Nothing

We'll see whether this will change with Camino 2.x Alpha.

Chrome and Firefox have the best approaches, as they allow tabs to be dragged or torn off from the full area of the tab. Safari 4 Beta introduced an oddball by doubling the tabs as a titlebar and draggable, tearable tabs. That meant that from 3 to 4 Beta, the draggable area shrunk to the right corner, leaving the us to awkwardly drag the window by the "titlebar" area in the tiny center of the tab, avoiding the drag area to the right and the [x] close button to the left. Firefox and Chrome provide distinct draggable areas to move the window alone, and to place it in and out of focus. Opera and Internet Explorer 7 are missing previews of tabs as they're being dragged, and IE 7 doesn't provide tab tearing. Camino 1.x offers nothing.

Conclusion

By now, most of the modern browsers (and probably many of the unmentioned browsers) have addressed the problem of what to do with tabs when heavily multitasking. To recap, there seems to be two major approaches - provide a contextual menu listing active tabs from left to the right, with grayed out items above or below for hidden items to the left or right respectively; or allow a carousel-like horizontal scrolling of the tabs in the bar to access the hidden tabs on either side. For moving tabs between windows, tearing off tabs (with previews) from one window to another is the most comprehensive form of a common approach.

What ever happens, the fact that we are in the middle of a second golden age of browsers with healthy competition means a lot of good for all of us users and developers.

The Desaturation of OS X

2009-05-19T15:13:00.001-07:00

Above: Unification of Aqua and Brushed Metal

In a nutshell, I still miss "Aqua", which probably requires no introduction by now, being the common visual theme that stood as the foundation of the Mac OS X operating system until the past couple years. To many people unfamiliar with the platform, this is generally the majority of what they know when they think of this and any OS, as the visual parts of the UI are easiest to see above all the beauty that is beyond skin deep.

Now, Apple is known for a thorough design, from beginning to finish, from hardware to software design. So when the look changed from the white plastic surfaces to aluminum surfaces on their product lines, the primary visuals of the OS turned metallic gray accordingly.

So here's the issue. So did everything else.

They overdid it. They turned the UI chrome gray (that's fine). But then they proceeded to do the same to the form elements, navigation buttons, and just about every UI element some shade of metallic gray. Is color as a visual cue no longer a part of their design philosophy?

But this change occurred in 2007, back when the current version OS X 10.5 debuted. So why resurrect this topic? The mixed blessing of third party applications on this platform is that many developers maintain consistency with the interface guidelines of the OS. As a result, when the OS turned into a desaturated stormy gray a couple years ago, it didn't stop there. It crept into every new or updated version of applications written for OS X. What you get is a continuing desaturation of the visuals of every interface we use. If anyone's listening, please, color is not dead.

We're outgrowing our tabs.

2009-05-18T11:00:00.000-07:00

I've been getting this sneaking suspicion lately that we're outgrowing our tabs.

And then today, a reference on Slashdot brings the question into the spotlight again.

Tabs. They've been around for a while, though arguably they became even more prevalent with their rising popularity as the standard multitasking approach in web browsers a little over half a decade ago. For most people, their heaviest multitasking activity generally involves interacting with the web in pages. In the early days of the Internet, with our dial-up connections and relatively modest computing resources, multitasking for most people meant maybe several pages. The average seemingly climbed since then, to the point where tabs came in to answer that problem.

Tabs work great when you have a mild number of documents or pages to switch between. The tabs themselves don't offer much visually, just a title or file name, which you'll have to hope doesn't look like a series of "Untitled1", "Untitled2", "Untitled3"... This issue is exacerbated once you run into far more tabs, and the truncation that comes along with it.

One of the problems with tabs is that operating systems seem to be designed to handle window-based multitasking. Take Mac OS X for example. Expose works wonders with multiple windows, but does nothing to help our 10, 20, 100 tabs in Safari, Firefox, Camino, Opera, or even any non browser app that uses tabs.

Part of this problem is mitigated with the use of effective visuals provided by favicons, which works great in cases where you have the same tab text (example: truncated Google *) with different icons for each unique section - Google Reader, Google Notebook, Google Docs, etc.

But if you're looking at multiple tabs within the same section, and therefore exhibiting both identical truncated tab labels and icons, you're going to have to examine each tab to find the one you want. An example of this would be if you had multiple Google searches going on, or multiple articles from the New York Times open, or multiple stock pages of Yahoo! Finance open.

This is why there was a trend years back of people shifting text in title bars like this: "Site Name - Page Title" to "Page Title - Site Name", once tabs and truncation became common.

There's another implemented approach where previews are shown when hovering over each tab, such as in Opera, but that still requires hovering over each tab. Building upon this, there have also been implementations displaying grids or single columns of previews of open tabs, such as with various Firefox extensions or Internet Explorer 7, though there is the issue of how best to handle multiple windows, each with multiple tabs.

Nonetheless, most, if not all, operating systems today have not provided us a way to handle the increasingly growing amount of tabs we use, especially with the continuing move of web applications playing many of the same functions as desktop applications. If there's any elegant solution, it has to come from the OS.

Unscripted Friday: Internet Sharing Toggle (Applescript)

2009-05-16T13:08:00.000-07:00

File: toggleinternetsharing.scpt
Language: Applescript
Download: http://gist.github.com/112789
Background: At work, I often share the Ethernet connection of my Macbook Pro over Airport, so that my iPhone can connect over Wi-Fi. However, at the end of the day, I switch Internet Sharing back off to free up the Airport, so that I can go online with my notebook wirelessly again on the go. I wanted a way to perform this task with just one click, and Applescript was my answer.


-- Internet Sharing Toggler: Toggle Internet Sharing on/off in OS X
-- 2009 May 16. Written for OS X 10.5.x.
-- Gordon Mei
-- Feel free to use and distribute however you'd like.
 
tell application "System Preferences"
  activate
  tell application "System Events"
    tell process "System Preferences"
      delay 0.5 --for running script again shortly after
      click menu item "Sharing" of menu "View" of menu bar 1
      delay 0.5
      tell window "Sharing"
        tell group 1
          tell scroll area 1
            tell table 1
              tell row 10 --"Internet Sharing"
                click checkbox 1
              end tell
            end tell
          end tell
        end tell
        delay 0.5
        if (exists sheet 1) then
          tell sheet 1
            click button "Start"
          end tell
        end if
      end tell
    end tell
    delay 0.1
    keystroke "w" using command down
  end tell
end tell

Unscripted Friday: Hot Corner Toggle Off (Applescript)

2009-05-15T18:48:00.000-07:00

File: togglehotcornersoff.scpt
Language: Applescript
Download: http://gist.github.com/111949


-- Hot Screen Off Toggler: Toggle all four hot corners off. This is the counterpart to the script that toggles all four hot corners on, for cases when a visitor comes over who isn't used to active screen corners.
-- 2009 May 14. Written for OS X 10.5.x.
-- Gordon Mei, with guidance from Pierre L. from Apple discussions
-- Feel free to use and distribute however you'd like.
 
tell application "System Preferences" to activate
tell application "System Events"
  tell process "System Preferences"
    tell menu bar 1
      tell menu bar item "View"
        delay 0.5
        tell menu 1
          click menu item "Exposé & Spaces"
        end tell
      end tell
    end tell
    tell window "Exposé & Spaces"
      tell tab group 1
        click radio button "Exposé"
        tell group "Active Screen Corners"
          tell pop up button 1 -- top left corner
            click
            tell menu 1
              click menu item "-"
            end tell
          end tell
          delay 0.05 -- delay here to prevent error: "can't get menu 1 of pop up button 2 of group...invalid index"
          tell pop up button 2 -- bottom left corner
            click
            tell menu 1
              click menu item "-"
            end tell
          end tell
          delay 0.05
          tell pop up button 3 -- top right corner
            click
            tell menu 1
              click menu item "-"
            end tell
          end tell
          delay 0.05
          tell pop up button 4 -- bottom right corner
            click
            tell menu 1
              click menu item "-"
            end tell
          end tell
          
        end tell
      end tell
    end tell
  end tell
  delay 0.1
  keystroke "w" using command down
end tell

Unscripted Friday: Hot Corner Toggle On (Applescript)

2009-05-15T18:37:00.000-07:00

File: togglehotcornerson.scpt
Language: Applescript
Download: http://gist.github.com/111945
Background: Hot corners, or active screen corners, are an option in OS X where you can toss your cursor to a corner to trigger an action, such as Expose, the launch of application, or the screensaver. However, this can take getting used to, and I'm reminded of this every time a visitor uses my notebook. To address this issue, I decided that I needed a one-click toggler to set and unset my four corners. GUI scripting via Applescript seemed to be the way to do it.


-- Hot Corner On Toggler: 
-- Toggle all four hot corners on to specified settings
-- (assumes you've set the script to use predefined settings you always use.
-- This is the counterpart to the script that toggles all four hot corners off,
-- for cases when a visitor comes over who isn't used to active screen corners.
-- 2009 May 14. Written for OS X 10.5.x.
-- Gordon Mei, with guidance from Pierre L. from Apple discussions
-- Feel free to use and distribute however you'd like.
 
tell application "System Preferences" to activate
tell application "System Events"
  tell process "System Preferences"
    tell menu bar 1
      tell menu bar item "View"
        delay 0.5
        tell menu 1
          click menu item "Exposé & Spaces"
        end tell
      end tell
    end tell
    tell window "Exposé & Spaces"
      tell tab group 1
        click radio button "Exposé"
        tell group "Active Screen Corners"
          tell pop up button 1 -- top left corner
            click
            tell menu 1
              click menu item "Spaces"
            end tell
          end tell
          delay 0.05
          -- delay here to prevent error: "can't get menu 1 of pop up button 2 of group...invalid index"
          tell pop up button 2 -- bottom left corner
            click
            tell menu 1
              click menu item "All Windows"
            end tell
          end tell
          delay 0.05
          tell pop up button 3 -- top right corner
            click
            tell menu 1
              click menu item "Application Windows"
            end tell
          end tell
          delay 0.05
          tell pop up button 4 -- bottom right corner
            click
            tell menu 1
              click menu item "Desktop"
            end tell
          end tell
          
        end tell
      end tell
    end tell
  end tell
  delay 0.1
  keystroke "w" using command down
end tell

Thoughtfulness Zen of the Moment

2009-05-04T14:24:00.000-07:00

I just noticed that Calculator.app on OS X lay out its buttons exactly like the layout of the numeric pad portion of the Apple keyboard. (I'm usually on a notebook keyboard with no numeric pad.) Needless to say, this is meant to help us feel as though we're operating an actual calculator. Although, I'm not entirely sure about the "=" equal sign representing the "+/-" key on Calculator.app. There's probably a backstory about how this key was inherited.

Mac OS X: 13 Things I Miss from Windows

2009-03-29T13:18:00.001-07:00

Last year, I started compiling a list of things I miss from the Windows operating system UI that were lacking in the OS X UI. I'd been a loyal primary Windows user for 15 years, using every Windows installation as they released on my own computer from Windows 3.1 to Windows XP, with the exception of the NT line up until 4.0. A bulk of all my web work, art, writing, and academics were all done on these systems, and have messed around with the systems more than many IT folks have.

But in 2006, after a half decade of using Windows XP, I concluded that the new Vista OS was not the best fit for my computing expectations, and my upgrade path ended. After exploring various Linux distributions and OS X, I decided OS X as it was finally met what I wanted from an OS.

I love this OS. I made that quite clear already. But there are some deep flaws with this operating system that disrupt my workflow.

Here's my list from last year, as it was as of October 28, 2008, because sometimes it feels as though all those years of feedback form suggestions to the Apple team just aren't getting through. Feel free to add valid UI-related issues of your own. Here we go:

1. File menu in dual monitor displays

If you are working on the right-hand monitor but your file menu bar is on the left-hand monitor, then it's a pain to keep mousing over between monitors. This is an example where the one menu bar per application model of Windows beats the fixed universal menu bar philosophy of the Mac.

Workaround: Third-party application DejaMenu tries to compensate for this by providing a contextual file menu for the monitor lacking the file menu bar, but navigating nested options in a contextual menu is not as convenient.

2. Cannot keyboard-cycle between thumbnails of images in Preview

When you open an image in Windows with the default Preview viewer (Windows Image and Fax Viewer), you can keyboard left and right to view other images in the same folder. This behavior has been present since Windows Me and Windows 2000. This behavior is not the same in Finder as it is in Windows Explorer.

Workaround 1: The way to do this in OS X's Preview is to open all the images so that they appear in your drawer. This is, of course, a different way of doing things, but it's not ideal by my standards.

Workaround 2: If you're just previewing, view one file with QuickLook (Spacebar), and then use the arrow keys to preview neighboring files in the folder. This is available on OS X 10.5 Leopard or later.

3. Folders don't group first and separately from files in Finder when sorted by name

When sorting by name, folders appear among files, instead of being grouped first by themselves. You'll see this kind of behavior if you run the UNIX ls command in a terminal. This is all preference, of course, but having come from Windows, I'm used to being able to move up and down a hierarchy of folders quickly because each next nested folder lists all enclosed folders grouped at the beginning, so that I don't have to scroll to find them.

Windows:
A Folder
C Folder
B File
D File

OS X / Unix:
A Folder
B File
C Folder
D File

Workaround 1:
The next best thing is to sort by "Kind" (except that folders sort according the letter "F"), and then in edit the InfoPlist in Finder by using Terminal, running:


cd /System/Library/CoreServices/Finder.app/Contents/Resources/English.lproj

sudo chmod 777 InfoPlist.strings
sudo chmod 777 .
open InfoPlist.strings

This will open it in a text editor. In that file, where it says "Folder" = "Folder", change it to "Folder = " Folder", where there's a single space before Folder. Save the file, and then Control-Option-click on the Finder icon in the dock and select "Relaunch". In list view, the "Kind" column text for folders should be updated to "Folder" with a preceding extra space.

Workaround 2: Path Finder
Of course, what would be ideal is to show the folders alphabetized first, and then the files alphabetized. For now, we'll just have to live with it, or rely on third party apps like Path Finder.

4. No function to restore Trashed items back to original location

After files have been deleted, there is no function to restore them all to their original locations as in Windows.

Update 12 Feb 2009: It appears OS X 10.6 Snow Leopard is going to finally provide the ability to restore trashed items to their original locations, known as "Put Back". Apparently, this functionality was available in OS 9 as "Put Away". Why they took so long to restore this function is beyond me.

5. Behavior of the window shade prompt from the title bar - no tabbing and resizing from the center

While I appreciate the attempt to attach a prompt to the title bar to associate each dialogue window more closely with the window being referenced by the prompt, there are a couple things that it misses.

Firstly, you can't hit the "tab" key, or any key for that matter, to focus on a different button (Yes/Not Now/etc.) by keyboard shortcut. (Note that, for confirmation prompts detached from the window, you can tab/spacebar to focus and select by keyboard alone. There's no logic for this inconsistency between detached and attached windows.)

Secondly, when dragging the corner to resize a larger dialogue window (such as selecting a file to upload), it resizes from the center, so beyond a certain point, the left side of the window is going to expand to the left beyond the edge of the screen. To see what I mean, open, say, TextEdit and try to save the document to pull down the window shade prompt. Now resize the prompt larger horizontally, and you'll notice the left side falls off the screen. What would make more sense is if the prompt resized from the left corner as an anchor, so that it's impossible for any of the prompt to fall off the screen while dragging, even if pulling the lower right corner to its maximum reach.

Additionally, because the window shade is fixed to the title bar, there is no way to move the dialogue box aside to reference content underneath for, say, deciding what to name a file, or which files to upload to a post.

6. Ability to resize windows from the four edges and other three corners

In OS X, you can only resize from the lower right-corner of the window by clicking and dragging a standard visual cue suggesting it can be dragged. This allows for the essentially border-less look of the windows in OS X, which works very nicely in tandem with the window drop shadows. The problem is that if that corner is ever out of view, say behind a window or off the edge of the screen, you need to first put that window in focus and move it within the viewport before being able to resize it. It arguably reduces the flexibility of resizing. For example, if I think the vertical size is perfect, I can safely perform a fixed horizontal resize in other operating systems. But in Mac OS X, you need some precision with your cursor to perform the same task.

This one's a common complaint of users crossing over from other OS platforms. You could try to argue that the drag handle on the lower right corner has a larger clickable area than a border, but in all my years using Windows, and seeing others use it, this is not really a real life issue, even for those with lesser mouse precision. The other main argument is that window resizing is allegedly an infrequent task. And while I've gotten used to the OS X behavior, the OS X use of window "zoom" instead of "maximize" leads to more resizing.

Update 2009 April: It turns out that it's rare for cases where the window drag handle on the bottom right corner will fall outside the screen edges. I've had applications like iTunes occasionally exhibit the issue, but given that how it was essentially impossible to manually reproduce the issue (I tried resizing on the larger resolution monitor in dual monitor mode, but it would auto resize appropriately to fit the lower resolution once dragged over.), I would say this is more a tiny annoying corner case than a widespread problem. Still, they are real world behavioral problems.

Workaround: For now, one of the best options is to use third party application Zooom/2, which allows you to resize from the inside of a window with a combination of clicks and modifier keys, among other things.

7. Files in folder re-sort immediately while renaming

When renaming a folder full of alphabetized files, the files sort themselves immediately after each rename. In Windows, the files do not sort until a folder reload, usually manually. This kind of sandbox working environment makes mass file renaming (such as with photos) much easier, especially if you want to visually reference the file you just previously renamed. In OS X, that previous file has already been thrown somewhere else in alphabetical order. Currently, the fix is to sort the files by "modified date" temporarily, since that part doesn't change when a file is renamed. However, you also sacrifice working in an alphabetized state, which you might have wanted while renaming.

When copying a folder to replace another with an identical name, it replaces files inside instead of merging the contents
In Windows, when you 'replace' a folder, it merges the different contents, and asks you if you want to replace when there's a duplicate. In OS X, when replacing a folder, it literally replaces the folder by deleting the original and copying over the new one. This is cleaner and truer to the 'replace' definition, but I still wish there were a merge function built into OS X. For example, I often merge two folders with an abundance of family photos. I want the ones that weren't there to be copied over, and the duplicates to remain untouched.

Workaround: To get around this, you have to sort by one of the columns in list view that will not change upon renaming. Columns like "Size" and "Date Modified" will do this, but of course, the files will no longer be sorted alphabetically by "Name" as you're renaming files.

8. Hitting 'Enter' key on a selected file renames instead of opens

In Windows, I was used to being able to navigate within a folder using the keyboard arrow keys, and then hitting the "Enter" key to open it. But in OS X, this same action puts you in rename mode (equivalent to F2 in Windows). To open the file with your keyboard, you have to use Cmd+O or Cmd+down (the counterpart to Cmd+up - one folder level up). Or you could always sacrifice keyboard shortcut speed and resort to the mouse double-click.

To me, assigning the "Enter" key to open a file and folder makes far more sense, considering that the "Enter" key is associated with initiating the execution of a task in many interfaces, such as submitting a form. But more importantly, opening a file or folder is a far more frequent task than renaming, which leaves me wondering why the more common task was assigned the modifier keyboard shortcut.

Workaround: Unfortunately, this doesn't seem to be one of the configurable keyboard shortcuts from "Preferences". There's a third party application that does the job, called ReturnOpen, but this one forgets to reassign another keyboard shortcut for rename in its place. Otherwise, I recommend using Cmd+down over Cmd+O because of the proximity of the right-side Cmd key and the down arrow key.

9. Holding "Shift"-click on the first and last items does not select a sequence of items in icon view (as opposed to list view)

In many user interfaces, holding the "Shift" key while clicking a first and second item will select everything in between. This is the case in Finder in list view, column view, and Cover Flow view, but not in icon view. And this is where it differs from behavior in Windows Explorer. Now, perhaps someone thought that since icon view is the only scattered view, unlike the list-based views of the other three, there was no file sequence analogy. Yet, Windows handles this just fine, whether it's on the desktop or within a folder's windowed view.

Workaround: Toggle back and forth between list/column/coverflow view and icon view to perform a Shift-click selection.

10. Cannot rename/delete/manage files in Open/Save dialogues

In the dialogues that appear when opening or saving a document, such as from a text editor or image editor, pretty much the only file management function you can perform is to create a new folder. In Windows, you essentially have a full blown Windows Explorer session in an open/save dialogue, so you can move, cut, copy, paste, rename, delete, or anything else possible with your files and folders. This way, you can, say, move or rename an original copy of the file by the same name before saving your file.

Workaround: (No suitable workaround found yet).

11. Desktop items have no option to sort by latest file added while icons arranged

There is no effective generic auto-arrange feature for your desktop items to arrange themselves neatly into a grid (without spacing and without re-sorting).

Or to put it another way:

In Windows and OS X, if you save new items to your desktop, it takes the next open spot on the desktop icon grid (under the condition that it's set to "auto-arrange" on Windows and "snap to grid" on OS X). In OS X, new icons accumulate from the right to left, and in Windows, from left to right. Now try moving a few files to a spot in the far from the cluster of icons where there are open spaces. (In Windows, switch off auto-arrange before doing this.)

If you want these outlying file icons to cluster back at the end of the original group of files, you can "auto-arrange" again in Windows, but in OS X, the closest action is to "Clean Up", which simply snaps them into alignment with the grid, but keeps them in their outlying areas.

I can see the logic intended behind keeping the file icons in place, but this can get messy if any of these icons start getting placed outside of the viewport. This happens two ways - either from bulk movement of files on the desktop, or from switching back and forth between external/dual monitors with different screen resolutions.

And why is it messy? With auto-arrange, it's very clear which files aren't visible in the viewport. You're not left wondering if there's a random file hidden outside of the confines of your currently visible desktop, without having to first auto arrange or check the desktop in a folder.

Now, both operating systems allow you to auto-arrange with sorting. So OS X does auto-arrange when you sort by name, date modified, etc. But the whole point was to keep the desktop unsorted. Arranging by "Date Modified" on OS X is the closest workaround, but "Date Modified" isn't always the same as which-file-just-got-dumped-onto-the-desktop.

Oddly enough, "stacks" in the dock in OS X Leopard do allow a sort by "date added" in addition to the existing "date modified" and "date created".

Between the OS X "Clean Up" option and auto sorted arranging, it's almost as though they forgot to throw in "auto-arrange-as-is".

Workaround: (No suitable workaround found yet).

12. Minimized documents in the OS X dock

(This item was updated in March 2009 to include Windows 7.)

I have mixed feelings about the dock itself, as many users do. There are many areas where it shines, though I'm not going to outline them here. My focus right now is on the subject of minimized windows in the OS X dock. In OS X, finding non-minimized windows is done by using Expose (dynamic proportionately-sized thumbnails with titles), which is a well-executed visual multitasking feature. There is a downside to this, which I'll return to in a bit. Non-minimized windows, on the other hand, only appear on the right-side of the dock as thumbnails with no titles unless hovering over.

Now take the Windows taskbar. Up until XP, it was solely text-based, and each document (minimized or not) had its own taskbar representation. Expose shines where the difference between documents is more visual (masses of images or webpages with similar names), whereas the taskbar shines more with documents are visually alike (text documents or command-line terminals with descriptive titles).

Expose still works great with the latter, given that you only have a few of these visually-similar documents open. But beyond that, it starts to fall apart, but not nearly as badly as a row of similar minimized document thumbnails in the dock with text labels upon hover. Furthermore, as helpful as Expose is, I still find it a bit odd that open non-minimized windows do not have individual document representation on the dock. But then again, the OS X dock solely groups these open documents by application. Just right-click on Finder or Safari or Firefox or TextEdit to see the list of open documents. This seems to be the route Windows 7 is taking, except with thumbnails, but I will get back to that too.

Unlike the OS X dock's group-by-application approach, the current Windows taskbar instead displays a taskbar for every document, regardless of application. Vista added thumbnails to mouseover'ed taskbar items, which is helpful, as well a 3D diagonally oriented Expose that displays the upper and left slivers of the preview (not as helpful). The closest thing Windows has is grouping by application after a threshold number of documents are open (in XP), which makes Windows a hybrid. And here's where I get back to Windows 7. I want the best of both worlds, and if individual document representation makes it to the Windows 7 release, and goes hand-in-hand with the grouping by application, this may be closer to what I've wanted all along.

13. Merge and Replace

This one has to be one of my top gripes with OS X. I left this for last because this one's a bit more complicated as to which one's doing it right. In Windows XP and its predecessors, if you copied a folder's contents into an older copy of that same folder, it would tell you, "This folder already contains a file named 'Photo1.jpg'.", with the file sizes and last modified dates of both of the duplicate file names. OS X only gives you the name, "Photo1.jpg", which leaves me severely handicapped in deciding whether I want to replace it with the newer copy.

The only redemption OS X has here is that they display an explicit "No to All" option through its "Apply to all" option for "Replace"/"Don't Replace". In Windows, seasoned users will know the hold "Shift" while clicking "No" to achieve the same effect, though I've wondered over the years why the "No to All" option wasn't displayed when the "Yes to All" option was.

Nevertheless, the OS X file replace issues do not stop there. The bigger problem is that if you're instead copying an entire folder to replace a folder by the same name (Folder1 into ParentFolder, which has a slightly different copy of Folder1), OS X will only prompt you to wipe-and-replace, leaving you with none of the contents of the original folder. Windows, on the other hand, copies over all files into the original folder, and prompts about any duplicate file names. This is effectively a merge. Windows Vista took this one step further and actually provided both the options of "Replace" and "Merge and Replace", easily one of my favorite features of Vista.

The argument behind the full wipe-and-replace by OS X Finder is that it's a true analogy to "replace". All right, but Vista corrected that by finally distinguishing between "replace" and "merge and replace". Sure, merging can be far messier, but if users are performing a manual sync of family photos or work documents in folders, they're in for a nasty surprise in OS X if they're not paying attention.

Workaround: Path Finder
Yes, Path Finder again. I can only hope Finder gains some improvements in the near future.

Update 12 Jun 2009: Screenshots of OS X 10.6 Snow Leopard indicate there will be some level of merge options. It's also worth mentioning that the UNIX command ditto comes in handy too if you're on older versions of OS X.

There are plenty of neat ideas in both operating systems. What I want to see is for people to get their preconceptions behind them, embrace changes outside their comfort zones, and pick out the cross-ideas that are being overlooked. It's in all of our best interests. Thanks.

-Gordon

Reviewing: Yahoo! Home Page Beta

2008-11-21T09:42:00.000-08:00

Reviewing: Yahoo! Front Page Beta
Slated for release: Early 2009
Review based on beta: As of November 2009

Visually, the top of the Yahoo! front page beta looks very odd, with the white clashing directly with the #637d90 color at the top-most part of the background gradient. This is a color contrast problem. Because of the background gradient, the #829cae 1-pixel border is noticeable on the lower part of the white content area, but not the top.

The shade of stormy blue in the background gradient doesn't really seem to match with the purple shade of the logo. In fact, the stormy blue sets a dimmer mood, and yet doesn't really hit the right color shade to feel professional or classy.

The site is also not using the purple favicon, and instead is still sporting the pixelated red Y! bang favicon they've been using for ages. This may seem trivial, but this is surprising because it seems like one of the easier tasks to implement, so it makes me wonder if it's an indication of a current lack of attention to detail.

And on the note of icons, the little icons under "Yahoo! Services" looks like pixel art, but that is fairly discontinuous with the slick icons used under "My Applications". Given that CSS sprites are being used, it wouldn't be much of a performance hit to use more modern icons. I hate to draw comparisons, but given that these are favicon-sized, see Google's favicons as examples. Those do not look like rudimentary pixel art.

I really want people to love what they see when they land on Y!'s new landing page. First impressions count, so I really want you guys to succeed and get it right the first time around. Make us proud!

Reviewing: Bleuprints

2008-11-21T09:40:00.001-08:00

Reviewing: Bleuprints
Review based on as is: November 2008

Author appears to have been meaning to do this for a while, possibly from his interest in user interfaces and usability. It explains why he felt so compelled to be active in reaching out to various companies and communities on how to improve the shortcomings of any given product with a UI short of being well thought out. Currently appears to be depository of such feedback.