TFF & Its 'List View'

Do the research first. And never play with matches.

Get It Try It

Pierre Igot runs a blog called Betalogue. He's been mentioned here before. And before that. Pierre's submitted a number of bug reports to Apple. He's not a happy camper with Leopard. Certainly some of the issues he's discovered raise serious concerns about what is actually going on in the greater San Francisco area of late.

But Pierre's latest foray is a bug of a different colour. Pierre works at 'Mac technical support', at web design, at graphic design, and as a system administrator. And Apple's ADC tools are free and accompany every OS DVD. So there's no excuse.

It's sad but true. Ever since Apple switched us from the classic Mac OS to Mac OS X, the list view mode in the Finder has been treated as a second class citizen.

Yes the table view (or the list view as Pierre Igot incorrectly calls it) is a blithering mess. But this 'switch' contention is way out in left field, not in the same ball park, and akin to sailing a dingy on an ocean without a rudder. David Pogue, Chris Stone, and especially this site have been pointing out the lack of continuity for years. There's no 'switch'. None. These are two distinct and totally unrelated operating systems. And that's a Good Thing™. Get over it.

There are still daily reminders of this class struggle in the Finder in Mac OS X 10.5.

Class struggle? CLASS STRUGGLE? Oh goodness.

Say you are viewing a folder's contents in column view in the Finder and you click on one of the items to select it. As this screen shot indicates, you can actually select the item by clicking anywhere in the line formed by the item in the column view list.

The screen shot unfortunately does not reveal if this is a browser view or a table view. Not that it need matter much but the distinction is important. And clicking anywhere in the line to accomplish something is not much more than a no-brainer: no matter if it's a browser view (NSBrowser - a NeXTSTEP class) or a table view (NSTableView - a NeXTSTEP class) you're namely dealing with the following.

Both 'controls' as they're called are actually 'composites' - controls that contain other embedded controls. Such is the benefit of object orientation.

Taking the table view: the table view class itself works with data source objects representing the rows in the view. Each row consists of a number of columns belonging to the class NSTableColumn. And the actual cell in each column of each row is a member of the NSTextField class.

Clicking on a row unequivocally means clicking on a row. You're going to be able to click anywhere in the row to select it. This is just the way it works. Get over it. If you don't like it then come with a better overall engineering design, thank you.

Of course even the above is variable and configurable. Table views can be set in their NIBs themselves to allow (or disallow) column selection, empty selection, multiple selection, and so forth.

Programmatically they can be set to allow (or disallow) selection on any one given row. This is painfully obvious to even Cocoa neophytes. One can't draw too many generalities here.

On the other hand, if you want to click on the item a second time in order to make the name editable, you have to click on the name itself. This makes sense...

This is a design issue. True. Igot says he thinks this makes sense. In reality it doesn't matter.

Now since the logic here is that the empty area on the right hand side of the item is a proxy for the item itself...

How does Igot pretend to divine the logic? Was he in on the first days of the development of the NeXTSTEP AppKit classes? Did he sit with Avie and chew this one out? Hardly. There is no logic Igot can be aware of. The simple fact is the one is a row which is clickable and the other is a cell in a column in that row. End of story.

Since clicking on that empty area in list view cannot possibly serve any other purpose, it should select the item itself, even though I am not clicking on its name.

Nonsense. Avie didn't know Igot. The logic is in the engineering and not in how one isolated end user decides to impute things.

the empty area serves as a proxy for the item itself

No it doesn't. The 'empty area' isn't empty at all - it's part of a row. And the user is selecting a row. Please.

But now consider what happens when I attempt to click and drag on this empty area in order to drag the selected item...

Yes of course. Because even this is programmable. The table view can namely be configured to disallow vertical drags. You have to in such case select first, wait half a second, and then drag horizontally (or mostly horizontally).

Where is this coming from all of a sudden?

Oh please. 'All of a sudden'? It's been part of the NeXTSTEP classes for over twenty years. It's not all of a sudden.

setVerticalMotionCanBeginDrag:

Sets whether vertical motion is treated as a drag or selection change to flag.

-(void)setVerticalMotionCanBeginDrag:(BOOL)flag

Discussion

If flag is NO then vertical motion will not start a drag. The default is YES.

Note that horizontal motion is always a valid motion to begin a drag. Most often you would want to disable vertical dragging when it's expected that horizontal dragging is the natural motion.

Available in Mac OS X v10.0 and later.

Not only is it inconsistent with the behaviour in column view...

By 'column view' our noble Pierre obviously means browser view. Someone who claims to be a Mac support techie and system administrator should be aware of this. But Igot apparently is not.

But consistency isn't something sought after here: these are different classes and different controls. The browser view can give you one column per row (and otherwise is way different in many many more ways) whilst the table view can give you as many columns as you want (even though Igot seems to think it was created for one column only).

It simply does not make sense.

Oh it makes sense alright. The correct formulation for the above is 'I can't make sense out of it'.

The inconsistency between the behaviour in column view and the behaviour in list view means that it is impossible for the user to get used to it.

It's time to call bullshit. Pure plain and simple. More words aren't needed.

How is the user supposed to add to his 'muscle memory' for mouse movements a mental check to first determine whether the window is in list view or in column view? It is impossible.

This seems to be the 'Igot Fallacy' - namely that all users are in the same class as Igot. It's really a shame to see someone who claims to work to help other users be so totally out to sea. It's a crying shame.

I suppose there is a logic to this variation depending on the direction of the dragging - and one that is somewhat similar to the weird behaviour when dragging tabs in the tab bar in a Safari 3.x window.

Now after ignoring the ADC documentation (see above) we're in addition equating NeXTSTEP classes with overrides Hyatt and his people put into a single application? We've lost it, totally lost it in such case.

I don't have much hope.

And neither can we who are involved in the classes themselves. But let's back up a bit. Let's look at this from the perspective of someone in the middle, halfway between Igot and the interface itself.

The Stuff Dreams Are Made Of

There's a common misconception that suits sit around in conference rooms and hack out design guidelines before any of the actual programming begins. That systems such as Apple's HI guidelines or IBM's seminal Common User Access or Microsoft's desultory Consistent User Interface are sketched out in toto before the work actually begins. They're not. They're written after the fact to explain what's already been done.

No one cares in the initial stages how people are going to react. In the initial stages no one knows if they'll react at all. One takes what's available and makes the most of it. And then and only then can the next generation come along and see what can be done with it.

Computerisation isn't about suits dreaming up ridiculous scenarios programmers laugh at - not to say this doesn't occur from time to time. But every time it happens it always ends in an abortive fiasco.

Computerisation as everything else creative is about 'thinking inside the box' - taking advantage of available technologies and finding ways to apply them. The word 'application' to describe something that uses such technologies is neither a misnomer nor an accident. That's exactly what applications do: they apply given technologies that already are for all practical purposes etched in stone.

Pierre Igot's dilemma is he's caught in a web of misunderstandings. It's important for end users - and Pierre Igot despite the claims of his CV is nothing more than an end user - to continue to absorb and to familiarise himself with the new system from as much input data as possible. Without whinging about older systems long since forgotten.

Everything Igot's written about Mac OS X technology is based on sloppy misunderstandings of how this technology actually works and is constructed. This isn't something the system architects wanted. But it's something Pierre Igot could have avoided.

For 'Mac technical support' and system administrators the path starts here.