Some days ago, I got a document from the company that I’m working for, stating a project’s technical guidelines for a client to be signed off. Most of the vocabulary was right, but sometimes wrongly used, as technological clichès. This mentioned document serves as a template for most projects, and I imagine that for a while it has not been revised in detail, as it seems to work, seems not to be broken.
It also happens with websites that features are not improved or redesigned because they seem to work fine. Even companies have the same approach, continuing to do things their way because it seems to work fine, it seems not to be broken.
And if it is not broken, why change it?
First, let’s think that perhaps what does not seem broken might be. We’re quite accustomed to see when something’s broken, but what if we cannot see it? Then we suppose it is OK. But there are new realms of broken that are not as obvious as cracks in the wall.
Same as with our health, perhaps a preemptive approach might help in those cases where, similarly, we take some doses of vitamin C to prevent a cold, as usually we cannot see we’re already infected, days before we can see we’re broken (ill).
Amongst the strategies we can follow, we could:
The one I use to approach my personal projects is the simplest and less rigorous, but has assured to me enough success and reliability: I assume that, after a certain time (that varies per issue) it has to be broken (or at least entering obsolescence). Many times it is, whether in language, content, semantics, usability, or just visually.
The web is a living entity, that evolves in time and every second has a new, different face. Being part of that world requires the amount of self-maintenance a living organ will need.
Check often, and you’ll see things will be less prone to break. Don’t wait until you revisit the site and get some broken image icons, or worse, the moment when your client tells you something is not expressed that way anymore. d’oh!