Choosing feet and inches favours the US audience; choosing metres and litres favours the rest of the world; making up your own confuses everyone.

This may seem like my “re-inventing” page, but it’s merely restatement of the same heuristics: I’m a big fan of cohesive development, design that takes the present/past environment into account, and looking to others to see how they may have solved a problem.

To emphasize, I look for things that:

  • acknowledge the environment, work with what’s already there (and discuss what flaws and limitations that highlights)
  • acknowledge the other entities in the space: similar technologies, cooperative technologies
  • acknowledge and discuss the existing solutions to discuss why they may be unsuitable, necessitating a new development respect the time and efficiency of others
  • accurately distribute labour: automation for automata, innovation for the “meatware” the users

If we’re leading-edge today, we’re have competition tomorrow: software won’t be alone forever in a new area. As well, we’ll never be alone on a user’s desktop: even if alone in that area, the users tend to involve other tools in their work.

Focusing a bit on the environment, and other entities in that space, so often we build software in a new space without any idea of what might come along later. It’s difficult to design for what will be there after we’ve blazed the trail.

Design can be done to be compatible. How?

  • Be compatible with one other tool
  • Where possible, format using existing standards and agreed patterns

Where possible, use existing standards: when creating a new tool to map compression of gases, or trends of herd-migration, or databae throughput as momentum trends, the design doesn’t need to invent a new unit to measure time, mass, velocity; the design doesn’t need a new language where English (or C++ ?) exists.

A new tool from great Britain could measure mass in Stone, but the rest of the world has no implicit understanding that Slugs and Stones are actually units of measure. By choosing standards such as SI Units (“the Metric System”) to enable use by many countries (outside the USA and two banana republics).

The current year in Thailand is 2552 — but having to convert to that every time hinders adoption by foreign users. By choosing an international formatting of time, date, and timezone, more countries can use existing formats already in-use by database tools to communicate with your tool rather than having to learn, for example, that your country uses DD^YY^MM as a date format rather than YY-MM-DD or MM/DD/YY. Rather than seeing “3/2/9”, the common “2009-10-27” is quickly understood, and users already have to convert to that in other tools.

“In Other Tools” — let’s see that again.

There are other tools out there that use various formats. Just because the newly-designed tool has a different general function (“database trends” rather than “herd-migration momentum patterns”), it can still work with other tools on the user’s desktop. By choosing a portable, compatible, international notation in data entries (“2009-09-21 06:21Z first light, herd is 2m/s nothbound heading 331.4 degrees”) the individual components (date, speed, bearing) can be plucked out by other tools of the markup can be determined.

In choosing units and formats, we do choose our audience: feet/inches/farenheit/3.8-litre-gallons implies a USA audience, whereas simply choosing a traditional 4.5-litre gallon can confuse USA users. Choosing neither blocks them both.

Simply choosing to be compatible with one tool shows awareness of other tools, and gains the possibility of your data being re-used in some form. It shows that your tool has chosen the standard that someone out there also uses, so you gain both the re-use of your users’ learning that other format (rather than your own new, radical, “better” one) and you show that you have indeed considered alternatives at some point.

“Playing well with other apps” starts with “playing well with one app”; after one, it’s much easier to expand to another format or unit or notation.