Additional iCal suggestions/observations

Through further use of the recently released iCal 1.5.1, I have come upon several more interface issues and one rather simple but possibly very useful idea for a future version.

  • The url pop-up menu in the Info Drawer reads “Go to Location” while the same item/menu in the Address Book reads “Go to Web Site.” Perhaps Apple should hire me as their official Interface Nitpicker.
  • The “location” input area that appears immediately beneath the title of an event or item should behave in the same manner as the address entries in Address Book, allowing the user to locate a map or driving directions online using a pop-up menu with menu items for those two services. The “From” address would be pulled from the user’s Address Book card. As an aside, the “Directions” option should be added to the Address Book as it is not currently an option. The current implementation simply shows a map of the address selected. If this were to be implemented, the input area would need to be structured with specific fields for street, city, state/province, and ZIP. The rather roomy “Notes” field could be compacted to make room.
  • Rendezvous calendar sharing. A simple checkbox in the Info Drawer when a calendar is selected could determine whether or not a calendar was shared on the local network using Apple’s implementation of the ZeroConf open standard. Setting write permissions would make it all the more useful. Yes, you can currently publish to a WebDAV server (including .Mac), but that requires configuration of or access to such a thing. Shared calendars would appear in the upper left calendar list in a “Shared” container of the sort used for iTunes sharing. A low bandwidth service such as calendar sharing could easily be handled by any Mac running OS X so I don’t think there are any real performance considerations.

Getting from point A to point B in Safari

Safari has no way (that I have found!) to switch between the bookmarks collection and the content display panes using the keyboard, even with Full Keyboard Access enabled in the “Mouse and Keyboard” preference pane.

Another annoyance with Safari: the address field does not allow for click-through dragging. To see what I mean, try dragging a link from the address bar to a new mail message or chat window which overlays the Safari window. Fun times! This should be a simple matter, but instead you get to play ping-pong between applications to position the target correctly, then perform the actual drag operation. Blech.

Apple has a fairly loose click-through guideline, recommending only that potentially destructive and difficult to undo controls (delete buttons for example) not be responsive unless the application is frontmost. Since this is not a destructive action, I cannot understand why they chose to implement it this way. My thanks to the OmniGroup, who implemented this handy feature in OmniWeb.

iCal interface problems

Having updated to version 1.5.1 of Apple’s iCal, I see a few things that could be good additions or changes for the next release.

  1. When dragging the resize bar between the calendar list and the mini-month pane, the double arrow cursor does not indicate when it cannot be dragged any further toward the top or bottom. This is generally indicated by the double arrow cursor changing to a single arrow pointing in the direction in which the column or row can be dragged. Try dragging a column in iTunes or in the Finder’s List view to see this in action.
  2. The resize bar between the To Do list and the calendar has the same problem as above, only horizontally.
  3. The middle button at the top of the mini-cal section is rather cryptic in function. A diamond? What the hell does that mean? The button brings the user to the current day in the main calendar, but this icon gives absolutely no clue as to that fact.
  4. The small blue calendar button in the lower left shows and hides the mini-months. This is not a poorly designed widget per se, but why not reuse the widget from iTunes (which shows or hides the artwork pane), building button familiarity across applications?
  5. The search scope of the input query cannot be specified, and the scope is not indicated in any way. The label simply reads “Search.” This does not indicate if only the currently selected calendar, currently checked calendars (the actual behavior), or the central main pane content will be searched.
  6. The lower left-hand “+” button in iCal is slightly different from the one in iTunes. The color is lighter and the symbol itself looks to be a bit smaller.

None of these are showstoppers, but details are important!

While switching between iTunes and iCal, I noticed that iTunes uses the hand icon rather than the double arrow cursor when the cursor is over the resizable panes. Initially I thought this was a Carbon vs. Cocoa difference, but the Finder uses the double arrow cursor. Odd. Developer choices, I guess.

Querious!

There are some differences between the implementations of the search field in the Finder, iTunes, Mail, and Safari. Consistency being one of the hallmarks of Apple software, I think this ought to be fixed.

Based on the screenshot at Apple’s 10.3 Finder info page, it looks like it displays the scope of the search in the inactive input box. I believe the magnifying glass menu is used, as in Mail and iTunes, to change the scope of the search.

iTunes displays a magnifying glass on the left of the search field which, when clicked, allows the user to select what field they would like to search: all, artists, albums, composers, or songs. The type of query to be performed is listed immediately beneath the input box. Because of the iTunes interface layout, placing the query type label beneath the entry box rather than inside is acceptable because it does not use additional screen space. With that said, it is still not consistent with other applications.

Mail uses the menu to allow users to select the field and scope of their queries; the entire message, subject line, to or from in either the currently selected mailbox or all of their mailboxes. When the search field is not in focus, it displays the name of the field selected for searching (message, subject, etc.).

Safari takes a different approach, using this left side magnifying glass menu as a history menu, displaying previously run queries when selected. When not focused, it also displays a text label for the type of query to be performed (always “Google”).

While they are both functional, the method used by Safari assumes that Google’s general search will always be the search engine used. The implementations in Firebird and Camino are open to extension, allowing the developers to add engines without having to change the existing UI.

The problem is one of displacement: if Apple ever adds the ability to select from multiple search sites/types, what happens to the history feature? I believe auto-complete could be used in this case. It is used in website search input boxes, so why not in Safari’s Google Search?

Alternately, the UI could be substantially overhauled. The current UIs are designed so that the option to select the engine is placed first. Users probably do not think of what engine they want to search first – they have a query in mind, not an engine. Placing the search engine selection menu on the right of the input dialog makes more logical sense to me, better reflecting the thought process of using search services. Also, rather than search queries being submitted only after the user hits the Enter/Return key, why not automatically submit the query once an alternate engine is selected?

Editing Note: this entry was revised on October 7/8 to include information on the 10.3 Finder and Mail’s search field interfaces.

Tweaking OS X

There has been some discussion (Tim Bray, Eric Meyer, MacDevCenter) of how people configure OS X to make it more usable for them. I trim down the Dock’s contents and add several things:

  • A-Dock
  • While it doesn’t have the massive number of features of DragThing, A-Dock gives me what I want: a separate Dock for folders and a way to quickly reveal the desktop. I place this in the lower right corner of the screen to take advantage of Ye Olde Fitts’s Law.

  • F-10 Launch Studio
  • This allow me to quickly launch any application without using much screen space unless it is activated with either the keyboard or by a hot corner (Fitts’ Law again). Applications can be organized into groups, which can be further organized alphabetically or by user preference. I have sent them some feedback asking them to add the ability to define row or column groups, depending on user choice.

  • CornerClick
  • I quickly miss the features this offers when not installed on a machine. It fits so easily into my workflow and is so simple, it feels like a natural extension of the interface. I imagine Exposé will make some of my settings redundant, but I’ll probably find new uses for it.

    I keep my Dock pinned in the bottom left corner (no magnification, no bouncing), populated only by the few applications that I leave running constantly such as Safari, iChat AV, iTunes, Terminal, Kung-Log, and Camino. These are never displaced by applications which come and go due to their left alignment. It makes the Dock far easier to work with.

    The corners make for easy targets, so I use them quite a bit.

Furthermore . . .

Why does iTunes not remember the position of playlists that are opened as separate windows?

Also, Excel would benefit from cursor coordinate highlighting – the column and row which the mouse cursor was in should highlight slightly to make it easier to determine precisely what cell you are in.

It's blue, it's an address . . .

But it’s not a link! I am rather tired of Read Me and help files under OS X that have Web and e-mail address links colored with the default browser link colors, but do not function as actual links. If you are writing a help file in which addresses will be displayed, write it in HTML. I don’t know if the situation has changed any in 10.3, but Apple really ought to make it possible for documents authors to include working URL links in RTF files.

Safari, Camino, and OmniWeb’s “Open URL” services are handy, but not nearly as simple as clicking on a text link.

Attack of the filename dependency!

A friend was having trouble installing the OS X version of Mozilla Firebird. This process is usually extremely simple: double-click the compressed file (assuming your browser or compression utility doesn’t handle such things automatically), mount the disk image, then drag the application to wherever you would like it to reside.

I was perplexed as to what the problem could be until he pasted the text of an error message into an IM: “the document “mozillafirebird-0.6.1-mac.dmg.g is an unknown format.” The .tgz file extension had somehow been screwed up. Adding the t z to the opposing sides of the g fixed the problem and made the file usable.

The moral of the story is that file extensions are an archaic, oftentimes perplexing way to determine file types. MIME types or T/C codes are much more transparent to end users. No user should have to guess as to a file’s type in order to access it. While there is no perfect typing system, filename extensions are certainly one of the worst.

iTunes stream browsing, nested playlists

An interface for Internet audio streams more like the Library and Music Store browsing interfaces is one of the few things I would change about iTunes.

Two panes spanning the full height of the window – genre in the left, station in the right. This would allow for easier categorical browsing.

The downside would be that you couldn’t view multiple stream categories at once. That capability doesn’t seem all that useful, so I don’t think it would be missed.

Also among my few feature requests is nested playlists. Having a sizable collection of music , I have several playlists of one genre, divided based on year. I’d like to be able to shove them into a top-level container labeled with the genre name, allowing me to keep them together without being constantly displayed. I understand the desire to keep things simple, but we don’t all have the luxury of monitors running at 1600×1200.