Those of us new to starting a Mac Software Business, often look to Wil Shipley for tips of the trade. Partly due to his sage advice and his clearly evident success as an independent Mac developer. Partly because his advice is the most easily available, and he is so open about his success!

Not being fresh out of University, I took Wil’s advice with a pinch of salt, but also looked to glean what I could from his WWDC student talk, various interviews and blog. From Wil, I have discovered that it is possible to invent a better mouse trap. Although I cannot find a competitor for Differencia, my other planned products have entrenched competitors. They no longer worry me, as I believe I can make a better product. I have come to appreciate that “less code is better code”. I always preferred readable, simple code. Thanks to Wil, I am no longer worried about not knowing cunning coding tricks, as I now know all about the horrors of premature optimisation, along with some of the code maintenance horrors that I was already all too familiar with. Wil’s Pimp My Code was of particular interest as he always imparts the philosophy behind the way he writes his code, which is often of more valuable than the code itself.

However I have also realised over the last year and a bit, that I am not Wil Shipley. I do not have 15+ years of Cocoa development experience. I do not have key contacts within Apple that can provide work-arounds or solutions to Cocoa bugs and performance problems. I do not know a stable of graphic designers with extensive experience of working on Mac applications. Mike Matas did not come banging on my door.

In particular, my name is not enough, on its own, to bring customers pouring in. Nor can I win an Apple Design Award for an unreleased product that only a select few beta testers and the ADA judging panel have seen. Yet.

This has not been particularly down heartening, because I felt that this was the right time for me to start a Mac software company and that I could bring a lot to the platform.

One of the things that drove me away from working for large enterprise was that they claimed that their staff were their greatest asset, whilst treating them like sheep. I have always felt that having a “Human Resources” department, rather a “Personnel Department”, was far too impersonal. The reality is that big companies do not invest in their “greatest assets”, but simply let them depreciate.

So the great thing about having your own company is that you are, in fact, the company’s greatest asset.

New developers often ask, “What product should I develop?” The common answer is to develop something that you would use yourself, and therefore have a vested interest in and have a passion for. In consultant speak; you need “Domain knowledge”. Almost every project I have ever worked on, either specifically included a reconciliation process as a deliverable, or required extensive regression testing, reconciling old and new. I have desperately wanted a reconciliation tool throughout my working life and I finally got fed up and made my own! Differencia is a product that I am really proud of and am looking forward to using myself.

A phrase I often used in the early days of my career was “Problem Exists between Keyboard and Chair”, to imply that a user with a support issue was either stupid or did not understand how the software worked. Inexperienced developers often believe that they have found a bug in the underlying system, when the reality is that 99% of the time, the problem lies in their own code. Similarly even experienced IT staff often assume the problem lies with their users when it comes to support issues, when usually the app should be improved to be less confusing. I covered this in depth in an earlier post.

There are other qualities I believe that I bring to the business. An ability to learn quickly, strong technically and strong project management skills. I am particularly proud that I have always been able to translate from a user perspective to a technical perspective, without confusing a user with technical details. Being able to talk in “the user’s language”, that many technical people find difficult.

I have also learnt a lot over the last year or so. How to exploit understanding a user’s perspective, to improve user interaction design. How to form partnerships for web and graphics design, where my abilities and experience are lacking. The differences between project managing an upgrade with large project team, and a new development with a single resource.

So the lesson for new independent Mac developers? I am not Wil Shipley, neither are you. However I am Sanjay Samani, and I have a lot to offer.

How to access CDROM ?

Yesterday one disc automatically came out – I pushed it back and it seems to have dropped deep inside the computer 

My father uses an iMac G5 with a slot loading CD drive. My initial reaction was amazement that he had gone 2 years without hitting this problem before. It reminded my of a number of issues that he has had over the years that have always been quite fascinating to resolve. My father is an intelligent 75 year old man who can do things with Excel that make my head hurt. Yet there are things that I find easy, “intuitive”, that he has problems with. 

PEBKAC

When IT people handle support requests, a lot of the issues are put down to PEBKAC – Problem Exists Between Keyboard And Chair. In other words it is too easy to assume users are not computer literate or are just plain stupid. Once, our brightest user phoned up saying he could not log in to our system and it turned out he had left the CAPS LOCK on. If our most intelligent users can fall prey to such simple mistakes, PEBKAC cannot be the issue. Apple and Microsoft have both tackled the Caps Lock key issue, which shows how these issues can actually be resolved by better user interaction design.

At Apple’s developer conference, John Geleynse, Apple’s User Experience Evangelist, always gives a talk on user interface design. Year after year he presses home the need to understand the user’s “Mental Model”. But this issue goes beyond even the topics John covers in his annual sessions.

My father mentioned that he was used to a physical eject key on the CD-ROM drive. I realised that the Mac’s solution is pretty poor as both the software button in the Finder and the button on the keyboard, whilst easy to access, are both located quite far away from the actual drive. This is a failure to apply the Proximity principle of good design. Of course the current method is still far more sensible than dragging the disk to the Trash.

He also complained that his address labels were no longer printing out correctly and in this case he had in fact been using different sized labels. What was fascinating was the Excel spreadsheet that he used to print his labels. He had adjusted row heights and column widths to represent each label and surrounded each label cell with narrow cells as margins. It was clearly a painstaking effort on his part. I was about to adjust his spreadsheet for the labels he was now using, when he opened up another one that worked perfectly. I considered telling him about Word Label Printing in combination with Mail Merge but concluded he would be more comfortable with the solution he was familiar with.

Again I have often come across intelligent users who have come up with cunning, but fragile, solutions where full solutions already exist. They were unaware of these solutions, that may well have been intuitive and easy to use, but their actual existence was not obvious.

Conclusion

These issues highlight that the problem is not stupid users but stupid user interaction design. All too often as developers we marvel at how users do not understand how the application works. Yet the issue is that we are too familiar with the application to appreciate what it feels like to be inexperienced with it. It is precisely those support issues that strike us a stupid that we should examine the most closely for opportunities to improve the user interaction of our applications. The problems do indeed exist between the keyboard and chair but not those of the users but of the developers.