Comments on UI Pattern Documentation Review

Patrick Stapleton — Wed, 15 Jul 2009 22:42:33 GMT

In many respects Jonathan I agree with you, anti-patterns would seem to be less restrictive. However in the situation where user experience leadership is required, patterns probably deliver more value.

Jonathan Baker-Bates — Wed, 15 Jul 2009 22:34:33 GMT

Personally, I’ve always been more interested in documenting anti-patterns. There’s too much danger of design constriction when attempting to describe in any detail what works. Better to record what doesn’t (and why). To put it another way, here’s what one of the fathers of engineering said about what were in effect design patterns for bridge builders:

“[I am] opposed to the laying down of rules or conditions to be observed in the construction of bridges, lest the progress of improvement tomorrow might be embarrassed or shackled by recording or registering as law the prejudices or errors of today.” – Isambard Kingdom Brunel

Eric Mariacher — Fri, 10 Jul 2009 19:25:39 GMT

Here is a classification done on a similar problem: http://www.visual-literacy.org/periodic_table/periodic_ta…

I find it especially efficient.

Harald Felgner — Thu, 09 Jul 2009 11:53:56 GMT

http://uipatternfactory.com/

Harald Felgner — Fri, 07 Jan 2011 19:39:22 GMT

6. Janne Lammi’s UI Pattern Factory, sharing UI patterns via flickr, which is the way to go …

Mike Scarpi — Tue, 07 Jul 2009 17:54:17 GMT

This site is pretty interesting. It’s meant to highlight Microsoft’s Silverlight, but also categorized patterns by type -

http://quince.infragistics.com

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.

Patrick Stapleton — Fri, 03 Jul 2009 02:37:16 GMT

The ability for designers to find the right pattern from a large number of available patterns is key. In my opinion the creation of a standard documentation approach for UI patterns could be a platform to enable the interconnection of libraries (or individual patterns). I can imagine a site where pattern consumers can search/browse thousands of patterns up-linked by hundreds of pattern designers.

Juan Lanus — Wed, 15 Jul 2009 17:30:59 GMT

Luis Soares (two comments above this one), actually if the consumers of the patterns can’t find them there is an usability issue. Usability of the internal system, I mean.

It’s not only a matter of publishing a list of patterns but also making them reachable to the consumers, as you said.
Thus, the publishers should not rely on the consumers looking for an exact term but instead opening the list of terms as in the web pages “keywords” meta tag.

If the users are allowed to enter the name of the concepts that led them to a particular pattern then a semantic network would build.

Another method is to publish mockups of already dome work with the contained artifacts linked to the pattern used in the solution.

Juan Lanus — Fri, 07 Jan 2011 19:40:22 GMT

Interestingly, this same issue of B&A has an article about using wikis for UI docs, which can be a starting point for The Repository.
Also, HFI recently published the findings of the 2009 UX Maturity Survey (http://www.humanfactors.com/UXMaturitySurvey.asp). Among tops challenges they list “A team that reinvents the wheel”.
All signs that the UX profession is moving from spotty and guru driven to institutionalized. Or at least there is a pattern here.

Luís Soares — Thu, 02 Jul 2009 14:57:23 GMT

Juan Lanus, it’s true that is hard to bear in mind all the patterns, but there are other determinant factors. The used media, the publicity given to the catalog, the provided examples (and counter-examples), the live code, the offered ways to search/start, etc. An example of a different way to start: instead of organizing your catalog through an organized pattern list – the solutions, you could organize them by problems – when the designer/developer is faced with a problem, he more easily matches it with another problems (listed in the catalog) rather than with the solutions. Example: instead of having the pattern “Input Feedback” under “Forms” one could have it under”, “Providing Feedback” (because the problem is to “how provide feedback”; the problem is not “forms”).

Luís Soares — Tue, 30 Jun 2009 17:44:35 GMT

More pattern sites:

http://quince.infragistics.com – web/desktop patterns, interesting as a navigation system for pattern catalog
http://ui-patterns.com/patterns – web patterns repository – fixed set of patterns
http://uipatternfactory.com – web patterns repository – patterns are being added frequently
http://interface.fh-potsdam.de/infodesignpatterns/pattern… – not for GUI design; it’s more for presentation of information

Juan Lanus — Tue, 30 Jun 2009 17:28:54 GMT

Hmm … a central repository … will I be able to upload my “deviation”? (Hi, San Ideos!)
I truly believe that my deviation is the actual thing, and that the version described there, that one is a deviation!
But I’m not against patterns as long as … nothing.
In my opinion the patterns should be local to a project, or a company. Company wide patterns foster the pursued normalized corporative look and feel. Project patterns are for product normalization.
Too much patterns are impossible to enforce because it’s difficult to remember the relationships between UI problems and solutions one has never used.
But there must be an authority regulating the application.
For example in a business application the authority has to stick a pattern to each data item, like “the address will be entered using pattern A4 and displayed like B5”.
Actually this happens at a more technical level it’s called “user controls” or something like that: a piece of software that exposes specified data and behavior.
In software architecture there are patterns, many of them, maybe hundreds. Our nifty chief architect, Pablo Graña, oversees dozens of projects here at Globant because this is an outsourcing company, and he recalls using less than a dozen. And he is really prone to canned, pretested, solutions.
He says that many patterns are being used unknowingly. Which is another view of what I say: one can not bear a whole patterns catalog in memory.
And finally, applying patterns kills the feeling of being creative, even if one knows it’s illusory.

Patrick Stapleton — Wed, 11 Nov 2009 18:35:06 GMT

I suppose this is where the central library shows its value. Assuming developers go back to the central reference rather than the deviation, this shift that you describe is less likely to occur.

San Ideos — Thu, 02 Jul 2009 17:49:14 GMT

Agree. Classification would improve usage.

Another widely observed reason for the wheel being reinvented every time is the case of the slight deviation.
Every need is unique and with every uniqueness, the pattern is re-interpreted and improvised to make it fit. The shift from deviant to non-compliant happens fast because every improvisation is seen as a work of greatness by the development team!