Go home

HIG doesn't necessarily require the H

This first part is fluff that allows me to "derive from scratch" an important realization - so I've kept it as terse as possible:

Programming physically separates interface and implementation. Too much in one way results in too much context to keep hold of, too much in the other results in complete ignorance. The centre, then, lies in an interface that, in the immortal words of the Apple HIG, reflect the user's mental model.

Wahey! This fits in perfectly - programmers know this as the law of least surprise! Let's see what else we can map from the "core principles" in the HIG to something like The Pragmatic Programmer.

Consistency

Consistency in the interface allows users to transfer their knowledge and skills from one application to another. Use the standard elements of the Aqua interface to ensure consistency within your application and to benefit from consistency across applications. Ask yourself the following questions when thinking about consistency in your product:

Managing Complexity in Your Software

The best approach to developing easy-to-use software is to keep the design as simple as possible. In other words, a simple design is a good design and the best tools are those that users are not even aware they are using. The more you can do to simplify the interface of your application for your users, the more likely it is that you will build a product that meets their needs and is enjoyable to use.

Oh god, yes! This ties in with actual simplicity to create orthogonality.

Modelessness

As much as possible, allow users to do whatever they want at all times. Avoid using modes that lock them into one operation and prevent them from working on anything else until that operation is completed.

Avoid state! I've had to omit many principles that depend on there being an actual interface, but it's clear that if I continued, we'd also have much luck with, perhaps, their Design Decisions or their Extending sections, for example, which also have their mappings onto implicit steps in the process of programming as well.

Why are so many user interface principles applicable to interface design as well? It's because the principles here reflect how we understand and intake new pieces of conceptual information - we like orthogonality in our tables, we get frustrated hunting down dependencies in articles. Programming interfaces and graphic interfaces, as interfaces, merely provide an abbreviated representation of actual "content" while still reflecting relationships between It is painful that we cannot formally unite the two words of UX and good programming practise together.

Go home