Accidental Reuse – a Recurring Theme

Uncategorized Add comments

Compatibility only helps the user, and in sourcecode, the re-user.

I’ve noted before that making up a new format for anything poses a low chance of being compatible with anything, and that compatibility is accidental at best. Choosing any other format to be compatible with, to form some agreement, means that you already have compatibility with one other existing entity, meaning:

  • you can learn from the comments and notes about what that project’s architect discovered and learned
  • whatever is compatible with that entity maybe accidentally compatible with your product
  • generic upstream tools require much less work to adapt to your tool
  • compatibility with anything means you have designed with compatibility in mind, so you’re not so wedged into a colloquial hole as the next guy

The counter-point, by choosing your own way, no matter how much better you may think it is, you’re now responsible for evolving and supporting all the tools that are in your users’ toolbox. This means that if decide, for example, that Julian dates shall be used, you generate a gap between your project and all the tools that don’t yet support Julian dates. Even if you have no competition in the world, your users have these little obstacles that build up. Faced with a knock-off of your fantastic tool that poses no such obstacles, you’ll soon be replaced.

I like to get things done. Finish, and go home, or hack on something else.

There is the feeling of “I hate having to fix my tools before I can use them to get stuff done” that actually pushes me away from Microsoft — even before they “evolved” the Office suite to use a random new UI. Indeed, rather than Julian dates, that “Ribbon Menu” now makes OpenOffice more compatible with our learned skill at Microsoft Office than Microsoft is.

This “Ribbon Menu” breaks residual knowledge; in forcing users to accept this impact to productivity, what benefit is the Ribbon Menu giving to users? If you’re going to break with the pack, have a good reason other than “we’re going back to how it was done before 16-bit CPUs were invented”.

By changing your users to a better interaction that is used by some other app, you support that app, you consolidate the UI that should have been described from the start, and you gain compatibility. You might accidentally gain compatibility with a few tools that work on that other project or tool.

For these reasons, I would ask:

On a new project: what are you compatible with?

If the answer is “nothing” or “an old 8-bit format” or “the dead language of spoken latin”, rethink your decision, if you ever considered the possibility of compatibility, to marching to the common drummer of the blizzard of possible standards.

On an existing project: are you going to turn down anything that consolidates user experience or formats?

Keep in mind, the next question could be “what will you do next year, when your competition appears, and has compatibility?”

Leave a Reply

WP Theme & Icons by N.Design Studio
Entries RSS Comments RSS Log in