I’m currently writing a few dialogue and interaction menus for my current AIR project, and the thought had occurred to me that having established a reasonable methodology for handling and displaying modal dialogues within my Cairngorm-based app, I was perhaps using them almost by default, without thinking too carefully about whether a modal dialogue was the most appropriate means of interaction. By modal in this context we mean “A state of a dialogue that requires the user to interact with the dialogue before interacting with other parts of the application or with other applications”.

At the same time, Chris and I have been talking about metadata recently (another entry to come, but the premise was that persuading users to input metadata about assets is hard to incentivise). Related to that, Chris sent me this great link to an entry by Jeff Attwood that in turns talks about an entry by Eric Lippert on how dialogue boxes are perceived by users:

* Dialog boxes are modal. But users do not think of them as “modal”, they think of them as “preventing me from getting any work done until I get rid of them.”

• Dialog boxes almost always go away when you click the leftmost or rightmost button.
• Dialog boxes usually say “If you want to tech the tech, you need to tech the tech with the teching tech tech. Tech the tech? Yes / No”
• If you press one of those buttons, something happens. If you press the other one, nothing happens. Very few users want nothing to happen—in the majority of cases, whatever happens is what the user wanted to happen. Only in rare cases does something bad happen.

In short, from a user perspective, dialog boxes are impediments to productivity which provide no information. It’s like giving shocks or food pellets to monkeys when they press buttons—primates very quickly learn what gives them the good stuff and avoids the bad.

I liked that, especially the bit about “Teching the tech” – while it’s quite funny it’s also a pretty accurate reflection of my experience as a user.

This is also related closely to what Chris and I were discussing about metadata; expecting the user to fill in information that has no obvious purpose and slows down the primary task of upload/publish or whatever it is that they are trying to do, is likely to be ignored. If those fields/dialogues are modal or conditional, it’s worth thinking carefully about whether there are alternative ways to complete the operation or gather the infomation. That’s harder to do of course, and there are cases where modal dialogues should be considered appropriate, e.g. where the application is about to do something destructive like deleting or overwriting a file, but there are alternatives, like how IE and Firefox avoid breaking the flow of interaction when blocking certain actions.

Kudos to Adobe, Google and Yahoo for creating the mechanism for Flash content to be indexed on search engines. With one or two reservations (like how to distinguish between application content and a site) I think this is another significant move towards maintaining the ubiquity of Flash. It seems as though Adobe is steadily, but impressively quickly, removing piece by piece the most-cited drawbacks of Flash. Some of the most significant announcements (in no particular order):

• H.264 video support
• Open-sourced Flex SDK, BlazeDS
• Opened access to Flash Player APIs
• 3D support (thanks to Papervision, Away3D etc.)

Obviously it doesn’t take a genius to work out that, in part, Adobe has had to make some of these moves – HTML5, advances in Javascript and browser technologies promise or already offer many features that up until now Flash had to itself; the canvas and video tags in HTML5, DHTML effects, processing.js, SproutCore, the list goes on – it was inevitable that some of Flash’s functionality would be adopted and integrated into other technologies, but I think that those people who still maintain that they ‘hate Flash’ should still agree that it has been a primary driver of change on the web. This is particularly true in three areas; animation, user experience and video. Flash may responsible in their eyes for evil banner ads and inaccessible sites/UIs, but those things are created by people, and a technology that provides a degree of creative freedom is open to abuse – there are plenty of bad DHTML sites around and more than a fair share of annoying DIV-based floating ads out there already, but there is also a great number of fantastic and successful experiments in user interface design, animation and application experience. Flash has enabled developers to do things on the web they could not have easily done by other means, and those people that attribute bad practice to Flash are both ignorant and in for shock if they believe the same things won’t happen when other technologies catch up. Up until now it’s been far too easy to blame Flash, when Flash isn’t the problem. Use it where it works, not where it doesn’t (like whole sites).

In addition to the technology itself, Adobe has provided the means to develop and deploy it effectively, with the Flex SDK and FlexBuilder. Personally I have no objection to proprietary technologies when they a) work, b) don’t break anything and c) positively drive change and allow people to do things that standards-based technologies often take much longer to enable (and often not quite as well). Flash and Flex won’t be the standard, they will peacefully co-exist with other technologies (along with man, and fish); a single unified standard just isn’t possible in a competitive world, nor is it always desirable. Someone has to innovate, and attacking Flash (or Apple come to to think of it) for being proprietary is like attacking Ferrari for making a better sportscar (and charging for it). If it enables you to go faster, better, and (similar to Java and JS) is on 90-something% of desktops, who can blame Adobe for adding features and functionality that will maintain or increase edge and adoption? And at the same time if it is making key components of its platforms open, regardless of motivation, it’s A Good Thing*. So long as the standards do catch up, it’s fine.

There is I think, one thing left to do at the moment, the final hurdle as I see it – accessibility. It’s kind of in there, but if Adobe could make Flash and Flex as accessible as a typical web page, or at least as easy to make accessible as a web page, it would remove the one last stick with which it gets beaten. In fact and to bring this full circle, the same mechanism by which search indexing now works may also prove the key to unlocking accessibility, so maybe that’s already possible?

*None of these arguments apply to Microsoft, especially the Ferrari analogy. Silverlight is neither better or faster.