OOFILE | Downloads | Purchasing | Press | Services | Company Information | Soapbox| References | F.A.Q. | HOME

Back to Soapbox index




I'm going to make this more of a blog style page, or at least date opinions within subsections, to show the evolution of the OS (and maybe my gradual habituation).



Today I moved from an iMac 450 DV+ to a G4/500 with 50% more RAM and dual monitors. It will be interesting to see how the file handling pain changes with lots more screen.

Kudos to Apple - I bought a 2nd-hand Mac with no drive and just moved my iMac 80GB over and rebooted. That's a processor change, different motherboard, different monitor architecture... I can't imagine even trying this with Windows or Linux.

Overall UI Points

Excellent piece in The Register

If performance impairs the usage of the machine, then that's bad UI. And performance on OS X is really NOT GOOD... there's no big flaw so obnoxious it's enough to cause a revolt , but it's felt like a constant hindrance, and the annoyances add up.

10.2 and File Open keystrokes

I wish I could avoid upgrading to 10.2 because I am furious that Apple still haven't fixed the File Open bug with keystrokes. In Navigation Services (ie: the File Open and Save dialogs in 8.6 through to OS 9) you can type a few keystrokes with the focus on the list to jump quickly to a file. This is now a habit for me and many other experienced Mac users I know.

In OS/X this has never worked. It seems that each keystroke is immediately reacted to in the leftmost of the browser panes, not the current list you're looking at (try it). As a habitual touch-typist I type several characters before even realising and my browser has jumped to a totally random location.

Update: 10.2.5?

Slowly, this aspect gets better. Something which makes me think it's not working is that the tab order in the File Open dialog is broken! The list doesn't have focus on entry to the dialog, the edit box for typing a pathname has focus. That kind of makes sense but it is 5 tab presses to move focus to the list! (No, it's NOT a linear layout issue - tabs jump all over the screen).

I still think the behaviour if you click in a given pane in the browser is unintuitive. The focus on panes is not clearly indicated and you have to click on a selectable item in a given pane to move across to it. That sounds sensible but doesn't work practice. I want to click in a pane to make that my current list and then start typing. I don't want to have to scroll a pane until I find something I can click on, click on a folder name and then be able to type - that is so much work that I may as well keep on using the mouse.


I realised two things today.

1) behaviour in Cocoa applications is a lot smarter - a Cocoa File Open panel is not the same as the Carbon one. For example, typing in the Go To box will scroll to a matching filename in your current location. I realised this because I've adopted habit patterns from the Cocoa-based software I'm writing for a client and became confused when BBedit didn't behave the same way.

2) Even the Carbon-based File Open mentioned above as being improved in 10.2.5 is swiftly habituated - I did some compatibility testing on a 10.2.3 box and very quickly became frustrated by not being able to type at all in File Open boxes!

Translucent Menus

10.1 opinion (10.2 fixed it, making menus much less translucent!)

Yes they are pretty, when you are demoing and using big fonts.

I watched myself and a fellow programmer give up on CodeWarrior's popup function menus and use the search facility last week because we couldn't read the menus. If you popup a small menu on top of a window full of text, the resulting mess is ridiculous. Maybe application authors need to add a hack but I think that menu translucency in general should cut out below a given menu size.

We need a Professional UI

late 2002, still current as of lots more experience in early 2003

This was a quick insight the other day - I don't really think Aqua is a professional UI. I think MacOS/X has the makings of a great professional operating system but we need changes on top. The main reason for this thinking is that Aqua seems to make it harder to manage deep hierarchies and lots of documents.

The file browser hides where you are - try working within a couple of directory hierarchies that are identical apart from a name 5 levels above you.

On an iMac, open a window with 200 documents in it. Now compare that experience with Classic.

Losing the Apple Advantage - the Subtle Power of File Types

File type metadata has been one of the subtle and brilliant differentiators between the Mac and Windows for over a decade. If the direction in OS/X is not reversed, we lose this distinction.

Please read the excellent ArsTechnica article.