Murray Thompson — Fri, 07 Jan 2011 19:41:50 GMT

Widely understood patterns that are used across platforms and languages exist in the object-oriented programming (OOP) community. If you say “abstract factory” folks would know what you’re talking about. Having this widely understood base also allows tools and frameworks to be based on top of them. I’m not sure if a hierarchy is really needed, but a standard approach to a strong set of commonly-used UI patterns would be very beneficial, as Patrick’s article mentions.

On making standard: With OOP, even though folks were likely using some of them before without the patterns’ labels, the “standard” patterns were established with the watershed “Gang of Four” book and most has come off of that … it just happens that we already have a number of great references that don’t necessarily share the same language. If the authors of the existing libraries, along with the rest of us, could agree on some standard patterns, including names for them, it could help make tham way more accessible to many folks. We need some kind of common reference to work from, but does not require a central authorizing pattern body. Patterns that work should survive out there in the wild… but they do need to be documented by someone and given a name everyone can use to mean the same thing. Maybe B&A is a good hub to establish this?

On variants/deviation: Patterns help check for common solutions, i’s to dot, and t’s to cross. Instead of starting everything from scratch, a pattern encapsulates ideas and approaches to implementation. Yet the nuts and bolts of how a pattern is applied in context is even more important, and still requires insight on how the interact with the whole in each case. This is where variants are created and applied, and doesn’t mean that they are in conflict with “the official” pattern. Patterns are living documents based on well-understood behaviors and structures: they may stabilize as they mature, but as more insight about them is gained, they can still change and new ones can be found (or in-house libraries made to encapsulate the variants within the organization).

On using code: I think if standard, industry-wide UI Patterns can be aggreed on, the patterns themselves should remain in the domain of UI, and avoid references to code… having code would stretch them too far. The community could add examples of how to implement them in a web page or whatever, but the pattern itself should only be concerned with the actual front-end UI elements. I think the references Patrick mention already steer clear of code specifics.

Boxes and Arrows: Comments by Murray Thompson