Closer To The Ideal

These are articles that I’ve often spoken of, and often copied the URLs to emails that I’ve sent to others, so I shall record them here, so in the future I shall only need to point people here.

The illusion of agreement:

“We should build a house!”

“Yes! A house!”

But what kind of house do they mean?

The interface as a spec: including stories inline:

Sometimes designing the static states takes more time, and doesn’t quite represent reality, as well as a brief note about how the functionality works. The key is to make this note in context — right next to the interface element its describing. The combination of real visuals and a brief contextual note shrink the chances of misunderstanding to near zero.

Designing an interface: from sketch to screen

The screen mostly followed the sketch, except for the controls in the upper right and the description field. That’s fine, because at step two those details Didn’t Matter. Coding the real thing, I found room for all three of those pieces in the top-right, and that worked better.

Thinking and sketching took me 10 minutes. Creating the real screen and updating the code can take two or three hours. That lopsided pattern, with short make-believe-time on the left and long build-time on the right, is always a good sign that you’re making progress. Ideas and paper are necessary, but they’re destined for the trash bin. So burn through them and focus on the good stuff.

The often interesting robert hoekman, jr:

Our Stories should be an experience rich site. It should offer an engaging environment that compels users to explore and connect emotionally to the storytellers. But it doesn’t offer this at all. Instead, it offers what looks like any other Google design. It’s plain, minimalist, and it’s focused entirely around the information and not the experience.

Google apparently thinks it has hit upon the secret formula to all successful websites - simple, minimalist designs that offer information in a concentrated form. In reality, this formula only works for certain classes of sites, of which the original Google website was the par exemplar. Google fails when it attempts to build a site that needs a philosophically different approach. As Hoekman explains:

 If Google’s goal here was to create emotional connections, they should definitely have considered something other than the business-as-usual, sterile design work that has become Google’s signature. Granted, some of the site’s pages are geared towards showing people how to conduct interviews for the site, and those pages are probably best left alone, but the main attraction here is an environment of storytelling, not another Google search results system.

…Design is meant to communicate content. With the right design, you can always meet your goals much more effectively. If you want emotional connections, design something that encourages them. If you want people to take action, design to encourage action. Don’t let your usual design style get in the way of doing something great.

Yet another example of bad web programming. I was researching the subject of cancer and followed a link on a government site that gets me to this page:

I think its fine to print debugging information to the screen when a website is under development, but on a live site, I think the error messages should try to be more helpful. Perhaps the error message can suggest the average speed it takes the site’s sysadmins to fix problems of this time. Or the error message can suggest that the visitor go get the page out of the Google cache. Even the cutesy error message that Stikipad used was more reassuring than this.

Taylor’s career was 30 years old when “management” became a recognized profession during the 1920s. Likewise, people have been software engineers for the last 50 years, but the field has been slow to coalesce the practices and disciplines that one associates with a profession. Jeff Atwood has a nice piece on the youth of computer science. My favorite part:

As in all programming, the idea is to notice when the same solution is appearing repeatedly in different contexts and to understand the commonalities. This is admirable and valuable. The problem with the “Design Patterns” movement is the use to which the patterns are put afterward: programmers are trained to identify and apply the patterns when possible. Instead, the patterns should be used as signposts to the failures of the programming language. As in all programming, the identification of commonalities should be followed by an abstraction step in which the common parts are merged into a single solution.

Multiple implementations of the same idea are almost always a mistake in programming. The correct place to implement a common solution to a recurring design problem is in the programming language, if that is possible.

The stance of the “Design Patterns” movement seems to be that it is somehow inevitable that programmers will need to implement Visitors, Abstract Factories, Decorators, and Façades. But these are no more inevitable than the need to implement Subroutine Calls or Object-Oriented Classes in the source language. These patterns should be seen as defects or missing features in Java and C++. The best response to identification of these patterns is to ask what defects in those languages cause the patterns to be necessary, and how the languages might provide better support for solving these kinds of problems.