Structure and Interpretation of Computer Programmers

I make it easier and faster for you to write high-quality software.

Tuesday, March 2, 2010

How to hire Graham Lee

There are few people who can say that when it comes to Cocoa application security, they wrote the book. In fact, I can think of only one: me. I’ve just put the final draft together for Professional Cocoa Application Security and it will hit the shops in June: click the link to purchase through my Amazon affiliate programme.

Now that the book’s more-or-less complete, I can turn my attention to other interesting projects: by which I mean yours! If your application could benefit from a developer with plenty of security experience and knowledge to share in a pragmatic fashion, or a software engineer who led development of a complex Cocoa application from its legacy PowerPlant origins through Snow Leopard readiness, or a programmer who has worked on performance enhancement in networking systems and low-level daemon code on Darwin and other UNIX platforms, then your project will benefit from an infusion of the Graham Lee magic. Even if you have some NeXTSTEP or OPENSTEP code that needs maintaining, I can help you out: I’ve been using Cocoa for about as long as Apple has.

Send an email to iamleeg <at> securemacprogramming <dot> com and let’s talk about your project. The good news is that for the moment I am available, you probably can afford me[], and I really want to help make your product better. Want to find out more about my expertise? Check out my section on the MDN show, and the MDN security column.

[] It came up at NSConference that a number of devs thought I carry a premium due to the conference appearances, podcasts and other material I produce. Because I believe that honesty is the best policy, I want to come out and say that I don’t charge any such premium. My rates are consistent with other contractors with my level of experience, and I even provide a discounted rate for NGOs and academic institutions.

posted by Graham Lee at 13:22  

Wednesday, July 8, 2009

Refactor your code from the command-line

While the refactoring support in Xcode 3 has been something of a headline feature for the development environment, in fact there’s been a tool for doing Objective-C code refactoring in Mac OS X for a long time. Longer than it’s been called Mac OS X.

tops of the form

My knowledge of the early days is very sketchy, but I believe that tops was first introduced around the time of OPENSTEP (so 1994). Certainly its first headline use was in converting code which used the old NextStep APIs into the new, shiny OpenStep APIs. Not that this was as straightforward as replacing NX with NS in the class names. The original APIs hadn’t had much in the way of foundation classes (the Foundation Kit was part of OpenStep, but had been available on NeXTSTEP for use with EOF), so took char * strings rather than NSStrings, id[]s rather than NSArrays and so on. Also much rationalision and learning-from-mistakes was done in the Application Kit, parts of which were also pushed down into the Foundation Kit.

All of this meant that a simple search-and-replace tool was not going to cut the mustard. Instead, tops needed to be syntax aware, so that individual tokens in the source could be replaced without any (well, alright, without too much) worry that any of the surrounding expressions would be broken, without too much inappropriate substitution, and without needing to pre-empt every developer’s layout conventions.

before we continue – a warning

tops performs in-place substitution on your source code. So if you don’t like what it did and want to go back to the original… erm, tough. If you’re using SCM, there’s no problem – you can always revert its changes. If you’re not using SCM, then the first thing you absolutely need to do before attempting to try out tops on your real code is to adopt SCM. Xcode project snapshots also work.

replacing deprecated methods

Let’s imagine that, for some perverted reason, I’ve written the following tool. No, scrub that. Let’s say that I find myself having to maintain the following tool :-).

#import <Foundation/Foundation.h>

int main(int argc, char **argv, char **envp)
{
NSAutoreleasePool *arp = [[NSAutoreleasePool alloc] init];
NSString *firstArg = [NSString stringWithCString: argv[1]];
NSLog(@"Argument was %s", [firstArg cString]);
[arp release];
return 0;
}

Pleasant, non? Actually non. What happens when I compile it?

heimdall:Documents leeg$ cc -o printarg printarg.m -framework Foundation
printarg.m: In function ‘main’:
printarg.m:6: warning: ‘stringWithCString:’ is deprecated (declared at /System/Library/Frameworks/Foundation.framework/Headers/NSString.h:386)
printarg.m:7: warning: ‘cString’ is deprecated (declared at /System/Library/Frameworks/Foundation.framework/Headers/NSString.h:367)

OK so we obviously need to do something about this use of ancient NSString API. For no particular reason, let’s start with -cString:

heimdall:Documents leeg$ tops replacemethod cString with UTF8String printarg.m

So what do we have now?

#import <Foundation/Foundation.h>

int main(int argc, char **argv, char **envp)
{
NSAutoreleasePool *arp = [[NSAutoreleasePool alloc] init];
NSString *firstArg = [NSString stringWithCString: argv[1]];
NSLog@"Argument was %s", [firstArg UTF8String], length);
[arp release];
return 0;
}

Looking good. But we still need to fix the -stringWithCString:. That could be just as easy, replacemethod stringWithCString: with stringWithUTF8String: would do the trick. However let’s be a little
different here. Why don’t we use -stringWithCString:encoding:? If we do that, then we’re going to need to take a guess at the second argument, because we’ve got no idea what the encoding should be (that’s why -stringWithCString: is deprecated, after all. However if we’re happy to assume UTF8 is fine for the output, let’s do that for the input. We’d better let everyone know that’s what happened, though.

So this rule is starting to look quite complex. It says “replace -stringWithCString: with -stringWithCString:encoding:, keeping the C string argument but adding another argument, which should be NSUTF8StringEncoding. While you’re at it, warn the developer that you’ve had to make that assumption”. We also (presumably) want to combine it with the previous rule, so that if we see the original file we’ll catch both of the problems. Luckily tops lets us write scripts, which comprise of one or more rule descriptions. Here’s a script which encapsulates both our cString rules:

replacemethod "cString" with "UTF8String"
replacemethod "stringWithCString:<cString>" with "stringWithCString:<cString>encoding:<encoding>" {
replace "<encoding_arg>" with "NSUTF8StringEncoding"
} warning "Assumed input encoding is UTF8"

So why does the <encoding> token become <encoding_arg> in the sub-rule? Well that means “the thing which is passed as the encoding argument”. This avoids confusion with <encoding_param>, the parameter as declared in the class interface (yes, you can run tops on headers as well as implementations).

Now if we save this script as cStringNoMore.tops, we can run it against our source file:

heimdall:Documents leeg$ tops -scriptfile cStringNoMore.tops printarg.m

Which results in the following source:

#import <Foundation/Foundation.h>

int main(int argc, char **argv, char **envp)
{
NSAutoreleasePool *arp = [[NSAutoreleasePool alloc] init];
#warning Assumed input encoding is UTF8
NSString *firstArg = [NSString stringWithCString:argv[1] encoding:NSUTF8StringEncoding];
NSLog(@"Argument was %s", [firstArg UTF8String]);
[arp release];
return 0;
}

Now, when we compile it, we no longer get told about deprecated API. Cool! But it looks like I need to verify that the use of UTF8 is acceptable:

heimdall:Documents leeg$ cc -o printarg printarg.m -framework Foundation
printarg.m:6:2: warning: #warning Assumed input encoding is UTF8

exercises for the reader, and caveats

There’s plenty more to tops than I’ve managed to cover here. You could (and indeed Apple do) use it to 64-bit-cleanify your sources. Performing security audits is another great use – particularly using constructs such as:

replace strcpy with same error "WTF do you think you're doing?!?"

However, notice that tops is a blunter instrument than the Xcode refactoring capability. Its smallest unit of operation is the source file; refactoring only within particular methods is not quite easily achieved. Also, as I said before, remember to check your source into SCM before running a script! There is a -dont option to make tops output its proposed changes without applying them, too.

Finally tops shouldn’t be used fully automated. Always assume that you need to inspect the output carefully, don’t just Build and Go.

posted by Graham Lee at 04:33  

Monday, December 22, 2008

Cocoa Memory Management

It becomes evident, thanks to the mass centralisation of the neverending september effect that is stackoverflow, that despite the large number of electrons expended on documenting the retain/release/autorelease reference counting mechanism for managing memory in Cocoa, Cocoa Touch, UIKit, AppKit, Foundation, GNUstep, Cocotron and Objective-C code, very few people are reading that. My purpose in this post is not to re-state anything which has already been said. My purpose is to aggregate information I’ve found on the topic of managing memory in Cocoa, so I can quote this post in answers to questions like these.

In fact, I’ve already answered this question myself, as How does reference counting work? As mentioned in the FAQ, I actually answered the question “how do I manage object lifecycles in (Cocoa|GNUstep|Cocotron)”? It’s actually a very violently distilled discussion, so it’s definitely worth checking out the references (sorry) below.

Apple have a very good, and complete, Memory Management Programming Guide for Cocoa. They also provide a Garbage Collection Programming Guide; remember that Objective-C garbage collection is opt-in on 10.5 and above (and unavailable on iPhone OS or earlier versions of Mac OS X). GNUsteppers reading along should remember that the garbage collector available with the GNU objc runtime is entirely unlike the collector documented in Apple’s guide. GNUstep documentation contains a similar guide to memory management, as well as going into more depth about memory allocation and zones. Apple will also tell you how objects in NIBs are managed.

The article which gave me my personal eureka moment was Hold Me, Use Me, Free Me by Don Yacktman. Stepwise has another article, very simple rules for memory management in Cocoa by mmalc, which is a good introduction though with one caveat. While the table of memory management methods at the top of the article are indeed accurate, they might give you the impression that keeping track of the retain count is what you’re supposed to be doing. It’s not :). What you’re supposed to be doing is balancing your own use of the methods for any given object, as described in rules 1 and 2 of “Retention Count rules” just below that table.

James Duncan Davidson’s book “Learning Cocoa with Objective-C” has not been updated in donkey’s years, but its section on memory management is quite good, especially the diagrams and the “rules of thumb” summary. Luckily, that section on memory management is the free sample on O’Reilly’s website.

If reading the theoretical stuff is all a bit too dry, the Mac Developer Network have a rather comprehensive memory management training video which is $9.99 for non-MDN members and free for paid-up members.

Finally, Chris Hanson has written a good article on interactions between Cocoa memory management and objc-exceptions; if you’re using exceptions this is a good discussion of the caveats you might meet.

posted by Graham Lee at 13:34  

Sunday, December 21, 2008

better security, not always more security

Today’s investigative investigations have taken me to the land of Distributed Objects, that somewhat famous implementation of the Proxy pattern used for intra-process, inter-process and inter-machine communication in Cocoa. Well, by people who measure whether it’s a performance hog, rather than those who quote it; as a hint, it was indeed a significant overhead when your CPU was a 25MHz 68030 and your network link a 10BASE-2 coaxial wire. These days we can spend around those problems freely.

Specifically, I wondered whether I should add discussion of the authentication capabilities in PDO to the FAQ entry. Not that it’s frequently asked – indeed, it’s a NAQ – but because getting mentions of security into a Usenet FAQ is likely to cause newbies to be thinking about security, which is possibly a good thing (for the world, not so much my uniquely employable attributes). But I decided no, though the subject is interesting, it’s not because of the technicality, but the philosophy.

Distributed Objects works by sending NSPortMessage messages over NSConnection connections. The connections and message-passing bumph are peer-to-peer, but DO adds some client-server distinction by having servers register their vended connections with name servers and clients look up the interesting vendors in said name servers. By default, anything goes; all connections are honoured and all clients serviced. There are two security features (both implemented as delegate methods) baked into DO, though. The most interesting of the two is the authentication.

The reason that the authentication feature is interesting is that it’s implemented in such a way as to make non-security-conscious developers question the security. The end sending the NSPortMessage includes some data based on the constituent parts of the message, and the end receiving the message decides whether to accept it based on knowledge of the constituents and of the data. On the face of it, this looks like shared-secret encryption, with the shared secret being the algorithm used to hash the port message. It also appears to have added no security at all, because the message is still sent in plain text. In fact, what this gives us is more subtle.

All that we know is that given the source information and the sender’s authentication data, the receiver gets to decide whether to accept the sender’s message. We don’t necessarily know the way that the receiver gets to that decision. Perhaps it hashes the information using the same algorithm as the sender. Perhaps it always returns YES. Perhaps it always expects the authentication data to be 42. On the other hand, perhaps it knows the public key of the sender, and the authentication data is a signature derived from the content and the sender’s private key. Or perhaps the “authentication data” isn’t used at all, but the source material gives the server a chance to filter malicious requests.

Now all of that is very interesting. We’ve gone from a system which looked to be based on a shared secret, to one which appears to be based on whichever authentication approach we decide is appropriate for the task at hand. Given a presumed-safe inter-process link, we don’t need to be as heavyweight about security as to require PKI; whereas if the authentication were provided by a secure tunnel such as DO-over-SSL, we’d have no choice but to accept the cost of the PKI infrastructure. Given the expectation of a safe server talking to hostile clients, the server (or, with some amount of custom codery, a DO proxy server) can even sanitise or reject malicious messages. Or it could both filter requests based on authentication and on content. The DO authentication mechanism has baked in absolutely zero policy about how authentication should proceed, by letting us answer the simple question: should this message be processed? Yes or no? Choose an approach to answering this question based not on what you currently believe could never be circumvented, but on what you currently believe is sufficient for the environment in which your DO processes will live. If a shared secret is sufficient and adds little overhead, then do that, rather than 4096-bit asymmetric encryption.

By the way, the second security feature in DO is the ability to drop a connection when it’s requested. This allows a DO server to survive a DoS, even from a concerted multitude of otherwise permissible clients.

posted by Graham Lee at 03:45  

Thursday, October 30, 2008

Solaris iPhone Edition

Apple’s one new feature in Snow Leopard is support for Exchange, which if not squarely an Enterprise lure is certainly bait for medium businesses. But here we hit Apple’s perennial problem; they want to sell more into businesses (because that’s where at least 2/3 of all PC money is to be made) but they want to design their systems for home users. When a system is designed to cover every possible potential use for a computer we end up with Windows, which is the kind of “few things to all people” solution that Apple are – rightly – keen to avoid. But as Tim Cook’s “state of the Mac” segment in the recent laptop event showed, one of Apple’s biggest growth areas is education which is organised along enterprisey lines.

Their solution thus far has been a partial one; we get Mac OS X which is basically a consumer OS, and then we get Mac OS X server which is the same OS with a few configuration changes and extra apps to support being used as a workgroup server. This is less distinct than the changes between Mac OS X and iPhone OS X, but the principle is the same; the same technology is used in different ways, so we get different interfaces to it. Note that these aren’t really very divergent products – a UNIX expert could set up an Open Directory Master on a standard Mac OS X box were they so inclined. We get the Mac Pro and the XServe as nods to the existence of more powerful hardware than the iMac. While Apple do have a network of business development managers, enterprise sales people, sales engineers and so on who can support larger customers, their capabilities and freedom are restricted by working on a consumer product in a consumer organisation.

Assuming that Apple aren’t going to retreat and consolidate all of their effort on the consumer/prosumer, the logical plan seems to be “the same only more so”; carry on the scheme of applying a common technology base to multiple markets, but with the product interfaces and configurations being specific to the role in which they’ll be used. Empower those enterprise sales, support and development teams to make the changes required in both the shared technology base and the domain-specific parts in order to advance their own cause. Allow them to do so in such a way that the consumer focus of the standard products is not diluted. To do all this, what Apple would need is to clearly delineate their Core OS, Consumer OS and Server OS engineering groups, while adding staff, expertise and intellectual property to their Server OS, Server Hardware and Enterprise Support groups.

The bit about “adding staff, expertise and intellectual property to their Server OS, Server Hardware and Enterprise Support groups” can be easily achieved by using the Blue Peter principle. Here’s one I prepared earlier. And no, I’m not going mad. Sun have plenty of experience in supporting larger customers and what marketing people like to call vertical markets, and have some good technology: hardware, operating systems software, enterprise services and applications. Their only problem is that they can’t make any money on it. On the other hand with Apple it seems that the money is there to be made, and the problem is stepping up to that plate without compromising the consumer products. Consolidating Mac OS X [+ Server] and Solaris 10 would not be trivial but is not beyond the realms of fantasy. NeXTSTEP ran on SPARC hardware, and as we know that Mac OS X runs on PPC, two different Intel architectures and ARM it’s likely that the effort to port Mac OS X to SPARC would not be great. But perhaps more useful in the short term is that OpenStep ran on Solaris before, and could do again. Even though Sun have switched Solaris to a SYSV-derived platform, due to Apple’s recent push for standardisation with Leopard the two OS are likely more source-code compatible than NeXTSTEP and SunOS 4 ever were. Getting Cocoa up on Solaris would mean that application portability (for the sorts of apps that server admins will want – including Apple’s own server admin tools, not for OmniDazzle) becomes viable while the combined company (Snapple?) concentrate on integrating the core tech. They could even get Jonathan Schwartz to do the coding.

Another factor in this proposition is that JAVA is cheap. Apple currently have about $20B in cash and Sun’s shares are worth $3.6B, but taking into account that Sun have lost 98% of their dot-com-boom value without slowing their R&D projects, the value for money when you want them for their tech, smarts and goodwill rather than their user base is astounding.

Oh, and speaking of JAVA, what about Java? Java currently represents Sun’s main income due to the licensing scheme, but Apple’s investment in the platform has declined over time from the Rhapsody days of “everything is Java”; currently the available Java on Mac OS X lags behind Sun’s version and isn’t ppc64 compatible. The WebObjects team (and hence the Apple store and iTunes) have a heavy Java investment, while other teams have dropped Java (Cocoa) and still others eschew it completely. The iPhone has a very busy developer ecosystem – and absolutely no Java. Where the hypothetical Snapple would leave Java is entirely open, but the option of packaging up the combined company’s Java assets and re-selling them would seem unnecessary, unless you thought that even $3.6B was too much to pay.

posted by Graham Lee at 00:43  

Monday, June 9, 2008

WWDC part 0

well, here it is, the pre-WWDC “I’m jetlagged so you have to put up with my wittering” post. I’m just waiting for a softwareupdate to finish so that I can go out with my camera, taking some early-morning pictures before heading off to stand in line for the Stevenote. I was out for beers with Ian and Neil last night, we’d all heard rumours of a 5 a.m. start to the queue. On the two previous occasions that I’ve been, 9 a.m. has been sufficient; but with the sellout nature of the event it’s likely that the room will fill up rather quickly so we’ve compromised on a 7 a.m. start. Actually, forget the 5 a.m. nonsense, there’s a line of overnight campers – I can’t decide whether they’re deliberately trying to re-enact a Joy of Tech cartoon, or actually have nothing to do with their lives.

posted by Graham Lee at 12:42  

Wednesday, June 4, 2008

Little hack to help with testing

Want the ability to switch in different test drivers, mock objects, or other test-specific behaviour? Here’s a pattern I came up with (about a year ago) to do that in a GNUstep test tool, which can readily be used in Cocoa:

NSString *driverClassName = [[NSUserDefaults standardUserDefaults] stringForKey: @"Class"];
Class driverClass = NSClassFromString(driverClassName);
id myDriver = [[driverClass alloc] init];

With a healthy dose of no, seriously, don’t do this in production code, you now have the ability to specify your test driver on the command-line like this:

$ ./myTestingTool -Class GLTestDriver

This uses the oft-neglected behaviour of NSUserDefaults, in which it parses the executable’s command-line arguments to create a defaults domain, higher in priority than even the user’s preferences file. You can use that behaviour in a graphical app too, where it comes in handy when working in Xcode. It then uses a combination of the runtime’s duck typing and introspection capabilities to create an instance of the appropriate class.

posted by Graham Lee at 19:18  

Thursday, April 24, 2008

Yeah, we’ve got one of those

Title linkey (which I discovered via slashdot) goes to an interview in DDJ with Paul Jansen, the creator of the TIOBE Programmer Community Index, which ranks programming languages according to their web presence (i.e. the size of the community interested in those languages). From the interview:

C and C++ are definitely losing ground. There is a simple explanation for this. Languages without automated garbage collection are getting out of fashion. The chance of running into all kinds of memory problems is gradually outweighing the performance penalty you have to pay for garbage collection.

So, to those people who balked at Objective-C 2.0’s garbage collection, on the basis that it "isn’t a 4GL", I say who cares? Seemingly, programmers don’t – or at least a useful subset of Objective-C programmers don’t. I frequently meet fellow developers who believe that if you don’t know which sorting algorithm to use for a particular operation, and how to implement it in C with the fewest temporary variables, you’re not a programmer. Bullshit. If you don’t know that, you’re not a programmer who should work on a foundation framework, but given the existence of a foundation framework the majority of programmers in the world can call list.sort() and have done with it.

Memory management code is in the same bucket as sorting algorithms – you don’t need for everybody to be good at it, you need for enough people to be good at it that everyone else can use their memory management code. Objective-C 2.0’s introduction of a garbage collector is acknowledgement of this fact – look at the number of retain/release-related problems on the cocoa-dev list today, to realise that adding a garbage collector is a much bigger enhancement to many developers’ lives than would be running in a VM, which would basically go unnoticed by many people and get in the way of the others trying to use Instruments.

Of course, Objective-C and ApPLE’s developer tools have a long history of moving from instrumental programming (this is what the computer must do) to declarative programming (this is what I am trying to achieve, the computer must do it). Consider InterfaceBuilder. While Delphi programmers could add buttons to their views, they then had to override that button’s onClick() method to add some behaviour. IB and the target-action approach allow the programmer to say "when this button is clicked, that happens" without having to express this in code. This is all very well, but many controls on a view are used to both display and modify the value of some model-level property, so instead of writing lots of controller code, let’s just declare that this view binds to that model, and accesses it through this controller (which we won’t write either). In fact, rather than a bunch of boilerplate storage/accessors/memory management model-level code, why don’t we just say that this model has that property and let someone who’s good at writing property-managing code do the work for us? Actually, coding the model seems a bit silly, let’s just say that we’re modelling this domain entity and let someone who’s good at entity modelling do that work, too.

<

p>In fact, with only a little more analysis of the mutation of Objective-C and the developer tools, we could probably build a description of the hypothetical Cen Kase, the developer most likely to benefit from developing in Cocoa. I would expect a couple of facts to hold; firstly that Cen is not one of the developers who believes that stuff about sorting algorithms, and secondly that the differences between my description of Cen and the description used by Apple in their domain modelling work would fit in one screen of FileMerge on my iBook.

posted by Graham Lee at 21:55  

Monday, April 21, 2008

Tracking the invisible, moving, unpredictable target

An idea which has been creeping up on me from the side over the last couple of weeks hit me square in the face today. No matter what standards we Cocoa types use to create our user interfaces, the official Aqua HIG, the seemingly-defunct IndieHIG, or whatever, ultimately producing what is considered a usable (or humane, if you like) interface for Mac OS X is not only difficult, but certainly unrepeatable over time.

The “interface” part of a Cocoa user interface is already hard enough to define, being a mash-up of sorts, and to differing degrees, between the Platinum HIG which directs the default behaviour of some of the *Manager controls and the OpenStep HIG which describes the default behaviour of most, if not all, of the AppKit controls. If that isn’t enough, there is an inexact intersection – some controls work differently in (what are loosely called, and I’m not getting into the debate) Cocoa apps than in Carbon apps. There have also been innovative additions on top of the aforementioned guides, such as sheets, unified toolbars and (the already legacy) textured interfaces. There have been subtractions from both – miniwindows still exist but nobody uses ’em, and window shading went west with Rhapsody.

But all of that is related to the user interface, not to user interaction (I’m in the middle of reading Cooper’s The Inmates Are Running the Asylum, I’m going to borrow some terminology but studiously avoid discussing any of the conclusions he presents until I’m done reading it). It’s possible to make HIG-compliant inspectors, or HIG-compliant master-detail views, or HIG-compliant browser views and so on. It’s also possible to make non-compliant but entirely Mac HID views, coverflow views, sidebars and so on. But which is correct? Well, whichever people want to use. But how do you know which people want to use? Well, you could get them to use them, but as that’s typically left until the beta phase you could ask usability gurus instead. Or you could take the reference implementation approach – what would Apple (or Omni, or Red Sweater, or whoever) do?

Well, what Apple would do can, I think, be summed up thus: Apple will continue doing whatever Apple were previously doing, until the Master User takes an interest in the project, then they do whatever the Master User currently thinks is the pinnacle of interaction design. The Master User acts a little like an eXtreme Programming user proxy, only with less frequent synchronisation, and without actually consulting with any of the other 26M users. The Master User is like a reference for userkind, if it all works for the Master User then at least it all works for one user, so everyone else will find it consistent, and if they don’t find it painful they should enjoy that. The official job title of the Master User role is Steve.

All of this means that even inside Apple, the “ideal” usability experience is only sporadically visited, changes every time you ask and doesn’t follow any obvious trend such as would be gained by normalisation over the 26M users. Maybe one day, the Master User likes inspectors. Then another day he likes multi-paned, MDI-esque interaction. On a third day he likes master-detail control, in fact so much so that he doesn’t want to leave the application even when it’s time to do unrelated work. Of course you don’t rewrite every application on each day, so only the ones that he actually sees get the modernisation treatment.

So now we come back to the obvious, and also dangerous, usability tactics which are so prevalent on the Windows platform, and one which I consciously abhor but subconsciously employ all the time: “I’m the developer, so I’ll do it my way”. Luckily there are usability, QA and other rational people around to point out that I’m talking shite most of the time, but the reasoning goes like this. I’m a Mac user, and have been for a long time. In fact, I might know more about how this platform works than anyone within a couple of miles of here, therefore(?) I know what makes a good application. One problem which affects my personal decisions when trying to control the usability is that I’m only tangentially a Mac person, I’m really a very young NeXTStep person who just keeps current with software and hardware updates. That means I have a tendency to inspector my way out of any problem, and to eschew custom views and Core Animation in favour of “HIG is king” standard controls, even when other applications don’t. And the great thing is that due to Moving Target reference implementation, I can find an application which does something “my” way, if that will lend credence to my irrational interface.

The trick is simply to observe that taking pride in your work and expressing humility at your capabilities are not mutually exclusive. If tens of other Mac users are telling me they don’t like the way it works, and I’m saying it’s right, apply Occam’s razor.

And if there isn’t enough fun for you in one usability experience, a bunch of us are presumably going to be providing the iPhone HIG-compliant V on top of our Ms and Cs before long.

posted by Graham Lee at 21:37  

Monday, June 11, 2007

Miniwindows

Maybe it’s just me who gets annoyed by teeny-tiny miniaturised views which are completely illegible. Even so, I’ve just uploaded an article I wrote on Miniwindows which can be used in any OpenStep implementation such as Cocoa or GNUstep. It’s based on the Hillegass TypingTutor example, but doesn’t really use any code from that and isn’t (I hope) otherwise reliant on that context, so it should be possible to see what’s going on even if you haven’t read Hillegass. Which you should ;-)

posted by Graham Lee at 15:31  

Powered by WordPress