Determining the Aqua UI appearance on MacOS X

Due to high workload at the day-job, I haven't been able to keep my schedule regarding the experiment building a Ribbon custom control for LiveCode. It's still going to happen, but is going to take a bit longer than planned. In the meantime, I will post some tidbits that are relevant to those that design custom controls for LiveCode.

In MacOS X, the Preferences application has a panel titled Appearance:



Yeah, I know I'm still on MacOS X Snow Leopard 10.6.8 - just waiting for Lion 10.7.2 before I upgrade.
Anyway, the Appearance option menu has two entries: Blue and Graphite.



Below that option menu, is the Highlight color option menu; and if we want to know this color in our LiveCode scripts, all we have to do is check the global 'hiliteColor' property. But there's no built-in way to access the Appearance. So how can we get this information? Do we have to write an external to find out whether we should have blue or graphite custom controls?

As it turns out, we can get at this system setting by using the 'defaults' command via the 'shell' function. Just plop the following in a button script:

on mouseUp
   local tVariant, tAppearance
   put word 1 to -1 \
       of shell("defaults read -g AppleAquaColorVariant") \
       into tVariant
   switch tVariant
      case 1
         put "Blue" into tAppearance
         break
      case 6
         put "Graphite" into tAppearance
         break
      default
         put "Unrecognized appearance variant [" & \
             tVariant & "]" into tAppearance
         break
   end switch
   answer tAppearance
end mouseUp

Click the button, and depending on your operating system and preferences setting, you'll see the appropriate message. It appears that at one point there were a few more appearances, but they were lost during a chopping frenzy in Cupertino. Be that as it may, you now have a way to check for the appearance setting in the preferences window.

UI Design Essentials

My design skills are limited to stick figures - and even then, people will react "Is that a MacBook the guy is holding?" - "No, that's a chihuahua peeking out of her purse..." Nevertheless, as a commercial software developer, I need to somehow be both a programmer and a designer, at the same time.

And when you cater to the Mac market, you're talking about the platform where applications have to bleed coolness - often with ground-breaking user interfaces, like Delicious Library or Apple's iApps. Following the platform's interface guidelines is only half the work: your job is to provide an elegant user interface that conveys information in an efficient manner, interacting in a compelling way at the same level as your target user.

Granted, I make database front-ends for a living. The boring kind of applications: accounting, order processing, and all that happy fun stuff that involves storing data in and loading it back from a database, and providing reports and statistics so that the end users can do their job. In my time, I have seen plenty of applications that were built from a developers' point of view. Which means it's logical, in a way, though not necessarily matching the user's line of thinking.

If you're lucky, the team that built the thing in the first place, took the time to read up on human-computer interaction, and tried to learn from the other applications out there. And if you're really lucky, they had someone on their team smart enough to say: "It's not enough to have menus and windows and buttons, but we should make sure that all elements in our application work consistently, as this will cut down on user training and support calls."

But I didn't mean to step onto the soapbox here - I just wanted to point you over to this entry on the Theocacao website - a blog for Mac developers, written by Scott Stevenson, who also maintains the Cocoa Dev Central learning center. You can fetch the slides of his UI Design Essentials talk as well as a movie recording. It may take a while to download the 532MB QuickTime HD file, but it is well worth it.

He talks about the history of developers and designers in software development, and although he can't make you a designer in as short a timeframe as an hour, he does make excellent points and offers practical advice. Specific topics touched include: the basics of iterative design and usability testing, the use of whitespace and partitioning, correct labels and prompts, as well as fonts and language design, covering inspector palettes and icons in the process.

He also ran through a real application that someone was brave enough to submit, pointing out design flaws that turn this functionally excellent application into something users can get to work by themselves, but could be so much better and easier to use by making a number of tweaks. In the wrap-up, he mentions a number of 'model citizens' that we should look at. Some of the best bits came up during the Q&A session at the end, which is only available in the video recording, unfortunately.

As you wait for the download to make its way to your computer, you may also want to chase down these books:

• Designing Interfaces by Jenifer Tidwell (O'Reilly)
• About Face 3 by Alan Cooper, Robert Reimann and David Cronin (Wiley)

While the latter is a very theoretical book which goes through great lengths to match up the implementation and mental models of developers and users respectively, the first book has great tips on how to improve the user interface of your desktop as well as web applications, filled with screenshots and explanations in a very readable format.

Of course, there are other resources out there, but I'm not going to add much more to this post - instead, I would like to encourage you to go out and look at applications that you use every day, and write down what you find annoying and what you like about the way it interacts with you as a user. And the n try to repeat what thery do right, and avoid what they do wrong.

While Quartam Reports works the way it does, as it was modeled after the Report Builder that shipped with Foxpro, it's not going to stay that way forever. I've already been prototyping a complete overhaul for a while now, and hope to make it a reality for version 2.0 - balancing between the "let's just get it over with" mindset of a developer who has to develop 189 of those pesky things, and the mindset of someone who is perhaps less-seasoned in the raw developing process, but has a good idea of the end-product and how it should turn mere facts into empowering information.

In the meantime, there's plenty to learn and consider and tweak, as usual... Not to mention plenty of code to toss and rewrite... It just never ends, does it?