UI patterns

So I've come back quasi-full circle, finding myself thinking of Wx-enabled smart widgets based on the wftk (seriously, it's like it's 2002 again), and last night after the laptop was off, I scribbled down the following note:

Basic mail UI against repo. Define mail-like queues as a thing.

The first sentence is a UI pattern (basic mail reader, with groups, then messages, then a document view for the mail itself), and the second is the data pattern it presents to the user (the concept of a message queue, possibly with threads, certainly with some kind of topic grouping).

This kind of pattern-based "architectural" programming could and should be carried down to the lowest possible levels of programming. That's a semantic mode of conceptualizing software.

Anyway, so I looked up "UI patterns", thinking that would get me that Yahoo effort (YUI, already noted elsewhere on this blog) - but instead it turned up UI-patterns.com, a short-lived effort by Danish web developer Anders Toxboe, an attempt to develop a UI pattern gallery/database/article focus site that seems to have gone on for 2010 and 2011 and stopped. Plenty of spam in the comments sections, but otherwise a ghost town.  Too bad, because it's pretty much what I'd like to start from in this attempt to come up with a language of UI pattern design.

Some good grist for the mill, anyway.

Filed under UI design, patterns, and architectural patterns, because I suspect the UI design has to be based on some conceptualization of the data that would be reflected in the system architecture.

Patterns

Here's what I'm slowly realizing about how people use patterns (this iteration of this particular insight is due to an article on business patterns I ran across): "The pattern gets you part of the way to the final objective by starting you off from a tried-and-trusted place. It looks familiar, but it is not a solution in itself—it is an abstraction of the solution that you have to embellish to make it the solution that suits your needs."

Here's the insight, yet again: by using the pattern only to document the solution instead of including that description into the code structure itself, we're losing information at both ends.  First, the pattern's structuring of the code is lost once the code is written, and second, changes to the code are not reflected in the pattern, so a learning opportunity for the pattern base is lost.

The pattern is the semantic structure of the solution.  The solution can almost be seen as the syntactic expression of the pattern in this view.

Food for thought.

Dbpatterns.com

Dbpatterns.com is a neat gallery/forking site for database patterns - it seems a little thin (you don't seem to be able to download patterns in a machine-readable form, for example), but the site itself is on Github and the idea is groovy.

Take that and make it machine-readable in a schema description format that can be composed and used to output SQL and man, I love it.

One-man programming shops

Here's an interesting blog post bemoaning the fact that one guy can't really expect to have a service that is as refined as something a whole team has hammered out.  His example is notifications - people expect a notification workflow that is as perfectly refined as Facebook, and it's too jarring if something doesn't work quite perfectly, whether that's because it took too long to notify, or there was a notification flood when twenty people opened your link, or .. whatever.

I'm not sure I buy this.  I mean, sure, it's true that a good team can work out something to perfection.  But a good team can also come out with iOS 6 maps - having more people on something is no guarantee of success.

And Facebook has a billion users - you can survive fine on five hundred.  They're offering what they offer - but you're offering something new, or something niche, and your users know you're not Facebook.  They really won't mind the occasional rough edge.  Those that do are callow wastes of your time - who leaves a good service because the logo was three pixels too wide?  Nobody.  Seriously.

But, all that said, this is why Best Practices and architectural patterns exist.  For something as universal as notifications, there should be some reference standard workflow, and ways to talk about it.  Every now and again you see a really nice survey article about best practices in, say, password reminders or order workflow - this is the kind of thing I'd like to see more of.

PLEAC cross-language sample code site

Interesting effort - another Rosetta-Stone kind of programming language site taking all the example code from the Perl Cookbook (vintage 2001) and asking people to submit the equivalent in their language of choice.

This is another source of something along the lines of "transaction patterns", that is, higher-level "things to do" that are implemented in lower-level code.  A semantically oriented declarative language needs to be able to talk at that level.  Maybe instead of "transaction patterns" they should be called "action patterns" or something.  They're at a far lower level than architectural patterns.

Dark Patterns

A fun Wiki documenting user interface patterns whose purpose is to scam the user.  Slow as molasses, but good work.

JDC: keeping languages straight

The ever-thoughtful John Cook opines on keeping similar languages straight, and provides links to some multi-lingual cheat sheets he uses.  Filing under patterns again, although it's not really what other people mean when they use that word.

Reference applications

So here's kind of an interesting notion: a bounty for a JEE reference application [JEE] that could illustrate how the various JEE building blocks fit together.  (And keep an eye on that bounty site, too.)

Minimal apps are kind of a cool way of characterizing new technologies, so maybe it would be a good idea to take a look at a kind of menagerie of them.

Filing this under patterns, because an example program could be considered a pattern definition of a sort.

DBI recipes

Recipes like this list are another source of patterns and boilerplate.

Design patterns in JavaScript

Interesting (online) book on JavaScript design patterns.

GUI Architectures

This is an utterly fascinating article I simply haven't had the time to read yet, on GUI architectures. I like this kind of post-hoc analysis/unification/whatever kind of article.

Backbone patterns

Must be patterns week.

MapReduce patterns, algorithms, use cases

What it says on the tin.

Game development tip: capabilities instead of inheritance

Nice little insight: direct inheritance isn't always the right development pattern to use. It's illustrated in terms of game development, but it's a nice thing to keep in mind anyway.

Nice user feedback pattern

Connex.io has a tasty little feedback pattern: just ask somewhere prominent, "Are you happy with the way this works? (yes/no)". If the user clicks no, drop down a text area to ask why.

This is really a nice idea!

Patterns and boilerplate

A couple of old ones, and a couple of new ones. I really think patterns and boilerplate are a key component of the semantic approach, and for some reason they're cropping up in my daily reading today.

• Designing social interfaces - a Wiki with about 100 user interaction patterns; also a book.
• UI patterns - I'm pretty sure this has been linked from this blog before.
• Flask boilerplate
• Backbone.js boilerplate
• Pattern tap - these are more design elements, perhaps.
• Yahoo! design pattern library, of course
• Patternry open UI patterns

Gamification as cargo cult

But a lucrative one! [article]

Seriously: larger strategies like "Web 2.0" or "social" and now "gamification" are quite reasonable collections of patterns - but pattern without content, in this case motivational content, is an empty thing.

I need a term for "site strategy patterns" or something like that.

Steve Yegge: the Universal Design Pattern

I think I need to reread this just to summarize it, but he starts from Doug Hoftstadter and goes to prototype-based programming, I think, is a reasonable one-sentence overview.

UI pattern database

Food for thought.

Transaction patterns

From February on "Web app design":

Oh, wait: a mother lode of so-called "transaction patterns" used in a toolkit for building database administration sites. It is incredibly detailed. These transaction patterns, by the way, constitute a language for user-level interaction with Websites that is not restricted to the Web domain - they'll work just fine in the Wx context as well. So they should definitely be analyzed, but they can't just be relegated to WWW::Publisher. I'm not really sure where they should go. Probably a new domain. Database::Declarative? I just don't know!

It took me a few minutes to find this post just now, as I hadn't really marked it very effectively. Now I'm doing so. The concept of the transaction pattern is a good one.