Andrew Stone Responds

May 31st, 2006

I had an off-line chat with Andrew Stone, to see what his reaction was to my recent entry about the design of Videator. He agreed to let me publish his response here as a counterpoint to my pretty strong criticism. He makes some good points and at the end of the day, he’s right: it’s best to download and try it out for yourself.

Thanks, Andrew!


Thank you for all the attention you have lavished on Videator.

I would ask you to consider people’s motivations in dissing both the application and me personally so vehemently. Why was such an emotional response generated by this new application? Should I be flattered that my work is not being ignored? Do I win points for touching raw nerves? ;-)

Working with the metaphor, batshit is an extremely rich source of nitrogen prized by gardeners. My software and the ideas contained therein is organic fertilizer for the software world. And in Jazz lingo, no higher complement than ‘crazy’.

I’m one of the last truly independent developers who has scratched out a living for 18 years innovating ideas which quickly get re-used and popularized by larger, better-funded software houses. I rely on good word-of-mouth to continue to get sales, so of course, getting such negative publicity is painful for more than just the ego.

When a new application comes along that does things that no other application has done before, of course there are going to be complaints about the way we decided to implement it! You have some valid design points of course, I am not attempting to deny that. However the emphasis on the exterior drowns out all the core brilliance of what the application can actually do.

It’s as though no one actually used the application but simply decided to trash it from the screenshots or their personal distaste for my independent status. The power of Videator is that it’s not a “limited choices – canned settings – just click here” kind of app Mac users have become so comfortable with. Those types of applications are easy to apply the design guidelines you mention.

Alas, Videator is breaking new ground and is perhaps outside the comfort zone of the armchair critic. Providing a set of tools to do almost unlimited manipulation of video, Videator takes on a very complex domain. Could the UI be tweaked to better? Certainly.

BTW – for people who don’t like polished metal, there is a switch in Preferences to get Aqua windows…

Why not focus on what’s cool and innovative about the application? I encourage people to download and try it for themselves – it’s free for 2 weeks and then just $49 and free upgrades for life – where new and better UI’s will no doubt emerge, it’s still a deal.

Download it now – or learn more at:http://videator.com

MBP: Good and Bad Apples

May 31st, 2006

This post is part of my MacBook Pro Complaints series. Instead of (or in addition to) linking directly to this post, consider linking to the series link, which includes a summary of all findings to date and direct links to the pertinent downloads that users may find useful. Thanks for reading!

Anybody who’s been following my MacBook Pro saga knows that I’ve had plenty to complain about over the past few months. Heck, I’m sick of hearing me complain. This entry is a compromise: I’ll both complain and rejoice about a few Apple employees I have had the pleasure and displeasure of working with over the past couple weeks.

Part 1: Good Apple

After the disappointment of sending my MBP in for repair, being without it for a week and a half, and then getting it back only to discover that nothing had been fixed, I was reluctant to send it in again. I ended up getting in touch with AppleCare again and ultimately being referred to Apple Customer Relations, which is a great service Apple provides for customers who “fall through the cracks” of ordinary customer care. Basically when you have a bad enough experience, they assign a customer relations person to keep an eye on your case and work with you through (hopefully) an ultimately positive resolution.

Apple Customer Relations is awesome! From the first call with my agent, she made it clear she was listening to me and understood my concerns. There were still very clear boundaries. No, Apple wasn’t going to send me a new computer. No, there are no loaners while the machine is in for repair. No, Steve Jobs will not take me to Disneyland. But within those boundaries she worked with me to try to find compromises that might make my life easier. She never questioned the legitimacy of my complaints (part of this is because they are not technically trained, but part of this is clearly because it’s bad business to tell your complaining customers that they are wrong).

I’m still so frustrated about the whole ordeal with my MacBook Pro, but the fact is, Apple is still talking to me. Apple is still trying to help. They are a big company and as such have secret support agendas, and have to avoid admitting when something is wrong even if they know it. Etc., etc., etc. But the are many, many companies where somebody with my number and severity of complaints would simply fall off the end of the support line. We’re sorry. Goodbye. I am at every step of the way afraid that I may be near the end of my support rope, but so far Apple has surprised me with their willingness to keep talking and acting. (While I’m handing out kudos, another company I’ve dealt with recently, TomTom, has excellent support on par with Apple’s).

When I spoke with my Customer Relations representative on May 23 (two days after my birthday!), I agreed to try bringing my computer into the local Apple Store. The idea was that instead of making me wait for the shipping to and from Texas for another round of repairs, I would bring it into the store where a capable technician could do most if not all of the part swapping that a specialist in Texas might do. I was skeptcial, but it was worth a shot. She comforted me by letting me know that she would be watching the progress and follow up with me about the results of the experience.

I wanted to avoid giving up my laptop for another week or more, so I went for it. I decided it was worth it to go along with this idea because it was virtually risk-free, and the time it would take to zip over to the Apple store was much less than the time it takes waiting for DHL to arrive, transit time, etc.

Part 2: Bad Apple

The worst part of any customer support ordeal is the stress of wondering whether you’ll make yourself clear. Whether they’ll respond politely to you. Whether they’ll understand what’s really going on. And whether they’ll actually agree with you that it needs to be fixed.

I took a deep breath on the afternoon of May 24, mentally prepared to make my case as convincingly as possible. The Apple store is the worst place in the world to complain about noise problems, because the blasting music makes every single machine in the store sound absolutely dead silent. (For any noise complaint, they take your machine into the back room where you can’t demonstrate to them how the noise varies or under what circumstances it most affects you). I knew I was up against a tough challenge, but I tried to be optimistic that I would get a Good Apple.

I checked in at the Genius Bar and waited with my buzzer. This was cool. It’s like waiting for a meal at Chevy’s or something. It went off in just a few minutes after I had arrived. So far, so good! Nice work, Apple Store. I met my “Genius,” who greeted me with a sort of contemptuous glare combined with a saccharine mumble of “What can we do for you today?” I explained that I had been sent by customer relations, that there were a few problems of varying priorities, and that the machine had already been sent in once for repair. I sort of waited for him to make the next move, expecting that he might want to glance at my record in his computer, since it showed a lot more information than I could reliably reiterate all at once. “Why don’t you just tell me what’s going on?” he said sort of impatiently.

OK, I plopped my MBP down on the counter and opened it up. I began explaining that I was most surprised that at least the brightness-related buzzing wasn’t fixed, because it’s pretty well-established that this is due to an inverter board problem. As I was talking he acted like I wasn’t there, and raised his black bic pen towards my computer. Using the ink-side tip of the pen, he reached into a corner of my screen’s display and flicked out a piece of dust or something. What are you doing to my computer, you freak?! I paused and when he was done sort of continued explaining. He seemed pretty bored. He finally said something along the lines of what did I expect for being on the “bleeding edge?” I put bleeding edge in quotes because it’s the only part I can guarantee was verbatim a quote from his mouth. He basically echoed that lame user sentiment that you “get what you pay for” when you choose to buy an early rev product. An Apple representative! Telling me that I was on his company’s bleeding edge!

I got a little bit emotional because, after working so many years at Apple, I hate seeing Apple store employees behave in a way that reflects poorly on the company. I explained to him (probably to his great boredom) that I didn’t feel like it was appropriate to classify me (and thousands of others) who made early, strong commitments to Apple’s new architecture as “bleeding edge.” Needless to say he didn’t see the error of his ways at all and insisted that you’ve got to expect a few things to be wrong in a first revision of a machine.

That was the beginning of a relationship that only went downhill. He finally agreed to take my MBP into the “back room” to listen to the noises for himself. He came back and announced that “there’s nothing wrong with the inverter and the CPU whine is within spec.” He handed me my MBP and sort of waited for me to leave, I suppose. I wanted more clarification. Nothing wrong with my inverter? Didn’t you hear the noise? He said that there was no inverter noise and what I was hearing was the CPU whine coming from different sides of the computer. Well, that’s totally inconsistent with my understanding of the inverter noise. Since it goes away and comes back with the brightness, I had to assume it’s inverter-related. In my pessimism I had more-or-less expected the CPU whine complaints to be dismissed, but the inverter noise! I know people who have had this one fixed! At least fix this, Apple. You know how, even!

Another minute or two of trying to get him to agree that we were talking about the same thing. I suggested that maybe I needed to let the machine warm up before the noise is loud enough. It’s difficult because, as I said I’m trying to get him to acknowledge unacceptable noises while Gwen Stefani is blaring on the stereo. He agrees that if I want to “hang out for 20 or 30 minutes” then he’ll listen again after it warms up.

Speaking of warming up, I thought I’d ask about the heat issue before I lost his attention, and that lasted all of about 15 seconds. “If the MBP gets too hot, it will shut down. If it’s not shutting down, there’s nothing wrong with it.” Well, that’s an interesting way of looking at it. Let’s say the maximum heat is 100C. By the Apple Store’s logic that means my computer can be at 99C all the time, while somebody else’s machine is at 60C all the time. We’re both “in spec,” but my hands are forming heat blisters.

So I hang out for 20 or 30 minutes, and then go back to the podium. While I’m waiting another MBP owner comes in, and starts chatting with another Genius. He’s complaining about the heat. The Genius he got is a lot more friendly and explains that unfortunately they can’t do any testing here in the store. They would have to send it away for testing, and that would take a week or two. The customer seemed somewhat satisfied by the response, thanked the Genius, and left the stoer.

I hang out for another 15 minutes or so while he refuses to acknowledge that I’m there. Finally, when another Apple Store employee asks if I’m being helped, I say that I’m “just waiting for him to have a free moment.” Five minutes later he is back in the “quiet room” (who knows how quiet even that room is) with my MBP.

He emerges. Hands me my MBP, and declares, “Both I and a coworker agree that the noise is within spec.” OK. You and a coworker. So this was a hint to me that the “spec” might be a subjective test. I tried to ask whether there was some mechanical test they perform, or whether it’s just based on their own personal hearing. He looked at me sternly and said “I can’t tell you, OK. I’m sorry.” He had a habit of saying “OK” habitually in that patronizing way, almost like the “mmkay” guy on South Park.

All this time I had been on my best behavior. I really tried to avoid calling him on his rudeness and refusal to listen carefully to my complaints. But now that the end was nigh I took the opportunity to give a little rant about how I didn’t think the machine as-is meets the criteria of a professional, $2500 machine. I complained that if Apple’s spec allows user problems to be dismissed so cavalierly, then it was a real shame for the company and its customers. At this point a quiet young woman who had been sitting at the Genius Bar for a few minutes turned to me and said empathetically, “I had six stuck pixels. They said the limit was 7.”

I commiserated with the woman for a minute and wished her luck. At least she has a number to be angry about. I just got an arrogant jerk who can’t even convince me that he understands what the problems with my machine are, let alone if or why they are “within spec.”

Part 3: Good Apple

My visit to the Apple Store almost ruined my day. I went to the store straight after picking up one of my best friends from San Francisco, who was in town for a few days. The last thing I wanted was to put a damper on his visit just because my crappy computer was never going to be repaired. He is a Mac fanatic and was just excited by the fact that we’d been in the Apple Store long enough that he’d authored a blog entry in the time he was waiting. “My first blog entry written in the Apple Store!” he said proudly as he shut his (quiet, cool, lovely) iBook G4 up and packed it in his bag.

I wasn’t looking forward to my next call with customer relations. As nice as she was, she had hinted that if the Apple Store decides there’s nothing wrong, then there might be nothing she could do. I had built myself up over the past few months to perhaps ultimately have to live with some flaws, but the screen buzzing was definitely not one of them. Pizza for dinner and watching episodes of The Office made things quite a bit better. I didn’t even take the MBP out of its case.

The next day, I got a voice mail on my cell phone while I was at the gym. It was my customer relations agent, and she sounded concerned. “I just wanted to check in because I’m looking at your case and I don’t see any repair ticket. I hope everything went OK at the store yesterday.” I called her back on Friday but got her machine. I said I was disappointed with just about every outcome of the store visit. Both the treatment from the “Genius” and the ultimate outcome. At this point I figured it might be the end of the road, so I said “I guess I might be out of luck, but call me back if you want to hear more about my experience at the store.”

Several days passed. It was Memorial Day weekend and all that. I was pretty sure I would hear from her again, but also slightly concerned that maybe that was it. Today she called and asked how I was doing. “I’m doing pretty good,” I said. I always say that because in reality, I am doing pretty good. The MBP can’t take that away from me! She asked me to tell her what happened at the store. So I basically told her everything that I’ve typed in this blog entry, minus the part about pizza and The Office.

To my great satisfaction, she agreed that the store employee had behaved inappropriately. I guess if nothing else, the fact that I got a turd for a Genius may have helped me gain some empathy from the relations agent. She offered to go back to “Plan B” which is me sending the machine back to Texas for another round of repairs. At this point I’m exhausted, don’t want to see another Genius for a long time, and would really like to have that buzzing fixed. If the whine doesn’t get fixed, I’ll just have to come to some compromise of running QuietMBP and losing battery life. But the buzzing, and if at all possible, the heat. Those fixed would be effing fantastic! As my frustration has risen over this whole affair, my expectations have plummeted accordingly.

She explained that she was going to transfer me to a “product specialist” who is a kind of hardcore customer service agent who works specifically with a particular kind of machine (I think). They want me to talk to him so he can get very specific concrete details into the problem report, and so he can trigger an “engineering seizure” of the machine if it sounds like it will be useful as a case study. She again assured me that she’ll be following the progress of the repair.

The product specialist was polite and empathetic. He also seemed to know what he was talking about, and didn’t pull that “I never heard of that before” crap that some agents do when hearing about any problem whatsoever. He was everything a good agent should be, which isn’t asking so much.

He asked me some very specific questions about the problems. Even took seriously the CPU whine complaint. I told him I was pessimistic about it getting fixed but I know that some people have MBPs that are “much quieter than mine.”

As usual, we’ll see how it goes.

Score for the past two weeks: Good Apples – 2; Bad Apples – 1. Stay tuned for more (but hopefully not too many more!) details.

Pain in the Nib

May 28th, 2006

Anybody who’s spent time with Apple’s Interface Builder (IB) application knows that it’s an amazingly intuitive, powerful tool for designing user interfaces. It’s also a major pain in the ass.

While Xcode has improved by leaps and bounds over the past few years, IB has struggled to keep up. For the most part, it seems that changes to IB have been the bare minimum that would placate the masses (and management). IB had to support Carbon, so they tacked on Carbon support. IB had to support Cocoa Bindings, so they added a new inspector pane. There have been some really cool improvements such as the “Compatibility Checking,” but the number of frustrating shortcomings leave me always hoping that a major renovation will soon come.

My problems with IB wouldn’t be nearly so bad if there were viable workarounds. Many of my criticisms stem from its inability to effectively edit multiple items at once. Many times I find myself repeatedly setting the same properties on an item, or typing highly similarly but mildly deviating bindings into a key value field. The problems I face in IB all the time are the kinds of problems I would have long ago automated, if only there was an easy way.

Nibtool is the command-line counterpart to IB, and new programmers on the Mac often assume that it offers exactly the kind of flexibility I have been wishing for. Here we have a tool that dumps a text version of the objects, classes, hierarchy, and connections in a nib file. Hallelujah! Once I dump it to a text file, I can run some shell script or regular expression replacement on the file and pop it back into the nib, right? Nope, sorry! The man page for nibtool lists only one bug, and it’s a big one:

You cannot regenerate a nib file using the output of nibtool.

The fact that this is listed as a bug has always given me hope that it would one day be fixed. Unfortunately, it appears to be getting fixed at the same pace as all the other bugs and quirks of IB. But when Michael McCracken posted this entry describing a happy discovery in the latest Xcode release notes, I shared his cautious optimism. Nibtool has been updated, and it includes a new pair of options for “importing” and “exporting” object properties from and to an existing nib file:

Nibtool can extract properties into a plist format that can be edited and then reimported into the nib using the new –export (-e) and –import (-i) flags.

Is this it? The holy grail? I have played around with the new nibtool a little bit, and all I can say is we’re closer, but this is by no means an easy or complete mechanism for manipulating the contents of a nib file. The release notes and man page are so vague that it’s difficult to even figure out how to use the new options. I have mostly deciphered the new behavior, and hopefully can clarify things for you by paraphrasing what the new options do.

In each case, the effects of the tool are only to manipulate the instance objects in the particular nib file. The functionality is therefore useless for adjusting things like connections, hierarchy, etc. Think of the nibtool import and export functions as shorthand for “iterate the objects in my nib and do keyed value reading or writing on them.” I think one of the confusions is that the PLISTFILE argument in each case is an input file to nibtool. Output is always to the standard output.

nibtool -e – Takes as input a special-format plist file that specifies a list of Objective-C class names and associated keypaths for values that should be fetched. For all objects in the nib that are of the specified class, this option produces as output an plist file containing the current keyed values for whatever keys you specify in the PLISTFILE.

nibtool -i – Takes as input a plist file of the format produced by nibtool -e. For every object specified in the input plist, this option essentially looks up the object in the nib and sets its value as specified in the plist.

So in a nutshell, you use nibtool -e to fetch a bunch of values as a text file. Tweak the text file as you see fit, and feed it back in with nibtool -i. A major drawback to nibtool -e is that if any object you specify doesn’t respond to the particular key, then the whole deal is called off. So you can’t for instance ask for “bounds” of all “NSObject” and hope to get just the objects in your nib that actually have a bounds property. You have to make sure that for whatever class you specify, every instance is key-value compliant for the given keypath.

So what is the magic format of the first input plist? It’s not too special, and is documented in the nibtool man page, but it is still clunky enough to limit casual use. You basically cannot use nibtool -e for anything useful unless you’ve already taken the time to put together a suitable “input plist” describing what it is you’re looking for. I knew that at the very least I was going to need something to make the input plist easy, so I started with a small python script that produces a plist for the simplest possible fetch: “given one class name and one keypath, fetch the values for all suitable objects in the nib.” This is ugly but it’s my very first python script. Cut me some slack. (Thanks to Gus Mueller for telling me about the os.popen() function, and to Mark Rowe for teaching me about Python’s magic triple-quoting).

#!/usr/bin/env python

import sys, os;

def usage():
    print 'usage: %s   ' % sys.argv[0]
    print 'produces a PLIST file from  suitable for editing'
    print 'keyPath value of all objects of class '
        
# Mild validation of the arguments
if len(sys.argv) != 4:
   usage()
   sys.exit(1)

# Construct a suitable temporary plist for the desired class and keyPath 
newXML = '''\
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
 "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
  <dict>
    <key>%s</key>
    <array><string>%s</string></array>
  </dict>
</plist>''' % (sys.argv[2], sys.argv[3])

# write it to a temporary file
xmlFileName = '/tmp/com.red-sweater.pythonClassValueHack.plist'
output = open(xmlFileName, 'w')
output.write(newXML)
output.close()

# now run nibtool feeding it the xml file and pointing it at the nib
myResults = os.popen('/usr/bin/nibtool -e ' + xmlFileName + ' ' + sys.argv[1])
sys.stdout.writelines(myResults.readlines())

Paste this code into a python text file and run it from the command line. I called my NibValFetch.py. Now when I cruise over to one of my nib files, I can do something like this:

./NibValFetch.py Preferences.nib NSTextField frame > hacking.plist

That is: get all the NSTextFields in Preferences.nib, and ask for their frame. The file “hacking.plist” now contains a list of all the NSTextField objects in my nib, along with a text representation of the frame for said field. Now if I wanted to make every text field 2 pixels wider or something, I could write a script to modify the hacking.plist file, and then feed that into nibtool -i.

I don’t really have time to delve into this much more right now. I’m not even sure the new functionality will prove very useful, but I figured that somebody out there will find a good use for it if nudged in the right direction. I hope this introduction to the new functionality clears up what it can and can’t do, as well as giving you a clue as to how you might go about leveraging it. If you think up any really clever hacks with it, please be sure to share in the comments!

Insane in the UI Brain

May 24th, 2006

(Note: Now updated with specific UI criticisms of Andrew Stone’s Videator application. Scroll down to the middle if you’ve already read the first part)

John C. Welch has posted a scathing critique of Andrew Stone’s new Videator core video application. In fact, he’s used his reaction to the application as an opportunity to confess that he thinks Stone is actually “batshit insane.”

I have to admit, the UI to Videator, and across most of Stone’s web site, looks more like something I’d see on a Phish poster than an awesome Mac application. Not likely to win any Apple Design Awards, I suspect. I remember when Mac OS X was first being developed, and lo and behold, this suite of Stone Design applications was already out the door. I never spent too much time with them, but remember being impressed that some alternative to major creative suite applications already existed for the future of the Mac. The reason I never used them is because they never “clicked.” The UI has always been a little off for the Mac, but Welch is right, this one is freakin’ insane. To add insult to injury, Stone lists the “intuitive, all-in-one interface” as one of the application’s selling points.

Whether that makes Stone himself insane is up for debate, but at the very least he could use a makeover. I see Stone as suffering from a couple major disorders: chronic clinging to outdated standards, and refusal to take conventional UI design rules seriously. He may not need a therapist, he may just need an intervention. We need a Bravo television show: “Mac Eye for the NeXT Guy.”

I have to concede a little admiration for Andrew Stone. The guy gets products out the door. He maintains, whatever that means, several products simultaneously and as far as I can tell stays financially afloat doing all independent software development. Kudos to Stone! That’s more than I can say for my own dilapidated software line-up. If he can do all that while still producing satan’s own UI experience, then more power to him.

If he’s surviving and getting press now, just think how well he’d do with a fantastic UI? Often when I mention UI design to developers I get a cold shoulder. Like, “I’m not a designer!” Fine, if you’re not a designer, you have two choices: either hire one or become one. My own design knowledge is bare-to-middling, but I know when something looks like ass. It turns out this is a big head-start. In fact, I know that most of my own web site looks like ass. I want to fix it, believe me! That’s why I’m dedicated to becoming a designer.

I’ll never be a great designer. I will however be an “OK” designer. Design is like cooking: you can learn to make something edible without much training. If nothing else, it’s worth it for all developers to learn design so that they know who to hire when they realize they don’t have time or talent to fix everything themselves. So how do you become a designer? I’m a fledgling learner myself, but here are several books I highly recommend in your pursuit of “fixing the design hole” in your expertise:

The Non-Designer’s Design Book is a great starting point for anybody looking to get their feet wet with design concepts. Robin Williams (not the comedian!) focuses on the four concepts of Contrast, Repition, Alignment, and Proximity. And yes, I did remember those thanks to the exceedingly useful mnemonic that comes along with them. She takes a stab at introducing you to these concepts through a number of “bad vs. good” comparisons. These exercises teach you to be a better critic. If you can tell when something looks like ass but never know why, her book may give you the fundamental tools you need to start making wise assessments.

Designing Interfaces is currently on the top of my list of design books. I’m about halfway through reading it, and enjoying every minute. This is the techie’s design book, if there ever was one. Anybody who appreciates design patterns will love the clinical yet common-sensical way that author Jenifer Tidwell elaborates on dozens of standard patterns in UI design (are you listening, Andrew Stone?). Patterns are fun to read about in both programming and other arenas, because they constantly give you that “oh, of course” feeling. While you’re technically learning new stuff, you’re really just reinforcing obvious stuff that you thought you knew but didn’t have the confidence to be sure about. Jenifer tells you you’re right for thinking that things like balance, alignment, and obviousness of effect are important to your application’s UI. Thanks to Jonathan Wight for recommending this book.

Don’t Make Me Think focuses on designing for the web, but is still quite an eye-opener for desktop application design. The underlying message of Steve Krug’s book is summarized in its title: users shouldn’t have to work hard to figure out how to use your application. This is so pertinent to Mac software design, it’s not even funny. Don’t make your users think. Don’t crowd up the interface. Don’t use non-standard controls. Don’t place verbs that users are unlikely to use on the same level as ones they are exceedingly likely to need. Make it clear what the heck your application does best and make sure the user falls feet first into that!

About Face 2.0 is the sequel to one of the first books I ever read about design: About Face. Although I haven’t yet read the 2.0 release of this book, I found the original fascinating and especially enlightened about the design of desktop user interfaces. It’s primary author Alan Cooper is regarded as the “father of Visual Basic.” I couldn’t help wondering while reading About Face why Microsoft hadn’t handed him the reigns to Windows as well. While the other books I’ve recommended will give you a steady footing in the basics of design, this book should help you connect the dots between those lessons in the abstract and the everyday UI objects of your daily development: Buttons, Checkboxes, Sliders, etc.

Update: Several readers offered additional suggestions in the comments below. I haven’t read these, but am adding them to my reading list based no their endorsement and their clear presence in the “aura of recommendations” surrounding the books mentioned above. “Designing Visual Interfaces” in particular I had already hopped onto my shopping list because of its positive citation in Tidwell’s book.

The Design of Everyday Things – by Donald A. Norman.
Recommended by Sascha Brossmann.

Designing Visual Interfaces – Kevin Mullet and Darrell Sano.
Recommended by William F. Adams (and implicitly by Jenifer Tidwell in Designing Interfaces).

Universal Principles of Design – by William Lidwell, Kritina Holden, and Jill Butler.
Recommended by Buzz Andersen.

The Inmates are Running the Asylum – by Alan Cooper. I just checked this out from my local library and I’m really impressed. I’m having a great time getting started on it – so much of what Alan Cooper says is “obvious in retrospect.” I love it!
Recommended by Andy Lee.

No Excuses

You’re a developer, but not a designer? That’s no longer acceptable. Let’s spend a little more time wrapping the product in something usable and beautiful. Our users will thank us for it, and it just might keep us from going “batshit insane.”

Update: Friday, May 26:

Wow! This post has really generated some interesting responses. I think partly owing to the visceral nature of John C. Welch’s original post, and partly owing to the strength of Andrew Stone’s good reputation, I am getting caught a bit in the crossfire. I really hoped that my criticism of Stone’s UI would be taken with the lightness I intended. I do think it’s bad UI, and I hope that he improves it by either hiring somebody or reading-up with an open mind. It doesn’t matter that he’s one of the oldest, most knowledgeable, and perhaps straight-out “best” Mac OS X developers on the planet. The product is frustrating and bad. The skills are not being put to optimum use.

Since the biggest complaint about Welch’s and my criticisms is that specific examples are not cited, I thought I would take some time to actually call out some of the first impressions that led me to agree with Welch’s assessment (about the UI, not the craziness). Below is a screen capture of the Videator UI that is very similar to one that could have been taken mere minutes into my first-run of the program. I’m not even a very good UI critic, but let me just take a stab at a few things that are wrong here, and why it’s frustrating to see an experienced developer (one whose company contains the word “design” no less) violate the user’s trust:


(Click for full-size image)

The first several labeled items in the screen shot have to do with the toolbar. But before I discuss those, I have a couple complaints that are not pictured. The toolbar is pretty offensive-looking in part because it contains a number of items of varying heights. It looks slightly less offensive when titles are turned on, because they “regularize” the heights. However, even doing this is non-trivial, because you first have to find the “Customize Toolbar” menu item. In every other Mac OS X application with a toolbar, you find this menu item in the “View” menu. In Videator however, since there is no “View” menu, you have to either know to right-click the toolbar for a contextual menu, or else find the menu items hidden way off in the “Tools” menu of the main menu bar.

The screenshot above is smallish partly so it will fit easier on this blog, and partly because being smallish exposes some of the worst UI glitches in the application. I would like to point out that when the window is biggish, the toolbar items float in a way that looks very awkward at first and only slightly less so when you figure out the minor rhyme to Stone’s reason. The gigantic “Instant Effects” popup in the middle of the toolbar is surrounded by expanding space such that, as the user resizes the window, the items to its left float left, the items to its right float right, and it stays more or less centered. Although I guess Stone might argue that the item is central to the application’s functionality, the weird alignment just seems weird. One of the take-aways from the Non-Designer’s Design Book is that you should pick an alignment, probably flush left or flush right, and stick with it unless you really know what you’re doing. If the user thinks one of your toolbar items should be put up on a pedestal, let them choose to organize things that way.

1. Funny Segmented Control. One of the first things that jumps out at me is that this funny segmented control has graphical content that appears ready to jump out of the control. The meaning of the icons is pretty obvious, thanks to the use of industry standard icons, but the lack of centering makes it look like this is a rush-job that hasn’t been refined for shipment.

2. Huge Popup Control. This popup control appears to have some kind of customized graphical content – perhaps representative of whatever the selected item is? It turns out the displayed content is always the same, and never changes to reflect what you’ve just selected. The “Instant Effects” title reflects the fact that anything you choose from this menu gets instantly applied to the working document. Since the state never changes, there is no excuse for the awkward height and width of this item. It, more than any other item in the toolbar, contributes to the sense that toolbar items are all over the board in terms of both height and width. For some reason Stone decided it was very important to represent this popup as a huge graphical/bigfont item, while the neighboring “export type” popup is just plain text.

3. Image Drag Well. I wouldn’t have known what to call this if Stone didn’t give it a name that shows up when you turn titles on in the toolbar. Unfortunately, if you haven’t turned on titles or hovered over the item with tool tips, it’s impossible to know what “png” means. It turns out it means that it’s the format any exported image will assume. The well next to it? My first impression is that this is something you drag an icon to. But it’s in fact something you drag from. See, together these items make up the “export an image” functionality that in a well-designed application would probably consist of a Preferences option for the type, and “just dragging from the movie.” To make matters worse, the popup menu for file types includes one non-image-format type: “effects”. JPEG, Tiff, or Effects? Hmm. If you choose this from the popup then the well loses its icon badge and becomes, for all I can tell, meaningless. I don’t know how to complete the expected user action when Effects is chosen.

4. Tab View Language Abuse. These abbreviated, lower-cased tab view titles scream “X-Windows” or something at me. I can empathize with the problem that must have motivated Stone to adopt this disgusting naming convention: the spelled out words would require a tab view that is too wide. I’m not saying this is easy to fix, but when a good designer encounters a problem like this, she challenges her assumptions and comes up with a solution that does not involve compromising the laws of UI language. In this case, perhaps a collection of small icons would be appropriate. It’s true that I was able to correctly interpret “pix, flix, and aud” as “Images, Movies, and Audio,” but it took work. More work than I care to give an application. Applications are supposed to make my use of them effortless and fun. It’s not fun to cringe at what look like typos in the UI. Furthermore, there is no easy distinction for me between “fx” and “my Fx.” I can sort of guess at the distinction, but since this application came with a bunch of items already in “my Fx,” I can only argue that they are in fact not my Fx, they’re Stone’s!

5. Ouchy Selection Feedback. Ouch! It hurts when selecting something in a matrix turns the background white, puts a selection rectangle around two UI elements at once, and invokes a time-honored cue (or something close to it) for letting the user know that they are now editing a text label, when in fact they are not. This is yucky! Use a standard selection-indicator convention. Enough said.

6. Extreme Lack of Contrast. Part of the problem with the white-background above is it draws to light just how much metal there is in the window, and how much less of it there should be. If the background to this matrix view and the one below it (label #8) were white, it would probably increase the overall ease or parsing the visual landscape, while making it easy to use a conventional selection metaphor instead of the invented yucky one above.

7. Ellipsis Abuse. The presence of the ellipsis symbol in Mac OS UI has a long history as a cue to the user that invoking that item will present further UI interaction. In other words, get ready to answer more questions. So what’s the difference between a plus sign and a plus sign with ellipsis? In this case, both buttons present document-modal sheets. But get this: the one without ellipsis is for saving a new gallery, while the one with is for reading one in from disk. The tool tips for both use the word “New” to the exclusion of either “Import” or “Save”.

8. Messy Overlap City. This is not a contrived situation. I just rearranged the panes in the application to my liking and resized the window to a certain smallish size. Suddenly I’ve got two or three UI elements all vying for this space of the UI. That looks like crap and tells me that the author either expects me to “look out for myself” when resizing the window, or they don’t care whether it’s easy to make their application look even more yucky than it first appeared to be.

9. Freaky Disclosure Thumb. What is this backwards disclosure triangle doing in the middle of my screen? It turns out it’s a split view thumb. Why invent a custom split view thumb that happens to strongly resemble a standard UI element with much different connotations? In a very twisted way, it does sort of behave like a disclosure triangle. Only, it never faces downward like a standard icon would. Its main innovation over a standard split view icon is that it points in the direction that the pane would expand or contract when clicked. And it only requires one click to expand or contract. But it also behaves as a draggable thumb, and is all in all very insulting to my understanding of what a little triangle should do on a Mac window.

10. Clunky Movie View. There’s nothing to see here in the snapshot. I just thought I’d point out that whenever you resize the window, the entire movie disappears, leaving a bare metal background. Mac users like to see instant feedback. We gave up things like the grey “resize rectangle” a long time ago, in favor for a live view of our resizing UI elements. In this case, a return to the crummy looking grey rectangle would be an improvement over the “disappears and reappears” behavior of this app.

11. Yet Another Image Export. Maybe. This icon offers the ability to take a snapshot of the screen. Something seemingly similar to the funny image export type/well (label #3). But in this case clicking the snapshot icon causes a sort of timed countdown before the image gets captured. Not really sure what this is good for, but I assume it’s so you can say “I’m going to take a picture of myself” and then smile all pretty like for the camera. One annoying UI aspect of this button is that it went disabled for me in one document and I can’t get it to come back. There may be a logical explanation, but to me that feature is now gone since I can’t get it to re-enable, and the help tags don’t mention anything about this scenario.

I suppose this laundry list of complaints might just make me sound like more of a cranky misanthrope than before. But it’s the damned-straight truth as I see it. I think all of these criticisms reflect areas where Stone could seriously improve the usability of his application without diminishing at all from the “Coolness Factor” that was rightly identified by people like Bill Bumgarner. In fact, the only thing cooler than a freakin’ cool app is a freakin’ cool app with a usable interface. Constructive enough for you?