I recently started maintaining my digital photo library outside of iPhoto (checking off the copy photos into iPhoto Library option in the preferences) because it was annoying how in order to find any photo you had to launch iPhoto. Subsequently, I had moved the location of my external archive, and just noticed that although iPhoto still displayed the thumbnails of these photos (in cache), it could no longer find the originals! I finally figured out how to resolve this without resorting to a fresh library…

While a few previous notes outlined the benefits of various third party applications and add-ons, I have actually become frustrated by WindowShade for its bugs in the minimize in place feature, and the lack of updates for finderpop.

Saw this article about Jef Raskin’s son’s ongoing attempts to implement his father’s ideas, over at : http://macenstein.com/default/archives/509

Apple’s Dock is a great all-purpose tool for basic and intermediate users, but it surely falls short when working with many open applications, minimized windows, or folders. If you ever run into these situations you will quickly find yourself a mini Dock with small, hard-to-read targets.

I have written about decoupling window minimization from the Dock before, but as Unsanity has not perfected their C-level performance on WindowShade, I will be using the Apple Dock for minimizations.

My Dock’s primary limitation is folder access. I want to access too many folders either from other applications or in general not while I have an open Finder window. Quicksilver permits fast key-based access to my filesystem, but sometimes, especially for drag-and-drop, mouse-based access is superior. Finder windows have that neat sidebar, but again, I don’t always have Finder windows sitting open, and don’t want to. In fact, I’d like to use Finder windows as little as possible; it reeks of individual files with description-less icons and their silly filenames. Even if I did settle for the sidebar, you can’t right click to delve into a folder.

In an effort to improve mouse-based folder access, I have revisited DragThing. Mouse-based UI is all about easy targets. As I have described previously1, the screen corners serve as the best targets. Since these are taken, we move on to the next best: screen edges. Now how can we put them to their best use?

[Enter DragThing…]

Current Desktop setup with Apple Dock and DragThing

While searching for how people use their screen corners in OS X, I was very surprised to stumble upon a Mac OS X Hints forum comment regarding the standard Apple screen corner triggers available from the Dashboard and Exposé System Preference:

As of 10.4, however, it is also possible to add modifier keys to the hot corners in the Dashboard and Exposé panel of System Preferences. Just hold down Shift, Control, Option, Command (or some combination thereof) while selecting an option from the list.

This may be useful if you find yourself accidentally activating Dashboard, Exposé or even the screen saver when you flick the mouse to a screen corner.

Note that when a modifer key is set, you must have the key pressed before you put the pointer in the corner; it is not enough to hit the modifier key as an afterthought.

I can’t believe I never tried that before. This tip nicely prevents the user from accidentally triggering a screen corner action, which I’ve noticed can happen quite frequency if screen real estate is limited or if the user doesn’t have fantastic control of the mouse/trackpad. Newbie bashing aside, anyone can easily trigger screen corner actions because of Fitts’ law. Your cursor wants to find the corners.

So I’ve been using Unsanity’s WindowShade utility, taking advantage of both traditional windowshading and minimizing windows in place. I have started clumping mini-windows together, and I just realized that what is now available to the Mac community is a 2-tiered version of Raskin’s scale-free desktop, aka the Zooming User Interface (ZUI). Not bad for a start.

A nice little two-tiered Zooming User Interface.

The key aspect of WindowShade that permits the analogy is maintanance of spatial relationships. That is, I minimize a window in place, position it where I would like, forget about it for a while, return to it but restoring the window to full size, work a bit, then reminimize. Now doesn’t that window shink back down to the exact same place that I had put it before? Fantastic.

A little update. I just noticed on the Jef Raskin web site under the Archy FAQ, that the authors do intend to use the Command key as a replacement LEAP key. How about that.

A page of links…

• Ars Technica “About the Finder…” article (John Siracusa)
• Live Journal discussion of the spatial finder
• The Mac Mind discussion
• John Gruber article

There are so many ways to design a graphical interface to a computer, one might often get lost in the process. I do at least. Thus one would like to determine a general and consistent set of guidelines for an interface.

Update: 7 September, 2005

Tog offers yet another take on Fitts’ law, and how it should be implemented in OS X. Note this article was written in 2000. Perhaps what bothers me most of all is that OS X offers no way of getting the trash can into the corner of the screen, although NeXTSTEP provided this as the default:

Note the Recycling Bin at the bottom right corner, making it easy to toss files. (photo courtesy of guidebookgallery.org)

Hello,

Perhaps you have received this suggestion before or thought of it yourselves, but I will attribute it to Jef Raskin. The idea would be to allow a dynamic zooming or scaling of windows that have been minimized in place. I see potential in your implementation of minimize in place, because windows remain in focus, and thus are editable. However, even at maximum zoom size, it is way too difficult to read text and other objects in these small windows. Thus I suggest you allow the user to scale a window to arbitrary size, controlled simply by how long the user holds the mouse button on the minimized window. This would allow one to keep an active mail inbox on screen, but at a small size, or the ability to monitor status windows at small scale - something that is possible at 128x128 pixels, but again, text cannot be read.

Also, I would suggest that menu and Dock commands that select a window that has been minimized in place should “un-minimize in place” the windows, since currently it is nearly impossible to distinguish when a minimized window has focus.

Thanks for listening, Dan Simola

The simplicity of the Apple UI has its merits, but there are a few major issues that have historically plagued the Mac OS and which deter from an otherwise enduring and endearing human-computer interaction.

Hi,

A few suggestions for how you can improve XCode:

1) option of showing invisible characters - every other major text editor has this option (BBedit, SubEthaEdit, emacs, etc). There is no reason XCode shouldn’t have it as well

2) Ability to split windows vertically in addition to horizontally - you guys are marketing your widescreen monitors - why can we only view two files on top of each other?

3) Code collapse - I have seen this on a growing number of text programs (PC editors and Kate for KDE) - you can temporarily collapse scope blocks/loops in your code, such as functions and for/while loops, etc

4) Separate the XCode text editor from XCode itself - XCode is really a project management program. but often I just want to open a text file and program in perl or python. I would rather just use XCode for this, instead of switching between XCode for projects and BBEdit for scripts. Apple really, REALLY needs to have a solid text editor, above and beyond the capabilities of BBedit even, and you already have the program in XCode. You just need to separate the text editor from the project manager.

Thanks for listening,

Dan Simola

Looking back at my thoughts, I see I have resolved all of my concerns by using the fantastic editor TextMate.