Someone by the name of Nando posted his Model-Glue cheat sheet to the Model-Glue discussion group. I took the time to clean it up and make it a little more readable, and fit onto two pages. I've printed it out as front and back of a single page, and keep it with my laptop for reference. I think I'll also add it to my sidebar for easy reference. Thanks to Nando for doing the leg work. I just made it pretty! Click the thumbnail to download the PDF.

Ok so in all seriousness I wasn't a special guest or anything, but I did get the opportunity to participate in the recording of Episode 4 — released early this morning — and I couldn't pass it up. I'll do my best to get links together for everyone that participated, but I don't think they all have a blog or even twitter account — or I may just not have them all. Sorry if I miss anyone! (But tell me, so I can update the list…)

• Host and Discussion Leader: Brian Meloche (and of course, operator of cfconversations.com)
• Adam Haskell, who wasn't in the BOF/session, was also part of the Podcast.
• "PHP Reformers" group:
  • Myself,
  • Seth Bienek,
  • Ken Auenson,
  • Chris Hough, and
  • Tim Farrar

• "New Blood" group:
  • John Farrar,
  • Brian Swartzfager,
  • Rick Mason,
  • Dana Tierney,
  • Ezra Parker, and
  • Jeff Coughlin

I'm not going to spoil the podcast for you, but I thought it might be interesting to write about some of the things we discussed in our BOF-turned-session (… turned-podcast) that didn't go into the podcast. The BOF was, of course, part of CFUnited 2008. The exercise was to brainstorm ideas for promoting CFML outside of the CFML community, and then to pick the best ideas as a group, and come up with a potential strategy for implementing them.

One person in each group was assigned the task of thinking of ludicrous ideas that would never get implemented. My perception of this role was that it was there primarily to set the tone in the group that there were no limitations — that no idea was too grandiose — and that the important thing was just to get the creative juices flowing, and sort out the good from the bad later. I have to say that I think this was a brilliant move on Brian's part. Here are some of the ideas that the PHP Reformers group came up with that, while … "interesting" … didn't get voted high enough to be given much attention. I suppose I should preface this by saying that these aren't intended to be condescending or hurtful to the PHP community, a majority of these came from our designated ludicrous idea contributor.

• Write a PHP Virus (Written in PHP? Attacks PHP? Who knows?)
• "Adopt a PHP Developer" week
• Free hosting
• CF vs. PHP commercials (ala Mac vs. PC)
• Spy on PHP for new feature ideas
• Get a CF Mascot / spokesperson
• Hold CFUnited @ Hooters Casino in Las Vegas
• Buy CF and get a mail order bride
• Guerilla warfare — Join the PHP team and sabotage their codebase
• Make star wars style movie for CF
• Nascar driver for CF — Adam Haskell actually mentioned this in the podcast…
• Rent a blimp
• Two words: Superbowl Ad
• <CFPorn />
• Celebrity Advocation
• Smear campaign against PHP (Bad spokesperson, false rumors, etc)

Can you build on this list? What other ways (again, the point is to be over the top!) could you convince more PHP developers to learn CFML?

Having never done anything with Flex before, I hope to get a fairly basic intro — how to get started — but at the same time, see an overview of the neat stuff you can do with Flex, in order to get some inspiration to learn it. We'll see how it goes…

• Adam says that the hardest part was just getting up and getting here this early (8:30am). It should all be downhill from here.
• "Flex is just a framework for writing ActionScript."
• Rather than HTML, we use MXML (Macromedia XML Markup Language — they really though that one through!) and ActionScript.
• Can communicate via SOAP, HHTP/S, AMF/S (Flash Remoting), RTMP/S. AMF is binary, so really fast.
  
• Flex SDK is the compiler: command line, free. 
• Flex Builder: Nice UI for Flex SDK. Professional eddition for charting, advanced data grid/OLAP, and performance profiling. Very nominally priced at $250-$700! 
• LiveCycle Data Services seems like ADO.NET data management. Enables their equivalent of "disconnected mode" with offline work & re-sync when you come back online — but somehow, seems even easier! 
• BlazeDS: is a free, open source product, very similar but not as full featured as LCDS. Offers real time data push to clients!
  
• Data Services is not required for Flex.
  
• Flash Remoting is baked in and has been available since CF 7.01.
  
• Flex uses {} as CF uses ##.
  
• Use <mx:RemoteObject …> to create an object that will communicate with CF.
  
• Flex's <mx:Application applicationComplete=""> is like HTML's <body onLoad=""> "mate" (pronounced "mah-tay") is Adam's recommended Flex Framework.

Start at the bottom of this post and work your way up.

3:44: I just realized that I got the numbering different from Joe's presentation. I don't know what, if anything, I missed. Whoops!

3:40: #8: Remoting. Available for Flex, etc. Not all requests have to come in from index.cfm, they can come through the remote CFC. I guess this would make more sense to me if I ever did anything with Flex.

3:36: #7: Formats! Various view-styles (HTML, XML, JSON, partial pages, etc) without duplicating events. All within one event-handler tag! Building web services within an MVC application in CF has never been so easy.

3:27: #6: Content cache. <event-handler name="page.home" cache="true"> I asked if you can setup the cache to be "disabled" in development mode even with caching turned on in the XML (so this doesn't have to be changed between production and dev environments) Joe says no (but interesting idea!), but a workaround would be to set the cache timeout to 0 in development. Programatic access to the cache manager is available, but the cache adapter provided is intended to be dead simple. If you need more than time-based caching, you're encouraged to implement your own.

3:25: Bean Injection! Yay! Auto-wiring without all of the manual labor. <cfcomponent beans="someDAO">

3:21: #5: Helpers. Works for both .cfm and .cfc. Easy way to inject UDFs or a library of them into your application, in a special scope (variable) called "helpers." Usage: #helpers.dateLib.daysTilXmas(now())#

3:15: #4: SES Urls baked in and a URL Manager. The component that handles this is wired in with ColdSpring, so it's easily replaceable if you don't like the default URL format or need something custom. URL manager now means linking is as simple as: #event.linkTo("myEvent")#

3:12: Third new feature? Application.cfc integration: onSessionStart/End, onApplicationStart, etc.

3:10: Second new feature? Event Types. This was discussed on the Model-Glue mailing list a bit, and some folks were unhappy about the implementation being in CFCs, as it is kind of configuration information; and then we'd have config in both XML and CFCs. Several people chimed in and asked for an implementation as XML. Joe says that it was committed yesterday (no documentation yet) so now we have either option. Awesome! Event types are almost like AOP, but more like decorators; you can add a before or after set of code for any event type. Cool stuff, I can't wait to play with this!

3:02: First new feature? Streamlined Workflow. Wiring is necessary, but predictable. When running in development mode, with the feature explicitly enabled, Model Glue will generate events for you. This is somewhat old news, but still just as exciting. Event Generation will also add CFCUnit/CFUnit test stubs. Cool!

2:57: Looks like we're almost through the history of Model-Glue, and about ready to get into new features. I seem to remember Joe writing somewhere that he would announce something as of yet unannounced here at CFUnited. I hope I'm right. :)

2:53: Joe asked if there were any Mach-II developers in the room, and decided he wasn't at too much risk of being hurt for things he would say. Snicker.

2:50: It looks like his preso will be mostly building on the "Roadshow" PDF that comes packaged with the v3 release candidates.

2:47: Here we go! (Can you tell I'm a little excited about this one?)

2:40: I thought Michael Dinowitz would never shut up! I'm pretty sure he went way-over his time for his Google Webmaster Tools preso. He's out now though, and folks are starting to pile in for Joe's Model-Glue preso.

This session isn't just about AJAX, it also applies to using DHTML to change pages — More appropriately: Non-Flash RIA's. Just like OO, design patterns can apply with usability too. UI design patters are starting to emerge.

Top AJAX Usability issues:

• Breaks the back-button
• Use fragments (#) to change URLs as actions are taken (See: Gmail url's changing while you navigate around your email)
• Use a library with history management
• Offer an undo option

"New-Fangled Web" – Brand new conventions

• It takes years for a nidea to become a convention
• Follow established design patterns: shift-select (traditionally found in lists) can be used for checkboxes and possibly elsewhere.
• Provide contextual guidance: use icons, hover elements, etc, to indicate in-place editing available.
• Provide a traditional alternative (in addition to neat things like sliders or date choosers, allow standard text input as well)

"Whats this thingamajig?" – use things people are familiar with.

• Users may struggle with: sliders,
• Provide a standard input in addition
• Use a large hit area

"Did that just work?"

• Give the user visual feedback
• When there's a wait (progress bars, spinner, etc)
• When something changes (can be too fast!)
• Judiciously use animation
• Add contrast, color, and highlighting
• The "yellow fade technique" – draw attention to changed information or messages, and then fade back to normal (I hear this should be a piece of cake with jQuery!)

Distratction vs. Frustration

• Don't distract the users focus with too much too fast
• Don't frustrate the user with slow response times
• Watch auto-suggest/type ahead delay
• Give generous delays on hover menus
• Optimize performance, load smart

It's not you, it's the site!

• Think out the interactions and test, test, test!
• Compensate for different environments (other browsers, resolutions, etc)
• Use a tried and tested framework
• If you can't do it right, don't do it! (Don't reinvent the wheel)

I'm not seeing it…

• AJAX may be heavily mouse-dependent and visual
• Non-standard controls aren't supported by assistive devices
• Screen readers can't tell when a page changes
• Use semantic markup with progressive enhancement
• Alternative content may be necessary
• Screen readers are getting better (W3C-ARIA)

Good, Better, Best

• Make it work without AJAX first
• Then add AJAX enhancements – unobtrusive design: add JS functionality with JS so that non-JS supporting browsers and devices still function
• have keyboard-navigable alternatives to rich controls
• keep mobile in mind!

Avoid AJAX as an afterthought

• Make rich interaction a key part of the design process
• Add it to solve problems, not just to add "sizzle"
• AJAX changes traditional design paradigms

Designing for Rich Interaction Applications vs. Sites Websites: The user's primary task is to move around an information space and read its content.

Applications: The user's primary task is to change … (She moved too fast through this slide and I couldn't get all of it…)

Great example: Flickr — browsing someone's photos acts like a website, managing/organizing your photos acts like an application Using AJAX to improve usability

• Eliminate circular flow
• Provide instant feedback for errors and validation
• Auto-save (sometimes — use drafts where appropriate. Examples: GMail, WordPress)
• Show contextual help/menus
• Streamline data entry (auto-suggest, type-ahead)
• Enable direct manipulation
• Look up the pattern!

More information:

• Rachel's AJAX Usability Bookmarks: http://del.icio.us/rmaxim/ajax-usability
• Techniques: http://dev2dev.bea.com/pub/a/2006/01/ajax-back-button.html?page=1
• Code libraries:
  • http://code.google.com/p/google-axsjax/
  • http://www.dojotoolkit.org

• Design Pattern Resources:
  • http://www.designinginterfaces.com
  • http://www.welie.com/patterns/
  • http://developer.yahoo.com/ypatterns/