Friday, May 29, 2009

Iconoclastic Friday

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.

Wednesday, May 27, 2009

The Ballad of OS X and Windows 7 Docks

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.

Tuesday, May 26, 2009

When Browser Tabs Spill

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.

Tuesday, May 19, 2009

The Desaturation of OS X


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.

Monday, May 18, 2009

We're outgrowing our tabs.


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.

Saturday, May 16, 2009

Unscripted Friday: Internet Sharing Toggle (Applescript)

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

Friday, May 15, 2009

Unscripted Friday: Hot Corner Toggle Off (Applescript)

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)

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

Monday, May 4, 2009

Thoughtfulness Zen of the Moment



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.