Of course, people don’t want to hear me say that they need to test their UI. And they definitely don’t want to hear that they have to actually move their precious butts to a customer location to watch real people do the work the application is supposed to support. The general idea seems to be that real programmers can’t be let out of their cages. My view is just the opposite: no one should be allowed to work on an application unless they’ve spent a day observing a few end users.

Software exists to solve problems. To understand the problems a proposed software application is supposed to solve, nothing beats walking a mile in the user’s shoes. (37signals calls this What’s Your Problem? in their book Getting Real.)

The first items aren’t that interesting. A 360|Flex folder and an Effective UI graph pad I picked up off a table while at that conference (thanks, guys!). I plan to use the graph pad to layout some screens for an upcoming project at work and want to keep it handy in case inspiration strikes. I’m still waiting for that inspiration.

Then I pulled out a two inch thick collection of papers I’d printed (duplex, to conserve paper). On top of the stack is D-Click’s Adobe Flex Coding Guidelines. I really don’t like placing opening braces on their own line. Drives me nuts. (For my money, the Sun Java Coding Conventions can’t be beat.) But, when in Rome, do as the Romans do. I recognize that being consistent (especially across developers on the same team) is more important than the merits of any single convention, so I’m trying to learn new habits.

Next up are printouts of six chapters from Adobe’s Building and Deploying Flex Applications (PDF here). I have only built Flex apps inside of Flex Builder, so I still need to learn the command line tools. My company is big on “repeatable builds”—meaning that any interally-developed production applications should be easy to regenerate from source without developer involvement. In practice, this means that the application must be built with a command line build script (Make, Ant, etc.). Besides, I get nervous when I’m overly dependent on an IDE. I like code completion, syntax highlighting, and refactoring, but I really like to know that I can do it all from vi or Notepad and the raw Flex SDK if desired or needed. Hence my interest in the Building and Deploying Flex Applications book. And I mean book! A full printout would weigh in at 400+ pages! So I picked the most important parts to me and just printed those.

The first chapter is Chapter 3 (Flex Application Structure). I just finished reading this chapter last night. Not a lot to say here. It’s good to have the layout with which I was familiar due to Flex Builder reinforced in print. Next up are Chapter 4 (Applying Flex Security), Chapter 7 (Building Overview), Chapter 9 (Using the Flex Compilers), Chapter 13 (Using ASDoc), and Chapter 14 (Creating Applications for Testing).

Then I come to printouts of various O’Reilly articles about Ruby on Rails that I intend to read Any Day Now™. Rolling with Ruby on Rails Revisited, Cookin’ with Ruby on Rails: May, Cookin’ with Ruby on Rails: Designing for Testability, Cookin’ with Ruby on Rails: More Designing for Testability.

And finally, I have Greg Hamer’s presentation slides for introducing Cairngorm at 360|Flex. I suppose I can take this out of my bag. I have the general idea of how Cairngorm works. I’m still waiting to write an app large enough to make playing with Cairngorm worthwhile. Okay, that’s not quite right. I’m still working on my first Flex app ever. I’m plugging into the 37signals Backpack API. When I’m done with that, I might look at refactoring it for Cairngorm just to get that experience under my belt.

And that’s wy my computer bag weighs a ton. What’s in your computer bag?

Flex developers come from a wide range of backgrounds. There were some management types and UI designers sprinkled in the mix, and I found that these people had the best questions and comments during the less technical sessions (e.g., “Design Eye for the Dev Guy”). About half of the attendees were designers—most with a strong background in Flash, but some Web (HTML/CSS) designers as well. The other half of attendees were developers—lots of .NET developers, a healthy batch of Java developers, enough Ruby developers so that I didn’t feel lonely, a handful of ColdFusion holdouts.

There were some areas where the conference could have been improved, though—most were related to communication.

• If I had known up front that the sessions would be video recorded and made available later, I would have been more inclined to join the Flex 101 and AIR 101 hands-on sessions, since I could watch the recordings of sessions I missed later.
• It wasn’t clear to me that the Flex Charity Code Jam (more, more) was intended to be a learning experience. I felt that as a Flex newbie, I wouldn’t have much to contribute.
• The vendors, who made it possible for me to attend an amazing conference for only $360, were tucked in a room off in the corner. I would have switched the chill-out room and the vendor room to give the vendors more presence. I swung through the vendor booths twice to pick up their marketing material note all of the URLs to research later. Thanks, vendors!

Beyond that, I agree with everything David Coletta said.

Unfortunately, way down in the VueScan release notes, under “Mac OSX Release Notes” is this little clause: To use the Epson Perfection 3170, 4180 or 4490 with VueScan, you need to first install the Epson software for this scanner.

Grumble, grumble. I missed that earlier. So I went to Epson’s Web site and downloaded just the OSX driver. The driver’s installer is a bit strange — it creates a folder with another installer inside of it — but when I was done running that installer, it seems that Epson’s driver was present and no new unwanted applications were to be found cluttering my drive. Therefore, I’m not overly upset with the need to install an Epson driver. [Updated 01Dec@2203: In fact, the installer did drop two applications into /Applications: Epson Scan and Epson Scanner Monitor. If no major harm comes to my system from dropping them in the Trash, then I'm still okay with the whole thing.] VueScan detected the scanner the first time it was launched after the driver was installed.

I haven’t used VueScan at all yet, except for a quick proof-that-the-scanner-works scan, so I can’t give a review of its performance. I can say that its UI is very functional, but lacking aesthetic appeal I’ve come to expect from Mac applications. It’s like a UI I would design, rather than the UI a good Apple developer would design. I’ll probably have more to say later once I’ve used VueScan some more. Oh, and I’ll probably have some feedback about the scanner, too. Sometime. In the future.