Solipsism Gradient

Matt Gemmell has posted source code for a trick to stroke inside a NSBezierPath. The default stroke lies on the path’s boundary, which generates some awkward situations with sharp corners.

We came up with this during a long and fruitful discussion of options (via iChat) for Matt’s upcoming Pie Chart control for Cocoa. Watch that space…

Update: forgot to say that there’s more good Cocoa source on this page. Enjoy.

Still more comments on the Ronco Spray-On Usability debate, itself (just to remind people) sparked by this ESR article.

Matt Gemmell, the Irate Scotsman, weighs in with a long and reasoned article:

UI must be designed from the start. Interface considerations infest your design choices, like it or not. Functionality can rarely be completely divorced from the controls which will trigger and modify it. Output must often lead to feedback for the user. The core modes of the application entirely determine the user’s type of experience. Like it or not, we have to realise that as much as it might offend our software engineering sensibilities, for the user the UI is the software.

…Hopefully it’s clear that interface and interaction design is a fine art, and is incredibly difficult to do well. It requires a huge amount of knowledge of your software’s platform, purpose, target market, and indeed of human psychology both in general and in the specific field of human-computer interaction. Certainly, it’s not for the faint of heart, and nor is it to be rushed or attempted without due experience and consideration.

Likewise, Rui Carmo at The Tao of Mac also writes at length:

…usability is a lot of hard work spent on ironing out even the smallest wrinkle. It is not something you “spray on” after the fact. It is either part of the design from the outset, or it isn’t. No amount of paint will disguise hard, unforgiving edges.

Usability has no tolerance for hard edges – the only kind of edge users notice is the bleeding edge, and guess what, they don’t like it.

Both are extremely recommended reading for interface designers.

Stan Kelly-Bootle (who posted a comment here some days ago) has a new Son of Devil’s Advocate column out – it links back to this humble weblog and threatens to do so again next month!

Stan also reprints, as usual, his “Devil’s Advocate” column 16 years ago in Unix Review magazine, where he attacks one of my pet peeves – the harmful punctuation-within-quotes convention:

And so it comes about that the author’s

If X$ is set to “x”, the string Y$ is set to “end”.

is usually mispublished as:

If X$ is set to “x,” the string Y$ is set to “end.”

This, of course, is “no big deal,” until the billion-dollar space probe reaches the wrong galaxy. (Wasn’t that a misplaced Fortran colon?…Ed.)

I can’t understand why this nonsensical and potentially harmful convention still survives…

I seize the occasion to plug, again, Stan’s magnum opus (or at least my favorite of his several opuses? opi? opae?), The Computer Contradictionary, 2nd Edition, which as usual is on my desk as I write this. Now… where’s the much-overdue 3rd Edition…?

The Advanced Developers Hands On Conference, for the first 18 years known as MacHack, will take place on July 21-24, 2004, in Dearborn, Michigan, USA.

I’ve attended 3 times in the past and written several papers for it. As most of you know, I heartily endorse the conference – it’s smaller, more concentrated, and much more fun than WWDC. The US is off my travel routes for now, so I won’t be able to attend – but I plan to publish a paper in absentia.

I just saw on Jon Rentzsch‘ site that he’s calling for MacHack stories by previous attendees… and he kindly linked to here, too. Thanks Jon, I will contribute some stories in the near future…

Quick update.

A few hours after posting the lamentation below I found out how avoid the text cursor. Both selecting and editing have to be disabled. Turning editing on (as I do, briefly, when inserting new stuff) turns selecting on again.

Turning all that off messed up some other functionality but I’m happy to report it was all easy to fix, and I now seem to be where I should have been a month ago.

Ah yes, and the contextual menu itself turned out to be a piece of cake… most of the code from Zingg! and Nudge could be reused.

So I hope to have something publishable Real Soon Now™…

This will take some explaining, and may not make much sense unless you’re a Cocoa developer. So feel free to skip this.

In early February – about a month and a half ago – someone asked an obscure question on the developer lists and, by chance, I had a code sample that did almost exactly what that guy wanted. So I sent it to him. So far so good… warm fuzzy feelings all around…

…it turned out that this gave me an idea for a new contextual menu for the Finder. So I thought, the new CM will be just that code sample with some padding, so let me start first on the application to configure stuff for the CM. Shouldn’t take more than a week or two.

As usual, I started out by designing the application icon first, which sidetracked me into a long investigation about the habits and aspect of a certain mammal. That done, I decided the user interface should consist only of a list of items. Fixed-size items each consisting of a few icons and a name. Of course, the first choice was using a NSTableView.

It turns out that the icons were too dissimilarly sized, so a table with one row per item showed too few items, and the UI looked ugly. So my next idea was to use a NSMatrix of cells, each cell with the subitems artfully arranged. This looked better, but…

I soon noticed that a NSMatrix operates with rows and columns of cells (duh!). I wanted a view that adapted itself to the window size the user wanted, but having to scroll both horizontally and vertically was ugly as soon as there were more than a dozen items. So I messed around for a couple of days with adapting the number of columns to the window width, and couldn’t get it to work reliably.

So I decided that I wanted something like iPhoto’s browser window, where there’s only a vertical scrollbar, and the view adapts instantly to width variations. So I started to write a custom view that would be inserted into a NSScrollView and do automatic layout of as many items fit into the current width.

After a week of this it was almost working… however, I was getting some strange behavior in certain conditions; when the window was resized very rapidly, or when the scroller had to appear during insertions, or, and so forth. It appeared that I wasn’t managing the communications between the NSScrollView and my own view correctly under all circumstances.

So I was trying to trace when NSTextViews communicate with their NSScrollViews, when it hit me that I could simply use a NSTextView and insert the item as specialized NSTextAttachmentCells. Bliss! This would give me all the required scrolling and resizing behavior automatically, and I would just have to write the specialized cell code and disable some of the NSTextView’s functions… it wouldn’t do to allow the user to insert actual text there, for instance.

There I went off into another two-week-long detour of writing and debugging the cell code. My cells consist of several subentities which are actually NSViews themselves – images and text – and they in turn have to be editable, selectable, and so forth. I’ll leave the saga of how I finally solved this for another post – it involves adding a subview to the NSTextView, something not normally done.

So after that I had to decide which text behaviors I wanted to leave in the NSTextView. No editing, OK. Selecting multiple items with the text cursor? Hmm… it looked interesting. The user could select several items and drag them somewhere! Perhaps for backing up the items into a Finder window – or to make a list of his items into a text windows. I happily set to work implementing routines for copying and dragging the current selection in various formats, which in turned allowed me to exercise my code under unforeseen conditions and decide how the items would be stored and saved.

Then when it was nearly finished I started to run into snags again. Suddenly I wanted to select two non-adjacent items, which NSTextView doesn’t allow. I changed my system-wide selection color (for a non-related reason) and suddenly selections in my NSTextView began to look ugly – worse, the way selections were made called the user’s attention to the fact that this was a NSTextView with much reduced functionality. This is never a good idea; it leads the user to expect certain things to work, and when they won’t work, it’s a negative experience.

So today I disabled all text selections wholesale, as well as all related functionality. This enabled me to throw out several chunks of code and someday might allow me to implement discontinuous item selections, too. So the NSTextView really just handles reflowing of my item list, and all the remaining functionality is shuffled off into my specialized NSTextAttachmentCell class.

So far so good; I expected to finally freeze my UI and get to work on the shareware related aspects – registration, trial expiration, and so forth. However, I still have to extirpate the final clue that I’m using a text view, namely the I-beam (text insertion) cursor. So far I’ve hammered away at this for the whole day without finding a solution that works all of the time.

As usual. 😥

Stay tuned…

I actually posted Nudge 1.01 some days ago, but there were only minute internal changes… and a new installer, which still looks much like a folder alias. If 1.0 is working for you, no need to download 1.01.

The new installer is much more intelligent, automatically routing a CM to the right folder, and creating it if necessary. If you’re suspicious about installers, double-click the installer and it will open the right folder for you, so you can move the CM manually.

This installer (or variations thereof) will be gradually adopted by my other products, and I plan to publish the source and make it available to other developers…

The Mac Software Business mailing list I referred to below is getting some interesting posts.

Jiva DeVoe alerted to this post on A Shareware Life (itself a very interesting site):

My company has received the following letter from a law firm claiming to have a client that has patented computer solitaire. And by extension, all computer card games.

I am not kidding.

…

The earliest date on any of these patents is a filing date of Dec 3, 1996 (it has some kind of amendment that says Jan 19, 1996, but whatever). Solitaire has been around for hundreds of years, and computer implementations have been around for decades. Windows Solitaire dates from around 1990. Most importantly in this case, our solitaire games were first released in 1995.

Wasn’t it Robert Heinlein who, in his Future History, mentioned “The Day They Killed All The Lawyers”? There’s more discussion about this at Dean’s World, by the way.