Table or Booth?

Introducing the WACD Methodology

Pronounced 'whacked', WACD is short for:

• W - Wild
• A - Ass
• C - Cowboy
• D - Development

Key WACD Tenets

• Use IDD (Instinct Driven Development). After all, you’re the one who has to build it.
• Always code alone. Other opinions rarely help, so, in the end, they just slow you down.
• Always don’t test. You know what you're doing. Like opinions, this is just more drag.
• Document when asked but never again. You’re not a writer. Who’s going to read it anyway?
• Keep information to yourself. Anything else just risks you losing your job.
• CM with zip. You're stuff is archived. You know where it is – that’s all that really matters.

Benefits of a WACD Team

• Overdue projects
• Low levels of usability
• Lots of application bugs
• Costly O&M
• High staff turnover

RIAs - The New Web UI

SproutCore is slick; has a RoR + Apple pedigree & leverages Javascript very nicely.  MobileMe integrates it.  Apple contributes heavily to the project.  Silverlight, AIR, and Google Gears compete.  Silverlight and GG require browser plug-ins.  Only GGs is open-source.  Here's a good overview: http://rapidappsgroup.com/content/desktop-web-applications-using-sproutcore/

Yellow Pages.com Rewrite

Lessons Learned:

• Freeze existing functionality
• Field small, co-located, talented team (4 developers)
• Dedicate long technology evaluation, prototyping, and planning period
• Assign technical decision maker and communicator to management
• Leverage UX team: all page design and HTML gen, then give to dev to slice up and wire
• Change only the obvious
• Deploy beta frequently and actively recruit feedback  

RailsConf 2008

I'm at RailsConf.

Portland, Oregon is, well, Portland (overcast and wet). Got in late last night and walked over to Stanford's. The service was friendly, even at 10:30 PM.  Everything about the burger was above average.  And it came with hot, crispy, slightly salty fries.  It was all devoured with sips of a local wheat bear that I forget the name of.

So far, having been away from Ruby and Rails for over a year, it feels like going back to a place you used to live. Some things are still the same. In other ways, I hardly recognize the place.  New techniques like elastic computing (and plenty of competing commercial hosting options), new tools such as git, tarantula, and hobo, etc.  Good stuff.

I'll pretend I blog and let you know how it all goes.

Book Review: Sketching User Experiences by Bill Buxton

Sketching User Experiences:  Getting the Design Right and the Right Design (Interactive Technologies), by Bill Buxton, is an excellent read on the scope, purpose, and implementation techniques for designing good user experiences.  Buxton's narrative style is easy, warm, and conveys his rich experience and passion for the subject.  He includes a rich set of stories and case studies that demonstrate the importance of design and techniques for doing it.

Enterprise Bearware

The price customers pay for software and the level of usability they get with that software is inversely proportional.  As long as it solves a big business problem or two, it doesn't matter how easy it is to actually use the stuff.

Romantic Keyboards

Advanced users need toolbars like Lance Armstrong needs training wheels.  As application designers and programmers we must pay attention to how user needs change as they progress towards advanced user status.  And, in doing so, we must help them to learn and maximize the right tool for the job.

Opting for Opt-in

"News and updates" pollute our mailboxes every day.  They're not always the infamous kind of spam we all know and hate; now they're 'newsvertisements,' sent to you because of that little, afterthought-checkbox at the bottom of on-line account sign-up forms.  They're usually checked by default.  At the rate new web apps are created, this is an increasingly common occurrence.

The M/VC Antipattern

Introduction
M/VC may be more familiar as "MVC," or Model-View-Controller the design pattern used in the Smalltalk environment [KP88] and cemented as the "Observer" pattern in Design Patterns [GHJV95] by the Gang Of Four.  In real life, subconsciously plowing along with M, then V, then C often leads to MV with little or no decoupled C.  Call this M/VC.  With controller code woven deeply into your view, it becomes nearly impossible to later switch the view out.

Eclipse Con 2005: Seamless UI Integration

This was a good topic by Julian Jones, the usability 'gatekeeper' for IBM's Eclipse tools.  The PDF has details but here's a quick summary:

• Don't harden UIs early.  Consider them loose and changeable until close to the final release.  Note: This implies clean model-view-controller separation and keeping a light view.
• Try out divergent ideas by shipping them in milestones (or the equivalent).  This encourages "natural selection" of good UI patterns.
• Use 'centralized planning' only where it is truly necessary.  Example: Eclipse's unified Help TOC.

On enforcing tight UI integration between disparate plugin development groups, Julian suggested that the dictatorial approach will never work and to use a 'gatekeeper' for publicizing good UI examples.  I agree.  IBM publicizes new UI features using formal walkthroughs.  He sights the PDE Overview page as an example of a good, internal UI-pattern that grew organically this way. 

The gatekeeper also manages decisions regarding ugly UI overlaps.  Currently, there is an ongoing discussion about how to resolve GEF sliding-pallettes, icon-bars, and side-bars in 3.1M5, which all effectively do the same thing but target vastly different users.