When you are solving a difficult problem re-ask the problem so that your solution helps you learn faster. Find a faster way to fail, recover, and try again. If the problem you are trying to solve involves creating a magnum opus, you are solving the wrong problem.

– Aza Raskin

For Quora, [design] means designing for whys (the product) and taking the most straightforward route possible for the hows (the interactions).

The hows are then driven by the answers to the whys—after all, why a user must enter a flow dictates how they progress through it.

The enabling features aren’t obvious and evident, because the key was getting rid of stuff.

– Jonathan Ive, on designing the iPod [Wired]

For example, what constitutes a wrong is an element or a motif that does not add to the cohesiveness of the communication. I have a hard time departing from an established visual language. If a link is blue, it makes sense for all links to be blue. If the color yellow is used to express “you are here”, it dilutes the communication to use it in another fashion. (This is an over-simplification and you can lean on things like context and established convention to bend the rules, but the concept remains).

In other words, what I’ve been doing is reducing design components to their atomic unit, attaching meaning to them, and using these basic building blocks to define the visual language.

However, what I consider good design is usually a bit more textured than the above methodology can justify. A better model for evaluating design is propositional density, which I’ll let Moritz Stefaner describe using the Fed Ex logo as an example:

Let us start with the notion of a proposition: in this context, a proposition is simply an elementary, atomic statement about the object at hand. “The FedEx logotype is purple” and “The FedEx logotype is set in a sans-serif font” are propositions, and because they describe salient, perceptible properties of the design, they are referred to as surface propositions.

Now, the FedEx logo became famous for a perceptual trick: The white space between the E and the x creates an arrow. This arrow induces, by its semiotic reading, a number of additional associations and readings of the design: “FedEx is on the go”, “FedEx is forward-thinking”, etc. Note that these propositions, unlike the surface propositions, are much harder to enumerate as they depend on the meaning that the observer ascribes to the arrow. These are called deep propositions as they describe underlying and often hidden meanings of the design. You can think of an iceberg, where the surface propositions are over the water – easy to see and clear cut – but the much larger part is under water.

These two concepts can be combined into a simple formula to calculate propositional density: # deep propositions / # surface propositions.

Generally speaking, good design usually has a high propositional density. On the other hand, if your propositional density is below one, you probably have superfluous, merely decorative elements in your design, which do not add to the deep reading.

Attempting to calculate this is neither practical or precise, but the recognition of deep propositions allows us to escape a rigorous system like the one I described and dabble in design elements that I would otherwise discard as decoration.

These monome devices, described as “adaptable, minimalist interfaces”, let you hack a grid of lights. The extreme design reduction liberates the device’s perceived potential. Adding any extra features to the device would be like replacing a blank canvas with a coloring book. The device is built by two people from the future, brian crabtree and kelli cain, where capitalization has long been regarded as superfluous decoration.

Moreover, an API is not about programming, data structures, or algorithms—an API is a user interface, just as much as a GUI. The user at the using end of the API is a programmer—that is, a human being.

– Michi Henning, API Design Matters

[via Jwatt]

That technology is Ryan Dahl’s Node. It’s the most exciting new project I’ve come across in quite a while.

At first glance, Node looks like yet another take on the idea of server-side JavaScript, but it’s a lot more interesting than that. It builds on JavaScript’s excellent support for event-based programming and uses it to create something that truly plays to the strengths of the language.